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

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

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

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

Resource and Service artifacts, DM 2017-10-30 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

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

ONF: Modeling alignment need across SDOs Cross SDO Modeling ONF: Modeling alignment need across SDOs 2017-11-28 -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

SDOs Modeling alignment Cross SDO Modeling 2017-11-28 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

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

Cross SDO Modeling 2017-11-28 IISOMI Guidelines © Ericsson AB 2017

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 [https://github.com/OpenNetworkingFoundation/EAGLE-Open-Model-Profile-and-Tools) Yang  Swagger JSON/RestConf Generation Tool is already available https://github.com/OpenNetworkingFoundation/EAGLE-Open-Model-Profile-and-Tools/tree/ToolChain/UmlYangTools Others like UML  JSON, UML  Swagger, UML  TOSCA being discussed

Model Driven API: MEF 17 Experience

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)

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)

Model Driven - ETSI MANO experience

ETSI Information model and specifications 2017-12-03 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

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

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

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

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

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

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

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