The request for review was started on April 10th, and now is closed. The comments received are marked in red in the table, all others do not have any comments/requests for now. In conclusion, the working consumpion is that the IM resource team is satisfied with the response.
If new issues arrived, a new request would be created.
ETSI NFV Industry Specification Group (ISG) IFA and SOL WGs thanks ONAP Modelling sub-committee for the input and proposed changes per https://wiki.onap.org/display/DW/Potential+Feedback+to+ETSI+IFA011+v2.5.1 to IFA and SOL WG. This document is a response to these changes.
ONAP Modelling sub-committee is asked to review Table 1 and provide feedback to ETSI ISG NFV IFA WG by May 1, 2019.
Legends used in the document:
BOLD BLUE text indicates those enhancements ONAP has made and would like to propose back to the ETSI NFV IFA011. And BOLD PURPLE text represents candidates for deprecation in support of HPA. These marking are original from ONAP.
No action required – The request is reviewed, and no action is needed
No action for now - The request is reviewed and there is additional detail requested from ONAP
Class Name | Attribute Name | Type | Multiplicity | Description | Applied Stereotypes | Category | Rationale | ETSI reference Discussion | IFA + SOL Recommendation | IFA Contribution | SOL Contribution | ONAP Recommendation | ONAP Comments |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Vnfd | vnfmInfo | String | 0..* (IFA has 1..*) | Identifies VNFM(s) compatible with the VNF described in this version of the VNFD. Using the name of micro-service of the vnfm drive. For vendor specific VNFM, the value composes of "vendorname" and "vnfmdriver", e.g. "mycompanyvnfmdriver"; for generic VNFM, the value is "gvnfmdriver". | OpenModelAttribute
support: MANDATORY | value specified cardinality change | Value is specified according to the usage in VFC project. Lower cardinality is changed to 0 because not all VNFs in ONAP need to be managed by VNFMs, SO/APPC could also serve the similar functionality. | NFVIFA(19)000200r1 | Multiplicity: 0.*: Keep current IFA011. ONAP can use this attribute for indicating either SO/APPC. Attribute Value: SOL001 is already defined with a pattern. | No action required | No action required | It is proposed not to change Multiplicity. Not to update the description. | |
Vnfd | localizationLanguage | String | 0..* | Information about localization languages of the VNF (includes e.g. strings in the VNFD). NOTE: This allows to provide one or more localization languages to support selecting a specific localization language at VNF instantiation time. The value refer to ISO936 https://www.iso.org/iso-639-language-codes.html . | OpenModelAttribute
support: MANDATORY | type and value specified | Value is specified according to the usage in VFC project. | NFVIFA(19)000200r1 | SOL001 v2.5.1 defines as string and reference to RFC5646 which reference to ISO639. | No action required | No action required | Typo in description (ISO639). Recommends to align with reference used in SOL (RFC5646 which reference to ISO639). | |
Vnfd | defaultLocalizationLanguage | String | 0..1 | Default localization language that is instantiated if no information about selected localization language is available. The value refer to ISO936 https://www.iso.org/iso-639-language-codes.html . | OpenModelAttribute
condition: Shall be present if "localizationLanguage" is present and shall be absent otherwise. | type and value specified | Value is specified according to the usage in VFC project. | NFVIFA(19)000200r1 | SOL001 v2.5.1 defines as string and reference to RFC5646 which reference to ISO639. | No action required | No action required | Typo in description (ISO639). Recommends to align with reference used in SOL (RFC5646 which reference to ISO639). | |
Vnfd | vnfReservedCpd | VduCpd | 0..* | Reserved IP Address for VNF which is not bounded to any specific VNFC, but assigned manually from outside and potentially shared as a floating IP among VNFCs. | OpenModelAttribute
support: MANDATORY | new attribute | The use cases presented in 215r3 are valid use cases and are similar to ONAP use case. 215r3 proposes 2 solutions. Further discussions required. Start with examples based on one of the solutions.
| Work in progress | Work in progress | We acknowledge the need for supporting shared IP addresses (VIPs). Please refer to NFVIFA(19)000288r1 which contains the currently identified use cases. ONAP is requested to comment/confirm the use cases. | ONAP has reviewed the use cases in the ETSI NFV presentation and ONAP agrees that the first two use cases are relevant for the vnfReservedCpd. ONAP thinks that the 3rd case (DNAT based load balancing) is not relevant. ONAP kindly asks ETSI NFV to provide a solution to support these use cases. | ||
Vnfd | modifiableAttributes | VnfInfoModifiableAttributes | 1 (IFA has 0..1) | Describes the modifiable attributes of the VNF. | OpenModelAttribute
support: MANDATORY | cardinality change | NFVIFA(19)000200r1 | modifiableAttributes defines the VNF-specific extension and metadata attributes of the VnfInfo. These are optional attributes and depending on the design of VNF. No change is needed. | No action required | No action required | It is proposed not to change Multiplicity. | ||
Vnfd | logo | String | 0..1 | File path of the vendor specified logo. | OpenModelAttribute isInvariant: false support: MANDATORY | new attribute | NFVIFA(19)000200r1 | What is the rational of having logo as part of the VNFD as an attribute? Perhaps, it should be part of the VNF Package information. Not important for modelling of VNFD. Might have impacts in SOL004, it has flexibility to include details specific to VNF by the VNF vendor. Can this be part of Non-MANO artefact? Not needed in the VNFD. | No action required | No action required | Not recommended to be part of VNFD. In ETSI, there is no requirement for including Logo or Guide in the Descriptor. Non-MANO artifacts can be used already for storing this type of data. This can be a ONAP-specific artefact or generic-artifact. | ||
Vnfd | guide | String | 0..1 | UUID of the vendor guide/documentation which is attached to VNF and can be downloaded from the model. | OpenModelAttribute isInvariant: false support: MANDATORY | new attribute | NFVIFA(19)000200r1 | Not the benefit of having guide as part of the VNFD as an attribute. Perhaps, it can be part of the VNF Package information. If included in package, any change in guide will need a new package. | No action required | No action required | Not recommended to be part of VNFD. What is the rational of having a guide as part of the VNFD as an attribute. Having a guide or logo in the VNFD, a new VNFD and VNF Package will be required when there is a small change to the guide or logo. In ETSI NFV, there is no requirement for including Logo or Guide in the Descriptor. Non-MANO artifacts can be used already for storing this type of data. This can be a ONAP-specific artefact or generic-artifact. | ||
Vdu | nfviConstraint | KeyValuePair | 0..* | Describes constraints on the NFVI for the VNFC instance(s) created from this Vdu. For example, aspects of a secure hosting environment for the VNFC instance that involve additional entities or processes. NOTE: These are constraints other than stipulating that a VNFC instance has access to a certain resource, as a prerequisite to instantiation. The attributes virtualComputeDesc and virtualStorageDesc define the resources required for instantiation of the VNFC instance. The "key/name" includes "AvailabilityZone" and "HostAggregates". | OpenModelAttribute
support: MANDATORY | type specified | Openstack has the concepts "availability zone" and "host aggregates" by which the operator could specify (or constrain) the deployment location of the VM (VNFC instance). It's proposed to have these two attributes defined in the VNFD as input parameters (with default values defined if necessary). | 1. Agree to type change proposed by ONAP. Change the type to “KeyValuePair” in IFA011 if okay from SOL WG point of view. 2. The proposed changes in the description would require further discussion. The use case that a “default value is given for availability zone or host aggregate” is unclear. In principle, at design time, it is not possible to know the value/names of the availability zones or host aggregates, therefore, it is not clear what value can be put there. Also, requirements on affinities (which is a use case for the zones), is already covered by the localAffinityOrAntiAffinityRule. The run-time signaling of placement constraints is supported on the interfaces, such as “VnfLocationConstraint” in the IFA013 (clause 8.3.4.4), the “placementConstraint” and “zoneGroup” in the granting process in the IFA007 (clause 6.3.2). Based on this it is recommended not to change the description and request further clarification from ONAP | NFVSOL(19)000162r1 (pending approval) | Thanks for indicating the change of type. We will update the datatype in IFA011. The datatype in SOL001 is changed to map of strings to support KeyValuePair. The proposed change in description is unclear. The use case that a “default value is given for availability zone or host aggregate” is unclear. In principle, at design time, it is not possible to know the value/names of the availability zones or host aggregates, therefore, it is not clear what value can be put there. Also, requirements on affinities (which is a use case for the zones), is already covered by the localAffinityOrAntiAffinityRule. The run-time signaling of placement constraints is supported on the interfaces, such as “VnfLocationConstraint” in the IFA013 (clause 8.3.4.4), the “placementConstraint” and “zoneGroup” in the granting process in the IFA007 (clause 6.3.2). Based on this, it is recommended not to change the description. | |||
Vdu | injectFiles | String | 0..* | Describes the information (e.g. URL) about the scripts, config drive metadata, etc. which can be used during Vdu booting process. | OpenModelAttribute
| new attribute | There are two ways to inject data into VM instance during instantiation process: 1) using config drive to provide such information (covered by the bootData attribute in the VNFD); 2) using an injection file. It's proposed to also support this way of providing additional data to the VM instance. Note: file injection is deprecated in OpenStack Queen version | File injection is deprecated in OpenStack Queen version, since file injection is insecure, not very user friendly, and there are alternatives: Therefore, file injection should not be introduced in IFA011. | No action required | No action required | File injection is deprecated in OpenStack Queen version, since file injection is insecure, not very user friendly, and there are alternatives: Therefore, file injection should not be introduced in IFA011. | ||
SwImageDesc | version | String | 1 | The version of this software image. | OpenModelAttribute
support: MANDATORY | question | "vnfSoftwareVersion" and "vnfdVersion" attributes have type "Version", while this attribute has type "String", should they be aligned? i.e., change "String" into "Version"? | SOL001 is consistently using type “String” for all “version” attributes, so it would be okay for IFA011 to keep using “String” type. However, it would make sense to align the use of “Version” vs. “String” in IFA011. - VNFD uses “Version” - SwIMageDesc uses “String” - RequestedAdditionalCapabilityData uses “String” Other IFA specifications use type “Version”, e.g. IFA014 consistently uses “Version”. Also, the IFA015 information model is introducing a primitive type “Version”. It is proposed to change to type from "string" to “Version” in IFA011 to be consistent with IFA014 & IFA015. It is up to the SOL specification work to specify what data type / format should be used for the primitive type “Version”, and IFA does not have to mandate the type “String”. | No action required | Thanks for indicating the change of type. We will update the datatype for version in IFA011. | |||
VirtualComputeDesc | requestAdditionalCapabilities | RequestedAdditionalCapabilityData | 0..* | Specifies requirements for additional capabilities. These may be for a range of purposes. One example is acceleration related capabilities. | OpenModelAttribute
support: MANDATORY | deprecate |
| Work in progress. Recommendation for deprecation process as approved by IFA WG will be followed | Work in progress | ||||
VirtualComputeDesc | computeRequirements | KeyValuePair | 0..* | Specifies compute requirements. | OpenModelAttribute
support: MANDATORY | type specified | Type and value are defined per HPA proposal. |
| It can be left to stage 3 to decide the type in some cases and leave it Not Specified in IFA011. SOL001 defines compute_requirements as Map of string, that is similar to KeyValuePair proposed by ONAP. Work in progress in determining values. | Work in progress | |||
VirtualCpuData | virtualCpuOversubscriptionPolicy |
| 0..1 | The CPU core oversubscription policy e.g. the relation of virtual CPU cores to physical CPU cores/threads. The cardinality can be 0 during the allocation request, if no particular value is requested. | OpenModelAttribute
support: MANDATORY | deprecate |
| Work in progress | Work in progress | ||||
VirtualCpuData | vduCpuRequirements | KeyValuePair | 0..* | Array of key-value pair requirements on the Compute (CPU) for the VDU. | OpenModelAttribute
support: MANDATORY | type specified | Type and value are defined per HPA proposal. |
| It can be left to stage 3 to decide the type in some cases and leave it Not Specified in IFA011. SOL001 defines vdu_cpu_requirements as Map of string, that is similar to KeyValuePair proposed by ONAP. Work in progress in determining values. | Work in progress | |||
VirtualCpuData | virtualCpuPinning | VirtualCpuPinningData | 0..1 | The virtual CPU pinning configuration for the virtualised compute resource. | OpenModelAttribute
| deprecate | Covered by vduCpuRequirements attribute per HPA proposal. |
| Work in progress | Work in progress | |||
VirtualMemoryData | virtualMemOversubscriptionPolicy |
| 0..1 | The memory core oversubscription policy in terms of virtual memory to physical memory on the platform. The cardinality can be 0 during the allocation request, if no particular value is requested. | OpenModelAttribute
support: MANDATORY | deprecate |
| Work in progress | Work in progress | ||||
VirtualMemoryData | vduMemRequirements | KeyValuePair | 0..* | Array of key-value pair requirements on the memory for the VDU. | OpenModelAttribute
support: MANDATORY | type specified | Type and value are defined per HPA proposal. |
| It can be left to stage 3 to decide the type in some cases and leave it Not Specified in IFA011. SOL001 defines vdu_mem_requirements as Map of string, that is similar to KeyValuePair proposed by ONAP. Work in progress in determining values. | Work in progress | |||
VirtualMemoryData | numaEnabled | Boolean | 0..1 | It specifies the memory allocation to be cognizant of the relevant process/core allocation. The cardinality can be 0 during the allocation request, if no particular value is requested. | OpenModelAttribute
support: MANDATORY | deprecate |
| Work in progress | Work in progress | ||||
VirtualStorageDesc | vduStorageRequirements NOTE: This attribute is moved to BlockStorageData in IFA011 v2.5.1 | KeyValuePair | 0..* | An array of key-value pairs that articulate the storage deployment requirements. | OpenModelAttribute
support: MANDATORY | type specified | Type and value are defined per HPA proposal. | This attribute is moved under BlockStorageData. It can be left to stage 3 to decide the type in some cases and leave it Not Specified in IFA011. SOL001 defines vdu_cpu_requirements as Map of string, that is similar to KeyValuePair proposed by ONAP. Work in progress in determining values. | Work in progress | ||||
VirtualStorageDesc | rdmaEnabled NOTE: This attribute is moved to BlockStorageData in IFA011 v2.5.1 | Boolean | 0..1 | Indicate if the storage support RDMA. | OpenModelAttribute
support: MANDATORY | deprecate |
| Work in progress | Work in progress | ||||
LogicalNodeData | logicalNodeRequirementDetail | KeyValuePair | 1..* | The logical node-level compute, memory and I/O requirements. An array of key-value pairs that articulate the deployment requirements. This could include the number of CPU cores on this logical node, a memory configuration specific to a logical node (e.g. such as available in the Linux kernel via the libnuma library) or a requirement related to the association of an I/O device with the logical node. | OpenModelAttribute
support: MANDATORY | type specified | Type and value are defined per HPA proposal. |
| It can be left to stage 3 to decide the type in some cases and leave it Not Specified in IFA011. SOL001 defines logical_node_requirements as Map of string, that is similar to KeyValuePair proposed by ONAP. Work in progress in determining values. | Work in progress | |||
Cpd | allowedAddressData Note: Ongoing discussion is proposing to move this out of Cpd (into VNFD) as it is specified to VNFD. | AddressData | 0..N | For specifying floating IP(s) to be shared among Cpds, which are reserved for vnfReservedCpd described in the VNFD. | OpenModelAttribute
| new attribute | NFVIFA(19)000215r3 | The use cases presented in 215r3 are valid use cases and are similar to ONAP use case. 215r3 proposes 2 solutions. Further discussions required. Start with examples based on one of the solutions. | Work in progress | Work in progress | We acknowledge the need for supporting shared IP addresses (VIPs). Please refer to NFVIFA(19)000288r1 which contains the currently identified use cases. ONAP is requested to comment/confirm the use cases. | ||
VduCpd | vnicName | String | 0..1 | Describes the name of the vNIC this CP attaches to, e.g. eth0. It will be configured during the Vdu booting process. | OpenModelAttribute
| new attribute | An optional attribute used when creating a port resource in Openstack. | This class currently contains attributes to specify requirements on a virtual network interface and the vnicType realising the CPs instantiated from this CPD. There is an existing attribute "Order" that might become redundant if a vnicName be defined in this class. As per IFA view, this attribute is not needed to be modelled in this class. | No action required | No action required | The rationale in adding this attribute is unclear considering that the order attribute already exists. It is proposed not to introduce vnicName attribute to this class. | ||
VduProfile | watchdog | String | 0..1 | Watchdog action to be triggered by the VIM for the VNF in case the heart beat fails, e.g. reset or hard shutdown, etc. | OpenModelAttribute
support: MANDATORY | new attribute |
| Need detailed rationale for adding new attribute. | No action for now | No action for now | Provide detailed rationale for adding new attribute | Rationale: The assumption is that there's a heart beat checking mechanism which can monitor the aliveness of the VMs inside NFVI. And the status of the heart beat checking is exposed to the VIM. This attribute is used to specify the behavior/actions of the VIM when it finds the heart beat checking fails (i.e., the VM can't be connected). The possible action could be reset, hard shutdown, etc. | |
VduProfile | vmBootUpTimeOut | Integer | 0..1 | Timeout value for the VNFM to wait before the successful booting up of the VDU. | OpenModelAttribute
support: OPTIONAL | new attribute | To specify the maximum time VNFM should wait before a VNF instance is successfully boot up. If timeout, the instantiation would be considered as failed. |
| Need more details on the use case need from OKNAP. | No action for now | No action for now | Need additional details to understand the use case. | Rationale: This attribute specifies a time period (e.g., 5 minutes) for the VNFM to wait after the VM is successfully created by the VIM. It's because that after the VM is created, there are some additional work to be done in the VM to instantiate the VNF, including running cloudinit scripts, doing application configurations, etc. The VNFM needs to wait for these work to be finished before connecting to the VNF, make some potential additional process and claim it as "instantiated". Note: VNFM could be generalized into a controller (e.g., VFC, CDS, APP-C, etc.) in ONAP's context. |
VirtualNetworkInterfaceRequirements | networkInterfaceRequirements | KeyValuePair | 0..* | The network interface requirements. An element from an array of key-value pairs that articulate the network interface deployment requirements. | OpenModelAttribute
support: MANDATORY | type specified |
| It can be left to stage 3 to decide the type in some cases and leave it Not Specified in IFA011. SOL001 defines network_interface_requirements as Map of string, that is similar to KeyValuePair proposed by ONAP. Work in progress in resolving multiplicity issue between IFA and SOL. | Work in progress | ||||
VnfVirtualLinkDesc | virtualLinkDescId | Identifier | 1 | Unique identifier of this internal VLD in VNFD. Model definition: Uniquely identifies a VLD in the parent descriptor. (this is because you can have VnfVirtualLinkDesc and NsVirtualLinkDesc) | Note: Inherited from Class VirtualLinkDesc OpenModelAttribute
support: MANDATORY | put this attribute in the root class "VirtualLinkDesc" |
| From IFA feedback, the model in IFA015 is informative and the VNF Virtual Link and NS Virtual Link are modelled by creating a common class VirtualLinkDesc. IFA011 and IFA014 have classes specific to VNF and NS and SOL001 changes are in line with IFA011 and IFA014 without defining a common type. | No action required | No action required | IFA015 being informative may be different from IFA011 and IFA014. Recommended to refer the normative specifications IFA011 and IFA014. | ||
VnfVirtualLinkDesc | connectivityType | ConnectivityType
| 1 | Specifies the protocol exposed by a VL and the flow pattern supported by the VL. | Note: Inherited from Class VirtualLinkDesc OpenModelAttribute
support: MANDATORY | complement the description | to align with IFA015 |
| From IFA feedback, the model in IFA015 is informative and the VNF Virtual Link and NS Virtual Link are modelled by creating a common class VirtualLinkDesc. IFA011 and IFA014 have classes specific to VNF and NS and SOL001 changes are in line with IFA011 and IFA014 without defining a common type. | No action required | No action required | IFA015 being informative may be different from IFA011 and IFA014. Recommended to refer the normative specifications IFA011 and IFA014. | |
VnfVirtualLinkDesc | testAccess | String | 0..* | Specifies test access facilities expected on the VL (e.g. none, passive monitoring, or active (intrusive) loopbacks at endpoints). | Note: Inherited from Class VirtualLinkDesc OpenModelAttribute
support: MANDATORY | put this attribute in the root class "VirtualLinkDesc" |
| From IFA feedback, the model in IFA015 is informative and the VNF Virtual Link and NS Virtual Link are modelled by creating a common class VirtualLinkDesc. IFA011 and IFA014 have classes specific to VNF and NS and SOL001 changes are in line with IFA011 and IFA014 without defining a common type. | No action required | No action required | IFA015 being informative may be different from IFA011 and IFA014. Recommended to refer the normative specifications IFA011 and IFA014. | ||
VnfVirtualLinkDesc | description | String | 0..1 | Provides human-readable information on the purpose of the VL (e.g. control plane traffic). | Note: Inherited from Class VirtualLinkDesc OpenModelAttribute
support: MANDATORY | put this attribute in the root class "VirtualLinkDesc" |
| From IFA feedback, the model in IFA015 is informative and the VNF Virtual Link and NS Virtual Link are modelled by creating a common class VirtualLinkDesc. IFA011 and IFA014 have classes specific to VNF and NS and SOL001 changes are in line with IFA011 and IFA014 without defining a common type. | No action required | No action required | IFA015 being informative may be different from IFA011 and IFA014. Recommended to refer the normative specifications IFA011 and IFA014. | ||
VnfDf | placementGroup | PlacementGroup | 0..* | Determine where VNFC's (VDU's) are placed with respect to the VNF | OpenModelAttribute
| Association | new attribute |
| Need detailed rationale for adding new attribute associated with new class proposal (Refer at the end of table) | No action for now | No action for now | Provide detailed rationale and use case for understanding addition of new class and associating to VnfDf. | |
VnfDf | baseConfigGroup | BaseConfigGroup | 0..1 |
BaseConfigGroup may establish internal networks such as OAM (VNF Mgmt) or MNS (Maintenance & Surveillance) established. | OpenModelAttribute
Experimental | Association | new attribute |
| Need detailed rationale for adding new attribute associated with new class proposal (Refer at the end of table) | No action for now | No action for now | Provide detailed rationale and use case for understanding addition of new class and associating to VnfDf. | |
VnfDf | deploymentGroup | DeploymentGroup | 1..* | DeploymentGroup provides the minimum viable VDU and associated VNFC configuration for a useable VNF. | OpenModelAttribute
Experimental | Association | new attribute |
| Need detailed rationale for adding new attribute | No action for now | No action for now | Provide detailed rationale and use case for understanding addition of new class and associating to VnfDf | |
VirtualLinkProfile | virtualLinkProfileId Note: This is missing in IFA011 but is in the model. This is a necessary attribute in order to instantiate the class | Identifier | 1 | Uniquely identifies this VirtualLinkProfile class. | OpenModelAttribute
support: MANDATORY | new attribute | align with IFA015 | NFVIFA(19)000229r1 | From the rationale provided by ONAP, the model in IFA011 is compared with IFA015. VirtualLinkProfile class is defined at VNF level and NS level. The particular class referred in ONAP query is specific to NS. For NS, the model should be based on IFA014 and it is verified that virtualLinkProfileId defined in the NS specific class in IFA014. And this is again in-line with IFA015. No discrepancies seen | No action required | No action required | It is recommended to review virtualLinkProfileId in the NS specific class. VirtualLinkProfile class is defined at VNF level and NS level. The particular class referred in ONAP query is specific to NS. For NS, the model should be based on IFA014 and it is verified that virtualLinkProfileId defined in the NS specific class in IFA014. And this is again in-line with IFA015. No discrepancies seen. ONAP can adopt a procedure to differentiate names reused across the VNF and NS classes. | |
VirtualLinkProfile | initiationParameters | KeyValuePair | 0..* | Specifies initiation parameters for the virtual link. Specified values include: cidr, allocationPools (represented by [starting ip address, ending ip address]), gatewayIp, networkName, segmentationId, physicalNetwork. NOTE: cidr, allocationPools, gatewayIp, networkName are already defined in L3ProtocolData in IFA. | OpenModelAttribute
| new attribute | NFVIFA(19)000229r1 | Description, cidr, allocationPools, gatewayIp, networkName are already defined in L3ProtocolData that is included in virtualLinkProtocolData element in VirtualLinkProfile class at VNF. The additional parameters requested on top of L3ProtocolData: segmentationId can not be added to L3ProtocolData as this is VLAN related. This can be added to L2ProtocolData. (Note, this value can be overridden any time) physicalNetwork in the Openstack points to provider network. Use the same name as openstack, the drawback is this will be specific to VIM implementation. A generic alternate solution should be considered. Further study required. Possible option tagging in the ExtManagedVirtualLink in the VirtualLinkProfile. | No action for now | No action for now | Description, cidr, allocationPools, gatewayIp, networkName are already defined in L3ProtocolData that is included in virtualLinkProtocolData element in VirtualLinkProfile class at VNF. The additional parameters requested on top of L3ProtocolData: segmentationId can not be added to L3ProtocolData as this is VLAN related. This can be added to L2ProtocolData depending also on the resolution of the physical network information. (Note, this value can be overridden any time.) physicalNetwork in the Openstack points to provider network. Use the same name as openstack, the drawback is this will be specific to VIM implementation. A generic alternate solution should be considered. Further study required. Possible option tagging in the ExtManagedVirtualLink in the VirtualLinkProfile. | ONAP has updated the VNFD information model according to IFA011 v2.5.1, (Updated V2.5.1 VNFD Model), in which cidr, allocationPools, etc. are already moved into the L3ProtocolData. Regarding segmentationId, it's acceptable to put it into L2ProtocolData. It's suggested to make this addition in the next version of IFA011. Regarding physicalNetwork, it's acceptable to generalize the name. However, the possible option is not sufficient. There could be two different use cases for the provider network: 1) use the provider network directly as an implementation of a virtual link, the possible option could work; 2) still need to create a virtual link, the provider network is a constraint of the creation, indicates the VL needs to be created on top of the selected provider network, in this case, the VL is still managed by the VNFM, so the ExtManagedVirtualLink may not be the proper place to model it. It's expected that ETSI could discuss more and come up with a concrete solution. | |
VirtualLinkDescFlavour | qos | QoS | 0..1 | QoS of the VL. | OpenModelAttribute
support: MANDATORY | question | IFA015 seems to have defined "VnfQoS" as the type. Should IFA011/014 follow the same pattern, i.e., define "VnfQoS" and "NsQoS" separately? | NFVIFA(19)000230r1 | QoS in Vnf template is same as the QoS in common template of IFA015. Recommendation to IFA to change the QoS class to NSQoS class in IFA014. (consistency between IFA014 & IFA015). This change has no impact to SOL001 but need to check SOL006. It is not mandatory to rename QoS for IFA011 as the SOL001 uses the same name. | IFA014 CR for renaming qos to NsQos | SOL006 confirmation | Thanks for indicating the change. We will update IFA014 with IFA015 alignment. This alignment has no impact to SOL001. | |
CpProtocolData | addressData | AddressData | 0..* | Provides information on the addresses to be assigned to the CP(s) instantiated from the CPD. | OpenModelAttribute
support: MANDATORY | question | IFA015 has the cardinality defined as 1, is it a mistake? | Agree to question from ONAP and change IFA015. It is proposed to create an entry in the ETSI bug tracker to change cardinality in IFA015. | IFA015 Bug tracker number | No action required | Thanks for indicating the change. We will update the cardinality in IFA015. This alignment has no impact to SOL001. | ||
VirtualCpuPinningData | virtualCpuPinningPolicy | Enum | 0..1 | The policy can take values of "static" or "dynamic". In case of "static" the virtual CPU cores are requested to be allocated to logical CPU cores according to the rules defined in virtualCpuPinningRules. In case of "dynamic" the allocation of virtual CPU cores to logical CPU cores is decided by the VIM. (e.g.: SMT (Simultaneous Multi-Threading) requirements). | OpenModelAttribute
support: MANDATORY | deprecate | Deprecate Datatype VirtualCpuPinningData |
| Work in progress | Work in progress | |||
VirtualCpuPinningData | virtualCpuPinningRule | Not specified | 0..1 | A list of rules that should be considered during the allocation of the virtual CPUs to logical CPUs in case of "static" virtualCpuPinningPolicy. | OpenModelAttribute
support: MANDATORY | deprecate | Deprecate Datatype VirtualCpuPinningData |
| Work in progress | Work in progress | |||
VnfConfigurableProperties | additionalConfigurableProperty | String | 0..* | It provides VNF specific configurable properties that can be modified using the ModifyVnfInfo operation. | OpenModelAttribute
support: MANDATORY | type specified | NFVIFA(19)000231r1 | In SOL001, a new TOSCA type is defined for additionalConfigurableProperty. SOL001 defined additionalConfigurableProperties as a datatype that is extendable as defined in section 5.7. | No action required | No action required | Recommendation to reference the datatype tosca.datatypes.nfv.VnfAdditionalConfigurableProperties as per SOL001 section 5.7. | ||
VnfcConfigurableProperties | additionalVnfcConfigurableProperty | String | 0..N | It provides VNFC configurable properties that can be modified using the ModifyVnfInfo operation. NOTE: A cardinality of "0" indicates that configuring this present VNF property is not supported. | OpenModelAttribute
support: MANDATORY | type specified | NFVIFA(19)000232r1 | In SOL001, a new TOSCA type is defined for additionalConfigurableProperty. SOL001 defined additionalConfigurableProperties as a datatype that is extendable as defined in section 5.7. | NFVIFA(19)000232r1 | No action required | Recommendation to reference the datatype tosca.datatypes.nfv.VnfAdditionalConfigurableProperties as per SOL001 section 5.7. | ||
LifecycleManagementScript | script | String | 1 | Information to locate a VNF LCM script (e.g. written in a DSL as specified in requirement VNF_PACK.LCM.001)triggered to react to one of the events listed in the event attribute. | OpenModelAttribute
support: MANDATORY | type specified | Description listed by ONAP is out of date and need to be corrected as per IFA011. script is modelled as artefact in TOSCA in each LCM operation. SOL001 data model is already handling the path to the script. The requirement of ONAP to support string type for script already supported by SOL001. Refer to the example in chapter 6.7.1 in SOL001. | No action required | No action required | Description in ONAP needs update to align with IFA011. Recommendation to reference the datatype from example in chapter 6.7.1 in SOL001. | |||
LifecycleManagementScript | scriptInput | KeyValuePair | 0..* | Array of KVP requirements with the key as the parameter name and the value as the parameter that need to be passed as an input to the script. NOTE: The scriptInput values are passed to the scripts in addition to the parameters received in the operation invocation request or indicator value change. | OpenModelAttribute
support: MANDATORY | type specified | The scriptInput is modelled as additionalParameters and this includes defining input as KeyValuePair. This is not restricted at this time to be strictly KeyValuePair The requirement of ONAP to support KeyValuePair type for scriptInput already supported by SOL001. | No action required | No action required | Recommendation to reference the datatype from example in chapter 6.7.1 in SOL001. | |||
MonitoringParameter | collectionPeriod | Enum (CollectionPeriod) but with no enumeration literals defined | 0..1 | An attribute that describes the recommended periodicity at which to collect the performance information. VNFM determines if this parameter is considered. The vendor may provide this information as a guidance for creating PmJobs if needed. NOTE: The MANO or NFVI may not support the recommended collectionPeriod based on their functionalities, and can reject the requests based on the recommended collectionPeriod in this case. | OpenModelAttribute
support: MANDATORY | type specified | The ONAP proposal for change of Type to ENUM is not possible as different metrics can have different values. scalar-unit.time is defined in SOL001 for collectionPeriod. | No action required | No action required | ETSI recommendation is to use scalar-unit.time in ONAP information model and data model. | |||
PlacementGroup | elementGroupId | Identifier | 1 | Unique identifier of this group in the VNFD. | OpenModelAttribute
support: MANDATORY | Attribute |
| Need detailed rationale for adding this class and new attribute | No action for now | No action for now | Provide detailed rationale for adding new attribute | defer discussion to later time, no action is required for ETSI for now | |
PlacementGroup | placementStrategy | Enum | 1 | Determine where VNFC's (VDU's) are placed with respect to the VNF. NOTE:
| OpenModelAttribute
support: MANDATORY | Attribute | Define an actual enum type with values: COLOCATION, ISOLATION, and EXCLUSIVELY |
| Need detailed rationale for adding this class and new attribute | No action for now | No action for now | Provide detailed rationale for adding new attribute | defer discussion to later time, no action is required for ETSI for now |
PlacementGroup | vnfcMembers | Not specified
| 0..N | References to Vdus that are part of this group. | OpenModelAttribute
support: MANDATORY | Association? | (should it be Identifier (Reference to Vdu)?) Good question. If it is the end of an association is should be type Vdu? |
| Need detailed rationale for adding this class and new attribute | No action for now | No action for now | Provide detailed rationale for adding new attribute | defer discussion to later time, no action is required for ETSI for now |
PlacementGroup | strategyScope | Enum | 1 | indicate if the strategy is applied at the host or rack level. | OpenModelAttribute
support: MANDATORY | Attribute | Define an actual enum with values: HOST, and RACK |
| Need detailed rationale for adding this class and new attribute | No action for now | No action for now | Provide detailed rationale for adding new attribute | defer discussion to later time, no action is required for ETSI for now |
BaseConfigGroup |
|
|
| Not enough details | No action for now | No action for now | BaseConfigGroup specifices access, storage types, and networks.
| defer discussion to later time, no action is required for ETSI for now | |||||
DeploymentGroup |
|
|
| Not enough details | No action for now | No action for now | DeploymentGroup provides the minimum viable VDU and associated VNFC configuration for a usable VNF. | defer discussion to later time, no action is required for ETSI for now | |||||
| ElementGroup | VnfdElementGroup as defined in ifa011v020302 states "a mechanism for associating elements of a VNFD. We generalized this, creating an "elementgroup", and subclassing it into HomingGroup, PlacementGroup, BasicCOnfigGroup, DeploymentGroup, etc, generalizing the definition to "a mechanism for associating elements for a certain purpose, including things such as homing, placement, scaling, etc.". | defer discussion to later time, no action is required for ETSI for now |