VNF Instance Model Update

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 Model	AAI Schema v15	VFC	Description	Note	Belongs in	Action	Comment

R3 Model	AAI Schema v15	VFC	Description	Note	Comment
vnfInstanceId	vnf-id / vnf-instance-id	nfInstId	identifier of the VNF instance		Xu: What's the relationship between vnf-id and vnf-instance-id within the AAI model?
vnfInstanceName	vnf-name	nf_name	name 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.
vnfdId	model-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
availabilityZone	regional-resource-zone		availability zone information of the VNF instance		Chesla: This should be removed and expressed as a relationship to the availability zone.
operationalStatus	operational-status		indicator for whether the resource is considered operational. Valid values are in-service-path and out-of-service-path.
orchestrationStatus	orchestration-status		whether the VNF instance is instantiated
oamlpv4Address	ipv4-oam-address		oam ip address, ipv4		Chesla: Would like the whole IM to standardize on naming of IP address field names.
oamlpv6Address	management-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.
inMaint	in-maint		whether the VNF instance is in maintenance mode, if yes, DCAE will not observe alarms/traps, etc.
isClosedLoopDisabled	is-closed-loop-disabled		whether closed loop function is enabled
encryptedAccessFlag	encrypted-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.
nfNamingCode	nf-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.
nfType	nf-type		Generic description of the type of network function
nfFunction	nf-function		English description of network function that the specific VNF deployment is providing.
nfRole	nf-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 descriptor	relationship
_vnfvirtuallink			Relationship to VnfVirtualLink	relationship
	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