Rationale:

There are some updates of the AAI schema regarding the VNF instance model, and it's identified that VFC also has an internal inventory which stores information of the VNF instance.

Propose to have an analysis from the updated AAI schema and VFC inputs (and potential ETSI spec updates) to update the R3 VNF instance model in R4.

In addition, there's some leftover issues regarding the R3 VNF instance model needs to be resolved in R4 and there're some suggestions need to be taken from the service instance model discussion.

Source:

R3 model: R3 Resource Clean Draft (Papyrus Based) - 1.2.19 VNF

AAI schema v15: https://gerrit.onap.org/r/gitweb?p=aai/aai-common.git;a=blob;f=aai-schema/src/main/resources/onap/aai_schema/aai_schema_v15.xsd;h=545efe035a04ab79e12cb32c2a81ec22edd13369;hb=refs/heads/master - generic-vnf

VFC: https://gerrit.onap.org/r/gitweb?p=vfc/gvnfm/vnflcm.git;a=blob;f=lcm/lcm/pub/database/models.py;h=3ac4a83274a16497877cde6fb3625318bd8540bb;hb=refs/heads/master - NfInstModel

Model Analysis:

R3 ModelAAI Schema v15VFCDescriptionNoteBelongs inActionComment
vnfInstanceIdvnf-id / vnf-instance-idnfInstIdidentifier of the VNF instance


Xu: What's the relationship between vnf-id and vnf-instance-id within the AAI model?
vnfInstanceNamevnf-namenf_namename of the VNF instance. Multiple names are possible.



vnfProductName

name to identify the VNF Product, invariant for the VNF Product lifetime


Chesla: Think this should be removed as it should be identifiable by "joining" to the descriptor.
description

description of the VNF instance


Chesla: At least within AT&T, we were trying to standardize on type/role/function fields to help describe.  Is it necessary to rename the function to description?  When I see description, I generally think of something quite free form.  We thought there could be policy and automation around type/role/function.  We were planning to have type/role/function in the descriptor.  Is this something in addition?
vnfProvider

provider of the VNF model


Chesla: Think this should be removed as it should be identifiable by "joining" to the descriptor.
vnfdIdmodel-invariant-id
identifier of the VNF model



vnfdVersion

version of the VNF model


Chesla: If this is a UUID uniquely pointing to the specific version of a model, then OK.  Don't want to see, e.g., v1.0, in this field.
vnfSoftwareVersion

Software version of the VNF. This is changed when there is any change to the software that is included in the VNF package



onboardedVnfPkgInfoId

vnf-package-name
identifier of the specific VNF package on which the VNF instance is based



availabilityZoneregional-resource-zone
availability zone information of the VNF instance


Chesla: This should be removed and expressed as a relationship to the availability zone.
operationalStatusoperational-status
indicator for whether the resource is considered operational. Valid values are in-service-path and out-of-service-path.



orchestrationStatusorchestration-status
whether the VNF instance is instantiated



oamlpv4Addressipv4-oam-address
oam ip address, ipv4


Chesla: Would like the whole IM to standardize on naming of IP address field names. 
oamlpv6Addressmanagement-v6-address
oam ip address, ipv6


Chesla: Would like the whole IM to standardize on naming of IP address field names. 
instantiatedVnfInfo

information specific to an instantiated VNF instance, e.g., vm information


Chesla: VM information doesn't belong as an attribute of the VNF.  I would expect the VNF would be related to a set of VNFC instances, and each VNFC instance is related to its VM (execution environment) instance.
inMaintin-maint
whether the VNF instance is in maintenance mode, if yes, DCAE will not observe alarms/traps, etc.



isClosedLoopDisabledis-closed-loop-disabled
whether closed loop function is enabled



encryptedAccessFlagencrypted-access-flag
whether this VNF is accessed using SSH



vnfConfigurableProperty

indicator for whether autoHeal and autoScale is enabled


Chesla: Need more info about the purpose of this. E.g., should there be a configuration object which the VNF is related to?  The model-customization-id is used today to link to configuration in ECOMP.  This one probably needs discussion with the SO team.
nfNamingCodenf-naming-code
String assigned to this model used for naming purpose.


Chesla: This is used by naming policies as a short string which is used to construct the name of the VNF instance.  It could be removed if it is in the descriptor.
vnfNamingPolicyId

Identifier of the policy which has the naming logic for this VNF instance



vnfHomingPolicyId

Identifier of the policy which provides homing conditions.



nfTypenf-type
Generic description of the type of network function



nfFunctionnf-function
English description of network function that the   specific VNF deployment is providing.



nfRolenf-role
Role in the network this model will be providing



closedLoopStatus

Whether closed loop capabilities are enabled for this or not.



_nfc   (vnfcinstance)

Relatonship to the NF components that are part of this VNF.relationship


_vnfd

Relationship to the VNF descriptorrelationship


_vnfvirtuallink

Relationship to VnfVirtualLinkrelationship



vnf-name2






vnf-type






service-id






prov-status






license-key






equipment-role






vnf-discriptor-name






job-id






heat-stack-id






mso-catalog-key






management-option






ipv4-loopback0-address






nm-lan-v6-address






vcpu






vcpu-units






vmemory






vmemory-units






vdisk






vdisk-units






nshd






nvm






nnet






resource-version






summary-status






entitlement-assignment-group-uuid






entitlement-resource-uuid






license-assignment-group-uuid






license-key-uuid






persona-model-version






model-customization-id






widget-model-id






widget-model-version






as-number






regional-resource-subzone






ipv4-oam-gateway-address






ipv4-oam-gateway-address-prefix-length






vlan-id-outer






nm-profile-name







vnfmInstId




































  • No labels