Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
Open Transport Configuration & Control

Space shortcuts

Expand all   Collapse all
Child pages
  • 2021-02-23 TAPI Meeting Notes

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

20 minsAdministrative

All



 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
All

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

Ramon Casellas

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.