...
International numbers available: https://zoom.us/zoomconference?m=Cf5Ha4SNAxTeBbkwwbCfPmJhrz-mZrJ0
Agenda - Architecture Tiger Team Weekly (08-JAN-2018)
I. Recommendations (from Architecture Tiger Team to Projects/PTLs) – Parviz (30 min)
Steps towards target architecture
In ONAP we need to take incremental steps toward a modular, microservices-based, model-driven architecture. More specifically, we should take necessary measures to migrate the functionality of the current monolithic legacy system to support cloud-native deployment models. To achieve this goal we may need to consider the following:
- Modular:
- Improve APIs between components. Document them using Swagger to improve alignment between components
- Align interfaces with industry standards, where available/appropriate (e.g., ETSI SOL-005, MEF SONATA, etc.)
- Microservices-based
- Use OOM for instantiation (support MSB natively)
- Register with MSB
- Use microservices best practices (e.g., separate data from the component, use common KV stores/databases, for KV stores – prefer Consul, etc.)
- Model-driven
- Align with data models from the Modeling Subcommittee (published last month)
- Explore ways to use model-driven principles inside each component
- S3P
- Use common libraries/SDKs/common services for S3P enhancements to improve overall system resiliency/reliability
- More focus on common services (where possible) also to help reduce testing
Some other considerations
- External APIs: Customers view ONAP as a black box. This should simplify the ONAP architecture/interfaces, leveraging the APIs developed by the Ext API project.
- Database migration: All databases of the ONAP platform (ie, MySQL relational database management system) should migrate to MariaDB in R2.
- API Improvements: Currently, ONAP internal interactions are mostly handled via REST-like APIs. We need to enhance the ONAP architecture to support RESTFUL APIs. We also need to ensure that the ONAP platform can handle cloud-native APIs and models.
- Versioning Support: Currently, the ONAP architecture doesn’t seem to support versioning (at least in a consistent manner).
- Support for Identity Management in SDC
- Support for Security Management in SDC – Kubernetes in OOM may provide this feature in R2. Needs clarification!
- Promote DevOps operations model
- Support for a full-blown containerization
- Support for Homing in R2
- Geo-redundancy – move from real-time (strong) consistency to eventual consistency model
- Multi-tenancy support
- Support for DB as a service
- Support for image management in R2 (requires SDC enhancements). This is to help with remote image management with virus/integrity check (via properly defined security tools).
II. Functional description of the target architecture components -Gil/Vimal(20 min)
ACTION: Update Orchestration, Generic NF Controller, and ONAP Design and Creation functions per input from Friday’s call. Work offline to sync-up with Seshu (SO PTL), Lingli/Yang/Jianguo (VF-C project team), Steve and Manoj to address any concerns/ comments they may have including the ones listed below.
Gil’s email:
Regarding the comment on today’s call that in the Beijing release we plan to take steps towards implementing (at least a subset of) SOL003 as the API between NFVO/VF-C…
I think our goal should be that all new code written in Beijing release is taking us closer to a common vision. And so before we get too far down the road implementing towards a specific interface we should have a discussion on the granularity of the operations appropriate across the Orchestration and Controller layers. In order to do that we need to first ensure we have agreement on the next level of detail on the functionality of Orchestration versus Controller layers.
To help start that conversation, I have created the attached where I use the “instantiate” and “scale” scenarios to make a comparison between the current ONAP implementation as manifested in the vCPE use case (for example) and what I see in the corresponding ETSI documentation. (I am no expert in ETSI, so please correct me if I have interpreted something wrongly.)
Note that this diagram assumes the following:
- VNF vendors should (will) provide “plug in play” scaling by adding VDUs, and so there is no need for ONAP to (re)configure the VNF as part of scale out/in orchestration (for example, to make the VNF application aware of the new VDU).
- A VNF by definition will execute in a single cloud instance. Specifically, there is no need for doing “homing” to find a VDU cloud provider/instance “home” that is being added to a VNF as part of a scaling event.
If the above are not true or are controversial, then the functionality in the “dashed box” (the per-VDU processing) will need to be supplemented to add the corresponding interactions.
My own preference would be to have a consistent approach across instantiation and scaling for mapping the functionality in the “dashed” box to ONAP components, but I would like to start a discussion on that.
II (a). Distinction between Service and Service Instance (Steve_comment)
ACTION: Resolve comment.
II(b). Some architecture comments/questions (Manoj_comment)
ACTION: Resolve comment.
III. ONAP External APIs (Orchestration Delegation/Federation) + Susana_comment(20 min)
ACTION: Andy to provide text description and figures (as needed) for external APIs (leveraging the stds specs including MEF, TM Forum, ..). This is for handling orchestration federation/delegation based on what we agreed and reflected in the target reference architecture. Please use the attached template for documenting the external APIs specifications. Also please work offline with Steve and Susana to review and resolve the following comments before submitting your update:
Parviz, attached is an updated slide deck to help address Steve’s comments on the ONAP External API deck.
I believe that Susana’s comments are referring to a different section in the larger deck, namely the “ONAP Orchestration Alignment” section, slides 9-14 of Mayer_py20171204 ONAP R2+ Architecture Proposal-Mayer
[Susana] Referring to Andrew slides, I have some questions/comments. According to some previous call, the current VF-C includes orchestration functionality as per ETSI MANO standards, i.e. including Network Service LCM and VNF(s) LCM; however, the slide 14 assumes that the SO is in charge of both VNF LCM and NS LCM, which is inconsistent with the current allocation of functionality. I assume the functionality of VF-C is not to be integrated into the SO, am I right?
Additionally, a Generic VNF controller includes some drivers for the external VNFM (which is also a VNF controller) and EM (which is the application controller). Shouldn’t the VNFM driver be part of the orchestration engine (of the VF-C, wherever it is now)?
IV. Catalog & VNFM (Maopeng) + Comment (Steve) – APPROVED
V. ACTION: Parviz to update the slide deck and incorporate any changes agreed so far.
ACTION: Maopeng to sync-up with Steve offline and submit an updated proposal for tomorrow’s call. The update should include any agreement reached with the SDC project team per Alex’s comment.
Hi Parviz, some ideas about the R2+ architecture. Hope we can discuss them in the tiger meeting, Thanks.
- P1 and P2 is about the RT-catalog and DT-catalog – Project approval pending!
- p3 about the orchestrator and VNFM
- About the model driven, suggest model in Arch subcommittee aligned with the modeling subcommittee. P4 is the modeling subcommittee reference.
[Steve] Hi Maopeng, regarding the removal of orchestrate network functions, I know what you mean, however still there can be orchestration of the configuration of the NFs that go across NFs at this level. Would it instead make sense to add a bullet under the first bullet on slide 10 along the lines of “note: LCM of a specific NFs is a controller function”?
[Maopeng] Hi Parviz, last meeting, I propose the confusion issues of orchestrator and controller and also we talk about the GVNFM Steve updated and get consensus about GVNFM.
Suggest 1: Page 10&11: request for clarification on the differentiation between orchestrator and VNFM on NF orchestration/LCM
remove “Orchestrate Network Functions (VNF/PNF)”and “LCM VNF/PNFs”
Suggest 2: Add G-VNFM as the input in the arch slide.
VI. Certificate Credential Management (Srini): CLOSED
Hi Parviz, ... Few comments :
Since we intend to have Certificate credential management and Secret Management Services in R2 and beyond, can we add them to “High-Level Functional view” slide in “Common Services” block? For the space reasons, you may want to put ‘cert, secret mgmt’.
Not verified, but this is understanding I am getting : Policy framework in R1 is a run time service for closed loop control only . In R2, my understanding is that policy framework is going to be used by OF and possibly others. If that is the case, it should be part of “Common Services”.
In all pictures: External Gateway, in my view, need to be below OSS/BSS and above ONAP External API. Alternatively, “External Gateway” in the same box as ONAP External API.
Hypervisor/OS Layer is not the right term to represent “Openstack”, “VMWare”, “Azure”, “AWS” and “Rackspace”. Suggestion is to use “VIM/Hyperscale layer”. AMZ term is not well known. Can we change this to “AWS”.
VII. NFVO functionality/API description in R1 (Yan) – APPROVED
VIII. GVNFV diagram update (Steve) – OPEN (5 min) - General agreement (SOL 002 to be removed from the diagram).
IX. API Specifications:
MEF/TMF APIs (Ext API), ETSI MANO Interfaces (based on SOL specs) and enhance existing interfaces in compliance with the architecture design guidelines, carrier-grade criteria/S3P, etc(10 min)
X. VDF proposed architecture (Susana) – OPEN (Deferred)
ATION: Susana to present the proposed architecture tomorrow (before the R2+ architecture deadline). Otherwise, it will be deferred to R3.
XI. Update the architecture figures with newly approved functional elements/projects (Parviz) – (5 min)
- MUSIC – as a shared service provides a unified platform for consistent state management across multiple sites (sharding startegy).
- ONAP Benchmark
XII. MSB Functional Description (10 min)
XIII. A&AI Functional Description (5 min)
------------------------------------
US numbers:
+1 646 558 8656, or +1 669 900 6833
Meeting ID: 761 325 550
International numbers available:
https://zoom.us/zoomconference?m=D_WZofsWmNr8ZvyR_5uMQv1i2yKSoUpS
-----
Agenda:
AGENDA (22-Dec-2017)
1.Functional description of the target architecture components (Vimal) - OPEN
...