Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • 2020-04-21 TAPI Meeting notes
Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

Discussion items

5 minsAdministrative

Andrea Mazzini


  • No TAPI Call
  • TAPI Virtual Meeting
20 mins

2.1.3 status update

Delivery content (RI, OAS)

Nigel Davis

Andrea Mazzini

Karthik Sethuraman

Arturo Mayoral

  • Andrea MazziniOnly one pending pull request, equipment object types in TapiNotification (#479)

Discussion on TAPI 2.1.3 delivery contents

  • Karthik Sethuramanis currently busy and for at least the two next weeks cannot help on the delivery process
  • A TAPI delivery normally includes:
    1. UML/Papyrus
    2. YANG and TREE files
    3. Reference Implementation, OpenAPI Specifications (OAS)
  • Nigel Davis and Andrea Mazzini are editing the YANG modules and will provide TREE files in the next days.
  • Arturo Mayoralwill give a try to generate OAS.
  • Karthik Sethuraman could help generating OAS but not before two weeks.
  • General agreement that the team shall progressively share these tasks, to
    • avoid too much dependency on one person only
    • get awareness of the overall production process, which will enhance e2e quality and consistency
100 mins

review of the TR-5XX.1-TAPI v2.1.3 Reference Implementation_v0.8.docx

Arturo Mayoral

Nigel Davis

Pedro Amaral

Andrea Mazzini

Arturo Mayoral presents TR-5XX.1-TAPI v2.1.3 Reference Implementation_v0.8.docx

Reviewed till chapter "4.3 Network Scenarios", excluded.

Summary of agreements:

  1. Clarification about Management and Control, at the time management is automated it simply becomes control, as explained by Core IM.
  2. Other minor enhancements to introductory chapter, agreed to remove the references to ONF TR-527, assuming that the TAPI related definitions are self contained in the Reference Implementation.
  3. Clarified that when options are described in the document (e.g. Transitional Link or Multi-layer Node, Unidir or Bidir model) it is intended that the Client Controller shall support/integrate all the options as implemented by Server Controllers.
  4. Clarified that the discovery of the root "href" entry does not imply to exercise the root tree of the API, but it allows to dynamically adapt the URLs to the different mount points implemented by each different provider.
  5. Clarified that both SSE and WebSocket are allowed solutions by the Reference Implementation.
  6. Table 3: Minimum subset required of TAPI RESTCONF Data API, added the note that "POST, DELETE operations are not intended for the context root object". The TAPI OAS shall support exactly the operations listed in the table.
  7. Nigel Davis and Andrea Mazzini propose to remove Path Computation and Virtual Network Service from the Reference Implementation
    1. Path Computation UCs were not  thoroughly reviewed by the team, there is no "solution quality". Agreed to add a disclaimer to UC12a and UC12b.
    2. Virtual Network Service, no UCs defined, agreed to keep the model in the list, as anyway belonging to the TAPI delivery.
  8. Clarified that OMS and OTS PhotonicLayerQualifier values are not used.
  9. Andrea Mazziniproposes to remove the Network Element name from INVENTORY_ID, because in case of NE name change several notifications will be raised with essentially redundant information. Explore to centralize NE Name e.g. in the Node.
    • No agreement, the NE Name remains in the INVENTORY_ID, because a Node may not always belong to a same NE, NE name change is not considered a frequent operation, Controllers are used to have this information in the ports.
    • Evolution to full Equipment model may make redundant the INVENTORY_ID.