...
| Anchor | ||||
|---|---|---|---|---|
|
VNF Model (VNF Instance)
Chesla general comment:
1) AAI is not generally the Provider of data. For the most part, AAI stores information provided other components. There are some exceptions (e.g., provStatus is set by other systems but AAI is considered the source of truth for the value). For example, the vnfInstanceId is provided by either SO or SDN-C. So it's not clear to me what is meant by provider and consumer in your table.
2) This captures a lot (but not all) of the fields currently considered by AAI to be necessary to support ONAP. If the goal here is to provide the info model for the VNF resource entirely, then there may be attributes that are known to components like SDN-C and not to AAI which you should capture here.
3) FYI - there are objects called line-of-business (captures service provider Product info), platform, project, and owning-entity. I don't see much below that seems to overlap with those concepts but wanted folks to be aware of them. One can relate the VNF instance to instances of these object types.
4) There are other useful IP addresses that should be considered
5) The managementOption field should be considered. It allows an operator to give an indication of what entity is managing the VNF instance. If you have an alternate plan for that, I'd like to understand it.
6) What's the plan for network management profile information?
| 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. We were planning to have type/role/function in the descriptor. Is this something in addition? | ||
| 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, SO | 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? The model-customization-id is used today to link to configuration in ECOMP. This one probably needs discussion with the SO team. |
NOTE: optionality, producer and consumer column are to be confirmed.
...