References

AAI-CCVPN Schema Proposal for Casablanca Release
AAI-BBS Proposals for Dublin Release / AAI-2154 - Getting issue details... STATUS
AAI Modeling Design - 2019-02-28

Principles

tbc

Discussion

From BBS use case

In general, first option is written as "add <new attribute> to <class>".

First justification for this action is that the <new attribute> is more generally applicable to other uses, not just this one case.
Second justification is that it will be used in high percentage of cases (not left empty) and have additional properties such as being mandatory.
Third justification is that there will be core code written that depends on this attribute, so it should be a core part of the schema
Fourth justification is that the exact nature and number of <new attributes> is well-known, so it will not require frequent schema changes to adjust to the conditions.

In general, the second option is written as "add Metadata sub-object then configure <new attribute> Metadatum entry".

First justification for this action is that the <new attribute> is more specifically applicable to this one case only.
Second justification is that it will be left empty in high percentage of cases, i.e. not mandatory.
Third justification is that there will be none of the core code depends on this attribute, but the information needs to be conveyed somehow
Fourth justification is that the exact nature and number of <new attributes> is variable or unbounded, so this avoids frequent schema changes to adjust to the conditions.

In general, the third option is written as "configure <new attribute> Metadatum entry linked from service-instance into relationship-list".

First justification for this action is that schema change is to be avoided as much as possible.
Second justification is that the <new attribute> is more specifically applicable to this one case only
Third justification is that it will be shared/linked/referred from several other objects via the relationship-list
Fourth justification is that there will be none of the core code depends on this attribute, but the information needs to be conveyed somehow
Fifth justification is that the exact nature and number of <new attributes> is variable or unbounded.

From AAI-2154

Victor to confirm the details below as discussed, after matching up existing AAI attributes to the proposals in the Model Design diagram for "HSIA CFS" in https://lf-onap.atlassian.net/wiki/display/DW/BBS+Modeling

To enable use of "Metadata" and "Metadatum" in relationship-list, add EdgeRules for:

generic-vnf to metadatum
pnf to metadatum
cp to metadatum

Use the "service-instance" with existing "Metadata" sub-object to contain all the relevant Metadatum entries (as per options described below).

To enable use of "CvlanTagEntry" and "VlanTag" in relationship-list, add EdgeRules for:

cp to cvlan-tag-entry
cp to vlan-tag

For generic-vnf "RG MAC Address" field proposal to do one of:

add "MAC Address" attribute
add "Metadata" sub-object, then configure "RG MAC Address" Metadatum entry
configure "RG MAC Address" Metadatum entry from service-instance into relationship-list

For generic-vnf "Service Type" field proposal to do one of:

add "Service Type" attribute
add "Metadata" sub-object, then configure "Service Type" Metadatum entry
configure "Service Type" Metadatum entry from service-instance into relationship-list

For generic-vnf "Upstream speed" and "Downstream speed" field proposal to do one of:

move to "logical-link", use speed-value to represent the connection speeds
move to "service-instance", use existing "Metadata" sub-object with "Upstream speed" and "Downstream speed" Metadatum entries

For generic-vnf "Access ID" field proposal to do one of:

add "Access ID" attribute (represents foreign key to data in an external management system in ESR)
add "Metadata" sub-object, then configure "Access ID" Metadatum entry
configure "Access ID" Metadatum entry from service-instance into relationship-list

For pnf "MAC Address" field proposal to do one of:

add "MAC Address" attribute
add "Metadata" sub-object, then configure "MAC Address" Metadatum entry
configure "MAC Address" Metadatum entry from service-instance into relationship-list

For pnf "Manufacturer" field proposal to do one of:

use existing "equipVendor" attribute

For pnf "SerialNumber" field proposal to do one of:

use existing "serialNumber" attribute

For pnf "Model" field proposal to do one of:

use existing "equipModel" attribute

For pnf "Type" field proposal to do one of:

use existing "equipType" attribute

For pnf "SW version" field proposal to do one of:

use existing "swVersion" attribute

For cp "OLT Name" field proposal to do one of:

add "cpName" attribute
add "Metadata" sub-object, then configure "OLT Name" Metadatum entry
configure "OLT Name" Metadatum entry from service-instance into relationship-list

For cp "OLT PON Slot" field proposal to do one of:

add "slotId" attribute
add "Metadata" sub-object, then configure "OLT PON Slot" Metadatum entry
configure "OLT PON Slot" Metadatum entry from service-instance into relationship-list

For cp "OLT PON Port" field proposal to do one of:

use existing "portId" attribute

For cp "CVLAN" field proposal to do one of:

configure "CvlanTagEntry" object into relationship-list (only for cvlan)
configure "VlanTag" object into relationship-list (capable of cvlan and svlan)

For cp "Expected ONT ID" field proposal to do one of:

add "Expected ONT ID" attribute (is this related to the proposed "attachmentPoint" attribute on pnf?)
add "Metadata" sub-object, then configure "Expected ONT ID" Metadatum entry
configure "Expected ONT ID" Metadatum entry from service-instance into relationship-list

Attachments

	File	Modified

No files shared here yet.