1. DF design as a node type (output by Chris and shitao)

2. Multiple DF:
Two layers of TOSCA service templates
Top level service template only contains the VNF node type definition
Each lower level service template contains one DF
Each lower level service template uses substitution_mapping to map to the top level VNF node type
At NSD design time, a specific VNF flavor ID will be set to the VNF node template and match to a specific DF service template
tosca-simple-profile-yaml v1.2 is needed

3. Mulitple DF (using substitution_mapping grammar in tosca-simple-profile-yaml-v1.2)
VNFD
lower level
tosca_definitions_version: tosca_simple_yaml_1_2
imports:
VNFD.yaml
substitution mapping
node_type: tosca.nodes.nfv.example_VNF
properties:
flavour_id: flavour1
node_templates:
VDU_1:
VDU_2:
Top level
DF_1 service template (df1.yaml)
VNFD service template (VNFD.yaml)
VDU_1
VDU_2
tosca_definitions_version: tosca_simple_yaml_1_2
metadata:
Node types:
tosca.nodes.nfv.example_VNF:
derived_from: tosca.nodes.nfv.vnf
properties:
VNFD_ID:
type: string
flavour_ID:
constraints:
- valid_values: [ flavour1, flavour2 ]
VL_1
DF_2 service template (df2.yaml)
tosca_definitions_version: tosca_simple_yaml_1_2
imports:
VNFD.yaml
substitution mapping
node_type: tosca.nodes.nfv.example_VNF
properties:
flavour_id: flavour2
node_templates:
VDU_1:
VDU_2:
VDU_3:
VDU_1
VDU_2
VDU_3
VL_1
1,Imports at top level mentioning the lower level STs may be needed
2, which VNFD related parameters should be set as properties, which should be set as metadata in VNFD service template.
3, tosca.nfv.vnf.vnfd is not the same as nowadays in SOL001
4, how to describe LCM operates
5, details of every definitions
6, top level ST, is the VNF node type is a abstract or concrete node type
NSD
tosca_definitions_version: tosca_simple_yaml_1_1
topology_template:
inputs:
deployment_flavor:
type: string
node_template:
VNF1:
type: tosca.nodes.nfv.example_VNF
VNFD_ID:
flavor_ID: { get_input: deployment_flavour}
# either flavour1 or flavour2
At NSD design time, a specific VNF flavor ID will be set to the VNF node template and match to a specific DF service template

4. Single DF:
VNFD contains only one topology option.
Only one layer of TOSCA service template is needed.
Normal substitution mapping mechanism is enough (tosca-simple-profile-yaml v1.2, V 1.1 can both be used)

5. Single DF (using substitution_mapping grammar in tosca-simple-profile-yaml-v1.1)
VNFD
tosca_definitions_version: tosca_simple_yaml_1_1
Node types:
tosca.nodes.nfv.example_VNF:
derived_from: tosca.nodes.nfv.vnf
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:
VDU_2:
VL_1:
NSD
tosca_definitions_version: tosca_simple_yaml_1_1
topology_template:
inputs:
deployment_flavor:
type: string
constraints:
- valid_values: [ flavour1 ]
node_template:
VNF1:
type: tosca.nodes.nfv.example_VNF
VNFD_ID:
flavor_ID: { get_input: deployment_flavour}

6. Deployment flavour service template design
Capability (derived from scalable capability) of VDU node
Capability of VL node
DF_1 service template
Policy? Did not support in tosca nowadays
VDU_1
VDU_2
workflow?
VL_1
Group
capability
Policy?

7. More detail for single DF proposal (based on tosca-simple-profile-yaml v1.1)

8. VNFD example for single DF
This usage follows the same way as in ONAP SDC, discussion is still required.
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.c
Vduproflie:
VDU_2:
scalable:
min_instances: 2
max_instances: 8
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
tosca.nodes.nfv.vnfd:
derived_from: tosca.nodes.Root
properties:
flavour_ID:
type: string
localizationLanguage
type:string
capabilities:
requirements:
- virtual_link:
capability: tosca.capabilities.nfv.ExtVirtualLinkable
relationship: tosca.relationships.nfv.ExtVirtualLinksTo
node: tosca.nodes.nfv.VnfExtVL
occurrences: [ 0, UNBOUNDED ]

9. Vduprofile tosca.capabilities.Scalable
Using scalable capability, or creating a new capability that derived from scalable capability
Policy defined in the VNFD service template
Group defined in the VNFD service template

10. VirtualLinkProfile
The flavor ID value can be set directly within the VL node template

11. Examples: preferred Example_2, capabilities: vlprofile: VL1:
flavor: flavor_1
node_template:
VDU1:
type: tosca.nodes.nfv.VnfVirtualLinkDesc
properties:
vl_flavors: [flavor_1, flavor_2]
Example_1,
Inputs:
VL_flavor:
constraints: {flavor_1, flavor_2}
node_template:
VDU1:
VL1:
type: tosca.nodes.nfv.VnfVirtualLinkDesc
properties:
vl_flavor: {get_input: VL_flavor}
Similar with IFA model, but from TOSCA perspective, it is not a good design and may not implementable.
preferred