This page is about ONAP modeling design principles and guidelines for release 2+
Guidelines:
1-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.
Lingli Deng I agree the scope for the entire modeling stack is too broad for us to work with within Release 2 time frame. I recalled that we agreed on starting with SERVICE and RESOURCE modeling for Beijing earlier. So I suggest we could consider rephrase it as "Initial focus on a Unified IM and TOSCA construct representation on Service and Resource".
2-Align terminology with ETSI (IFA11, IFA14) where appropriate
-Mapping needed between equivalent terms, identify the differences
-Based on use cases, select the appropriate model
3-Identify all the types/constructs we need
[Munish Agarwal] 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.
- Lingli Deng Scaling is an appealing feature to have with Bejing. But I do not believe the modeling subcommittee should be the place to define feature requirements. Instead, we should take funtional/non-functional requirements input from other forums, such as Usecase subcommittee, etc., and identify the indicated modeling gaps to fulfill those requirements as our target.
4-Initial round should be based on SDC DM and OpenECOMP
([Munish Agarwal] Not relevant in the guidelines section. Consider moving to Principles) Thinh Nguyenphu (Unlicensed): agreed with the comment
Lingli Deng It seems that we do need to clearly state what we mean respectively by "Principles" and "Guidelines". IMHO, Principles are the facts/targets we agree to behold, while Guidelines specifies in high level step-by-step how we work together to ensure those principles while achieving the target. If we could agree on the above differentiation, I suppose this statement seems more relevant to Guidelines rather than Principles.
-Identify existing construct defined in SOL001 and TOSCA NFV Profile
-Propose new constructs to TOSCA NFV profile when desired types are not defined ([Munish Agarwal] 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
Lingli Deng: Good suggestion. We should encourage mutual contribution between this community and SDOs or other OS communities as always. But the suggested efforst, although welcome and encouraged, is not committed to this specific group, nor is the target or constraint to the practice of this specific group. Hence, I suggest removal of the entirety of this statement.
Munish Agarwal] Identify DM for VNFD based on the SDC DM, eCOMP IM and NFV SOL001 (IFA011)
Lingli Deng This statement is duplicating the guideline Item #4.
Munish Agarwal] Identify DM for NSD based on the eCOMP IM and NFV SOL001 (IFA014)
Lingli Deng This statement is duplicating the guideline Item #4.
•Try to maintain backward compatibility
Munish Agarwal] The APIs should be backward compatible.
Munish Agarwal] Backward compatibility guidelines on API need to be defined.
Lingli Deng API is not in the scope for this group, I suppose.
Munish Agarwal] Define UML modelling guidelines. Take inspiration from IISOMI 514 UML Modeling Guidelines
Lingli Deng UML is another Data Modeling language, it is not clear to me what would be the benefits of introducing another DM to represent the IM, or whether or not it would introduce undesirable constraints in defining the IM. Since it is not an urgent decision, I suggest we could leave the choice/recommendation on using it and its tools out of the current document and for further discussion.
•Create a (class) diagram which outlines ONAP DM relationship to TOSCA Simple Profile 1.2 ( Munish Agarwal] Not clear. Consider rephrase)
-Follow the principals define in next slide
•Validate the model using the selected use cases
•Tools: Papyrus
Munish Agarwal] IM Language: UML
Lingli Deng UML is another Data Modeling language, it is not clear to me what would be the benefits of introducing another DM to represent the IM, or whether or not it would introduce undesirable constraints in defining the IM. Since it is not an urgent decision, I suggest we could leave the choice/recommendation on using it and its tools out of the current document and for further discussion.
Munish Agarwal] Evaluate the EAGLE work done in MEF to generate APIs from the Models
Lingli Deng API is not in the scope for this group, I suppose.
Principles:
•New constructs
-Best effort to use TOSCA Simple Profile 1.2 “normatives”
-Extend/Derive from Simple Profile 1.2 “normatives”s (Munish Agarwal] 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
...
Munish Agarwal] There should be a clear distrinction between the IM (Information Model) and DM (Data Model)
-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
...