1. OPEN-O Architecture Comments
August 30th, 2016

2. 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

3. 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

4. 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

5. 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

6. 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

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

8. 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

9. Thank You

10. 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.

11. 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

12. 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