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

Date

Attendees

Goals

  • Admin
  • Continue discussion on OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning, (blocking, 1)
    • Check the possible consequences of OTU/OTSiA agreed use cases to MCA/OTSiMCA model 
    • 3R
    • ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UC

Agred 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

Andrea Mazzini



TAPI Call: 2 hours

  • Some clarifications on Restconf/depth and Restconf notification expected contents
  • Issue 501
  • Continue on OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning, (blocking, 1)
    • Check the possible consequences of OTU/OTSiA agreed use cases to MCA/OTSiMCA model
    • 3R
    • ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UC
10 minsTR-547 name-value pairsNigel Davis

Nigel Davis in the TR-547-TAPI v2.1.3 Reference Implementation Agreement.docx are specified some name-value pairs which definition needs further clarifications.

20 mins

Restconf Issue 501

All

Andrea Mazzini shows the further clarifications added to 501:

  • Karthik Sethuraman looks like that the "presence" statement implies that the client controller must perform checks:
    • "Having a presence container so high in the tree has a performance impact as validating its presence means a call to the full config/state tree."
  • Karthik Sethuraman not sure but very likely the "presence" statement was necessary for Eagle tool. Suggests to ask to implementation people.
  • Nigel Davis explored the usage of the "presence" statement for the root of a Streaming separate subtree.
    • Andrea Mazzinito perform some tests, e.g. run the Eagle tool without "presence" statement.
80 mins

OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning, (blocking, 1)

  • Check the possible consequences of OTU/OTSiA agreed use cases to MCA/OTSiMCA model 

Andrea Mazzini

Andrea Mazzini presents the updated slides (otcc2020.AM.001_TAPI_Photonic_Model_Evolution.pptx).

Summary of agreements:

  1. Replace all occurrences of MCA with MCG, because is inherently NOT possible to associate an overhead to an MCG.
    1. Similarly for OTSiMCA?
      • Action everybody to carefully evaluate this proposed change, from MCA to MCG and from OTSiMCA to OTSiMCG, as we have been discussing of MCA and OTSiMCA since more than two years!
  2. Remove all MCA and OTSiMCA MEPs and MIPs, because ITU-T defines MCA as the monitoring capability only for the OTS and OMS spans/trails.
  3. To the model proposal, add DSR case, where OTSi layer directly supports DSR, without OTN (done in updated version).
  4. MCA/MCG slide with two add/drop ports, add example where the MCs supported by the two ports remain separate (see below).
  5. For further analysis: in general, a given MC "cross connection" may actually support more MC "top connections". The ROADM network provides forwarding which is more similar to multicast.
    1. Explore whether current TAPI definition prevents more accurate representation of the ROADM forwarding/fabric
    2. Explore whether a more accurate model of the ROADM forwarding/fabric is necessary

Nigel Davis shows the following picture from "TR-512.A.4_OnfCoreIm-Appendix-AnalogueAndMediaExamples-L0":


  • The MCs supported by the two ports remain separate: