1. Consideration of Modeling Evolution in ONAP Michela Bevilacqua Peter Wörndle and Tara Cummings
13 December , 2017

2. Contents Model Landscape Information Model(s) in ONAP and in SDOs
Model Driven API
Model Driven API: MEF experience
Model Driven API: ETSI MANO
ONAP Modeling Evolution Priorities

3. ONAP: a model driven platform for automation
Service Providers aim to reduce service delivery time, automate resource/service lifecycle management, enable zero-touch.
Model driven implies a number of things
from modelling the resources and services under the control of ONAP.
via the modelling of the interfaces between the components that comprise ONAP  
through to modelling “directives” that control all life-cycle aspects so as to enable zero-touch, fully automated operations.
Models are used to describe resources, service, products, the relationships and actions (processes, policy, operations) on these

4. Model Driven Approach
ONAP is not the only industry effort working with model based approaches, others are as well.
Models defined at design time can then be executed at run time
Models used to communicate functional capabilities for any architecture
Using models as the start of a toolchain to generate meta-data and/or working code is referred to as model-driven
What a model driven approach means for ONAP and how that relates to other industry initiatives

5. Resource and Service artifacts, DM
Policy rules
BPMN flows
Model Driven API DM
Analytic rules
VNFD
Resource and Service artifacts, DM
Model Driven API
flows
TOSCA descriptors
Closed Loop directives

6. Model Landscape in ONAP and alignment needs
Model Landscape is already extensive in ONAP
Alignment needs… in ONAP
Common Information Model
Integrated and Consistent Management of the Models in ONAP
A service is not only a TOSCA descriptor for the deployment but need to address all the directives to control service operations across several ONAP components and even architectural boundaries
… around ONAP
Models traditionally provided by SDOs and open-source have been un-coordinated, creating near impossible integration scenarios
How ONAP can address this challenge?
Engage in SDO alignment
Address Interoperability: API key role in ONAP, Internal/external SDO touchpoints

7. ONF: Modeling alignment need across SDOs
Cross SDO Modeling
ONF: Modeling alignment need across SDOs
-this slide has been used in other presentations to primarily highlight the need for collaboration and modeling alignment between SDOs/open source.  It does show a proposed path forward, but it doesn’t highlight the complexities for the proposed path to be a true reality.  For example, the ETSI IFA-15 or IFA-24 claims alignment with ONF…however, the ETSI team modified the ONF model to fit it into the ETSI view.  It’s quite useless as is, but great propaganda and hopefully the claims will help generate momentum that will result in true alignment.  I think the MEF approached things right with the NRM model, they based their work on the ONF models and collaborated with ONF when issues were found or when fixes were needed.     
© Ericsson AB 2017

8. SDOs Modeling alignment
Cross SDO Modeling
SDOs Modeling alignment
ONF, MEF, TMF, ETSI-NFV, OASIS-TOSCA, and ITU-T have partnered to collaborate and define a common model-driven approach that advances interoperability
Open Information Modeling and Tooling led by IISOMI
More groups are joining the discussions…IETF, IEEE, OIF
© Ericsson AB 2017

9. Tool Chain √ UML YANG JSON Documentation xxx.uml UML  YANG Mapping
YANG  JSON Mapping
YANG
xxx.yang
JSON
xxx.json √
different
Swagger JSON API
xored YANG Viewer
Validation
Tree

10. Cross SDO Modeling
IISOMI Guidelines
© Ericsson AB 2017

11. IISOMI Model Driven API Methodology
Models in UML with supporting documentation tool
ONF TR 512: Core Information Model, ONF TR 513: Common Information Model
Guidelines that promote normalized use of UML, shared tooling use and tool driven standardized language mappings
ONF TR 514: UML Modeling Guidelines, ONF TR 515: Papyrus Guidelines [maintained by IISOMI)
Tooling software that converts an appropriate UML model into an interface schema such as Yang, JSON
ONF TR 531: UML to YANG Mapping Guidelines [maintained by IISOMI)
IISOMI EAGLE-Open-Model-Profile-and-Tools [
Yang  Swagger JSON/RestConf Generation Tool is already available
Others like UML  JSON, UML  Swagger, UML  TOSCA being discussed

12. Model Driven API: MEF 17 Experience

13. MEF 17 – LSO SOF TE PoC
SOF-TE PoC demonstrates a working implementation of SOF sub-functional components and interface points defined by LSO in order to provide SOF with topology information.
SOF-TE demonstrates open software microservices of a number of SOF-sub components.
SOF sub-function Composer can leverage SOF-TE topology for cross-vendor SDN path computation. It can also be leveraged for service chaining in a hybrid network of SDN, NFV and legacy networks.
SOF-TE PoC includes:
Implementation of PRESTO to extract and “stitch” ICM layer topology into a Graph database.
Visualization of topology and connectivity services.
Alignment of MEF with ONF TAPI model.
Open source code developed in Python.
LSO Service Orchestration Functionality Topology Engine (SOF-TE)

14. MEF 17 LSO SOF-Te PoC: Focus on Model prospective
Design First Approach for APIs
Model -> Swagger (Eagle tool generated)
Topology model defined in UML
Topology model defined in Swagger Specification
TAPI open source tools to convert UML -> YANG -> swagger
Swagger tools used for API codegen
Swagger generated server and client templates, as well as test cases
Implementation of swagger generated templates.
MEF and TAPI model alignment
LSO Service Orchestration Functionality Topology Engine (SOF-TE)

15. Model Driven - ETSI MANO experience

16. ETSI Information model and specifications
ETSI Information model and specifications
Update IFA requirements to improve Interface implementation details
Other Organizations
Update model based on agreed interface changes
TOSCA
SOL xx Interface & Descriptor Specifications
IFA xx Interface & Descriptor Requirements
IFA 015 Information Model
IFA 024 IM Touchpoints
UML
OpenAPI
API and Descriptor specifications follow the IFA requirements
UML
Overall interface consistency checks across different reference points and documents

17. Experiences from the ETSI modeling approach
IM is a good tool to check consistency across paper specifications
IM is a good tool to create formal relationships also with technical work in other communities
Lose coupling between Stage 3 specifications, interface requirements and IM requires significant coordination efforts
Only few people contribute to the model as the model is not a mandatory part of the process, i.e. interface changes can be driven without a model update
Minor divergences and risk for additional divergence between the deliverables

18. ONAP Modeling Evolution Priorities
Key Take Away
Common Information Model
Integrated and Consistent Management of the Models
Engagement in the SDO alignment: Interoperability
Model driven Tools

19. ONAP Modeling Evolution Priorities
Key Take Away
Common Information Model
Terminology
UML version of the CIM, CIM repo
WoW for :
CIM evolution:
input provided by different ONAP components, architecture team or others,
unique CIM backlog in a agile way.
CIM mapping to DMs in ONAP and retro-feedbacks

20. ONAP Modeling Evolution Priorities
Key Take Away
Common Information Model
Integrated and Consistent Management of the Models
Engagement in the SDO alignment: Interoperability
Model driven Tools

21. ONAP Modeling Evolution Priorities
Key Take Away
Common Information Model
Integrated and Consistent Management of the Models
Engagement in the SDO alignment: Interoperability
Define the touchpoints per SDO
External API Interoperability
Internal API interoperability, starting with standard touchpoints
Model driven Tools

22. ONAP Modeling Evolution Priorities
Key Take Away
Common Information Model
Integrated and Consistent Management of the Models
Engagement in the SDO alignment: Interoperability
Model driven Tools
Improve TOSCA guidelines
Monitor and collaborate with industry initiatives about tool chains

23. ONAP Modeling Evolution Priorities
Key Take Away
Common Information Model
Integrated and Consistent Management of the Models
Engagement in the SDO alignment: Interoperability
Model driven Tools