ONAP-ETSI Alignment Workshop - 18 February 2020
This workshop will be hosted by the ETSI NFV SOL WG (see meeting call logistic below). The workshop is open all ONAP and ETSI NFV members. It is a technical information sharing meeting only with no decision or approval making process.
The goal of the workshop is to share technical details of the ETSI Alignment project on SOL002, SOL003, SOL005 Adapters, and ONAP-ETSI Catalog Manager.
Date: February 18, 2020 Time: 14:00 – 15:00 C.E.T
1) Welcome, logistic and agenda: link
2) ONAP: ETSI-Alignment Architecture and Roadmaps - ETSI NFV Workshop Presentation link
3) ETSI NFV SOL WG Release 2 and 3 status link
1. CNF spec? IFA029? IFA040? • On March 9, 2020, ETSI NFV IFA WG presented ETSI NFV management concepts for container-based VNFs, IFA029, and IFA040 technical overview. The slide set is available at: https://nfvwiki.etsi.org/index.php?title=NFV_Release_4_FEAT17_%E2%80%93_CNF_management_concepts_-_9_March_2020
2. Or-Vi SOL Spec? • ETSI does not currently provide Stage 3 specifications for implementing the individual operations of the Virtualized Resources Management interface defined in ETSI GS NFV-IFA 005. The current assumption is that such operations can be implemented using de-facto industry standards. However, from ETSI GS NFV-IFA 005 v2.7.1 and v3.3.1, it is stated that "virtualized resource descriptors" can be used to exchange the information associated to interface operations fulfilled by the requirements related to virtualized resource management interfaces. A virtualized resource descriptor is a template declaring parameters, requirements, lifecycle and composition of a set of virtualized resources. As an example, in OpenStack case, these are the Heat Orchestration Templates. Currently, ETSI NFV is specifying as part of the DGS/NFV-SOL014 work item the data models corresponding to the virtualized resource descriptors. In the work item draft, examples on how to apply the specified modeling to OpenStack’s HOT is provided. However, the current scope of DGS/NFV-SOL014 only focuses on these data models and it does not specify or profile external specifications for specific interface operations to be used for exchanging virtualized resource descriptors with the VIM. • A draft version of DGS/NFV-SOL014 ed271 is available at: https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL014ed271_VR_desc_stage3/NFV-SOL14ed271v030.zip
3. Modeling direction for GVNFM? • The APIs produced and consumes by ETSI-compliant VNFMs are expected to comply with the REST APIs specified in ETSI GS NFV-SOL 002 and ETS GS NFV-SOL 003, irrespective of whether this VNFM qualifies as a generic VNFM or not. It should be noted that the term generic VNFM is introduced in ETSI GS NFV-IFA 009, the report on architecture options, to designate a VNFM that can serve multiple VNFs of different types and/or originating from different providers. • The specifications of the VNFD (ETSI GS NFV-SOL 001 and 006) do not currently mandate any particular language for writing LCM scripts referenced from a VNFD. • The VNF configuration API specified in ETSI GS NFV-SOL 002 provides a generic solution for a VNFM to configure a VNFC instance (e.g. a load balancer) with information about other VNFC instances being added/removed within a VNF instance.
4. VNFD representation for Cloud Native? • Overall, the planned impact of the cloud-native VNFs and OS container management and orchestration is reflected by the NFV Release 4 implementation plan of the FEAT17 “Cloud-Native VNFs and Container Infrastructure management”. The public version of the feature implementation plan is available at: https://nfvwiki.etsi.org/index.php?title=Feature_Tracking#FEAT17:_Cloud-Native_VNFs_and_Container_Infrastructure_management • In particular, the information model of the VNFD will be enhanced with a new information element OsContainerDesc, introduced as a new attribute to the VDU. This enables to model MCIOs (K8s objects such as Pods) as VDUs, referencing multiple OS containers. Additionally, IFA011 will be enhanced with additional requirements to support the inclusion and reference of MCIOPs (such as Helm Charts) in the VNF Package.
5. Hybrid Modelling for CNF? It is the current assumption • See response #1 and presentation slide on FEAT17, https://nfvwiki.etsi.org/index.php?title=NFV_Release_4_FEAT17_%E2%80%93_CNF_management_concepts_-_9_March_2020
6. Indirect mode of resource management? • The signaling of parameters related to the indirect mode are available in the stage 3 (protocol and data model) of the VNF LCM API (SOL002, SOL003). The stage 3 of the NFVO "south-bound" API (i.e. API exposed by the NFVO to the VNFM) for indirect resource management is not available. Before the work on such API could start, a stage 3 specification of the Virtualized Resource Management interface (VIM "north bound") in the Vi-Vnfm reference point would have to be developed or a set of alternative external standards selected. There are currently no plans for specifying a stage 3 for this interface, from an interface/operations point of view. However, stage 3 work is ongoing with regards to the modeling of the virtualized resource descriptors (see also question #2).
7. Is the forge.etsi.org swagger official? • OpenAPI representations of the APIs specified in ETSI NFV SOL GSs are available in the form of a set of YAML files on the ETSI Forge, here: https://forge.etsi.org/rep/nfv • This content is “official” is that all files are reviewed and approved by the SOL WG and are the subject of a continuous maintenance process to fix bugs and misalignments with the original GS contents. • The following Wiki page provides user-friendly access to OpenAPI representations for multiple API versions: https://nfvwiki.etsi.org/index.php?title=SOL_OpenAPI_Representations • Stable draft versions are also accessible through this Wiki page. • In case of discrepancies between the contents of these and the original GS contents, the later take precedence. • The content of the ETSI Forge licensed under the terms of the BSD-3-Clause LICENSE: https://opensource.org/licenses/BSD-3-Clause
8. VNF Indicator? • The protocol specification of the VNF indicator interface is available in SOL002 and SOL003 version 2.7.1. • SOL001 version 2.7.1 contains also the specification of VNF indicators in the VNFD. • Furthermore, SOL WG has recently approved the CR on SOL001 with the specification of the usage of VNF indicators in auto-scaling and auto-healing rules in the VNFD. This specification will be incorporated in the first version (3.3.1) of SOL001 release 3, planned for H1-2020. A draft version of release 3 is available at: • https://docbox.etsi.org/ISG/NFV/Open/Drafts/SOL001ed331/NFV-SOL001ed331v302.zip • The specification of VNF indicators in the NSD, as part of the MonitoredData and its usage in NSD auto-scaling rules, is not available yet in SOL001.