Table of Contents
...
Epic | User Story | Description | Guilin Plan? | JIRA | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Onboard and Design ETSI SOL004 compliant VNF packages | Executive Summary - Enable a vendor provided ETSI SOL004 compliant VNF package including an ETSI SOL001 VNF Descriptor to be onboarded into ONAP for composition into an ONAP Service Business Impact - Enables operators and service providers to use same ETSI compliant VNF packages with ONAP and existing NFVO. Industry compatibility. Business Markets - All operators that are currently using ETSI packages to deploy VNFs Funding/Financial Impacts - Reduction in operations expense from using industry standard VNF packaging. Reduction in capital expense from vendors using a single packaging methodology. Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. | Yes |
| ||||||||||||||
Support for onboarding ETSI v2.7.1 SOL001 VNF Descriptor (Link to ETSI SOL001 v2.7.1) |
| Yes |
| ||||||||||||||
Support for mapping of ETSI v2.7.1 SOL001 VNF Descriptor into SDC AID Data Model | Support for mapping of ETSI v2.7.1 SOL001 VNF Descriptor into SDC AID Data Model | Yes |
| Support for editing ETSI v2.7.1 SOL001 VNF Descriptor |
| Yes | | Jira Legacy | | |||||||||
| server | System Jira | serverId | 4733707d-2057-Yes |
| |||||||||||||
| Support for editing ETSI v2.7.1 SOL001 VNF Descriptor |
| Yes |
| ||||||||||||||
Support for using an ETSI v2.7.1 VNF in an ONAP Service |
| TBD | |||||||||||||||
| Support the substitution_mappings in the VNFD. | Currently, the substitution_mappings is not supported by SDC. Lack of this support blocks SOL004 VNF package management and ETSI Catalog Manager:
Support of the substitution_mappings and user-defined node_types will remove the issues and support ETSI package management and others. Support of the user-defined node types is handled by another task. This task needs to handle the substitution_mappings only. For the testing, use the vgw6.csar For the Frankfurt release workaround, we added the following to the MainServiceTemplate.yaml, so the ETSI Catalog Manager can retrieve the descriptor_id from the metadata, instead of from the node_type. Once the substitution_mapping is supported by SDC, we don't have to use the descriptor_id in the metadata section.
| Yes |
| ||||||||||||||
Onboard ETSI SOL007 compliant Network Service Descriptor packages | Executive Summary - Onboard an ETSI SOL007 v2.7.1 compliant (Link to ETSI SOL007 v2.7.1) Network Service Descriptor package including an ETSI version 2.7.1 SOL001 Network Service Descriptor (NSD) to be onboarded into ONAP for composition into an ONAP Service or deployment using an ETSI compliant NFVO.
Business Markets - All operators and service providers that are developing ETSI compatible Network Services Funding/Financial Impacts - Reduction in operations expense from using industry standard NSD packaging. Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. | stretch goal |
| ||||||||||||||
| Support onboarding for Cataloging and Preserving the original SOL007 package | Support onboarding for Cataloging and Preserving the original SOL007 package (Link to ETSI SOL001 v2.7.1) | stretch goal |
| ||||||||||||||
| Support for mapping of ETSI v2.7.1 SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data Model | Support for mapping of ETSI v2.7.1 SOL001 Network Service Descriptor in the SOL007 package into SDC AID Data Model
| stretch goal |
| ||||||||||||||
Close this, expect the current SDC distribution is sufficient | |||||||||||||||||
Close this, expect the current SDC distribution is sufficient | |||||||||||||||||
Design ETSI SOL007 compliant Network Service Descriptor & packages | Executive Summary - Design, catalog and distribute an ETSI SOL007 v2.7.1 compliant (Link to ETSI SOL007 v2.7.1) Network Service Descriptor package including an ETSI version 2.7.1 SOL001 Network Service Descriptor (NSD) for deployment using an ETSI compliant NFVO.
Business Impact - Enables operators and service providers to use vendor provided and internally designed Network Service Descriptors with ONAP and existing NFVO. Industry compatibility. Business Markets - All operators and service providers that are developing ETSI compatible Network Services Funding/Financial Impacts - Reduction in operations expense from using industry standard NSD packaging. Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. | Yes |
Note: there is a PoC for this. Soon, the PoC design could be shared as initial input for discussions | ||||||||||||||
| Design ETSI SOL001 NSD and generate an ETSI SOL001 v2.7.1 compliant Network Service Descriptor & package | Design ETSI SOL001 NSD and generate ETSI SOL007 v2.7.1 compliant Network Service package
| Yes |
| ||||||||||||||
| Close this, expect the current SDC distribution is sufficient | ||||||||||||||||
| Close this, expect the current SDC distribution is sufficient | ||||||||||||||||
| Support design of Service templates, leveraging NSDs | Support design of Service templates, leveraging NSDs | Yes |
| ||||||||||||||
| Change the ONBOARDED_PACKAGE directory to ETSI_PACKAGE directory | Change the ONBOARDED_PACKAGE directory to ETSI_PACKAGE directory | Yes |
| ||||||||||||||
| Support for Nested/Hierarchical ETSI SOL001 v2.7.1 Network Service Descriptor | Executive Summary - Onboard an ETSI SOL007 v2.7.1 compliant (Link to ETSI SOL007 v2.7.1) Network Service Descriptor package including an ETSI version 2.7.1 SOL001 Network Service Descriptor (NSD) that includes references to other Network Service Descriptors for composition into an ONAP Service or deployment using an ETSI compliant NFVO. Business Impact - Enables operators and service providers to use vendor provided and internally designed Network Service Descriptors with ONAP and existing NFVO. Industry compatibility. Business Markets - All operators and service providers that are developing ETSI compatible Network Services especially for 5G Slicing where each Slice Subnet is associated with a Network Service Funding/Financial Impacts - Reduction in operations expense from using industry standard NSD packaging. Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. | No |
| ||||||||||||||
| Support for onboarding of the SOL007 v2.7.1 compliant NSD package including SOL001 NSD that includes references to other NSDs for composition into ONAP Service | Support for onboarding of the SOL007 v2.7.1 compliant NSD package including SOL001 NSD that includes references to other NSDs for composition into ONAP Service | No |
| ||||||||||||||
| Onboard ETSI SOL004 compliant PNF packages | Executive Summary - Enable a vendor provided ETSI SOL004 compliant PNF package including an ETSI SOL001 PNF Descriptor to be onboarded into ONAP for composition into an ONAP Service Business Impact - Enables operators and service providers to use same ETSI compliant PNF packages with ONAP and existing NFVO. Industry compatibility. Business Markets - All operators that are currently using ETSI packages to deploy PNFs Funding/Financial Impacts - Reduction in operations expense from using industry standard PNF packaging. Reduction in capital expense from vendors using a single packaging methodology. Organization Mgmt, Sales Strategies -There is no additional organizational management or sales strategies for this requirement outside of a service providers "normal" ONAP deployment and its attendant organizational resources from a service provider. | Yes |
| ||||||||||||||
SDC supports onboarding of the SOL004 PNF package includes SOL001 PNFD
|
| Yes |
| ||||||||||||||
Support for mapping of ETSI v2.7.1 SOL001 PNF Descriptor into SDC AID Data Model | SOL001 PNFD 2.7.1 Mapping to SDC AID DM | Yes |
| ||||||||||||||
| Support additional package artifact Indicators for ETSI packages and Non-ETSI packages | SDC supports additional package artifact types to split ETSI packages from other non-ETSI TOSCA packages
| Yes |
| ||||||||||||||
| SDC Notification supports additional package artifact types to split ETSI package from other non-ETSI TOSCA packages | SDC (Notification) supports additional package artifact types to split ETSI package from other non-ETSI TOSCA packages
| Yes |
| ||||||||||||||
| SDC client supports additional filtering on the artifact types for distinguishing between ETSI packages and Non-ETSI packages | SDC client supports additional filtering on the artifact types for distinguishing between ETSI packages and Non-ETSI packages
| Yes |
| ||||||||||||||
| Support ETSI Package Security and validation |
| Yes |
| ||||||||||||||
|
| Done | |||||||||||||||
|
| Yes |
| ||||||||||||||
| Support of ETSI Package Validation | VNF SDK will support ETSI package validation for VNF and NS | TBD | |||||||||||||||
| VNF SDK will support ETSI VNF package pre-onboarding for validation | VNF SDK will support ETSI VNF package pre-onboarding for validation | TBD | |||||||||||||||
| VNF SDK will support ETSI NS package pre-onboarding for validation | VNF SDK will support ETSI NS package pre-onboarding for validation | TBD |
...
There are two options. For now, we chose the option A. The option B is under discussion.
Option A (chosen):
Define a new data type based on the org.openecomp.resource.abstract.nodes.VF with ETSI SOL001 VNF data type attributes.
...
type attributes.
- Make the org.openecomp.resource.abstract.nodes.ETSI.VNF a superset of both tosca.nodes.nfv.VNF and org.openecomp.resource.abstract.node.VF
- During VNF onboarding, SDC copies SOL001 VNF attribute contents to the corresponding attributes in the org.openecomp.resource.abstract.nodes.ETSI.VNF a superset of both tosca.nodes.nfv.VNF and org.openecomp.resource.abstract.node.VF
- During VNF onboarding, SDC copies SOL001 VNF attribute contents to the corresponding attributes in tte org.openecomp.resource.abstract.nodes.ETSI.VNF
- SOL001 VNF attributes in SDC AID DM VNF will be visible to SDC UI, so SDC UI can change the attributesVNF
- In Guilin, SO NFVO, VFC and SVNFM get those SOL001 VNF attributes from the descriptor, not from AAI. So, AAI schema changes are not expected in Guilin.
- SOL001 VNF attributes in SDC AID DM VNF will be visible to SDC UI, so SDC UI can change the attributes.
- But the onboarded vendor ETSI package will note be changed by the SDC UI users in Guilin.
- Since SO NFVO, VFC and SVNFM use only the original ETSI package, those changes will not be used in Guilin;
- For the Honolulu release, it is under consideration
- to sync up between those modified SOL001 VNF attributes and the vendor ETSI Package attributes
- to reflect those modified SOL001 VNF attributes in the orchestration
- ONAP specific attributes that are inherited from the org.openecomp.resource.abstract.nodes.VF will be filled up by SDC (design time)
- Those attribute contents will not be mapped back into the SOL001 VNF (reverse mapping). For that case, only the SOL001 VNF corresponding attributes will be copied
...
SOL001 VNF (tosca.nodes.nfv.VNF) | Mapping | New SDC AID DM VNF (org.openecomp.resource.abstract.nodes.ETSI.VNF) derived from org.openecomp.resource.abstract.nodes.VF | ||||
|---|---|---|---|---|---|---|
| name | required | type | name | required | type | |
| <SOL001 tosca.nodes.nfv.VNF attributes > | <SOL001 tosca.nodes.nfv.VNF attributes > | |||||
| descriptor_id | yes | string | <--> | descriptor_id | yes | string |
| descriptor_version | yes | string | <--> | descriptor_version | yes | string |
| provider | yes | string | <--> | provider | yes | string |
| product_name | yes | string | <--> | product_name | yes | string |
| software_version | yes | string | <--> | software_version | yes | string |
| product_info_name | no | string | <--> | product_info_name | no | string |
| vnfm_info | yes | list of string | <--> | vnfm_info | yes | list of string |
| localization_languages | no | list of string | <--> | localization_languages | no | list of string |
| default_localization_language | no | string | <--> | default_localization_language | no | string |
| configurable_properties | no | tosca.datatypes.nfv.VnfconfigurableProperties | <--> | configurable_properties | no | tosca.datatypes.nfv.VnfconfigurableProperties |
| modifiable_attributes | no | tosca.datatypes.nfv.VnfInfoModifiableAttributes | <--> | modifiable_attributes | no | tosca.datatypes.nfv.VnfInfoModifiableAttributes |
| lcm_operations_configuration | no | tosca.datatypes.nfv.VnfLcmOperationsConfiguration | <--> | lcm_operations_configuration | no | tosca.datatypes.nfv.VnfLcmOperationsConfiguration |
| monitoring_parameters | no | list of tosca.datatypes.nfv.VnfMonitoringParameter | <--> | monitoring_parameters | no | list of tosca.datatypes.nfv.VnfMonitoringParameter |
| flavour_id | yes | string | <--> | flavour_id | yes | string |
| flavour_description | yes | string | <--> | flavour_description | yes | string |
| vnf_profile | no | tosca.datatypes.nfv.VnfProfile | <--> | vnf_profile | no | tosca.datatypes.nfv.VnfProfile |
| <SDC AID DM VF attributes that are inherited from org.openecomp.resource.abstract.nodes.VF> | ||||||
| nf_function | no | string | ||||
| nf_role | no | string | ||||
| nf_type | no | string | ||||
| nf_naming_code | no | string | ||||
| nf_naming | no | org.openecomp.datatypes.Naming | ||||
| availability_zone_max_count | no | integer | ||||
| min_instances | no | integer | ||||
| max_instances | no | integer | ||||
| multi_stage_design | no | boolean | ||||
| sdnc_model_name | no | string | ||||
| sdnc_artifact_name | no | string | ||||
| skip_post_instantiation_configuration | no | boolean (default true)
| ||||
| controller_actor | no | string (default: SO-REF-DATA)
| ||||
Option B:
Define a new data type based on the tosca.nodes.nfv.VNF with SDC AID DM VNF data type attributes.
SDC AID DM VNF data type attributes will be handled as the 'additionalAttributes', which is a map of key, value pairs.Those attribute contents will not be mapped back into the SOL001 VNF (reverse mapping). For that case, only the SOL001 VNF corresponding attributes will be copied.
| ||
|---|---|---|
SOL001 VDU mapping to/from VNF SDC AID DM VFC
...
| SOL001 VDU | SDC AID DM VFC (org.openecomp.resource.abstract.nodes.VFC) | ||||
|---|---|---|---|---|---|
| Name | Required | Type | Name | Required | Type |
| name | yes | string | nfc_function | string | |
| description | yes | string | high_availability | no | string |
| boot_order | no | boolean | vm_image_name | string | |
| nfvi_constraints | no | map of string | vm_flavor_name | yes | string |
| monitoring_parameters | no | list of tosca.datatypes.nfv.VnfcMonitoringParameter | nfc_naming_code | no | string |
| configurable_properties | no | map of tosca.datatypes.nfv.VnfcConfigurableProperties | vm_type_tag | no | string |
| boot_data | no | tosca.datatypes.nfv.BootData | nfc_naming | org.openecomp.datatypes.Naming
| |
| vdu_profile | yes | tosca.datatypes.nfv.VduProfile | min_instances | no | integer |
| sw_image_data | no | tosca.datatypes.nfv.SwImageData | |||
Solutions for VDU and VFC mapping
...
and VFC mapping
- Make the org.openecomp.resource.abstract.nodes.ETSI.VFC a superset of both tosca.nodes.nfv.Vdu and org.openecomp.resource.abstract.nodes.VFC
- Note: the org.openecomp.resource.abstract.nodes.VFC represents design-time VFC, not VFC instances
- During VNF onboarding, SDC copies SOL001 VDU attribute contents to the corresponding attributes in the org.openecomp.resource.abstract.nodes.ETSI.VFC a superset of both tosca.nodes.nfv.Vdu and org.openecomp.resource.abstract.nodes.VFCNote: the org.openecomp.resource.abstract.nodes.VFC represents design-time VFC, not VFC instancesVFC
- In Guilin, SO NFVO, VFC and SVNFM get those SOL001 VDU attributes from the descriptor, not from AAI. So, AAI schema changes are not expected in Guilin.
- SOL001 VDU attributes in SDC AID DM VNF will be visible to SDC UI, so SDC UI can change the attributes.
- But the onboarded vendor ETSI package will note be changed by the SDC UI users in Guilin.
- Since SO NFVO, VFC and SVNFM use only the original ETSI package, those changes will not be used in Guilin;
- For the Honolulu release, it is under consideration
- to sync up between those modified SOL001 VDU attributes and the vendor ETSI Package attributes
- to reflect those modified SOL001 VDU / VFC attributes in the orchestration
New SDC AID DM VFC type (org.openecomp.resource.abstract.nodes.ETSI.VFC)
...
| SOL001 VNFD | SDC AID DM VFD | |||
|---|---|---|---|---|
| Name | Grammar | Name | Grammar | |
| tosca_definitions_version | string (tosca_simple_yaml_1_2) | tosca_definitions_version | string (tosca_simple_yaml_1_2) | |
| description | string | description | string | |
| metadata | map of <string> | metadata | map of <string> | |
| imports | Single-line grammar
Multi-line grammar
| imports | Identifies the lower level models (VFC, CP, VL, heat) | |
| data_types | <data_type_name>: derived_from: <existing_type_name> version: <version_number> metadata: <map of string> description: <datatype_description> constraints: - <type_constraints> properties: <property_definitions> | data_types | <data_type_name>: derived_from: <existing_type_name> version: <version_number> metadata: <map of string> description: <datatype_description> constraints: - <type_constraints> properties: <property_definitions> | |
| node_types | <node_type_name>: derived_from: <parent_node_type_name> version: <version_number> metadata: <map of string> description: <node_type_description> attributes: <attribute_definitions> properties: <property_definitions> requirements: - <requirement_definitions> capabilities: <capability_definitions> interfaces: <interface_definitions> artifacts: <artifact_definitions> | node_types | <node_type_name>: derived_from: <parent_node_type_name> version: <version_number> metadata: <map of string> description: <node_type_description> attributes: <attribute_definitions> properties: <property_definitions> requirements: - <requirement_definitions> capabilities: <capability_definitions> interfaces: <interface_definitions> artifacts: <artifact_definitions> | |
| topology_template | topology_template: description: <template_description> inputs: <input_parameter_list> outputs: <output_parameter_list> node_templates: <node_template_list> relationship_templates: <relationship_template_list> groups: <group_definition_list> policies: - <policy_definition_list> workflows: <workflow_list> # Optional declaration that exports the Topology Template # as an implementation of a Node Type. substitution_mappings: <substitution_mappings> | topology_template | similar, but the following are different
| |
| string |
| string | |
|
| <parameter name>: type: <parameter_type> description: <parameter_description> required: <parameter_required> default: <parameter_default_value> constraints: - <parameter_constraints> | ||
| vnf: tosca.nodes.nfv.Vnf vdu: tosca.nodes.nfv.Vdu vl: tosca.nodes.nfv.VnfVirtualLink vduCp: tosca.nodes.nfv.VduCp vduCompute: tosca.nodes.nfv.Vdu.Compute |
| vfc: type: org.openecomp.resources.vfc.<> vl: type: org.openecomp.resources.vl.<> cp: type: org.openecomp.resources.cp.<> allotted_resource: type: org.openecomp.resource.allottedResource.<> | |
| <workflow name> | |||
policies
| tosca.datatypes.nfv.ScalingAspect
|
| list of VF Modules VFModule_Base: type: org.openecomp.groups.VfModule VFModule_Expansion: type: org.openecomp.groups.VfModule | |
| optional list of policies | |||
| substitution_mappings | substitution_mappings | |||
|
| |||
| <capability_type_name>: derived_from: <parent_capability_type_name> version: <version_number> description: <capability_description> properties: <property_definitions> attributes: <attribute_definitions> valid_source_types: [ <node type_names> ] | capabilities | <capability_type_name>: derived_from: <parent_capability_type_name> version: <version_number> description: <capability_description> properties: <property_definitions> attributes: <attribute_definitions> valid_source_types: [ <node type_names> ] | |
|
| |||
| group | not defined | group | <group_type_name>: derived_from: <parent_group_type_name> version: <version_number> metadata: <map of string> description: <group_description> properties: <property_definitions> members: [ <list_of_valid_member_types> ] requirements: - <requirement_definitions> capabilities: | |
| policy | only the Abstract.SecurityGroupRule policy type is defined
| policy | <policy_type_name>: derived_from: <parent_policy_type_name> version: <version_number> metadata: <map of string> description: <policy_description> properties: <property_definitions> targets: [ <list_of_valid_target_types> ] triggers: <list_of_trigger_definitions> | |
| relationship | tosca.relationships.nfv.VirtualBindsTo tosca.relationships.nfv.AttachesTo | relationship | <relationship_type_name>: derived_from: <parent_relationship_type_name> version: <version_number> metadata: <map of string> description: <relationship_description> properties: <property_definitions> attributes: <attribute_definitions> interfaces: <interface_definitions> valid_target_types: [ <capability_type_names> ] | |
| annotation_type | <annotation_type_name>: version: <version_number> description: <annotation_type_description> properties: <property_definitions> | |||
| annotation | <annotation_name>: type: <annotation_type> properties: <property_assignments> | |||
...
- SOL001 concept of Aspect+ScalingDelta combination is one to one with the ONAP concept of VF Module.
- SOL001 concept of VDU is one to one with the ONAP concept of A&AI vServer
- SOL001 concept of a connection point associated with a VDU corresponds to the ONAP concept of the same name, as does the understanding of the meaning of “internal” versus “external” connection point.
- ONAP-compliant SOL001 VNF Vendors will be obliged to name their HEAT files using a naming convention that encodes the SOL001 Aspect+ScalingDelta names
- ONAP-compliant SOL001 VNF Vendors will be obliged to name their SOL001 Aspect+ScalingDelta parameters using a naming convention that readily maps to the corresponding HEAT properties.
- In addition, if AT&T has already deployed such a vendor’s VNF into its network, the HEAT naming will remain invariant, and (at least) the (AT&T version of that) SOL001 be written to match it.
- What to do
- ONAP will be extended to incorporate the constructs of Aspect and Scaling Level. This includes SDC’s, SOs, and A&AI’s modeling of these constructs and A&AI's ability to capture and SO’s ability to set/update the "current scaling level" of a VNF for a given Aspect.
- If ETSI in their SOL001 VNFD had defined a "ScalingDelta" in a straightforward manner, i.e., in terms of the VNFCs that comprise it, then it would be very easy to extract VF Module information from the VNFD. (I would like to see ETSI define "ScalingDelta" in this manner, as opposed to the current way they do so. ) However, given that they did not, ONAP SDC would need to be extended to derive the VF Module “structure” from the SOL001 document through the algorithm below. “Structure” in this case includes the VDU topology, connection points and associated parameters. This algorithm will:
- Determine the set of Aspects and corresponding VDUs and associated ScalingDeltas (step_deltas) from the SOL001.
- Determine the set of ScalingLevels associated with each Aspect and the ScalingDeltas associated with each.
- Translate the VDU-centric representation of ScalingDeltas (step_deltas) as per SOL001 to come up with a ScalingDelta-centric representation that captures the number and type of VDUs associated with that ScalingDelta across the various VDU types.
- Create a VF Module object that corresponds to each ScalingDelta-centric representation of a ScalingDelta calculated above.
- Fill in the details of the VF Module object based on the SOL001 data to represent the VDU connection points, associated Networks (internal or external), and associated Parameters.
- Determine if there is an artifact in the SOL004 package that is a HOT YAML whose file name corresponds (through a VNF vendor obligatory naming convention) to the Aspect+ScalingDelta from which this VF Module object was derived. If so, associate that HOT file with the VF Module.
- Name the VF Module based on a naming convention to capture the Aspect+ScalingDelta names
- Determine and capture the mapping from each Aspect + ScalingLevel model for the VNF to the corresponding VF Module.
- Given a desired state Aspect+ScalingLevel, will be able to calculate (from the SDC distributed mapping of Aspect+ScalingLevel to VF Module along with the current Scaling Level for this Aspect as per A&AI) the (ordered set of) VF Module(s) needed to take that VNF from the “current scaling level” to the desired level for that Aspect.
- Note: As an aside, SDC enhancements are being discussed. It is not clear if the SDC changes will be available in the Dublin time frame. some “stubbing off” SDC with a simulator could be suggested to at least prove in the run-time aspects of the solution.
Solution:
- SDC deduces the VF-Module from the SOL001 VNFD Policies>scaling_aspects>properties>aspects
- Additional VF-Module attributes are deduced as the following table
- SOL003 Adapter may need to transform the VF-Module back to the SOL001 VNFD policies for the scaling and healing requests from VNFM(s) – not part of Guilin
Gliffy macroId 4e072032-7cad-4d7d-befc-a60416101d10 name ONAP ETSI-Alignment VF-Module Mapping pagePin 7
| macroId | 4e072032-7cad-4d7d-befc-a60416101d10 |
|---|---|
| name | ONAP ETSI-Alignment VF-Module Mapping |
| pagePin | 7 |
...