NOTE: This poll closes on Thu March 8th, 2018

One vote per company


HPA is a desired feature to be supported in R2, but no agreements have been reached on the attributes to be included into the clean version. This poll is to decide which (or all) of these attributes are to be included in the clean version (R2 IM).

Attributes include (defined in ETSI IFA011 v2.4.1):

  • vduCpuRequirements (attribute of IE/class VirtualCpuData)
  • vduMemRequirements (attribute of IE/class VirtualMemoryData)
  • vduStorageRequirements (attribute of IE/class VirtualStorageDesc)
  • logicalNode (attribute of IE/class VirtualComputeDesc)
  • nicIoRequirements (attribute of IE/data type VirtualNetworkInterfaceRequirements)
  • networkInterfaceRequirements (attribute of IE/data type VirtualNetworkInterfaceRequirements)

Examples of the above attributes can be found at https://wiki.onap.org/pages/viewpageattachments.action?pageId=24051740&metadataLink=true, or if you have ETSI account, NFVIFA(18)000162 contribution.

Poll Question

Which (or all) of the attributes you would like to include in R2 IM?

Option 1: include this attribute in the clean version (same as IFA011)

Option 2: include this attribute in the clean version and remove other redundant (legacy) attributes (modification based on IFA011)

Option 3: not include this attribute in the clean version

Please put your @name in one of the option column for each attribute (or the "ALL" for simplicity) and provide any comments you might have.

AttributeOption 1Option 2Option 3Comments
"ALL"

Andy Mayer

Amir Levy

Andrei Kojukhov

Michela Bevilacqua

Xu Yang

Lingli Deng

Yufei ZHou

han yanan

Alexander Vul

xinhuili

Brian Hedstrom

Fernando Oliveira


All the listed attributes (for simplicity).

Brian Hedstrom: The link provided above for Key-Value Pair Registries.docx, for the HPA Key Value Pairs, is linking to an OLD version of the file. The vduComputeRequirements Registry Example provided in the link above DOES NOT MATCH the vduComputeRequirements Registry Example provided in NFVIFA(18)000162r1. It's not clear to me if we are voting on the attributes only in this attribute table, or also voting on supporting the key value pairs per NFVIFA(18)000162r1. I would suggest the key value pairs be a separate poll/discussion. My vote here is for the attribute table only.

Xu Yang: to Brian, the vote is only for the attribute table, not the key value pairs.

maopeng zhang:

I agree HPA requirements.

  1. All changes for HPA in R2 should not effect R1 VoLTE case.  It needs the data model compatible, which the VoLTE case already used. If this can be pre-condition in R2, I agree with add HPA attributes. But how to add, we needs more details.
  2. The main purpose of OPT2 is to avoid redundancy parametes.
    Needs more KVP details and data model definitions to clear the solution benefits.

Michela Bevilacqua: updated version of the key value pairs registry to be supported in R2 and identification of deprecated (legacy) attributes to be finalised.

Thinh Nguyenphu: With Option 1 or Option 2, there is a way in TOSCA grammar to indicate the status of each TOSCA properties (supported, unsupported, experimental, deprecated). Thus, we can indicate to implementer how some of these duplicate attributes status. Of course Option 2 is possible, it would requires these supporting companies to bring concrete CRs to remove these duplicate attributes, as soon as possible. It is not good practice to remove an attribute(s) once a specification is already published without early notification.

Brian Hedstrom I support deprecating or obsoleting the hardcoded legacy attributes in favor of the key-value pairs. I don't think they should be deleted from the DM in order to support backward compatibility (and make them optional), but they should be deprecated or obsoleted so they are not used going forward.


vduCpuRequirements





Xu Yang: Possible redundant attributes: numVirtualCpu, virtualCpuClock, logicalCpuPinningPolicy, logicalCpuThreadPinningPolicy

Alexander Vul: the computeRequirements attribute is not HPA related.

Xu Yang: remove computeRequirements

Alexander Vul: These are not redundant. If I remember right, they are complementary...

vduMemRequirements





vduStorageRequirements





logicalNode


Xu Yang: Question: In the example document, the logical node requirements are categorized into compute, memory and network categories. But in IFA011, only one logicalNode attribute is defined, what's the mapping here?

Alexander Vul: There is a single k/v array holding attributes from three registries... We will optimize this, when registries are created.

Brian Hedstrom Is logicalNode and logicalNodeDescr the same attribute? I'm finding both in the Wiki. logicalNode is not listed as an attribute for Class: VirtualComputeDesc

nicIoRequirements


Xu Yang: Question: related to the above comment, if the network logical node requirements are specific, should this be a dedicated data type instead of a reference?

Alexander Vul: Hmm... Need to think about it. As I review both the NFV Profile based spec and the SOL spec, I am finding some oddities.. We may have a mistake or two in how things got modeled..

Brian Hedstrom nicloRequirements is not listed as an attribute (or data type for other attribute) for Class: VirtualNetworkInterfaceRequirements

networkInterfaceRequirements





logicalNodeData


Brian Hedstrom This appears to be a Class, not an attribute.


redundant

  • No labels

8 Comments

  1. Xu Yang

    Kevin Scaggs, I see you also want to put monitoring parameter here, but I'm not sure which attribute(s) you are refering to as well as the options. Maybe you can edit the page yourself, or let's have another poll regarding to that topic.

    1. Alexander Vul

      Monitoring parameters are orthogonal to HPA. We should deal with them separately or risk more confusion...

      1. Kevin Scaggs

        I agree - we must handle as a separate topic.

  2. Alexander Vul

    Yang Xu , can you clarify option 3?  As we said on the call, The enhanced approach to HPA specification (post IFA011  v2.3.1) is meant to holistic and more fine-grained. Removing individual HPA attribute is going to have an adverse effect on their entire HPA specification scheme. The reason for this is because the values of the pre IFA011 v2.3.1 (legacy) attributes are going to be different from values of the (new) attributes in the key/value pairs...

    Same goes for the (legacy) attributes. Removing them one at a time, will not work either.

    The way I see it, we have three options...

    OPTION 1 - Use currently approved HPA specification scheme in IFA011 v2.4.1.

    OPTION 2 - Use legacy pre-IFA011 v2.3.1 specification scheme.

    OPTION 3 - Allow legacy approach for backward compatibility (pre-R2) only, but use the new approach for R2 and beyond...


    1. Xu Yang

      Without clear definition of the key/value, the usage of a particular attribute is still unclear to some participants. Option 3 is to allow those who still have concerns to express their opinions. Again, though I provided the example document as information here, it's highly appreciated if you can provide some definition/specification for those key/values for R2 model.

      I think your OPTION 1 and 3 are covered in the current poll, we can add your OPTION 2 if you wish.

      1. Srinivasa Addepalli

        Hi,

        You can find the HPA policy example here:  Policy Specification and Retrieval for OOF.   Currently, they are expected to be manually authored.  When TOSCA DM with HPA is ready,  we are hoping that TOSCA templates would be created with HPA information.  When those templates are on-boarded, policies will get generated automatically (thereby avoiding manual authoring the policies).  I hope these examples are useful.

        Srini

  3. maopeng zhang

    1. About the changes, there is a basic assumption, which can not effect VoLTE case, or compatible with the model R1 VoLTE case used.  If the project can not promise it , it will be a risk.

          2. About OPT 2, we should make it clear

              2.1 what attributes need to be removed

              2.2 how to remove the attributes.

                    Remove from KVP or from the attributes already existed in the clean page?

                    is the remove way one by one attributes or for all?


    Thanks.

    1. Xu Yang

      About option 2, we need the definition of key/value to decide which attributes need to be removed. Some potential attributes are given in the "comments" column.

      Regarding how to remove the attributes, it's about removing the redundant attributes in the clean version page, my understanding is removing them as a whole once we have the analysis result.