...
- ETSI NSD to ONAP service descriptor translation by Anatoly Katzman
Materials to discuss:
Recommendations from the last DM call: ONAP NSD discussion v0_9.pptx, the deck also incorporates vCPE using SOL001.docx and service-VcpeWithAll-template.yml:
Recommendation A: - SDC update VL type based on SOL001 v2.5.1. Avoid, vendor specific type
Recommendation B: - Deprecate the use of the capabilities to represent properties on the node
Recommendation C: - Deprecate all the type definition and adopt ETSI NSD model which is node type properties and in case extend ETSI model for ONAP specific properties (i.e. ONAP configuration properties)
Recommendation D: - Deprecate all the type definition and define a new (E2E) Service model that can be in the future adopt by ETSI and ONAP.
Reminder:
Dual nature of the ONAP data model:
Outside: support for SOL001, HEAT, and, possibly, other external data models – onboarding, integrations
Inside: ONAP has its own internal DM:
- org.openecomp.*
- tosca.*.nfv.*
The existing ONAP logic depends on the current ONAP internal model. "Deprecate everything" will break everything.
Alternative recommendations:
Recommendation 1:
Usage of capabilities and requirements - better judgement to be applied when adding capabilities and requirements to PNFs, VNFs, and Services. Today, the node types generated by SDC during PNF/VNF/Service composition include HUNDREDs of capabilities and requirements:
- During VNF/PNF/Service composition - SDC gathers ALL vacant capabilities and unfulfilled requirements of ALL internal nodes of the type VNF/PNF/Service implementing topology and exposes them through substitution_mapping as capabilities/requirements of the created VNF/PNF/Service type
- During ServiceProxy generation – SDC copies ALL vacant capabilities and unfulfilled requirements from the source service to the generated service proxy type.
The service designer should be able to specify which capabilities/requirements are RELEVANT for exposure on the created type.
Recommendation 2:
Deprecate Replace the tosca.*.nfv.* type definitions, and replace them with SOL001 v2.5.1. Retain the org.openecomp.* type definitions.
Recommendation 3:
When onboarding ETSI models (VNFDs, PNFDs, NSDs), apply the following translation rules:
- Zero translation for all tosca.*.nfv.* objects (nodes, capabilities, interfaces, properties, etc.) – including all CPs and VLs - for the exception of tosca.nodes.nfv.VNF, tosca.nodes.nfv.PNF, and tosca.nodes.nfv.NS
- Translate tosca.nodes.nfv.VNF into org.openecomp.resource.abstract.nodes.VF (as we do now)
- Translate tosca.nodes.nfv.PNF into org.openecomp.resource.abstract.nodes.PNF
- Translate tosca.nodes.nfv.NS into org.openecomp.resource.abstract.nodes.service