ETSI NFV IFA011 changes response #2 to ONAP (Ref: NFVIFA(19)000486)

Class Name

Attribute Name

Type

Multiplicity

Description

Applied Stereotypes

Category

Rationale

IFA + SOL Response

ONAP Response

ONAP Recommendation

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)000288r1 presented 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.

ETSI work in progress.

Related contributions: IFA contribution NFVIFA(19)000259r6 - Approved.

SOL contribution NFVSOL(19)000296r2 - in the process of email approval.

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

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.

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.

1. NFVIFA(19)000484r2 is IFA contribution that added segmentationId to L2ProtocolData in IFA011 v2.7.1.

2. On the response to physicalNetwork, it is not clear on why it is mentioned that VNFM needs to manage the virtual Link.

It might be good to understand the ONAP terminology and slides or mapping on how this works in openstack. Need more information on physicalNetwork.

Is this still on the same lines as providerNetwork ?

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

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.

Key questions raised in the discussion that need additional information from ONAP.

1.     Who will make use of this information and when and what purpose is not clear.

2.     Can this be explained with a flow example that will clarify things.

3.     The details explained in rationale are not clear. Should the application configuration done after VNFM is notified?

4.     If VNFM is the consumer, can this be done by adding such attribute to configurableProperties or Extension parameters.

5.     There are lot of variables that might influence the actual bootup and the value specified may not be sufficient always to handle these scenarios. How a static value from VNFD be helpful?

6.     Can this be done alternatively in a script for the lifecycle operation?

[Xu] VNFM waits for the timeout before contacting the VNF (no matter it finishes configuration or not)

Requesting additional information

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.

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.

Key questions raised in the discussion that need additional information from ONAP.

1.     Who uses this attribute (VNFM or VIM)?

2.     Need to be clear if the parameter need is at VNFC, VNF or VIM ?

3.     Should VIM take this decision on its own based on this watchdog behaviour? This could be a risk in restarting VM or shutting down VMs in case of some error scenarios.

4.     Is there a heartbeat mechanism specified at ONAP and provide more clarity? (ETSI has not defined such mechanism).