Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Navigation

Contributors

(login to see contributors list)


References

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://wiki.onap.org/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.


  • No labels