Child pages
  • 2021-01-26 TAPI Additional Call - Meeting Notes
Skip to end of metadata
Go to start of metadata




  • Last week we agreed to cancel the TAPI call of 26 Jan. due to Karthik Sethuraman and Andrea Mazzini engagement in MEF 1Q21 meeting.

  • To speed up the RIA 1.1 review process we agreed to have an additional call, where anyway no decisions can be taken.


Discussion items

15 minsUse case 0d: Multi-domain OTN interdomain links discovery (Plug-id based on OTN TTI)
  1. NEP at ENNI must include an ENNI identifier (inter-domain-plug-id) which must be unique in both the connected managed domains.
  2. The inter-domain-plug-id is based on OTN technology (OTU Trail Trace Identifier, SAPI/DAPI).
  3. The algorithm to ensure inter-domain-plug-id uniqueness.
45 mins

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

  • Current version of otcc2020.AM.001_TAPI_Photonic_Model_Evolution.pptx does not include the case where the provisioning of a ConnectivityService implies not only the creation of supporting Connections but also the creation of other supporting ConnectivityServices. The association between CSEPs, CSEP has Server CSEP may not be appropriate, see notes in the picture below. 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.

  • Post meeting note, another approach, more generic, would be to introduce full recursiveness of ConnectivityServices under provisioning, see the picture below:

45 minsUse case 1h: Unconstrained asymmetric DSR Service Provisioning, UNI DSR E-NNI OTUk grey interface.
  • This UC considers the asymmetric connection between UNI and ENNI a-z points with essentially same rate:
    • (UNI) CSEP a: tapi-dsr:DIGITAL_SIGNAL_TYPE_10_GigE
  • The scenario implies no provisioning of any ODU related parameter, e.g. ODU2 TTI.
  • Agreed that the correct rate at ENNI side is OTU, which model is missing from TAPI version 2.1.3, hence DSR_OTU rate is proposed in the RIA 1.1
    • Do we need two distinct versions of RIA, respectively applicable to TAPI 2.1.3 and next 2.3? Likely yes, considering the possible requirements to introduce some new features but keeping 2.1.3 version.
    • Another example are the 2.1.3 MCA, OTSiMCA layer qualifiers, deprecated in 2.3
    • Andrea Mazzini it is planned the detailed documentation of the differences between 2.1.3 and 2.3
10 mins

Use case 2a: Unconstrained service provisioning with OCh/OTSi (channel selection).

This UC is likely not feasible with 2.1.3 version, because OTU layer is not modeled. For further discussion whether to deprecate it from RIA/2.1.3.
5 minsUse case 2b: Unconstrained service provisioning with ODU selectionThis UC is analogous to 1g but at different layer protocols, hence similar considerations apply.