Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


20 minsAdministrative


 TAPI Call: 2 hours

Karthik Sethuramanrecalls that Lyndon Ong has provided the TAPI overview of OIF 2020 Interop White Paper (2020-oif-transport-sdn-api-interoperability-demo)

Ramon Casellas points out that we need to define a timeline/best estimation of TAPI 2.3 delivery.

  • It is true that we spent quite some time for "server constraints" management (UC 1g, 2b).
  • It is also true that multi-layer constraints and asymmetric provisioning are complex scenarios regarding both technology aspects and provisioning steps.
  • Andrea Mazzini suggests that reviewing the weekly call minutes may speed up discussions.

Nigel Davis proposes to plan a review session of draft TR-548 (Streaming RIA)

  • There are some new sections which have been never reviewed.
  • Preliminary agreement to dedicate the second hour of a regular TAPI call, e.g. next week.
    •  Andrea Mazzinito send an email informing attendees to verify the agreement.
10 mins

Review of TAPI/pull/505

Andrea Mazzini

Andrea Mazzini presents major changes introduced by the pull request:

  1. Added all comments to common, topology, connectivity, oam, notification and path computation models.
  2. TapiConnectivity, in the CSIP added reference to its NEP.
  3. New model TapiAlarm, created from the YANG specification of Use Cases 16a and 16b.
  • Karthik Sethuraman indicates the "request review" link on the pull request page, necessary to inform reviewers.
100 mins

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

  • Use case 1h: Unconstrained asymmetric DSR Service Provisioning, UNI DSR E-NNI OTUk grey interface

Andrea Mazzini presents three provisioning scenarios, spanning initial to final states of the asymmetric provisioning:

  1. DSR CS Provisioning on existing ODU4 CS
    • first is created the ODU4 infrastructure, then the client DSR CS which includes its 1:1 ODU container.
  2. Detailed ODU4 infrastructure provisioning.
  3. ODU CS Provisioning on existing OTU/OTSiG CS
    • first is created the OTU/OTSiG infrastructure, then the client ODU4 CS.

Scenario 1, final view including suggested changes:

  • After some discussion and Hing-Kam Lam presentation of latest ITU-T G.872 (below a picture from G.872 AR text v06.docx):

  • agreed that current "ODU" value of Layer Protocol Name is now misleading, because of the introduction of "OTU" Layer Protocol Qualifier,
  • agreed that in TAPI 2.3 the "ODU" value shall be deprecated, replaced by "DIGITAL_OTN" value, which more correctly describes the technology.
  • Ramon Casellas indicates the apparently missing link between Infrastructure and Handoff ODU4 CS, added a background Node to indicate the forwarding capability at client ODU rates.
  • Ramon Casellas suggests to improve the description of DSR CSEPs, aligning to the agreed scenario for server constraints (see 2021-02-16 TAPI Meeting Notes), i.e. the DSR CS has 4 CSEPs, two of them with ODU2 related constraints.

Scenario 3, final view including suggested changes:

10 mins

Link model, agree a general rule

Nigel Davis indicates that in current RIA draft the presence of the Link object instance is specified as optional in some scenarios.

  • Ideally we shall define a general rule to avoid uncertainty.

Ramon Casellas, following GMPLS concept of forwarding adjacency, one possible rule could be to always instantiate the Link which is client (or result) of an underlying Connection.

  • Discussion to be continued.