OPEN-O Architecture Comments

Slides:



Advertisements
Similar presentations
Introducing Open Platform for NFV Please direct any questions or comments to 1.
Advertisements

Zhipeng (Howard) Huang
Introducing Open Platform for NFV Please direct any questions or comments to 1.
1 Adopting and Embracing Open Source for NFV Guy Shemesh Senior Director for Cloud Solutions, CloudBand October 2015.
Open Source and Info Models 17 Dec 2015 Bryan Sullivan, AT&T.
OPEN-O for MODM Unified NFV/SDN Open Source Orchestrator
OPEN-O Approach 1, 2, 3 and 1.5 Discussion in Beijing.
Open-O GS-O Project Proposal
SDN-O LCM for Mercury Release Key Points and Overview
Open-O SFC.Mgr Proposal
ARC: Definitions and requirements for SO/APP-C/VF-C discussion including call notes Chris Donley July 5, 2017.
Bryan Sullivan, AT&T June 13, 2017
ONAP and MEF LSO External API Framework Functional Reference Architecture 12 July 2017 Andy Mayer, Ph.D. © 2016 AT&T Intellectual Property. All rights.
Rationalizing ONAP Architecture for R2 and Beyond Vimal Begwani – AT&T
ONAP layering/MEF alignment
Defining ONAP APIs With BSS/OSS
ONAP Architecture Meeting 8/8
Open-O Client Project Proposal
Orchestration and Controller Alignment for ONAP Release 1
ONAP Architecture Slides Current Plan of Record
Open-O Client Project Proposal
OPEN-O Project Proposal Training
Aligning Orchestration and Controller Per Merger Agreement Vimal Begwani – AT&T Jamil Chawki – Orange Alla Goldner -- Amdocs.
OPEN-O Modeling Directions (DRAFT 0.6)
Defining ONAP VNF Package Model
Tina Tsou, Bryan Sullivan,
Aligning Orchestration and Controller Per Merger Agreement Vimal Begwani – AT&T Jamil Chawki – Orange Alla Goldner -- Amdocs.
OPEN-O GS-O Planning Mercury Release
Workshop Discussion on Day-2
ETSI NFV: IFA & SOL specifications list
OPEN-O Multiple VIM Driver Project Use Cases
ONAP Interface to External Controllers
ARC: Definitions and requirements for SO/APP-C/VF-C discussion Chris Donley Date , 2017.
ONAP Architecture Meeting 8/8
OPEN-O Modeling Directions (DRAFT 0)
ARC 5: Deployment Options Chris Donley
ONAP Integration Through Information and Data Modeling
MEF LSO Legato SDK 24 October 2017 Andy Mayer, Ph.D. Tara Cummings.
Introduction to OPNFV CVP
Dovetail project update
ONAP Usecase subcommittee July Virtual developers event
ONAP Integration to External Domain Management Systems (DMS)
17 Dec 2015 Bryan Sullivan, AT&T
ETSI NSD Overview & TOSCA model Thinh Nguyenphu, Nokia thinh
Open-O Client Project Proposal
Approach to finalize the TOSCA NFV profile
ONAP – Centralised Parser Distribution Atul Purohit - Vodafone
OPEN-O Nanjing Workshop
Agenda Where we are (Amsterdam Architecture)
ONAP APIs Andrew Mayer, AT&T
ONAP Amsterdam Architecture
Consideration of Modeling Evolution in ONAP Michela Bevilacqua Peter Wörndle and Tara Cummings 13 December , 2017.
Christopher Donley Prakash Ramchandran Ulas Kozat
Isasku, Srini, Alex, Ramki, Seshu, Bin Hu, Munish, Gil, Victor
OSM Workshop SDN World Congress Oct’16
Documenting ONAP components (functional)
State of OPNFV MANO OPNFV MANO WG Report
ETSI Multi-access Edge Computing:
A 5G experimental environment focused on vertical applications
ONAP Beijing Architecture Chris Donley 1/9/18
Proposed Software Development Process
Defining ONAP VNF Package Model
An Introduction to Software Architecture
ARC Alignment ExtAPI ExtAPI Team.
Applying Use Cases (Chapters 25,26)
Open Source MANO (OSM) develop an Open Source MANO software stack aligned with ETSI NFV ISG
Open Source Projects Collaborations with ONAP
Reinhard Scholl, GTSC-7 Chairman
GNFC Architecture and Interfaces
ONAP Architecture Principle Review
Presentation transcript:

OPEN-O Architecture Comments August 30th, 2016

Architecture Decision June 2016 D1. TSC agrees that as part of each project final approval, we may go back to re-adjust its scope or other design elements, where necessary, as necessary based on the proposed overall architecture (after it is approved) and/or due to emerging new understanding of other projects D2. The architecture committee (ARC) will create a proposed long term architecture and release specific. D2a. Will include reference to out of scope elements e.g. OSS, BSS and discussion about migration D3. The ARC will create “problem being solved” material for the project comprising of the different sub problems each project is solving. The individual projects may have to adjust theirs to reflect the specific subset addressed by their project only

Architecture Review Topics Key structural issues – Design for scale, flexibility, pluggable arch, API stability, ETSI compliance (updates), Service Orchestration and Resource Orchestration, external API and DM, Catalog, Actors, VIM and Controllers interfaces: sVNFM  gVNFM, SDN Controllers diversity, SFC std?, Security model, RBAC, … S3P – Stability, Scalability Security and Performance Key functionality – ensuring consistent parsing TOSCA  WSO2, GS-O role (external API), SDN-O to OpenStack interaction, EPA/KPI support, Infrastructure efficiency goals, catalog, VNF on-boarding SDK and functionality, interoperability goals Licensing strategy Closed code usage Open arch from Beijing Network side – black box to GS-O? OpenStack/ODL side – multi Writer?? Forum for TOSCA and ETSI extensions proposals

The Value of Architectural review The question on the table is do we really think we need an architecture review prior to Release 1, or not? Assuming schedule is top priority and views that architecture discussion is slowing the community down, we may simply update the Release1 goals to be A point in time code release Not targeting common pluggable and modular architecture No intending to conduct an architectural review per D1 However, it will mean more work for Release2

Suggested focus for this meeting Review of Open-O life cycle and inter-project interaction per use case Epics – bring up, on-boarding, network connectivity, intra-VIM, SDN controller interaction Epics / User Stories / Actors supported Flow diagram walk through For each project identify… Micro-services being provided External APIs and managed objects being exposed Deployment considerations/requirements Database requirements Deployment/operational footprint requirements

Required Decisions Remove Architectural review from Release1 M3 milestone Officially agree on canonized TOSCA YAML over YANG model API external, internal Ability to add a new project/micro service later (potentially as experimental or late in the cycle) if it doesn’t negatively affect schedule or adds significant risk

Release 2 definition/ design Assume this will not start before …. RC2? Actual release in November? A TSC meeting FtF is to be planned

Proposed Open-o SDO interaction model Embrace and extend, in a fashion where it is plausible to get adopted Open-O  SDO-x    Software IM’ IM Text, Block Diagrams Interoperable NB, SB and VNF  DM/API DM/API Open Source Architecture SDO Architecture framework SDO driven IM. Innovation welcome (IM’), but eventual SDO approval required DSL like TOSCA and YANG included Open-O and SDO exchange architecture inputs, IM contribution/direction and IM/API when relevant DM goal is broad industry interoperability Architectural framework generally takes after SDO but not standardized Timelines are decoupled. Open-O will provide timely feedback to SDO TSC to discuss relevant SDO and proposed interaction model

Thank You www.open-o.org

O2. ARC: What aspects / portions of the Orchestration of NS, NFV and SDN are supported by O-Common, NFV-O, SDN-O and GS-O? O7. ARC: define role of GUI provided by GS-O, O-Common NFVO and SDNO O15. ARC –What is the strategy for supporting commercial only or upstreamed code? O18. ARC –propose a common API style for NBI and SBI for Open-O O25. ARC – what is the long term plan for SDN-O integration? Keep as separate? Expose its NBI directly? SDN-O GUI exposed to the User? O26.ARC – define RBAC and resource controlled in each access right level O35. ARC - propose a solution for inter entity network connectivity. Explore the tradeoff between direct VNF-O and SDN-O or going back to GS-O (see points above on GS-O assumed role). O40. ARC, LD – each project has to define S3P and documentation support. For S3P, each project needs to define perf parameters/goals e.g. time to setup a VNF in the VIM, time to setup an e2e through SDN-O linear w number of hops, etc.

2) O-Common (v 0.3) - Arthur Berezin O.69 ARC: Nested Descriptors long term support O.71 ARC: use of Model Designer long term SDN-O O.202 OH, ARC: should SDN-O be a standalone entity exposing its own NB and SB APIs (GUI, Catalog, Data Model) or what is the right level of integration with rest of Open-O for rel1 and long term? Current proposal has no way for GSO to orchestrate any SDN-O internal micro services but the E2E connectivity service O.203 OH, ARC: provide the NB Rest API. Referring to ETSI MANO spec fig 5.2 what is the difference between the WAN Infrastructure Manager and SDN-O? What is the pro/cons of using Or-Vi and Nf-Vi as a starting point for NB and SB API? If MEF Legato is proposed, provide a write up of its pro/cons and industry support. What is the flexibility to change it? O.204 ARC: assume a connectivity type can be requested from GS-O? Or else what is the meaning of asking for an E2E connectivity from GS-O? O.205 ARC: is Open-O to be architected presented as Hierarchy of orchestrators or provide also a top seeing all physical and logical infrastructure and exposing based on RBAC

O.206 ARC: assume that some VNFs will be on boarded based on their YANG model, so TOSCA Common and the associated Designer have to support YANG and conversion to TOSCA (of relevant parts). Should the Designer for the physical network and SDN-O be integrated too – i.e. related also to TOSCA/YANG interaction/ integration O.218 ARC: What is the preferred long term approach for SDN to VIM network connection – direct? By SDN-O? Through GS-O? Who owns the global VNFFG? O.223 OH, ARC: specific network connectivity using specific technologies is proposed as the SDN-O “micro-services”. Is it scalable and comprehensive? Is the E2E Network connectivity another such “micro service” does it provide the physical network topology (connectivity, QoS, Security, HA, utilization level etc.) as well? O.227 OH, ARC: Use TOSCA as the API style vs CMCC request for separation of roles and ability to see the scope of the infrastructure On-boarding a service – no catalog. API and some micro services. O.228 OH, ARC: define desired approach for Network Service on-boarding – interaction with GS-O, global inventory, separate in SDN-O? How automated is it vs desired automation goals? O.233 OH, ARC: what is the long term approach to design and on-boarding environment? Does it make sense to use the Common TOSCA designer? O.236 ARC: IM/DM an API alignment with external SDO and open source