...
| attribute name | optionality | data type | constraint | description | provider | consumer | note | Chesla's Comments |
|---|---|---|---|---|---|---|---|---|
| vnfInstanceId | M | identifier of the VNF instance | AAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy | AAI: vnf-id | OK | ||
| vnfInstanceName | O | name of the VNF instance | AAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy? | AAI: vnf-name | OK, would make it mandatory just from a usage perspective | ||
| vnfInstanceAlterName | O | alternative name of the VNF instance | AAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy? | AAI: vnf-name2 | OK | ||
| vnfInstanceNamingCode | O | short code of the VNF instance | AAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy? | AAI: nf-naming-code | This is used in naming policies as a short string which is used to construct the name of the VNF, just FYI. | ||
| vnfProductName | O | name to identify the VNF Product, invariant for the VNF Product lifetime | AAI | SO, VF-C? | maybe combined with one of the above name attributes relates to ETSI IFA007v231: vnfProductName | Think this should be removed as it should be identifiable by "joining" to the descriptor. | ||
| description | O | description of the VNF instance | AAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy? | AAI: nf-function, ETSI IFA007v231: vnfInstanceDescription | 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. | ||
| vnfProvider | M | provider of the VNF model | AAI | SO, VF-C? | ETSI IFA007v231: vnfProvider | Think this should be removed as it should be identifiable by "joining" to the descriptor. | ||
| vnfdId | M | identifier of the VNF model | AAI | SO, VF-C, APP-C, DCAE? | AAI: model-invariant-id, ETSI IFA007v231: vnfdId | This is part of your "join" key to the descriptor. OK | ||
| vnfdVersion | M | version of the VNF model | AAI | SO, VF-C, APP-C, DCAE? | AAI: model-version-id, ETSI IFA007v231: vnfdVersion | 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 | M | Software version of the VNF. This is changed when there is any change to the software that is included in the VNF package | AAI | SO, VF-C, APP-C? | ETSI IFA007v231: vnfSoftwareVersion | OK | ||
| onboardedVnfPkgInfoId | M | identifier of the specific VNF package on which the VNF instance is based | AAI | SO, VF-C? | ETSI IFA007v231: onboardedVnfPkgInfoId | Surprised me but not my area of expertise. | ||
| availabilityZone | M | availability zone information of the VNF instance | AAI | SO, VF-C, APP-C? | AAI: regional-resource-zone | This should be removed and expressed as a relationship to the availability zone. | ||
| provStatus | O | provisioning status, used as a trigger for operational monitoring of this resource by service assurance systems valid value example: PROVISIONED, PREPROVISIONED, CAPPED | AAI | service assurance system | AAI: prov-status | OK, must have enumerated values. | ||
| operationalStatus | O | indicator for whether the resource is considered operational. Valid values are in-service-path and out-of-service-path. | AAI | SO, APP-C? | AAI: operational-status | OK, must have enumerated values | ||
| instantiationState | O | whether the VNF instance is instantiated | AAI | SO, VF-C? | ETSI IFA007v231: instantiationState | Is this what AAI currently calls orchestration-status? | ||
| oamIpv4Address | O | oam ip address, ipv4 | AAI | SO, VF-C, APP-C, DCAE? | AAI: ipv4-oam-address | Would like the whole IM to standardize on naming of IP address field names. | ||
| oamIpv6Address | O | oam ip address, ipv6 | AAI | SO, VF-C, APP-C, DCAE? | AAI: management-v6-address | Would like the whole IM to standardize on naming of IP address field names. | ||
| instantiatedVnfInfo | M | information specific to an instantiated VNF instance, e.g., vm information | AAI | SO, VF-C, APP-C, DCAE? | ETSI IFA007v231: instantiatedVnfInfo | 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 | O | whether the VNF instance is in maintenance mode, if yes, DCAE will not observe alarms/traps, etc. | AAI | DCAE | AAI: in-maint | OK | ||
| isClosedLoopDisabled | O | whether closed loop function is enabled | AAI | Policy | AAI: is-closed-loop-disabled | OK | ||
| encryptedAccessFlag | O | whether this VNF is accessed using SSH | AAI | AAI: encrypted-access-flag | OK | |||
| vnfConfigurableProperty | O | indicator for whether autoHeal and autoScale is enabled | AAI | VF-C | ETSI IFA007v231: vnfConfigurableProperty | Need more info about the purpose of this. E.g., should there be a configuration object which the VNF is related to? |
NOTE: optionality, producer and consumer column are to be confirmed.
...