Date

at 10:00AM EDT

Meeting Link: https://zoom.us/j/957965398

Discussed

  • Record the Meeting!!
  • Recording:
  • Introductions
  • JIRA Review Matthieu Geerebaert
  • Brainstorming for Dublin Andy Mayer; ALL
    • Items for Legato
      • TEAM PLEASE ADD ITEMS HERE
        From Orange (Ludovic):

      • 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

    • Items for Interlude
      • TEAM PLEASE ADD ITEMS HERE
        from Orange (Ludovic)

         Study how we can control modification requested at Interlude level – they are at least 2 subtopics there:

    • Identify where the information could be managed within ONAP (in SDC ? have attribute change value and state change authorized at SOF-SOF interaction level ?)
    • Explore if External API can be used by internal ONAP Components as a proxy to talk to external Partner ( e.g. ONAP 1 SO call ONAP 1 ExtAPI, then ONAP 1 ExtAPI call ONAP 2 ExtAPI ) i.e. ONAP internal components can communicate securely internally, External API act as proxy to forward request ( e.g. Service Order ) to Partner ( maybe a Partners ONAP External API Framework ). 
    • Define the API (resource model) that allow system to request ‘authorized’ service modification (Policy API ?)




Last TIme:



Action items