ONAP R4 Resource IM Call 2019-1-7

General Information:

• Date and Time: 2019, Jan 7, 10pm~11pm Beijing Time, 9am~10am US Eastern
• Meeting Room: https://zoom.us/j/645982535

Agenda:

• Backlog
• PNFD update
• New VNFD requirement

Material:

• Modeling Current Activity Status
• Proposed PNFD Model
• Requirements for VNFD

Minutes:

• Backlog:
• PNFD update:
  • 3 comments from last time:
    • show inheritance: 
      • add NetworkFunctionDesc, Cpd, etc.
      • note: no attributes defined for the father classes
      • Kevin and Chesla are working on the root model proposal (Onboarding / Internal (Platform) Draft)
    • editorial change for pnfdInvariantId
    • add attribute swVersionList
      • reflect DM change in R3
      • ETSI doesn't have this attribute; Ben plan to talk with Thinh on future contribution
      • suggest to change multiplicity: from 1 to 1..N. The reason for a "list" of software versions: PNF can have partitions (e.g., active partition, passive partition, etc.), which have different software versions.
      • Should partition status, i.e., active/passive be part of design time as well? (currently in run time model, i.e. AAI)
      • 2 possible ways: 1) have a structure defined for version (for example, add a "usage" besides the version number); 2) define explicitily attributes for different use cases (partitions), for example, "activeSwVersion", "passiveSwVersionList", etc.
      • seems agree on the 2nd solution
      • Jessie would do update for next week's call
• New VNFD requirement
  • changes:
    • VeVnfmInterface: move to run time instance model
    • dependOn: change to association
    • sriovAntiAffinityGroup:
      • suggest to remove "sriov"
      • suggest to change to association
      • suggest to reuse the AffinityOrAntiAffinityGroup defined in the VnfDf, suggest to use the same pattern with the VduProfile/VlProfile to reference to that group
    • securityGroupEnabled:
      • online change of the description: "each" → "the"
    • securityGroup:
      • Jessie would like to check with security group
    • multiAttach:
      • not related to the type of storages, no change