Draft Dublin Legato High Level Requirements

Owned by Andy Mayer
Last updated: Oct 03, 2018
2 min read



This page is intended to capture the ongoing study and discussion in the Ext-API project related to the BSS/OSS interaction enabled through the MEF Legato specification. This is related to the JIRA item planned in the Casablanca cycle. While it is essential to carry out a detailed study on the inter-provider interactions and overall impact on ONAP as a solution, the scope of this page will be limited to the impact on External API. Additionally, while the focus is on the MEF Legato specification, there is some good amount of work being done in many SDOs to address the scope of BSS/OSS management interactions - notably TMForum, ETSI, NGMN, ONF, IETF etc. It is worth noting the scope and outcome of these SDOs and analyze some best practices that ONAP can incorporate.  Further, the page also captures the short term and long term requirements to support Legato interaction.

















Requirements

Easy

  • Provide easy-access to serviceSpec description JSON File. This feature was push by Huawei/Adrian and then deprecated from Casablanca but it's something interesting. It is already documented in https://jira.onap.org/browse/EXTAPI-105 and https://jira.onap.org/browse/EXTAPI-108

  • Publish NBI ServiceOrder notification on internal ONAP DMAAP component

  • Leverage DMAAP Component or SDC own capability  to add catalog notification from NBI.

  • Leverage DMAAP Component to add inventory Notification from NBI.

  • Extend SO APIs to also support SO PUT for serviceInstances API, SO PUT is already supported by e2eServiceInstances SO APIs. The SO PUT could then be used by Service Order with action modify to allow for SO to handle the recreation of the Service Instance with the specified ServiceCharacteristics.

Complex …. If not code targeted to Dublin I think design should begin with Dublin

  • Not a short term feature...but in long term it could be cool to see how we can leverage DCAE information to expose service problem API in NBI (via SPM API)... a lot of pre-work is required to check feasibility

  • And last but not last...it should be cool to ease the BSS life with  the ONAP service. As of now, in the SO, the serviceSpec expected is the technical solution...meaning that if we have in SDC 2 services described: a vFirewall Editor1and a vFirewall Editor 2 , we expect to have either one of these in the service order... but from a BSS - in some UC -  it could be better to request a vFirewall...and let the service layer pick one of them depending on internal rule.... This is what we usually identify under the CFS-RFS decoupling. We'll need some help to SDC, we'll need to define NBI boundary but definitively it's something making sense from Orange perspective.

I will add there a third category…. Improvements on NBI dependent to others components roadmap:

  • Improve service inventory API to retrieve instantiated service characteristic value

  • Improve ServiceOrder in order to tackle service modification request that will managed in ONAP/SO as a real service modification (and not delete and add)  to modify attribute value and/or status

Dependency on other projects