...
6) What's the plan for network management profile information?
| attribute name | optionalitycardinality | data type | constraint | description | provider | consumer | note | Chesla's Comments | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| vnfInstanceId | M1 | identifier of the VNF instance | AAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy | AAI: vnf-id | OK | |||||||||||
| vnfInstanceName | O1 | 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 | |||||||||||
| vnfInstanceAlterNameO | 0..1 | alternative name of the VNF instance | AAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy? | AAI: vnf-name2 | OK | |||||||||||
| vnfInstanceNamingCodeO | 0..1 | short code of the VNF instance | AAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy? | AAI: nf-naming-code | 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. | |||||||||||
| vnfProductNameO | 0..1 | 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. | |||||||||||
| descriptionO | 0..1 | 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 | M1 | 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 | M1 | 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 | M1 | 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 | M1 | 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 | M1 | 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 | M1 | 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. | |||||||||||
| provStatusO | 0..1 | 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. | |||||||||||
| operationalStatusO | 0..1 | 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 | O1 | whether the VNF instance is instantiated | AAI | SO, VF-C? | ETSI IFA007v231: instantiationState | Is this what AAI currently calls orchestration-status? | |||||||||||
| oamIpv4AddressO | 0..1 | 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. | |||||||||||
| oamIpv6AddressO | 0..1 | 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. | |||||||||||
| instantiatedVnfInfoM | 0..1 | 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. | |||||||||||
| inMaintO | 0..1 | whether the VNF instance is in maintenance mode, if yes, DCAE will not observe alarms/traps, etc. | AAI | DCAE | AAI: in-maint | OK | |||||||||||
| isClosedLoopDisabledO | 0..1 | whether closed loop function is enabled | AAI | Policy | AAI: is-closed-loop-disabled | OK | |||||||||||
| encryptedAccessFlagO | 0..1 | whether this VNF is accessed using SSH | AAI | AAI: encrypted-access-flag | OK | ||||||||||||
| vnfConfigurablePropertyO | 0..1 | 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: optionalitycardinality, producer and consumer column are to be confirmed.
...
NOTE: Whether this model is applicable for both virtual NFC and physical NFC is to be confirmed.
| attribute name | optionalitycardinality | data type | constraint | description | provider | consumer | note | Chesla's Comments |
|---|---|---|---|---|---|---|---|---|
| nfcInstanceId | M1 | identifier of the NFC instance | AAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy | AAI: vnfc-name, ETSI IFA008v231: vnfcInstanceId. | OK - but has there been an info modeling standard on attribute naming? E.g., should this be vnfcInstanceId or nfcInstanceId? | ||
| nfcNamingCodeO | 0..1 | short code of the NFC instance | AAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy? | AAI: nfc-naming-code | This is used by naming policies as a short string which is used to construct the name of the VNFC instance. It could be removed if it is in the descriptor. | ||
| descriptionO | 0..1 | description of the NFC instance | AAI | SO, VF-C, APP-C, SDN-C, DCAE, Policy? | AAI: nfc-function | Same comments as on VNF, we would like to see type/role/function and perhaps description is in addition. Also, type/role/function can be in the descriptor. | ||
| vduId | M1 | identifier of the model of the NFC instance | AAI | SO, VF-C, APP-C? | AAI: model-invariant-id, ETSI : vduId | Has the modeling team had the hard discussion regarding what ONAP really wants VDU to mean? Regardless, perhaps this shouldn't be an attribute but instead should be a relationship? | ||
| l3InterfaceIpv4AddressListO | 0..N | layer-3 interface addresses, ipv4 | AAI | SO, VF-C, APP-C, SDN-C? | AAI: l3-interface-ipv4-address-list | This is not an attribute, it is a relationship. See general comments as well. | ||
| l3InterfaceIpv6AddressListO | 0..N | layer-3 interface addresses, ipv6 | AAI | SO, VF-C, APP-C, SDN-C? | AAI: l3-interface-ipv6-address-list | This is not an attribute, it is a relationship. See general comments as well. | ||
| vnfcStateO | 0..1 | operating status of the VM valid value example: STARTED (POWER_ON), STOPPED (POWER_OFF) | AAI | SO?, VF-C | ETSI IFA008v231: vnfcState | Should this be vnfcOperatingState? Should it be operationalStatus (akin to the VNF instance)? Should we standardize on "State" vs. "Status"? | ||
| provStatusO | 0..1 | 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 | ||
| inMaintO | 0..1 | whether the NFC instance is in maintenance mode, if yes, DCAE will not observe alarms/traps, etc. | AAI | DCAE | AAI: in-maint | OK | ||
| isClosedLoopDisabledO | 0..1 | whether closed loop function is enabled | AAI | Policy | AAI: is-closed-loop-disabled | OK |
NOTE: optionalitycardinality, producer and consumer column are to be confirmed.