| 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 | cardinality | data type | constraint | description | provider | consumer | note | Chesla's Comments |
|---|---|---|---|---|---|---|---|---|
| vnfInstanceId | 1 | identifier of the VNF instance | SO, VF-C, APP-C, SDN-C, DCAE, Policy | AAI: vnf-id | OK | |||
| vnfInstanceName | 1 | name of the VNF instance | SO, VF-C, APP-C, SDN-C, DCAE, Policy? | AAI: vnf-name | OK, would make it mandatory just from a usage perspective | |||
| vnfInstanceAlterName | 0..1 | alternative name of the VNF instance | SO, VF-C, APP-C, SDN-C, DCAE, Policy? | AAI: vnf-name2 | OK | |||
| vnfInstanceNamingCode | 0..1 | short code of the VNF instance | 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. | |||
| vnfProductName | 0..1 | name to identify the VNF Product, invariant for the VNF Product lifetime | 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 | 0..1 | description of the VNF instance | 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 | 1 | provider of the VNF model | SO, VF-C? | ETSI IFA007v231: vnfProvider | Think this should be removed as it should be identifiable by "joining" to the descriptor. | |||
| vnfdId | 1 | identifier of the VNF model | 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 | 1 | version of the VNF model | 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 | 1 | Software version of the VNF. This is changed when there is any change to the software that is included in the VNF package | SO, VF-C, APP-C? | ETSI IFA007v231: vnfSoftwareVersion | OK | |||
| onboardedVnfPkgInfoId | 1 | identifier of the specific VNF package on which the VNF instance is based | SO, VF-C? | ETSI IFA007v231: onboardedVnfPkgInfoId | Surprised me but not my area of expertise. | |||
| availabilityZone | 1 | availability zone information of the VNF instance | SO, VF-C, APP-C? | AAI: regional-resource-zone | This should be removed and expressed as a relationship to the availability zone. | |||
| provStatus | 0..1 | provisioning status, used as a trigger for operational monitoring of this resource by service assurance systems valid value example: PROVISIONED, PREPROVISIONED, CAPPED | service assurance system | AAI: prov-status | OK, must have enumerated values. | |||
| operationalStatus | 0..1 | indicator for whether the resource is considered operational. Valid values are in-service-path and out-of-service-path. | SO, APP-C? | AAI: operational-status | OK, must have enumerated values | |||
| instantiationState | 1 | whether the VNF instance is instantiated | SO, VF-C? | ETSI IFA007v231: instantiationState | Is this what AAI currently calls orchestration-status? | |||
| oamIpv4Address | 0..1 | oam ip address, ipv4 | 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 | 0..1 | oam ip address, ipv6 | 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 | 0..1 | information specific to an instantiated VNF instance, e.g., vm information | 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 | 0..1 | whether the VNF instance is in maintenance mode, if yes, DCAE will not observe alarms/traps, etc. | DCAE | AAI: in-maint | OK | |||
| isClosedLoopDisabled | 0..1 | whether closed loop function is enabled | Policy | AAI: is-closed-loop-disabled | OK | |||
| encryptedAccessFlag | 0..1 | whether this VNF is accessed using SSH | AAI: encrypted-access-flag | OK | ||||
| vnfConfigurableProperty | 0..1 | indicator for whether autoHeal and autoScale is enabled | 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: cardinality, producer and consumer column are to be confirmed.
| Anchor | ||||
|---|---|---|---|---|
|
NFC Model (VNFC Instance)
Chesla's General Comments:
There needs to be an info modeling session around VDU, VNFC, and the various execution environments provided by the cloud. It's important to be in agreement as to whether the VDU is considered to be the VNFC descriptor. Also, ONAP should come up with a well-understood and agreed to separation of concerns between the info/data model for the cloud and the info/data model for the virtualized components. For example, how many VNFCs per execution environment (where one example of an execution environment is a VM). The VNFCs should have connection points? Those connection points should be related to the interfaces on the execution environment? I implore the ONAP team to give this a great deal of thought before deciding. It's worth getting right up front than paying for it later.
NOTE: Whether this model is applicable for both virtual NFC and physical NFC is to be confirmed.
| attribute name | cardinality | data type | constraint | description | provider | consumer | note | Chesla's Comments |
|---|---|---|---|---|---|---|---|---|
| nfcInstanceId | 1 | identifier of the NFC instance | 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? | |||
| nfcNamingCode | 0..1 | short code of the NFC instance | 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. | |||
| description | 0..1 | description of the NFC instance | 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 | 1 | identifier of the model of the NFC instance | 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? | |||
| l3InterfaceIpv4AddressList | 0..N | layer-3 interface addresses, ipv4 | 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. | |||
| l3InterfaceIpv6AddressList | 0..N | layer-3 interface addresses, ipv6 | 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. | |||
| vnfcState | 0..1 | operating status of the VM valid value example: STARTED (POWER_ON), STOPPED (POWER_OFF) | 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"? | |||
| provStatus | 0..1 | provisioning status, used as a trigger for operational monitoring of this resource by service assurance systems valid value example: PROVISIONED, PREPROVISIONED, CAPPED | service assurance system | AAI: prov-status | OK | |||
| inMaint | 0..1 | whether the NFC instance is in maintenance mode, if yes, DCAE will not observe alarms/traps, etc. | DCAE | AAI: in-maint | OK | |||
| isClosedLoopDisabled | 0..1 | whether closed loop function is enabled | Policy | AAI: is-closed-loop-disabled | OK |
NOTE: cardinality, producer and consumer column are to be confirmed.