Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

This page is about ONAP modeling design principles and guidelines for release 2+

Guidelines:

• Initial focus on a Unified IM and TOSCA construct representation

[Thinh Nguyenphu (Unlicensed)] what is Unified IM? currently, my understanding from there are many projects using different part of one ore models. Or, are we trying to bring Service CSAR, NS CSAR, VNF CSAR, WAN API, Cont/WAN  into a Unified IM? 

Thinh Nguyenphu (Unlicensed)] Also, this bullet point should be separate into two bullets for additional clarifications. for example, SO and SDN-C: WAN API is using TOSCA Rel1 and 2? Or we should clearly states: VNF descriptor, NS descriptor, and CSAR package (VNF package and NS/service Package) as initial focus.

• Align terminology with ETSI (IFA11, IFA14) where appropriate
   -Mapping needed between equivalent terms, identify the differences
   -Based on use cases, select the appropriate model

•Identify all the types/constructs we need

  • Identify GAPs  and prioritize per release

  • Thinh Nguyenphu (Unlicensed)] beside gaps and priority, the guideline should identify supporting features. For example, scaling feature can a simple scaling to a more complex scale such as aspect scaling to scaling to a specific level, etc. A similar different to deployment flavour too. Describing use case is important.

   -Initial round should be based on SDC DM and OpenECOMP (Not relevant in the guidelines section. Consider moving to Principles)  Thinh Nguyenphu (Unlicensed): agreed with the comment


  -Identify existing construct defined in SOL001 and TOSCA NFV Profile

  -Propose new constructs to TOSCA NFV profile when desired types are not defined (It would be good to define extensions to SOL001. VNF vendors will provide TOSCA VNFD compliant to SOL001. The new constructs in ONAP can be proposed in ETSI SOL001). Thinh Nguyenphu (Unlicensed): agreed with the comment


•Try to maintain backward compatibility

•Create a (class) diagram which outlines ONAP DM relationship to TOSCA Simple Profile 1.2 (Not clear. Consider rephrase)
   -Follow the principals define in next slide

•Validate the model using the selected use cases

•Tools: Papyrus

  • IM Language: UML


 Principles:

•New constructs
   -Best effort to use TOSCA Simple Profile 1.2 “normatives”
   -Extend/Derive from Simple Profile 1.2 “normatives”s (Using simple profile 1.2 as basis and define new constructs taking in consideration both SOL001 and TOSCA NFV profile is the proposed way forward. Is that the correct understanding. Please clarify in either case)


   -Derive directly from tosca.nodes.root
   -DM does not need to match exactly the IM; DM can represent the IM
   -DM are pruned and refactored from IM
   -Discuss extensibility guidelines to be progressed

•Properties
   -Best effort to put properties on capabilities (Not clear. Consider rephrase to clarify)

•Namespace
  -TBD

  • Thinh Nguyenphu (Unlicensed)] In order to avoid namespaces and types name types definitions collision, it is recommended that ONAP uses the rule and guidelines as described in the OASIS TOSCA Simple YAML Profile v1.2. At minimum, ONAP describes:
    • Namespace Alias: TBD
    • Namespace Prefix: TBD
    • tosca_definitions_version:TBD
    • ONAP's types: naming convention and format


  • No labels