Remain issues 2018.1.17

1，VNFD node type 2, Deployment flavour 3, VDU.Compute 4, VDU.Storage Design issues 1，VNFD node type 2, Deployment flavour 3, VDU.Compute 4, VDU.Storage

1，VNFD node type

VNFD design case 1 (V1.2 is needed) Main idea: Every VNF have the same node type (tosca.nodes.nfv.vnf) tosca_definitions_version: tosca_simple_yaml_1_1 Topology_template: substitution_mappings: node_type: tosca.nodes.nfv.vnf properties: VNFD_ID: aaaa-bbbb-cccc-1234 version: 1.0 provider: a_company capabilities: node templates: VDU_1: VDU_2: VNFD_1 NSD service template (contains two VNFDs) Substitution_mapping: Searching from all VNF descriptor service templates Do the mapping based on properties constraint matching (as defined in V 1.2) tosca_definitions_version: tosca_simple_yaml_1_1 Topology_template: node_templates: VNF_node_1: type : tosca.nodes.nfv.vnf properties: VNFD_ID:aaaa-bbbb-cccc-1234 version: provider: type : tosca.nodes.nfv.vnf VNFD_ID:aaaa-bbbb-cccc-5678 tosca_definitions_version: tosca_simple_yaml_1_1 Topology_template: substitution_mappings: node_type: tosca.nodes.nfv.vnf properties: VNFD_ID: aaaa-bbbb-cccc-5678 version: 1.0 provider: b_company capabilities: node templates: VDU_a: VDU_b: VNFD_2

NSD service template (contains two VNFDs) VNFD design case 2 Main idea：Each VNF has different node type, but all derive from the same parent VNF type(tosca.nodes.nfv.vnf) VNFD_1 tosca_definitions_version: tosca_simple_yaml_1_1 Topology_template: substitution_mappings: node_type: tosca.nodes.nfv.vnf1 capabilities: node templates: VDU_1: VDU_2: VL_1: NSD service template (contains two VNFDs) tosca_definitions_version: tosca_simple_yaml_1_1 Topology_template: node_templates: VNF_node_1: type : tosca.nodes.nfv.vnf1 properties: version: provider: type : tosca.nodes.nfv.vnf2 Based on different VNF node type to find the correct VNFD(service template) Further, the node type can be set as the VNFD_ID tosca_definitions_version: tosca_simple_yaml_1_1 Topology_template: substitution_mappings: node_type: tosca.nodes.nfv.vnf2 capabilities: node templates: VDU_a: VDU_b: VL_a: VNFD_2 2018/11/22

VNFD example for single DF tosca_definitions_version: tosca_simple_yaml_1_1 metadata: vnfd_id: <file_uri> #Required   vnf_provider: <provider_string> #Required   vnf_product_name: <name_string> #Required   vnf_software_version: <version> #Required   vnfd_version: <version> #Required Node types: tosca.nodes.nfv.example_VNF: derived_from: tosca.nodes.nfv.vnfd properties: flavor_ID: # requirements: ExtVirtualLinkable topology_template: substitution_mapping: node_type: tosca.nodes.nfv.example_VNF capabilities: ExtVirtualLinkable: [VDU_1, ExtVirtualLinkable] node_template: VDU_1: type: nodes.nfv.VDU scalable: min_instances: 2 max_instances: 8 VDU_2: VL_1: type: nodes.nfv.VirtualLinkDesc Group: element_group_1: type: tosca.groups.affinity members: [VDU_1, VDU_2] Policies: localAffinityOrAntiAffinityRule_1: type: tosca.policy.placement.local targets: VDU_1 type: # affinity or anti-affinity scope: scalingAspect_1: type: : tosca.policy.scale targets: element_group_1 Does this align with ONAP SDC? tosca.nodes.nfv.vnfd: derived_from: tosca.nodes.Root properties: # capabilities: requirements: - virtual_link: capability: tosca.capabilities.nfv.ExtVirtualLinkable relationship: tosca.relationships.nfv.ExtVirtualLinksTo node: tosca.nodes.nfv.VnfExtVL occurrences: [ 0, UNBOUNDED ]  

Only the parent VNFD node type needs to be specified. recommendation Using VNFD design case 2，different VNFD uses different VNFD node type，it gives flexible for VNFD venders to set their own types Only the parent VNFD node type needs to be specified.

2，Deployment flavour

VNFD example for single DF tosca_definitions_version: tosca_simple_yaml_1_1 metadata: vnfd_id: <file_uri> #Required   vnf_provider: <provider_string> #Required   vnf_product_name: <name_string> #Required   vnf_software_version: <version> #Required   vnfd_version: <version> #Required Node types: tosca.nodes.nfv.example_VNF: derived_from: tosca.nodes.nfv.vnfd properties: flavor_ID: # requirements: ExtVirtualLinkable topology_template: substitution_mapping: node_type: tosca.nodes.nfv.example_VNF capabilities: ExtVirtualLinkable: [VDU_1, ExtVirtualLinkable] node_template: VDU_1: type: nodes.nfv.VDU scalable: min_instances: 2 max_instances: 8 VDU_2: VL_1: type: nodes.nfv.VirtualLinkDesc Group: element_group_1: type: tosca.groups.affinity members: [VDU_1, VDU_2] Policies: localAffinityOrAntiAffinityRule_1: type: tosca.policy.placement.local targets: VDU_1 type: # affinity or anti-affinity scope: scalingAspect_1: type: : tosca.policy.scale targets: element_group_1 Does this align with ONAP SDC? tosca.nodes.nfv.vnfd: derived_from: tosca.nodes.Root properties: # capabilities: requirements: - virtual_link: capability: tosca.capabilities.nfv.ExtVirtualLinkable relationship: tosca.relationships.nfv.ExtVirtualLinksTo node: tosca.nodes.nfv.VnfExtVL occurrences: [ 0, UNBOUNDED ]  

3，VDU.Compute

VDU.Compute VDU.Compute VirtualCompute Contains tosca.capabilities.compute, which including CPU and memory information This capability is overlapped with tosca.capabilities.compute Issue_1: since VDU.Compute is already derived from tosca.nodes.compute, is virtual_compute capability still required

VDU.Compute Here “deprecated” status means VDU.Compute will not use those attributes as defined in tosca.nodes.compute. But this usage of “deprecated” is not explicitly supported in TOSCA Simple Profile in YAML. The reason to set those attributes as “deprecated”, is that IFA model does not contains those attributes. But from implementation perspective, those attributes seems reasonable for a VM. Issue_2: how to support/implement the new meaning of “deprecated”, is that really needed to deprecate those attributes for VDU.compute.

Suggestion, based on latest IFA011 2.3.1 Table 7.1.9.2.2.2-1: Attributes of the VirtualComputeDesc information element Attribute Qualifier Cardinality Content Description virtualComputeDescId M 1 Identifier Unique identifier of this VirtualComputeDesc in the VNFD. logicalNode 1..N logicalNodeData The logical Node requirements. requestAdditionalCapabilities 0..N RequestedAdditionalCapabilityData Specifies requirements for additional capabilities. These may be for a range of purposes. One example is acceleration related capabilities. See clause 7.1.9.5. computeRequirements Not specified Specifies compute requirements. virtualMemory VirtualMemoryData The virtual memory of the virtualised compute. See clause 7.1.9.3. virtualCpu VirtualCpuData The virtual CPU(s) of the virtualised compute. See clause 7.1.9.2. properties requirements requirements requirements capabilities

New definition

4，VDU.Storage

VDU.VirtualStorage The VDU.AttachTo relationship type is still missing，this new relationship type should apply to either AttacheTO or ConnectsTo based on the value of type_of_storage There is no such usage or example existing in TOSCA.

recommendation Suggest to use TOSCA existing storage node type VDU.BlockVirtualStorage internalCpd VDU.compute VDU VduCpd VirtualStorageDescriptor cap property req VirtualComputeDescriptor cap req Attachment property VirtualLinkable cap AttachesTo Nfv_compute req property VDU.ObjectVirtualStorage input VirtualBindable req property input VirtualBindsTo Attachment VirtualStorageDescriptor Connect cap VirtualBindable cap req Substitution mappings artifact ConnectsTo Connect swImageDescriptor Suggest to use TOSCA existing storage node type Different type of storage uses different node type，