/
Discussion page 20171015 for ONAP Modeling Design Principles and Guidelines

Discussion page 20171015 for ONAP Modeling Design Principles and Guidelines

Owned by Hui Deng
Last updated: Feb 02, 2018 by Brian Hedstrom
6 min read

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

Refer to ONAP Modeling Design Principles and Guidelines (20171023) for approved working version of the modeling principles and guidelines.



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".

@Andy Mayer:



  • Initial focus of Information Model will capture Service Desc, VNF Desc models

  • First doing an Information Model and then do a TOSCA representation based on the Information Model applying OASIS TOSCA Simple Profile 1.2

  • The model will support the VNF requirements (e.g. scaling). The modeling team should not define the feature requirements, but rather Information Model support for defined requirements.

  • Principles focus on the "what"

  • Guidelines are best practices and focus on the "how" 



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 th