Notes on ONAP Service Instance State Model to TMF 638 Mapping

References

• Discussion point from BBS Meeting Minutes#2019.02.07

• Powerpoint file linked https://wiki.onap.org/download/attachments/8227019/ONAP%20Service%20Instance%20State%20Model%20to%20TMF%20638%20Mapping%20%281%29.pptx?version=1&modificationDate=1549533524000&api=v2

Attention To

• @David Perez Caparros@Seshu Kumar Mudiganti@James Forsyth@Adrian OSullivan

Contributors

Notes

• Slide 3 "shell object created in A&AI":

  • note that mandatory fields and mandatory relationships cannot be enforced in AAI schema, if it is to allow empty shell objects as well as fully-formed objects

  • those "mandatory" fields and relationships need to be enforced by the clients of AAI instead, meaning it could be distributed across many ONAP projects

• Slide 4 orchestration-status in Dublin:

  • with the changes to the state names, how will the data migration be handled for operators upgrading to Dublin from previous releases?

  • is there any forwards-compatibility or backwards-compatibility?

• Slide 5 service-instance schema in AAI:

  • there are currently no substantive differences between Casablanca (v14) and Dublin (v15)

• Slides 7, 8, 10 mappings from TMF 638, TMF 641, ETSI SOL 005:

  • would it be better to create a "state-mapping" class in AAI that can show explicitly the mapping to ONAP orchestration-status?

  • the "state-mapping" object can be related to the service-instance object and queries can be performed using both the ONAP-native status or the external-standards-native status

• Slide 11 HSIA service updates to AAI:

  • seems OK

• Slide 12 Nomadic ONT updates to AAI:

  • red-boxes appear to be missing the update of ONT's attachment point?