1. Open Source and Info Models 17 Dec 2015 Bryan Sullivan, AT&T

2. Background OPNFV integrates upstream projects into a coherent platform for NFV, starting from the infrastructure layer and moving up the management stack OPNFV does not have an information model nor plans to establish one –Relies on existing running code and data models from OpenStack, ODL, etc OPNFV relies upon upstream open source projects / components which –Expose/consume data via open APIs and specific adapters/translators => flexible –Have implicit models, but not maintained in formal modeling language –Are intended to have limited scope, yet sometimes compete, and evolve toward cleaner boundaries and model convergence over several releases Jan 20162ETSI NFV Inter-SDO Information Modeling Workshop

3. Model-Driven Frameworks in Standards and Open Source Model-driven frameworks are preferred as an architectural approach –Standards based information models are used by open source projects when they meet needs for model-driven management frameworks, e.g. are focused and well- defined Various model representations will likely have a role for specific areas –YANG: the model representation for netconf-based network config mgmt in ODL –TOSCA: a model representation for cloud services, being applied to NFV –In various cases these may require to/from JSON or YAML for use in specific interfaces / REST APIs But… Developers find the path of least resistance and will reuse anything that makes sense to minimize reinventing the wheel Jan 20163ETSI NFV Inter-SDO Information Modeling Workshop

4. Example: Lineage of standards adoption for TOSCA Jan 20164ETSI NFV Inter-SDO Information Modeling Workshop 2013 - OASIS TOSCA - Focused on describing cloud services - Large participation from cloud players 2014 – ETSI NFV ISG MANO Non Normative specification for management and orchestration for NFV 2015 - TOSCA For NFV Profile Based on the MANO VNF Descriptor Evolving 2015 – NFV IFA Several normative interface specs re Management and Orchestration, and NFV Information Modeling TACKER (Generic VNF Manager for OpenStack) Note: example only; OPNFV has not yet selected/integrated VNFM solutions TACKER (Generic VNF Manager for OpenStack) Note: example only; OPNFV has not yet selected/integrated VNFM solutions Implementation feedback to published and in-progress specs (a goal…) One example of how open source projects pick up draft specs, implement them and (can) provide feedback implementation experience to SDOs, as specs are developed or afterward

5. OPNFV Information Model Needs Rapidly developed, cross-SDO aligned data models –OPNFV is bottom-up, implementation-focused, builds on what is available and fills gaps as needed. R1 (Arno) focused on VIM/NFVI, but OPNFV is expanding to VIM-NBI-using functions e.g. the conceptual VNFM and NFVO. Upstream projects are moving quickly per draft specs for those functions, e.g. VNFM and TOSCA. SDOs should expect gaps to be filled quickly. Thus quick and cross-SDOs aligned progress is required to help ensure that the first generation of NFV platforms leverage standardized information models. Ability to map NFV concepts, entities, relationships to existing APIs and models in upstream projects –Defacto upstream models may need some “reverse engineering”, e.g. to enable alignment with SDO info models Focus first on functions of lower layer management stack entities, e.g. VIM and VNFM, then work up the stack and across the VNF/service lifecycle –Open source collaborative energy flows from the bottom up, and for NFV is currently centered around provisioning and management of applications and their resources Early access and input into the development of industry specifications –As far as possible, all SDOs should make drafts publicly accessible –SDOs and open source projects e.g. OPNFV should share info and feedback through collaboration tools, e.g. JIRA Jan 20165ETSI NFV Inter-SDO Information Modeling Workshop

6. Conclusions CATALYST - OPNFV can be the catalyst for industry adoption of standards based specifications and models if and where they are aligned with the open source implementations REALITY - SDOs need to account for “de facto” standards both in architecture and in information modeling TIME - Timely publishing and broad accessibility facilitates alignment – We can’t wait years for a spec to be completed only to realize that it is off from the implementations. MODULARITY – Publish modules that enable projects to get started soon, without dependency upon a large information model Jan 20166ETSI NFV Inter-SDO Information Modeling Workshop

7. We look forward to collaborating with you! Jan 20167 Platforms Standards Customer Motivation Choice Realization Services Services motivate development of platforms and standards Standards provide choice and scalability in platforms and services Platforms are how services are realized and standards validated Open Source