Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. ETSI NSD to ONAP service descriptor translation by Anatoly Katzman

Materials to discuss:

Recommendations from the last DM callONAP 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