Assumptions:

1. Operator has already deployed ETSI SOL003 compliant VNF Manager(s)
2. Operator has already deployed ETSI SOL005 compliant NFVO(s)
3. Operator has existing Service Assurance tools that VNF(s) interact with
4. Operator is currently using proprietary mechanisms to configure NFs
5. Operator has used above mechanisms to deploy SOL001/SOL004 compliant VNFs
6. Operator has multiple VIMs; with different HW capabilities and configurations
7. 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

1. External VNFM scenarios:
   1. ONAP needs to ingest and save SOL004 CSAR package for later consumption by a SOL003 compliant VNF Manager
   2. ONAP needs to ingest and interpret a SOL001 compliant VNF Descriptor in order to design an ONAP Service
   3. ONAP needs to understand resource requirements in the VNF-D for each deployment and scaling level
      1. ONAP needs a way to ingest or create a VIM tenant/project space
      2. ONAP needs to inventory (A&AI, Multi-Cloud/VIM) the VIM tenant/project resources and capacity
      3. 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)
      4. Such resources should be reserved if the VIM has that capability (OOF, Multi-Cloud)
   4. ONAP needs to have a SOL003 compliant SBI
   5. ONAP needs a mechanism for specifying that a VNF instance should be runtime managed by a particular VNFM type (design time)  and instance (run time)
   6. ONAP needs to have a way to inventory (A&AI) a VNF that was deployed using an external VNFM
2.  External NFVO scenarios:
   1. 1a above
   2. 1b above
   3. ONAP needs to be able to convert an ONAP Service into a SOL001 compliant Network Service Descriptor (NS-D)
   4. ONAP needs to have a SOL005 compliant SBI
   5. ONAP needs a mechanism for specifying that a service should be runtime managed by an external NFVO
   6. ONAP needs to have a way to inventory a Service that was deployed as a Network Service using and external NFVO

Contributions...

Recording of call 11/12/2018: double_click_to_convert_01.zoom

VZDeploymentOptionLegacy.pptx