NSD model in ONAP service descriptors (draft7) Thinh Nguyenphu, thinh.nguyenphu@nokia.com Michela Bevilacqua, michela.bevilacqua@ericsson.com Ciaran Johnson, ciaran.johnston@ericsson.com Shitao li, lishitao@huawei.com Lianhao Lu, ianhao.lu@intel.com February 7, 2019

Use Case & Scope Use Case: At onboarding, SOL001 v2.5.1 NSD is supported at SDC. Use case: ref: https://wiki.onap.org/display/DW/vCPE+with+Tosca+VNF+Test+Guide Analyze ETSI NSD model vs ONAP Service descriptor generated by SDC for vCPE use case Slide set contains three parts: Mapping NS.CSAR to SOL001 v2.5.1. Detailed comparison between SOL001 NSD v2.5.1 and Service descriptors generated by SDC Scope: identify properties, types definitions and ONAP service configuration data. Summary and recommendation

Part#1: vCPE.yaml in original NS.CSAR

vCPE.yaml in original NS.CSAR Vgw Vgmux Vcpe_vbrgemu Vcpe_infra Vcpe_vbng Vcpe_public_net vcpe_public_net node template of type tosca.nodes.nfv.NsVirtualLink vgw, vgmux, vcpe_vbrgemu, vcpe_infra, vcpe_vbng node template of type tosca.nodes.nfv.VNF Mapping to SOL001 v2.5.1 NSD -> see attachment

Part #2: Service-VcpeWithAll-template.yaml in SDC csar

Service-VcpeWithAll-template.yaml in SDC csar oam-zte vCPE_Infrastructure_GW_demo_app vCPE_Infrastructure_vGMUX_demo_app vCPE_Infrastructure_BGREMU_demo_app vCPE_Infrastructure_demo_app vCPE_Infrastructure_Metro_vBNG_demo_app 0 Key points and Recomendations: The usage of oam-zte VL node type is to support VFC requirement. Also, SDC only this type for VL for VFC use cases. 2) A new node type is defined for each node template. Recommendation: SDC update VL type based on SOL001 v2.5.1. Avoid, vendor specific type vCPE_Infrastructure_Metro_vBNG_demo_app 0 node template of type org.openecomp.resource.vf.VcpeInfrastructureMetroVbngDemoApp vCPE_Infrastructure_GW_demo_app: type: org.openecomp.resource.vf.VcpeInfrastructureGwDemoApp vCPE_Infrastructure_demo_app: type: org.openecomp.resource.vf.VcpeInfrastructureDemoApp vCPE_Infrastructure_BGREMU_demo_app: type: org.openecomp.resource.vf.VcpeInfrastructureBgremuDemoApp vCPE_Infrastructure_vGMUX_demo_app: type: org.openecomp.resource.vf.VcpeInfrastructureVgmuxDemoApp oam-zte: type: tosca.nodes.nfv.ext.zte.VL

imports: - nodes: file: nodes. yml - datatypes: file: data imports: - nodes: file: nodes.yml - datatypes: file: data.yml - capabilities: file: capabilities.yml - relationships: file: relationships.yml - groups: file: groups.yml - policies: file: policies.yml - annotations: file: annotations.yml - service-vcpe_with_all-interface: file: service-VcpeWithAll-template-interface.yml - resource-vCPE_Infrastructure_BGREMU_demo_app: file: resource-VcpeInfrastructureBgremuDemoApp-template.yml - resource-vCPE_Infrastructure_BGREMU_demo_app-interface: file: resource-VcpeInfrastructureBgremuDemoApp-template-interface.yml - resource-vCPE_Infrastructure_demo_app: file: resource-VcpeInfrastructureDemoApp-template.yml - resource-vCPE_Infrastructure_demo_app-interface: file: resource-VcpeInfrastructureDemoApp-template-interface.yml - resource-vCPE_Infrastructure_Metro_vBNG_demo_app: file: resource-VcpeInfrastructureMetroVbngDemoApp-template.yml - resource-vCPE_Infrastructure_Metro_vBNG_demo_app-interface: file: resource-VcpeInfrastructureMetroVbngDemoApp-template-interface.yml - resource-ext ZTE VL: file: resource-ExtZteVl-template.yml - resource-vCPE_Infrastructure_GW_demo_app: file: resource-VcpeInfrastructureGwDemoApp-template.yml - resource-vCPE_Infrastructure_GW_demo_app-interface: file: resource-VcpeInfrastructureGwDemoApp-template-interface.yml - resource-vCPE_Infrastructure_vGMUX_demo_app: file: resource-VcpeInfrastructureVgmuxDemoApp-template.yml - resource-vCPE_Infrastructure_vGMUX_demo_app-interface: file: resource-VcpeInfrastructureVgmuxDemoApp-template-interface.yml service-VcpeWithAll-template.yml Service template contains two major parts: node_templates: all of the vCPE VNFs as a resource. substitution_mappings: node_type: org.openecomp.service.VcpeWithAll which describes all of it capabilities What is the different between resource-*-template vs. resource-*-template-terface.yml? Working assumption: *-interface.yml is a abstract service template, whereas other one is deploy. Where is vcpe_infrastructure_demo_app.virtualstorage_roo t_all.feature defined? Defined in resource-VcpeInfrastructureDemoApp-template-interface

Node_templates: at the service level overview ref: service-VcpeWithAll-template.yml Top level service template, per Entry-Definitions: Definitions/service-VcpeWithAll-template.yml Not a valid TOSCA template: missing node_template: org.openecomp.service.VcpeWithAll Node_templates: at the service level overview ref: service-VcpeWithAll-template-interface.yml Only define the capability of the service and each of VNFs (application) ref: nodes.yml An empty abstract service node with no property, requirements or capabilities defined. Key points: Today, capabilities in ONAP are used as a set of properties and not for matching requirements. Multiple levels service template design Recommendations : a) Deprecate the use of the capabilities to represent properties on the node b) 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) c) Deprecate all the type definition and define a new (E2E) Service model that can be in the future adopt by ETSI and ONAP

Node_templates: VNF template level (resources) overview Ref: Service-VcpeWithAll-template.yml ref: resource-VcpeInfrastructureGwDemoApp-template-interface.yml VcpeInfrastructureGwDemoApp drived_from an abstract node VF ref: nodes.yml An abstract node with no requirements or capabilities defined.

Service-VcpeWithAll-template in SDC csar node_type:org. openecomp Service-VcpeWithAll-template in SDC csar node_type:org.openecomp.service.VcpeWithAll substitution_mappings: node_type: org.openecomp.service.VcpeWithAll capabilities: vcpe_infrastructure_demo_app.virtualstorage_root_all.feature: - vcpe_infrastructure_demo_app - virtualstorage_root_all.feature vcpe_infrastructure_metro_vbng_demo_app0.vl_cpe_signal.feature: - vcpe_infrastructure_metro_vbng_demo_app0 - vl_cpe_signal.feature vcpe_infrastructure_demo_app.vdu_vdns_0.monitoring_parameter: - vcpe_infrastructure_demo_app - vdu_vdns_0.monitoring_parameter vcpe_infrastructure_bgremu_demo_app.cp_vbrgemu_public.feature: - vcpe_infrastructure_bgremu_demo_app - cp_vbrgemu_public.feature vcpe_infrastructure_demo_app.cp_vaaa_onap_private.feature: - vcpe_infrastructure_demo_app - cp_vaaa_onap_private.feature oamzte.virtual_linkable: - oamzte - virtual_linkable vcpe_infrastructure_demo_app.cp_vdns_public.feature: - vcpe_infrastructure_demo_app - cp_vdns_public.feature vcpe_infrastructure_demo_app.vdu_vaaa_0.feature: - vcpe_infrastructure_demo_app - vdu_vaaa_0.feature Key points: These capabilities are legacy of openecomp. Some of ONAP components may still use these capabilities. The grammar is not correct. Recommendation: These capabilities should not be consider as part of Dublin service or NSD modeling. And adopt Simple YAML v1.2 capabilities. See slide 8

tosca.nodes.nfv.VNF vs. org.openecomp.resource.abstract.nodes.VF Required Type descriptor_id yes string descriptor_version provider provider_name software_version product_info_name no product_info_description vnfm_info list of string localization_languages default_localization_language configurable_properties tosca.datatypes.nfv.VnfConfigurableProperties modifiable_attributes tosca.datatypes.nfv.VnfInfoModifiableAttributes lcm_operations_configuration tosca.datatypes.nfv.VnfLcmOperationsConfiguration monitoring_parameters list of tosca.datatypes.nfv.VnfMonitoringParameter flavour_id flavour_description vnf_profile tosca.datatypes.nfv.VnfProfile org.openecomp.resource.abstract.nodes.VF Required Type nf_function string nf_role nf_type availability_zone_max_count integer min_instances max_instances multi_stage_design boolean Key Points: No type seems to directly map 1:1 https://wiki.onap.org/display/DW/4.3.1.+Node+Types#id-4.3.1.NodeTypes-1.1.1.6.2org.openecomp.resource.abstract.nodes.VF https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/001/02.05.01_60/gs_NFV-SOL001v020501p.pdf page 99

org.openecomp.resource.vf.VcpeInfrastructureGwDemoApp org.openecomp.resource.vf.VcpeInfrastructureGwDemoApp derived_from: org.openecomp.resource.abstract.nodes.VF Required vf_module_id no vcpe_image_name No nf_function public_net_id vgw_name_0 nf_type onap_private_net_cidr nexus_artifact_repo cpe_public_net_id mux_gw_private_net_id mux_ip_addr dcae_collector_ip vnf_id cpe_public_net_cidr dcae_collector_port vg_vgmux_tunnel_vni mux_gw_private_net_cidr nf_naming multi_stage_design nf_naming_code onap_private_net_id availability_zone_max_count demo_artifacts_version max_instances vgw_private_ip_0, vgw_private_ip_1, vgw_private_ip_2 pub_key nf_role install_script_version min_instances cloud_env Key Points VF node types has very few properties (in red), a lot of common properties are added to each node type created by SDC. New common properties are mainly about networking and ONAP specific properties 2) Required for inherited properties is overwritten Recomendation: Create a new data type as ONAP deployment configuration

Nodes.yaml: there is a vfc.nsd as an alloted resource ? org.openecomp.resource.vfc.NSD: derived_from: tosca.nodes.Root description: ECOMP Allotted Resource base type all other allotted resources node types derive from properties: nsd_id: type: string required: true description: ID of the NSD nsd_designer: type: string required: true description: Designer of the NSD nsd_version: type: string required: true description: Version of the NSD nsd_name: type: string required: true description: Name of the NSD providing_service_uuid: type: string required: true description: The depending service uuid in order to map the allotted resource to the specific service version providing_service_invariant_uuid: type: string required: true description: The depending service invariant uuid in order to map the allotted resource to the specific service version providing_service_name: type: string required: true description: The depending service name in order to map the allotted resource to the specific service version requirements: - virtualLink: capability: tosca.capabilities.network.Linkable relationship: tosca.relationships.network.LinksTo capabilities: virtual_linkable: type: tosca.capabilities.network.Linkable OPEN POINTS: How it is used the NSD node type ? It seems that ETSI NSD is modelled as a component of a VF ? As an allotted resource.. Per Lianhao: The description of this node type is wrong, it’s not meant to be as an allotted resource(allotted resource should be derived from org.openecomp.resource.vfc.AllottedResource). It was first introduced during Amsterdam  release(https://git.onap.org/sdc/commit/?id=eb5a085568495aa851078fa9b2db1c663ab0e060). Maybe it’s related to volte case? Per Maopeng: org.openecomp.resource.vfc.NSD is derived_from: tosca.nodes.Root. In my mind, the description may be something wrong. It is not truely implimented in SDC design and just imported as a resource. Recommendation: remove (deprecate) org.openecomp.resource.vfc.NSD from the nodes.yaml type definition generate by SDC. And use SOL001 v2.5.1 tosca.nodes.nfv.NSD type

Is OpenEcomp VF resource an ETSI VNF or a scaling group ? ETSI VNF vs ONAP VF Is OpenEcomp VF resource an ETSI VNF or a scaling group ? Considerations and Recomendations SDC is mapping an ETSI VNF (tosca.nodes.nfv.VNF) to a VF (org.openecomp.resource.vf). Nevertheless, the VF module intention should be to represent a scaling group/ scaling aspect in ETSI more than a full VNF(i.e. the minimum set of entities that can be scaled separated). Multiple VFs can be part of a VNF. The scaling aspect introduction in the Resource Descriptor is lacking and it may impacts resource and indirectly service mappings in SDC It is reccomended to progress a separate investigation about the introduction of the scaling aspects in the internal resource model.

tosca.nodes.nfv.NsVirtualLink vs tosca.nodes.nfv.ext.zte.VL required type segmentation_id string false network_name is_predefined boolean mtu integer dns_nameservers list physical_network dhcp_enabled network_id host_routes list: tosca.datatypes.nfv.ext.HostRouteInfo ip_version vendor name start_ip vlan_transparent cidr gateway_ip network_type end_ip location_info tosca.datatypes.nfv.ext.LocationInfo capabilities: virtual_linkable tosca.capabilities.nfv.VirtualLinkable xx tosca.nodes.nfv.NsVirtualLink type required provider string false version true vl_profile tosca.datatypes.nfv.VlProfile connectivity_type tosca.datatypes.nfv.ConnectivityType qos tosca.datatypes.nfv.Qos service_availability tosca.datatypes.nfv.ServiceAvailability capabilities: VirtualLinkable tosca.capabilities.nfv.VirtualLinkable xx Ref: ns_csar: type_definition.yaml Key points: - No types seem to directly map 1:1 ext.zte.VL was defined prior SOL001 v2.5.1 is defined. There are some similarity of the type. Recommendation: deprecate tosca.nodes.nfv.ext.zte.VL and begin using tosca.nodes.nfv.NsVirtualLink as defined in SOL001 v2.5.1 Ref: service-VcpeWithAll-csar: resource-ExtZteVl-template.yml

Difference of Correlation VNF in VNFD & NSD (1/2) The way vCPE use case used in Casablanca release: using node property (descriptor_id) In NSD topology_template: node_templates: vCPE_Infrastructure_GW_demo_app: type: tosca.nodes.nfv.VNF properties: descriptor_id: 3fca3543-07f5-492f-812c-ed462e4f94f4 provider: onap … … In VNFD substitution_mappings: node_type: tosca.nodes.nfv.VNF

Difference of Correlation VNF in VNFD & NSD (2/2) ONAP-AID: using metadata In NSD topology_template: node_templates: vCPE_Infrastructure_GW_demo_app: type: org.openecomp.resource.vf.VcpeInfrastructureGwDemoApp metadata: invariantUUID: 8ef4e438-a4f8-4f50-bd9b-dec5ddde26d4 UUID: 511fb4ff-6a10-4699-864f-f3e7ad9b34b3 customizationUUID: 18fefb49-7e86-4209-a7da-cd7ddc8aed7b name: vCPE_Infrastructure_GW_demo_app type: VF … … properties: In VNFD tosca_definitions_version: tosca_simple_yaml_1_1 metadata: invariantUUID: 8ef4e438-a4f8-4f50-bd9b-dec5ddde26d4 UUID: 511fb4ff-6a10-4699-864f-f3e7ad9b34b3 name: vCPE_Infrastructure_GW_demo_app type: VF … … topology template: substitution_mappings: node_type: org.openecomp.resource.vf.VcpeInfrastructureGwDemoApp capabilities: node_templates: Key points: - UUID and invarianUUID must not be modelled as metadata type, per TOSCA YAML because the data provided within metadata, may be ignored by TOSCA orchestrator and should not affect runtime behavior.

Recommendation: based on TOSCA grammar and ETSI NFV SOL001 v2.5.1 In NSD topology_template: node_templates: vCPE_Infrastructure_GW_demo_app: type: tosca.nodes.infGW.VNF properties: flavour_id: simple vnf_profile: instantiation_Level: level_1 min_number_of_instances: 2 max_number_of_instances: 6 In VNFD substitution_mappings: node_type: tosca.nodes.infGW.VNF requirements: virtual_link: Note：The type definition of tosca.nodes.infGW.VNF will be included in another yaml file inside the VNF CSAR package. Correlation based on the same type name Key points: - the node type “org.openecomp.resource.vf.VcpeInfrastructureGwDemoApp” is derived from AID’s own node_type ‘org.openecomp.resource.abstract.nodes.VF’, not derived from ETSI SOL001’s ‘tosca.nodes.nfv.VNF’. These 2 type definitions have different properties. There seems to be no simple 1-to-1 mapping between these 2 node types.

Open questions To be confirmed with SDC that NSD CSAR package is supported by SDC or manual added.

Backup

org.openecomp.resource.abstract.nodes.VF: org.openecomp.resource.abstract.nodes.VF: derived_from: tosca.nodes.Root properties: nf_function: type: string nf_role: type: string nf_naming_code: type: string nf_type: type: string nf_naming: type: org.openecomp.datatypes.Naming Default: true availability_zone_max_count: type: integer default: 1 constraints: - valid_values: - 0 - 1 - 2 min_instances: type: integer max_instances: type: integer multi_stage_design: type: boolean default: false by default these properties are required: true However, the derived_type defined differently. This may seems like a bug in the type definition. These properties are more or less describing network function similar to PNF. Similar to SOL001: vnf_profile

Resource-VcpeInfrstructureGwDemoApp-template-interface.yaml capabilities: vl_mux_gw_private_net.feature: type: tosca.capabilities.Node occurrences: - 1 - UNBOUNDED valid_source_types: [ ] vdu_vgw_0.virtual_compute: type: tosca.capabilities.nfv.VirtualCompute occurrences: - 1 - UNBOUNDED valid_source_types: [ ] properties: virtual_memory: type: tosca.datatypes.nfv.VirtualMemory required: true requested_additional_capabilities: type: map required: false entry_schema: type: tosca.datatypes.nfv.RequestedAdditionalCapability compute_requirements: type: map required: false entry_schema: type: string logical_node: type: tosca.datatypes.nfv.LogicalNodeData required: false virtual_cpu: type: tosca.datatypes.nfv.VirtualCpu required: true cp_vgw_public.feature: type: tosca.capabilities.Node occurrences: - 1 - UNBOUNDED valid_source_types: [ ] llu_vnf.feature: type: tosca.capabilities.Node occurrences: - 1 - UNBOUNDED valid_source_types: [ ] vl_cpe_public.monitoring_parameter: type: tosca.capabilities.nfv.Metric occurrences: - 0 - UNBOUNDED valid_source_types: [ ] vl_cpe_public.feature: type: tosca.capabilities.Node occurrences: - 1 - UNBOUNDED valid_source_types: [ ] vl_cpe_public.virtual_linkable: type: tosca.capabilities.nfv.VirtualLinkable occurrences: - 1 - UNBOUNDED valid_source_types: [ ] vdu_vgw_0.monitoring_parameter: type: tosca.capabilities.nfv.Metric occurrences: - 0 - UNBOUNDED valid_source_types: [ ] vl_mux_gw_private_net.monitoring_parameter: type: tosca.capabilities.nfv.Metric occurrences: - 0 - UNBOUNDED valid_source_types: [ ] virtualstorage_root_all.feature: type: tosca.capabilities.Node occurrences: - 1 - UNBOUNDED valid_source_types: [ ] cp_vgw_cpe_public.feature: type: tosca.capabilities.Node occurrences: - 1 - UNBOUNDED valid_source_types: [ ] cp_vgw_mux_gw_private_net.feature: type: tosca.capabilities.Node occurrences: - 1 - UNBOUNDED valid_source_types: [ ] vdu_vgw_0.virtual_binding: type: tosca.capabilities.nfv.VirtualBindable occurrences: - 1 - UNBOUNDED valid_source_types: [ ] virtualstorage_root_all.virtual_storage: type: tosca.capabilities.nfv.VirtualStorage occurrences: - 1 - UNBOUNDED valid_source_types: [ ] vl_mux_gw_private_net.virtual_linkable: type: tosca.capabilities.nfv.VirtualLinkable occurrences: - 1 - UNBOUNDED valid_source_types: [ ] cp_vgw_onap_private.feature: type: tosca.capabilities.Node occurrences: - 1 - UNBOUNDED valid_source_types: [ ] vdu_vgw_0.feature: type: tosca.capabilities.Node occurrences: - 1 - UNBOUNDED valid_source_types: [ ] requirements: - cp_vgw_mux_gw_private_net.dependency: occurrences: - 0 - UNBOUNDED capability: tosca.capabilities.Node node: tosca.nodes.Root relationship: tosca.relationships.DependsOn - virtualstorage_root_all.dependency: occurrences: - 0 - UNBOUNDED capability: tosca.capabilities.Node node: tosca.nodes.Root relationship: tosca.relationships.DependsOn - cp_vgw_public.dependency: occurrences: - 0 - UNBOUNDED capability: tosca.capabilities.Node node: tosca.nodes.Root relationship: tosca.relationships.DependsOn - vdu_vgw_0.dependency: occurrences: - 0 - UNBOUNDED capability: tosca.capabilities.Node node: tosca.nodes.Root relationship: tosca.relationships.DependsOn - cp_vgw_cpe_public.dependency: occurrences: - 0 - UNBOUNDED capability: tosca.capabilities.Node node: tosca.nodes.Root relationship: tosca.relationships.DependsOn - vl_cpe_public.dependency: occurrences: - 0 - UNBOUNDED capability: tosca.capabilities.Node node: tosca.nodes.Root relationship: tosca.relationships.DependsOn - llu_vnf.dependency: occurrences: - 0 - UNBOUNDED capability: tosca.capabilities.Node node: tosca.nodes.Root relationship: tosca.relationships.DependsOn - cp_vgw_onap_private.dependency: occurrences: - 0 - UNBOUNDED capability: tosca.capabilities.Node node: tosca.nodes.Root relationship: tosca.relationships.DependsOn - vl_mux_gw_private_net.dependency: occurrences: - 0 - UNBOUNDED capability: tosca.capabilities.Node node: tosca.nodes.Root relationship: tosca.relationships.DependsOn - vdu_vgw_0.virtual_storage: occurrences: - 1 - UNBOUNDED capability: tosca.capabilities.nfv.VirtualStorage node: tosca.nodes.nfv.Vdu.VirtualStorage relationship: tosca.relationships.nfv.Vdu.AttachedTo - cp_vgw_mux_gw_private_net.virtual_link: occurrences: - 1 - UNBOUNDED capability: tosca.capabilities.nfv.VirtualLinkable node: tosca.nodes.nfv.VnfVirtualLink relationship: tosca.relationships.nfv.VirtualLinksTo - cp_vgw_public.virtual_link: occurrences: - 1 - UNBOUNDED capability: tosca.capabilities.nfv.VirtualLinkable node: tosca.nodes.nfv.VnfVirtualLink relationship: tosca.relationships.nfv.VirtualLinksTo - cp_vgw_cpe_public.virtual_link: occurrences: - 1 - UNBOUNDED capability: tosca.capabilities.nfv.VirtualLinkable node: tosca.nodes.nfv.VnfVirtualLink relationship: tosca.relationships.nfv.VirtualLinksTo - llu_vnf.virtual_link: occurrences: - 0 - UNBOUNDED capability: tosca.capabilities.nfv.VirtualLinkable node: tosca.nodes.nfv.VnfVirtualLink relationship: tosca.relationships.nfv.VirtualLinksTo - cp_vgw_onap_private.virtual_link: occurrences: - 1 - UNBOUNDED capability: tosca.capabilities.nfv.VirtualLinkable node: tosca.nodes.nfv.VnfVirtualLink relationship: tosca.relationships.nfv.VirtualLinksTo - cp_vgw_mux_gw_private_net.virtual_binding: occurrences: - 1 - UNBOUNDED capability: tosca.capabilities.nfv.VirtualBindable node: tosca.nodes.nfv.Vdu.Compute relationship: tosca.relationships.nfv.VirtualBindsTo - cp_vgw_public.virtual_binding: occurrences: - 1 - UNBOUNDED capability: tosca.capabilities.nfv.VirtualBindable node: tosca.nodes.nfv.Vdu.Compute relationship: tosca.relationships.nfv.VirtualBindsTo - cp_vgw_cpe_public.virtual_binding: occurrences: - 1 - UNBOUNDED capability: tosca.capabilities.nfv.VirtualBindable node: tosca.nodes.nfv.Vdu.Compute relationship: tosca.relationships.nfv.VirtualBindsTo - cp_vgw_onap_private.virtual_binding: occurrences: - 1 - UNBOUNDED capability: tosca.capabilities.nfv.VirtualBindable node: tosca.nodes.nfv.Vdu.Compute relationship: tosca.relationships.nfv.VirtualBindsTo   node_types: org.openecomp.resource.vf.VcpeInfrastructureGwDemoApp: derived_from: org.openecomp.resource.abstract.nodes.VF properties: vf_module_id: default: vCPE_Customer_GW type: string description: The vCPE Module ID is provided by ONAP required: false vcpe_image_name: default: ubuntu_16.04 type: string description: image name for vcpe in openstack glance required: false nf_function: type: string required: false public_net_id: type: string description: public network id used during onap installation required: false vgw_name_0: default: zdcpe1cpe01gw01 type: string description: Name of the vGW required: false nf_type: type: string required: false onap_private_net_cidr: default: 10.0.0.0/16 type: string description: oanp OAM network cidr required: false nexus_artifact_repo: default: https://nexus.onap.org type: string description: Root URL for the Nexus repository for Maven

Resource-vcpeInfrastructureGwDemoApp-template substitution_mappings: node_type: org.openecomp.resource.vf.VcpeInfrastructureGwDemoApp capabilities: vl_mux_gw_private_net.feature: - vl_mux_gw_private_net - feature vdu_vgw_0.virtual_compute: - vdu_vgw_0 - virtual_compute cp_vgw_public.feature: - cp_vgw_public - feature llu_vnf.feature: - llu_vnf - feature vl_cpe_public.monitoring_parameter: - vl_cpe_public - monitoring_parameter vl_cpe_public.feature: - vl_cpe_public - feature vl_cpe_public.virtual_linkable: - vl_cpe_public - virtual_linkable vdu_vgw_0.monitoring_parameter: - vdu_vgw_0 - monitoring_parameter vl_mux_gw_private_net.monitoring_parameter: - vl_mux_gw_private_net - monitoring_parameter virtualstorage_root_all.feature: - virtualstorage_root_all - feature cp_vgw_cpe_public.feature: - cp_vgw_cpe_public - feature cp_vgw_mux_gw_private_net.feature: - cp_vgw_mux_gw_private_net - feature vdu_vgw_0.virtual_binding: - vdu_vgw_0 - virtual_binding virtualstorage_root_all.virtual_storage: - virtualstorage_root_all - virtual_storage vl_mux_gw_private_net.virtual_linkable: - vl_mux_gw_private_net - virtual_linkable cp_vgw_onap_private.feature: - cp_vgw_onap_private - feature vdu_vgw_0.feature: - vdu_vgw_0 - feature requirements: cp_vgw_public.dependency: - cp_vgw_public - dependency vdu_vgw_0.virtual_storage: - vdu_vgw_0 - virtual_storage vl_mux_gw_private_net.dependency: - vl_mux_gw_private_net - dependency cp_vgw_cpe_public.virtual_binding: - cp_vgw_cpe_public - virtual_binding cp_vgw_mux_gw_private_net.virtual_binding: - cp_vgw_mux_gw_private_net - virtual_binding cp_vgw_cpe_public.dependency: - cp_vgw_cpe_public - dependency cp_vgw_public.virtual_link: - cp_vgw_public - virtual_link cp_vgw_onap_private.virtual_link: - cp_vgw_onap_private - virtual_link cp_vgw_mux_gw_private_net.virtual_link: - cp_vgw_mux_gw_private_net - virtual_link virtualstorage_root_all.dependency: - virtualstorage_root_all - dependency vdu_vgw_0.dependency: - vdu_vgw_0 - dependency cp_vgw_cpe_public.virtual_link: - cp_vgw_cpe_public - virtual_link cp_vgw_mux_gw_private_net.dependency: - cp_vgw_mux_gw_private_net - dependency vl_cpe_public.dependency: - vl_cpe_public - dependency llu_vnf.dependency: - llu_vnf - dependency cp_vgw_onap_private.dependency: - cp_vgw_onap_private - dependency llu_vnf.virtual_link: - llu_vnf - virtual_link cp_vgw_public.virtual_binding: - cp_vgw_public - virtual_binding cp_vgw_onap_private.virtual_binding: - cp_vgw_onap_private - virtual_binding   1 yaml file per node LLU_VNF: type: tosca.nodes.nfv.VNF VL_cpe_public: type: tosca.nodes.nfv.VnfVirtualLink VL_mux_gw_private_net:type: tosca.nodes.nfv.VnfVirtualLink VDU_vgw_0:type: tosca.nodes.nfv.Vdu.Compute VirtualStorage_root_all: type: tosca.nodes.nfv.Vdu.VirtualStorage Cp_vgw_mux_gw_private_net:type: tosca.nodes.nfv.VduCp Cp_vgw_cpe_public: type: tosca.nodes.nfv.VduCp Cp_vgw_public: type: tosca.nodes.nfv.VduCp Cp_vgw_onap_private:type: tosca.nodes.nfv.VduCp