Open Source and Info Models 17 Dec 2015

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

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 Open. Stack, 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 2016 ETSI NFV Inter-SDO Information Modeling Workshop 2

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 welldefined • 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 2016 ETSI NFV Inter-SDO Information Modeling Workshop 3

Example: Lineage of standards adoption for TOSCA 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 2013 - OASIS TOSCA 2014 – ETSI NFV ISG MANO - Focused on 2015 - TOSCA For NFV Profile describing cloud Non Normative services 2015 – NFV IFA specification for - Large management and participation from orchestration for cloud players NFV Based on the MANO VNF Descriptor Evolving Several normative interface specs re Management and Orchestration, and NFV Information Modeling TACKER (Generic VNF Manager for Open. Stack) Note: example only; OPNFV has not yet selected/integrated VNFM solutions Implementation feedback to published and in-progress specs (a goal…) Jan 2016 ETSI NFV Inter-SDO Information Modeling Workshop 4

OPNFV Information Model Needs • Rapidly developed, cross-SDO aligned data 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 – • OPNFV is bottom-up, implementation-focused, builds on what is available and fills gaps as needed. R 1 (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. 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 – – Jan 2016 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 ETSI NFV Inter-SDO Information Modeling Workshop 5

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 2016 ETSI NFV Inter-SDO Information Modeling Workshop 6

Services motivate development of platforms and standards We look forward to collaborating with you! Services ion zat ali Re Open Source Platforms are how services are realized and standards validated Jan 2016 Cho Customer ice Motivation Standards provide choice and scalability in platforms and services 7