Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added comment column to NFC instance and general comments as well.

...

attribute nameoptionalitydata typeconstraintdescriptionproviderconsumernoteChesla's Comments 
vnfInstanceIdM

identifier of the VNF instanceAAISO, VF-C, APP-C, SDN-C, DCAE, PolicyAAI: vnf-id OK
vnfInstanceNameO

name of the VNF instanceAAISO, VF-C, APP-C, SDN-C, DCAE, Policy?AAI: vnf-name OK, would make it mandatory just from a usage perspective
vnfInstanceAlterNameO

alternative name of the VNF instanceAAISO, VF-C, APP-C, SDN-C, DCAE, Policy?AAI: vnf-name2 OK
vnfInstanceNamingCodeO

short code of the VNF instanceAAI SO, VF-C, APP-C, SDN-C, DCAE, Policy?AAI: nf-naming-code This This is used in by naming policies as a short string which is used to construct the name of the VNF , just FYIinstance.  It could be removed if it is in the descriptor.
vnfProductNameO

name to identify the VNF Product, invariant for the VNF Product lifetimeAAISO, 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

description of the VNF instanceAAISO, VF-C, APP-C, SDN-C, DCAE, Policy?AAI: nf-function, ETSI IFA007v231: vnfInstanceDescriptionAt 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?
vnfProviderM

provider of the VNF modelAAISO, VF-C?ETSI IFA007v231: vnfProviderThink this should be removed as it should be identifiable by "joining" to the descriptor.
vnfdIdM

identifier of the VNF modelAAISO, VF-C, APP-C, DCAE?AAI: model-invariant-id, ETSI IFA007v231: vnfdId

 This is part of your "join" key to the descriptor.

OK

vnfdVersionM

version of the VNF modelAAISO, VF-C, APP-C, DCAE?AAI: model-version-id, ETSI IFA007v231: vnfdVersionIf 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.
vnfSoftwareVersionM

Software version of the VNF. This is changed when there is any change to the software that is included in the VNF packageAAISO, VF-C, APP-C?ETSI IFA007v231: vnfSoftwareVersion OK
onboardedVnfPkgInfoIdM

identifier of the specific VNF package on which the VNF instance is basedAAISO, VF-C?ETSI IFA007v231: onboardedVnfPkgInfoId Surprised me but  not my area of expertise.
availabilityZoneM

availability zone information of the VNF instanceAAISO, VF-C, APP-C?AAI: regional-resource-zoneThis should be removed and expressed as a relationship to the availability zone.
provStatusO

provisioning status, used as a trigger for operational monitoring of this resource by service assurance systems
valid value example: PROVISIONED, PREPROVISIONED, CAPPED
AAIservice assurance systemAAI: prov-statusOK, must have enumerated values.
operationalStatusO

indicator for whether the resource is considered operational. Valid values are in-service-path and out-of-service-path.AAISO, APP-C?AAI: operational-statusOK, must have enumerated values
instantiationStateO

whether the VNF instance is instantiatedAAISO, VF-C?ETSI IFA007v231: instantiationStateIs this what AAI currently calls orchestration-status? 
oamIpv4AddressO

oam ip address, ipv4AAISO, VF-C, APP-C, DCAE?AAI: ipv4-oam-addressWould like the whole IM to standardize on naming of IP address field names.   
oamIpv6AddressO

oam ip address, ipv6AAISO, VF-C, APP-C, DCAE?AAI: management-v6-addressWould like the whole IM to standardize on naming of IP address field names. 
instantiatedVnfInfoM

information specific to an instantiated VNF instance, e.g., vm informationAAISO, VF-C, APP-C, DCAE?ETSI IFA007v231: instantiatedVnfInfoVM 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

whether the VNF instance is in maintenance mode, if yes, DCAE will not observe alarms/traps, etc.AAIDCAEAAI: in-maint OK
isClosedLoopDisabledO

whether closed loop function is enabledAAIPolicyAAI: is-closed-loop-disabledOK
encryptedAccessFlagO

whether this VNF is accessed using SSHAAI
AAI: encrypted-access-flagOK
vnfConfigurablePropertyO

indicator for whether autoHeal and autoScale is enabledAAIVF-C, SOETSI IFA007v231: vnfConfigurablePropertyNeed 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.

...

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 nameoptionalitydata typeconstraintdescriptionproviderconsumernoteChesla's Comments 
nfcInstanceIdM

identifier of the NFC instanceAAISO, VF-C, APP-C, SDN-C, DCAE, PolicyAAI: 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

short code of the NFC instanceAAISO, VF-C, APP-C, SDN-C, DCAE, Policy?AAI: nfc-naming-codeThis 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

description of the NFC instanceAAISO, VF-C, APP-C, SDN-C, DCAE, Policy?AAI: nfc-functionSame 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.
vduIdM

identifier of the model of the NFC instanceAAISO, VF-C, APP-C?AAI: model-invariant-id, ETSI : vduIdHas 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

layer-3 interface addresses, ipv4AAISO, VF-C, APP-C, SDN-C?AAI: l3-interface-ipv4-address-listThis is not an attribute, it is a relationship.  See general comments as well. 
l3InterfaceIpv6AddressListO

layer-3 interface addresses, ipv6AAISO, 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

operating status of the VM
valid value example: STARTED (POWER_ON), STOPPED (POWER_OFF)
AAISO?, VF-CETSI IFA008v231: vnfcState Should this be vnfcOperatingState?  Should it be operationalStatus (akin to the VNF instance)?  Should we standardize on "State" vs. "Status"?
provStatusO

provisioning status, used as a trigger for operational monitoring of this resource by service assurance systems
valid value example: PROVISIONED, PREPROVISIONED, CAPPED
AAIservice assurance systemAAI: prov-status OK
inMaintO

whether the NFC instance is in maintenance mode, if yes, DCAE will not observe alarms/traps, etc.AAIDCAEAAI: in-maint OK
isClosedLoopDisabledO

whether closed loop function is enabledAAIPolicyAAI: is-closed-loop-disabledOK

NOTE: optionality, producer and consumer column are to be confirmed.