Skip to end of metadata
Go to start of metadata




  • Admin
  • GNPy/CCAMP – TAPI alignment, presentation of candidate TAPI extensions.
  • Delivering RIA 1.1 (TR-547-TAPI Reference Implementation Agreement_v1.1_RCAS.docx)
    • Continue review of “asymmetric” provisioning UC – DSR NEP and “OTU” NEP
    • Server constraints vs. multiple augment of (distinct) technology specific packages
    • Plan for the other UCs still to be reviewed:
      • 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
  • Review of otcc2021.ND.001_TapiLayers.pptx contribution

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

10 minsAdministrative


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.

 2 hours

0 mins

Continued admin from 2021-06-01 TAPI Meeting Notes

Andrea Mazzini

Andrea Mazzini has a persistency issue with diagram style sheets. Solved, it is due to the rename (through File Explorer) of project directory.

10 minsSome considerations on TIP CANDI POCRamon Casellas

Ramon Casellas clarifies that is a very specific POC, with limited augments to TAPI.

  • It is now necessary to converge: rely on Equipment augments or Topology/Connectivity augments?
  • How to provision the amplifier gain? Through OTS/OMS ConnectivityService? Otherwise introducing a new dedicated "Service" object?
10 mins

TAPI 2.3 delivery

TR-548 delivery


The team confirms the agreement that TAPI 2.3 shall include the Streaming and Fault Management integration.

Arturo: TIP MUST will adopt TAPI 2.3 once FM and Streaming are integrated.

Nigel Davis should perform the necessary augments in a week or so.

Nigel Davis confirms that TR-548 is almost ready for publication, likely within next week.

  • Noted that TR-548 is currently applicable to TAPI 2.1.3
    • Nigel Davis clarifies that the document has been structured to be relatively independent from TAPI releases. Adding the FM augments to the stream will make the document applicable also to TAPI 2.3
90 mins
  • GNPy/CCAMP – TAPI alignment, presentation of candidate TAPI extensions.

Andrea Mazzini presents otcc2021.AM.001_TAPI-GNPy-extensions.pptx

The more likely scenario foresees the explicit model of ILA Nodes:

Team agrees that the CCAMP definitions shall be directly used to augment TAPI objects.

Ramon Casellasindicates that in OpenConfig the CCAMP Transceiver Mode is just a key which identifies a set of parameters. Also in TIP MUST the Transceiver Mode is under discussion.

In some past calls we discussed if and how to add a "functional" model to TAPI, i.e. something intermediate between Equipment and Forwarding (Topology/Connectivity). Another possible solution could rely on topology recursion, i.e. add a second level to represent inner structure of a Node, like the booster/preamp Node:

Arturo agrees that the second level of topology could be a simpler solution.

Huy Tran presents the Reference Implementation (tapy_topo_v0-HuyTRAN.json ), below two excerpts:

  • Ramon Casellas maybe is better the CEP rather than the Connection for the amplifier augment.
    • Nigel Davis in the Core IM the Forwarding Construct is the object which can represent amplification features.
    • Andrea Mazzini agrees with Ramon Casellas that in TAPI we usually do not augment the "connections", rather the "points". Furthermore augmenting CEPs can simplify the specification of direction.
    • Ramon Casellas adds that the multi-stage amplifier shall be considered. It could be modeled as a sequence of Connections or something simpler. For further analysis.

Ramon Casellas briefly shows a CTTC presentation on GNPy, where TAPI augments were explored, to underline that it's time to converge.