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

Date

Attendees

Goals

  • Admin
  • Technical discussion on Integration of Streaming and Fault Management
  • Delivering RIA 1.1 (TR-547-TAPI Reference Implementation Agreement_v1.1_RCAS.docx)
    • Selection of UCs which review is necessary for RIA 1.1 delivery, e.g.
      • “asymmetric” provisioning UC – DSR NEP and “OTU” NEP
      • 0d – clarification on SAPI/DAPI vs. TxTI/ExT
      • 3d - Constrained Provisioning diversity based on SRG / Diverse Routing in SRG failure
      • 5d - Asymmetric service provisioning with 1+1 Protection with Diverse Service Provisioning (eSNCP)
      • ASON related UCs
      • 12a: Pre-calculation of the optimum path
      • 12b: Simultaneous pre-calculation of two disjoint paths
  • Server constraints vs. multiple augment of (distinct) technology specific packages

Agreed Items & Priority

  • Below the list of the agreed items and related priority.
  • An item is blocking when its resolution is necessary precondition for the delivery.

TAPI 2.1.3 and RIA 1.1

  1. OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning (solved)
  2. ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UCs (solved)
  3. Alarm / TCA notification (blocking, 1)
    1. Subscription
    2. Notification contents
      • Probable Causes / Elementary alarms (e.g. ITU-T cZZZ fault causes), including TCA PM Parameters
  4. OTS and OMS model (solved)
  5. Path Computation Use Cases (blocking, 2)

TAPI 2.3 and RIA 1.2

  1. MEP/MIP model vs. direct inclusion of OAM parameters in the CEP (solved)
    1. ODU OAM
    2. Photonic OAM
    3. TCA provisioning
  2. Physical impairments (not blocking)
    • OFC is augmenting TAPI Link, others the AbstractStrand.
    • Type of amplifier, fibre attenuation, etc.
  3. Photonic model capability (not blocking)
  4. Lifecycle management of ConnectivityService at every layer, necessary to identify UCs (not blocking)
    • Lifecycle management of single ConnectivityService, necessary to identify UCs
  5. 3R (not blocking)
  6. UNI Client interfaces modelling. DSR/ODU multiplexing over ODU (not blocking)
  7. RESTCONF Response codes for use cases (not blocking)
  8. TAPI OAS, action points to be assigned (not blocking)
  9. Routing Constraints (not blocking)
  10. Physical Route (not blocking)

Discussion items

15 minsAdministrative

All




Agreed to dedicate one week / 4 days / two hours per day for the review of TR-547: July 5,6,7,9 10-12 CEsT

  • Invited Ramon, Nigel, Ronald. Please others interested to contact Andrea.


Next TAPI weeky call - 2 hours

5 minsTR-548 deliveryNigel Davis

Nigel Davis will set up an additional separate call for clarification regarding TR-548 scope, involving Jack Pugaczewski (MEF and TMF).

  • Nigel Davis had a chat with Jack, who confirmed that TR-548 (on Kafka) is used as reference, for further discussion the level of alignment, also including PM.

Nigel Davis  is still working on TR-548, considering also possible developments related to the integration with Fault Management.

15 minsSome considerations on TIP MUST

Arturo Mayoral 

Arturo Mayoral indicates that TIP discussions continued, MUST will focus on next definition cycle of NBI, specially for:

  • Alarm/PM (addressed by TAPI 2.3)
  • Integration with GNPy for OLS management (in the scope of TAPI 2.4)

MUST is evaluating the usage of different standard management interfaces (IETF, ONF, OpenConfig).

Also recalled that MUST is restricted to operators:

  • Ramon Casellas is there any formal liaison between TIP and ONF?
  • Arturo will explore a proper mechanism for collaboration.

Andrea Mazzini in the context of GNPy, have MUST defined Use Cases related to optical path computation?

  • Arturo answers that the discussion is focused on the availability of optical impairment parameters of the managed topology - to allow GNPy application to compute the optical path.
  •   Ramon Casellas recalls that another Use Case of interest is the provisioning of amplifiers.
    • We need to explore OTS/OMS ConnectivityService or a new dedicated "Service" object.
10 minsSome considerations on OTSiA provisioning use casesRamon Casellas

Clarified that TAPI 2.1.3 does not foeresee OTU layer, hence the OTSi/A related use cases do not mention any "digital" provisioning.

For further evaluation if and how update the RIA 1.1 with the "transponder" provisioning scenarios agreed for TAPI 2.3, e.g.

40 mins

Technical discussion on Integration of Streaming and Fault Management

Nigel Davis

Nigel Davis presents some alternative solutions for TapiFm data types (AlarmInfo and TcaInfo) to augment TapiStreaming ConditionDetector or LogRecordBody objects.

Agreed that:

  1. The solution shall provide model equivalence between Notification and Streaming communication modes.
    1. Define a new FM data structure which can augment either Notification signal or Streaming class.
    2. Some redundancy could be acceptable.
  2. Backward compatibility with respect to TAPI 2.1.3 is not considered - this allows more degree of freedom.

Nigel Davis shall build a detailed proposal in one week.

Karthik Sethuraman highest priority is adoption. Hence the solution shall not be too much disruptive with respect to TAPI 2.1.3 and in general with respect to consolidated/legacy terminology/concepts.

10 mins

“asymmetric” provisioning UC – DSR NEP and “OTU” NEP

Andrea Mazzini

Andrea Mazzini shows this picture concerning OTU NNI

Agreed that RIA 1.1 - for TAPI 2.1.3 - will not change the current picture (below), as far as TAPI 2.1.3 does not foresee OTUk layer protocol qualifier.

  • To evaluate if and how add notes/sub-paragraphs for 2.3 specific items/differences.


Post meeting note: we agreed that the CSEP of OTN SIP shall be modeled as DSR CSEP.

50 mins

Use Case 0d – clarification on SAPI/DAPI vs. TxTI/ExT

All

Andrea Mazzini shows current RIA specification:


We need to clarify the SAPI+DAPI relationship with OTN TxTI and ExTI (see G.798 6.2.2.1 dTIM at the OTS-O, OTSiG-O, OTU, ODUT and ODUP layer).

There are two alternative assumptions:

  1. There is a unique domain of naming:
    • SAPI and DAPI values are shared between domains interconnected by the ENNI.
  2. There are separate naming domains:
    • SAPI and DAPI values could be unique for each domain.

In the first case, an example would be:

  • Domain 1 NEP sapi = andrea; dapi = nigel
  • Domain 2 NEP sapi = nigel; dapi = andrea

In the second case, an example would be:

  • Domain 1 NEP sapi = andrea; dapi = nigel
  • Domain 2 NEP sapi = kam; dapi = ramon

In this second case it is necessary to add to the NEP of Domain 1 and to the NEP of Domain 2 the respective remote sapi/dapi info:

  • Domain 1 NEP remote-sapi = kam; remote-dapi = ramon
  • Domain 2 NEP remote-sapi = andrea; remote-dapi = nigel

We could abandon the SAPI/DAPI terminology and model the NEP PlugId attribute as:

  • local-id
  • remote-id

Where:

  • NEP 1 local-id is how NEP of Domain 1 is naming itself
  • NEP 1 remote-id is how NEP of Domain 2 is naming itself

Considering OTN technology:

  • the local-id will be the content of TxTI
  • the remote-id will be the content of ExTi