Members
- Gil Bullard
- Margaret Chiosi
- Lingli Deng
- ramki krishnan
- Fernando Oliveira
- Alexander Vul
- Yan Yang
- maopeng zhang
- Srinivasa Addepalli
- Raghu Ranganathan
- Viswanath Kumar Skand Priya
- Margaret Chiosi
- Parviz Yegani
- Xu Yang
- Andrei Kojukhov
- Ciaran Murphy
- Manoj Nair
- Raquel Morera
- Chaker Al-Hakim
- Ranny Haiby
- Seshu Kumar Mudiganti
- Linda Horn
- shitao li
- please add your name if interested in this topic
Kickoff Materials
Meeting Information
Weekly meeting: Mondays at 9am ET.
Meeting number (access code): 594 955 640
Meeting password: 3QK6Mn8d
Join by phone
+1-800-365-8460 US Toll Free
+1-210-795-0492 US San Antonio Toll
Global call-in numbers | Toll-free calling restrictions
Agenda: December 3, 2018
- Review Assumptions list
- Review Updated VZDeploymentOptionLegacy.pptx
- Review Implications/Requirements section for presentation at Arch Committee meeting on Dec 4.
Assumptions:
- Operator has already deployed ETSI SOL003 compliant VNF Manager(s)
- Operator has already deployed ETSI SOL005 compliant NFVO(s)
- Operator has existing Service Assurance tools that VNF(s) interact with
- Operator is currently using proprietary mechanisms to configure NFs
- Operator has used above mechanisms to deploy SOL001/SOL004 compliant VNFs
- Operator has multiple VIMs; with different HW capabilities and configurations
- Operator desires to integrate ONAP into the existing environment
Objectives
- Examine orchestration scenarios in order to determine if new architectural requirements are necessary
- Develop recommendations for composition of the ONAP Service DM (How does the ETSI NFV SOL001 Network Service Descriptor supported?)
- Develop recommendations for interfaces between the orchestration elements (OSS, SO, VF-C, VNFM, NFVO)
- Develop recommendations for how ONAP controllers work with external orchestration elements (NFVO, VNFM, EMS)
- Develop recommendations for how external Service Assurance interacts with DCAE and Policy
Develop recommendations on breaking ONAP into more modular consumable pieces (Margaret)
Tasks
To Do's
- Recommendation on whether an ONAP should support an E2E Service that is composed of xNFs that are orchestrated by separate orchestrators (SO, SO + external VNFM, VF-C, external NFVO) for next Arch meeting (Nov 13)
- Mapping of SOL005 APIs to ONAP NBI
- Develop scenarios with stories about how ONAP could be used in near term brownfield legacy environment Fernando Oliveira
- Develop scenarios with stories about how a legacy environment could migrate off of a brownfield legacy environment towards a ONAP native model Fernando Oliveira
- Describe how ONAP DCAE could be integrated with legacy Service Assurance platform Fernando Oliveira
- Describe how legacy inventory system would interact with ONAP A&AI
- Develop scenarios for how Application Configuration could be supported with enhanced SOL001 VNF-D using an external SOL003 compliant VNF Manager Fernando Oliveira
Implications/Requirements
- External VNFM scenarios:
- ONAP needs to ingest and save SOL004 CSAR package for later consumption by a SOL003 compliant VNF Manager
- ONAP needs to ingest and interpret a SOL001 compliant VNF Descriptor in order to design an ONAP Service
- ONAP needs to understand resource requirements in the VNF-D for each deployment and scaling level
- ONAP needs a way to ingest or create a VIM tenant/project space
- ONAP needs to inventory (A&AI, Multi-Cloud/VIM) the VIM tenant/project resources and capacity
- ONAP needs to confirm that the VIM resources (vCPU, RAM, Storage, Network, EPA (SR-IOV, GPU, Pinnned CPU, Locked RAM, ..), ...) necessary for the deployment or scale operation are available (SO, A&AI, OOF)
- Such resources should be reserved if the VIM has that capability (OOF, Multi-Cloud)
- ONAP needs to have a SOL003 compliant SBI
- ONAP needs a mechanism for specifying that a VNF instance should be runtime managed by an external VNFMa particular VNFM type (design time) and instance (run time)
- ONAP needs to have a way to inventory (A&AI) a VNF that was deployed using an external VNFM
- External NFVO scenarios:
- 1a above
- 1b above
- ONAP needs to be able to convert an ONAP Service into a SOL001 compliant Network Service Descriptor (NS-D)
- ONAP needs to have a SOL005 compliant SBI
- ONAP needs a mechanism for specifying that a service should be runtime managed by an external NFVO
- ONAP needs to have a way to inventory a Service that was deployed as a Network Service using and external NFVO