2018-05-23 [ExtAPI] Meeting notes

Date

May 23, 2018 at 10:00AM EDT

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

Apologies

@mark gibson unable to start zoom session - not properly setup to share so session did not happen.    Apologies to all for the missing session. 

Discussed

  • Record the Meeting!! (issue with Zoom recording)

  • Introductions

  • Update on code contribution @Ludovic Robert

    • Everything is done for Beijing, no bugs open

    • Pairwise texting complete.

    • Congratulations to implementation team!

  • Casablanca feature proposal Ludovic Robert

    • 1/ Add notification for serviceOrder API

      Relevance : ***

      Complexity : Easy

      Allow BSS (or any other) system to receive order/OrderItem update. BSS (or any other system) will not have to pool. We can allow several distinct notification (Nice to have: let subscriber specify notification contains). Minimum is to provide ServiceOrderStateChangeNotifications etc to HUB subscriber. After if we’re able to get a notification from SO it will be perfect but initial requirement is only at external API northbound

      Prerequisite : nothing for basic deliver…SO notifications to have high performance (without SO notification, NBI will pool SO as of today)

      Notifications related to ServiceOrder: - ServiceOrderCreationNotification - ServiceOrderAttributeValueChangeNotification - ServiceOrderStateChangeNotification - ServiceOrderInformationRequiredNotification - ServiceOrderRemoveNotification

      2/update ServiceOrder to manage Service modification request UC

      Relevance : ***

      Complexity : Average to High depending on SO capability to handle service modification

      This will allow BSS system to trigger service modification request. By modification we mean: characteristic value change, status change (other ?). Minimum could be to handle modification that can be managed in SO with a Delete Service and then Add service (this is a change up to nbi but remove/add down to nbi). This is not service order modification butt service modification on existing service instance in the inventory (new service order with action change)

      Prerequisite : could require SO upgrade – Check if some use case can be handle by NBI only (triggering add/remove in SO) ?

      Possibly related to CC VPN use case, explore other use cases

      3/Add notification for serviceInventory API

      Relevance : **

      Complexity : Easy

      Allow BSS (or any other) system to receive service state update.

      Prerequisite : It requires to have a notification from AAI because NBI will not pool AAI



      4/Add notification for serviceCatalog API

      Relevance : **

      Complexity : Easy

      Allow BSS catalog function to receive service catalog notification as serviceSpec status change or characteristic change (new value in an enum list for example). Could be interesting to track these serviceSpec update to update accordingly productSpec

      Prerequisite : It requires to have a notification from SDC because NBI will not pool AAI



      5/Improve ServiceCatalog API for characteristic (Adrian suggestion)

      Relevance : **

      Complexity: ***

      Expose from NBI json (or other format) file describing the serviceSpec characteristic (same type of file we can retrieve on MEF Git Hub to describe an UNISpec for example)

      Prerequisite : Need SDC improvements

      Convert YAML in CSAR to ONAP wide consistent JSON schema for Service Characteristic Input parameters and provide across the ServiceCatalog API

      6/Improve ServiceInventory API

      Relevance : ***

      Complexity: ?

      As of now we retrieve very few information from AAI – Perhaps digging more in the instantiated VNF or VF could allow us to have more information as service state or serviceCharacteristic for example.

      Adrian has also some thoughts on that.

      Prerequisite : Need AAI expertise

      Need enhancement to AAI UI to see more topology details across API

      7/Integrate External API/NBI within ONAP MSB

      Relevance : **

      Complexity: ?

      Prerequisite : Work with MSB team

    • May need to consider how External API agent functionality can be decoupled from MSB

  •  

    • 8/ Build End-to-End Use Case 

      Relevance : **

      Complexity: ?

      Prerequisite : 

    • Showcase External API from a complete Service Lifecycle perspective. Apply ONAP Use Cases.

  • All agree that these 8 items are to be included into scope for Casablanca

  • Contribution @Former user (Deleted) (CenturyLink)

    • Casablanca Proposal: see: <link>

    • API Logging possibly using a Log Processor like Apache Nifi

    • Allows temporal flow analysis of API calls

    • Looking for interest in contributing to this activity

    • Logging message structure with JSON schema

    • Demo next week

    • Agree to add to Casablanca scope

    • Share with Architecture Sub-committee (Jack and  Parviz)





  • Contribution @Manoj Nair (Netcracker)

    • Casablanca Proposal, see: link

    • Extend ExtAPI scope to include "southbound APIs" to External SDN Controller, Edge Orchestrators, Domain Orchestrators, Domain Controllers (also Legacy OSS)

    • Need to explore relationship with MEF Presto NRP based on ONF TAPI

    • Continue discussion next week

  • Next week: ONF TAPI discussion see: <link>

  • Interlude Update (@MEHMET TOY)

    • Example Modify CIR for E-Access Service instantiated in a Partner Domain

    • Flows showing how Interlude works for the Elastic E-Access service

    • Potential Casablanca definition

  • Next Time: Discussion on relationship to MSB "External Gateway"; External API code to do mediation / translations

    • Cover registration, "visual range" of service as external 

  • Next Time: Continue Casablanca planning:

    • HOMEWORK: Which APIs have business impact; Put together PPT on proposed Casablanca API functionality.

    • Use Cases for Interlude; End to end flows 

    • Code to parse YAML from Service Catalog. Work with SDC on TOSCA toolset. Parse YAML within SDC once and create inputs once Service Definition is finalized.

    • Service Qualification / Servicability (pre-order) (is capacity and topology available supporting the specific set of service parameters; do policies permit instantiation, mapping of Service requirements to capabilities provided by the platform; checking against of service constraints and characteristics from Service catalog (or via catalog exposure to BSS), Service compatibility with other services instantiated within the customer's service group )

    • License Accounting

    • A&AI Customer (Possible removal of customer info from ONAP)

    • Enhancements for complex input types (transition from name-value pair to JSON structures-blob ) (e.g., MEF Bandwidth Profiles, L2 Connectivity as a Use Case)

  • Next Time:

    • Sync up with A&AI on JIRA issues (@Jenny Huang@Ludovic Robert) Next time

    • Document API style used for External API at Legato interface reference point 

    • Casablanca use cases for External API

    • Modeling of external facing APIs for ONAP and other ONAP projects (e.g., CLI)

    • Alignment on API styles for ONAP external APIs

    • Slide updates for MEF meeting on External API and Legato  (Wednesday Morning) @Andy Mayer@Ludovic Robert; Bithika; @MEHMET TOY@Abinash Vishwakarma@mark gibson@Neil Thayer

Last time

  • R3+ Interlude discussion @MEHMET TOY

    • Elastic EVC use case impacts on Legato and Interlude

    • It may be possible to apply Service Catalog, Service Ordering, Service Inventory to Interlude

    • Action: @Andy Mayer to send Mehmet invite to modeling discussion

    • Explore possible inclusion of future ONAP use case for Elastic Connectivity Service @MEHMET TOY@Andy Mayer@Parviz Yegani

    • Relationship with IETF L2 & L3 SM?

  • Need for End to End use case within the ONAP Context  @MEHMET TOY@Andy Mayer (review with arch team)

    • ACTION: Recommend end-to-end interactions based on LSO Operational Threads  @MEHMET TOY; @mark gibson@Former user (Deleted);  @Andy Mayer (review with arch team); Include scope of Presto wrt ONAP

    • ACTION: Possible application of External API at PRESTO with SDNC interactions with domain controllers (VOLTE use case) Possibly @Former user (Deleted)

    • Could possibly be part of R3 Casablanca scope





Working:

  • Continue ExtAPI Design for Beijing @Ludovic Robert

    • Update: Removed VNF creation from scope and notification feature from scope

    • Utilizing the ExternalAPI/NBI repo for Beijing code

    • Making good progress for 29 March milestone

    • Documentation

    • Repo committs

    • ACTION: Need to schedule meetings with SDC, SO, and A&AI to discuss API mapping; Also Run-time Catalog.

    • ISSUE: Is SDC Providing CSAR from Catalog API? Could SDC provide a simple service view with input parameters of the service?

    • ISSUE: Does SO require customer on instantiation requests? Is A&AI really keeping Customer (or Consumer) information?

  • Begin Interlude Use Case discussion

  • Dana Bobko will present an API Versioning proposal (NEXT WEEK )

  • User Stories / Use Cases; State Models; Sequence diagrams for External and Internal interactions with ONAP components @Andy Mayer

    • End-to-end Operation Threads

    • Service Catalog

      • Query Service Catalog

      • Retrieve Service Model

    • Service Ordering

      • Place Service Order

      • Query Service Order

      • Retrieve Service Order

      • Delete Service Order

      • Retrieve Service Order State

      • Subscribe to Service Order Notifications

      • Receive Service Order Notifications

    • Service Inventory

      • Query Service Inventory

      • Retrieve Service

      • Retrieve Service State

    • Service Topology (spec only)

      • Query Service Topology

      • Retrieve Service Topology

    • License Management (spec only)

      • Receive License Usage Notifications

  • Recording: 

Upcoming:

  • Next call will take place on 30  May 2018 

  • Architectural considerations for External APIs (mapping to ONAP components)

  • User Stories / Use Cases; State Models; Sequence diagrams for External and Internal interactions with ONAP components

  • Continue review and refinement of ONAP Common Model UML (Service Abstraction focus)

  • Discussion on coordination with Architecture, Modeling, and MSB efforts (@Alex Vul)

Action items