1. Remain issues

2. 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

3. 1，VNFD node type

4. 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

5. 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

6. 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 ]

7. 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.

8. 2，Deployment flavour

9. 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 ]

10. 3，VDU.Compute

11. 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

12. 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.

13. Suggestion, based on latest IFA011 2.3.1
Table : 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
computeRequirements
Not specified
Specifies compute requirements.
virtualMemory
VirtualMemoryData
The virtual memory of the virtualised compute. See clause
virtualCpu
VirtualCpuData
The virtual CPU(s) of the virtualised compute. See clause
properties
requirements
requirements
requirements
capabilities

14. New definition

15. 4，VDU.Storage

16. 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.

17. 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，