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