Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

Agreed Items & Priority

  • Below the list of the agreed items and related priority for the next TAPI & RIA versions.
    • An item is blocking when its resolution is necessary precondition for the next delivery.
  1. OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning (blocking, 1)
    1. 3R
    2. ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UCs.
  2. OTS and OMS model (blocking, 2)
  3. Lifecycle management of ConnectivityService at every layer, necessary to identify UCs (blocking, 3)
    1. Lifecycle management of single ConnectivityService, necessary to identify UCs
  4. MEP/MIP model vs. direct inclusion of OAM parameters in the CEP (blocking, 4)
    1. ODU OAM
    2. Photonic OAM
    3. TCA provisioning
  5. Elementary alarm (e.g. ITU-T cZZZ fault causes), including TCA related notif), current and history (blocking, 5)
  6. Photonic model capability (blocking, 6)
  7. UNI Client interfaces modelling. DSR/ODU multiplexing over ODU (not blocking)
  8. RESTCONF Response codes for use cases (not blocking)
  9. TAPI OAS, action points to be assigned (not blocking)
  10. Routing Constraints (not blocking)
  11. Physical Route (not blocking)

Discussion items

10 minsAdministrative

 TAPI Call: 2 hours

5 mins

Review TAPI/pull/503

Karthik Sethuraman

Karthik Sethuramanapproved the pull request.

5 mins

Review the updated TR-547-TAPI Reference Implementation Agreement_v1.1.docx

  • List of object retrieval – agreement to remove them from Table 3: Minimum subset required of TAPI RESTCONF Data API.

Confirmed the decision to remove from RIA Table 3: Minimum subset required of TAPI RESTCONF Data API the following GET APIs:

  1. /data/tapi-common:context/tapi-connectivity:connectivity-context/connectivity-service/
  2. /data/tapi-common:context/service-interface-point/
  3. /tapi-common:context/tapi-path-computation:path-computation-context/path-comp-service/
  4. /tapi-common:context/tapi-common:context/tapi-notification:notification-context/notif-subscription/
  • As agreed on last call, Ramon Casellas will add a clarification note in the RIA, explaining the rationale of this choice, no retrieval of a node which is a list.
5 mins

Review the updated TR-547-TAPI Reference Implementation Agreement_v1.1.docx

  • Minor correction on equipment-category

Equipment category is listed as “[RACK, SUBRACK, CIRCUIT_PACK, SMALL_FORMFACTOR_PLUGGABLE, STAND_ALONE_UNIT]” while the complete values are  “[EQUIPMENT_CATEGORY_RACK, EQUIPMENT_CATEGORY_SUBRACK,  EQUIPMENT_CATEGORY_CIRCUIT_PACK, EQUIPMENT_CATEGORY_SMALL_FORMFACTOR_PLUGGABLE, EQUIPMENT_CATEGORY_ STAND_ALONE_UNIT]”.

20 mins

Review the updated TR-547-TAPI Reference Implementation Agreement_v1.1.docx

  • Clarification on Inventory

Karthik Sethuraman indicates that the Inventory feature is described only in the related Use Cases (4a, 4b) but there is no introduction paragraph, e.g. in section "3.2 TAPI Information Model".

  • Agreed to add a section dedicated to Equipment/Physical model.
    • Noted that section "4.3 Network scenarios" is missing the mapping with Equipment/Physical model, e.g. how to represent an amplifier, a WSS etc.
  • Agreed to change the title of "4.2 Inventory considerations", as the section is related to "INVENTORY_ID" tag.
  • Ramon Casellas points out that the Table 3: Minimum subset required of TAPI RESTCONF Data API does not include Equipment items.
    • We need to agree whether to add required API for equipment or not, i.e. leaving open the solution as it is currently.
    • Similar considerations shall be done for OAM related API.
60 mins

Review the updated TR-547-TAPI Reference Implementation Agreement_v1.1.docx

Cristian Rosero presents otcc2021_usecase0d_Plug_id.pptx

  • The proposed OTN interdomain links discovery procedure builds an unique ENNI identifier using as input the SAPI/DAPI information available on the two facing OTU Trail Terminations.
  • Agreed that some more details are necessary to describe the ENNI for the UC, e.g. single lambda/single OTUk, no underlying WDM network (i.e. back to back conmection), etc.
  • Andrea Mazzini could be useful to distinguish between "handshake/discovery" phase, where the received far end SAPI is accepted by default and "control/connectivity monitoring" phase, where the received far end SAPI is checked against accepted SAPI, and e.g. TIM alarm is raised if different.
  • Nigel Davis and Ramon Casellas agree that an orchestrator can manage the SAPI/DAPI combinations at the two ENNI terminations:
    • East ENNI-N it is SAPI-East/DAPI-West
    • West ENNI-N is it SAPI-West/DAPI-East
  • Cristian Rosero provides a demo of the related code, showing how the algorithm eventually combines the two East/West identifiers into a unique value.
    • Ramon Casellas suggests to split the "inter-domain-plug-id" attribute of ENNI-N NEP into e.g.
      • inter-domain-plug-id-dapi
      • inter-domain-plug-id-sapi
    • delegating to the orchestrator the appropriate recombination.
  • Cristian Rosero will come back with additional considerations on the OTN interdomain links discovery procedure.
45 mins

Review the updated TR-547-TAPI Reference Implementation Agreement_v1.1.docx

  • Use case 1g: Unconstrained PHOTONIC_MEDIA/OTSiMC over MC Service Provisionin

Andrea Mazzini shows the 2021-01-26 TAPI Additional Call - Meeting Notes, use case 1g.

  • When the provisioning of a ConnectivityService implies not only the creation of supporting Connections but also the creation of other supporting ConnectivityServices then the association (composition) between CSEPs, CSEP has Server CSEP may not be appropriate. One issue is the possible overlap between CSEPs belonging to different CSs, another issue the explicit provisioning of UUID of the "supporting" ConnectivityServices, which are actually created by the Server.
  • Summary of the agreements:
    1. Given the YANG tree constraints, we may need to introduce the "Order" concept, where the ConnectivityServices (and their CSEPs) instances can be organized to provide complex provisioning directives. The "Order" instance will be the root of a new tree. This would allow the independent creation of distinct ConnectivityService instances, a sort of nuance of intent result:
      1. Order is provisioned by the Client.
      2. ConnectivityServices and Connections are created be the Server.
        • The ConnectivityServices (and CSEPs) belonging to the Order are distinct instances wrt the ConnectivityServices (and CSEPs) created by the Server.
    2. With respect to UC 1g (and analogous 2b: Unconstrained service provisioning with ODU selection), two possible solutions:
      1. Option 2 as described in 2021-01-26 TAPI Additional Call - Meeting Notes
      2. Abandon the CSEP has Server CSEP association, using instead dedicated new structures/pacs with only the required parameters.
  • Ramon Casellas indicates that it could be possible to stretch the Restconf by specifying in the same POST two distinct roots, for further study.
  • Below the "Option 2", i.e. there are two distinct MCG CSEP instances:

  • Below the new "Option 3", with dedicated data structures for server layer constraints:

  • Below the possible model of Order: