ETSI NFV IFA011 changes response to ONAP (ref: NFVIFA(19)000290r1)

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

• isInvariant: false

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

• isInvariant: false

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

• isInvariant: false
• support:  CONDITIONAL

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

• isInvariant: false

support:  MANDATORY

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.

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

• isInvariant: false

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

• isInvariant: false

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

NFVIFA(19)000224

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

NFVIFA(19)000224

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

• isInvariant: false
• support:  MANDATORY

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

NFVIFA(19)000224

File injection is deprecated in OpenStack Queen version, since file injection is insecure, not very user friendly, and there are alternatives:

https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/deprecate-file-injection.html

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:

https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/deprecate-file-injection.html

Therefore, file injection should not be introduced in IFA011.

SwImageDesc

version

String

1

The version of this software image.

OpenModelAttribute

• isInvariant: false

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"?

NFVIFA(19)000222

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

NFVIFA(19)000222

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

• isInvariant: false

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

• isInvariant: false

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

• isInvariant: false

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

• isInvariant: false

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

• isInvariant: false
• support:  MANDATORY

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

• isInvariant: false

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

• isInvariant: false

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

• isInvariant: false

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

• isInvariant: false

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

• isInvariant: false

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

• isInvariant: false

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

• isInvariant: false
• support:  MANDATORY

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

• isInvariant: false
• support:  MANDATORY

new attribute

An optional attribute used when creating a port resource in Openstack.

NFVIFA(19)000202r2

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

• isInvariant: false

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

• isInvariant: false

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

• isInvariant: false

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

• isInvariant: true

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

• isInvariant: false

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

• isInvariant: false

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

• isInvariant: false

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

• isInvariant: false
• support:  MANDATORY

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 set Access Control Lists (ACL's) and establish security groups and server groups.
• BaseConfigGroup creates/establishs storage for the VM's (OpenStack Cinder).

BaseConfigGroup may establish internal networks such as OAM (VNF Mgmt) or MNS (Maintenance & Surveillance)  established.

OpenModelAttribute

• isInvariant: false
• support:  MANDATORY

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

• isInvariant: false
• support:  MANDATORY

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

• isInvariant: true

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

• isInvariant: false
• support:  MANDATORY

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

• isInvariant: false

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

• isInvariant: false

support:  MANDATORY

question

IFA015 has the cardinality defined as 1, is it a mistake?

NFVIFA(19)000223

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

• isInvariant: false

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

• isInvariant: false

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

• isInvariant: false

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

• isInvariant: false

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

• isInvariant: false

support:  MANDATORY

type specified

NFVIFA(19)000233r1

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

• isInvariant: false

support:  MANDATORY

type specified

NFVIFA(19)000233r1

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

• isInvariant: false

support:  MANDATORY

type specified

NFVIFA(19)000234

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

• isInvariant: true

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

PlacementGroup

placementStrategy

Enum

1

Determine where VNFC's (VDU's) are placed with respect to the VNF.

NOTE:

• Co-location - members of the group share the same physical host or rack.
• isolation - members of the group do not share the same physical host or rack.
• Exclusivity - members have sole use of a given physical host or rack (not shared with any vnfcs outside the group).

OpenModelAttribute

• isInvariant: false

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

PlacementGroup

vnfcMembers

Not specified

0..N

References to Vdus that are part of this group.

OpenModelAttribute

• isInvariant: false

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

PlacementGroup

strategyScope

Enum

1

indicate if the strategy is applied at the host or rack level.

OpenModelAttribute

• isInvariant: false

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

BaseConfigGroup

Not enough details

No action for now

No action for now

BaseConfigGroup specifices access, storage types, and networks. 

• BaseConfigGroup may set Access Control Lists (ACL's) and establish security groups and server groups.

• BaseConfigGroup creates/establishes storage for the VM's (OpenStack Cinder).

• BaseConfigGroup may establish internal networks such as OAM (VNF Mgmt) or MNS (Maintenance & Surveillance) established.

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.

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