1. Pages
2. …
3. Open Transport Configuration and Control Home
4. TAPI
5. TAPI Call-in Details and Notes

2023-05-09 TAPI Meeting notes

All

Preliminary agenda:

• Continue the Path Computation UCs analysis
• Continue the discussion of adding OMS CEP spec to version 2.1.3
• Model of the internal connectivity matrix of a ROADM

Arturo

Arturo summarizes the TIP MUST position on TAPI versions:

• TIP MUST is starting the monitoring of TAPI for the preparation of the next version of MUST Technical Requirements, planned for October this year.
  • Operators seem not in a hurry to adopt TAPI 2.4.1, is it better to wait for TAPI 2.5?
  • TIP MUST will consider only the mature/consolidated UCs of TAPI RIA.
• Andrea Mazzini The TAPI 2.4.1 version shall be considered as a milestone, in other words 2.5 version is planning to enhance 2.4.1.
  • TAPI 2.4.1 is the best delivery with respect to both past 2.x and 2.1.x deliveries
  • TAPI 2.4.1 was specified as the reference for future deliveries (at least in the medium term)
  • This said, it is recommended to start reviewing 2.4.1, without waiting for 2.5, which is incremental and backward compatible.
  • Arturo agrees and foresees one month for the review by TIP MUST.
    • The outcome shall include a prioritization of TAPI 2.1 RIA Use Cases.
• Arturo mentions that is ongoing a gap analysis between GNPy and TAPI 2.4.1 optical impairments model.

Nigel Davis is currently following and contributing to IETF CCAMP for the specification of Nework Hardware Inventory (draft-ietf-ccamp-network-inventory-yang).

• The target is (as usual...) to avoid unnecessary variations between SDOs.
• In CCAMP the current discussion shall lead to the next version of the draft, before its expiration (Sept. 20203).
• Positive, collaborative attitude.
• Will keep ONF TAPI team updated.

Nigel Davis presents an updated diagram.

• Clarified the header role of the first structures augmenting pure Protobuf object.
  • These structures declare what is next in the payload.
  • Andrea Mazzini suggests to check if there is and in case which is the common practice.

Andrea Mazzini shows the preliminary list of UCs:

Olivier presents the otcc2023.OR.001_TAPI21X_EnhancementForTpce.pptx slide set.

• Context is the work on TransportPCE of Optical OpenDaylight system.
• Considering that TAPI 2.4.1 implementations are not yet available, the proposal is to extend TAPI 2.1.3, allowing to test the solution in a short time.
  • The extension being a parameter facilitating the discrimination between ROADM add/drop and degree ports:
    • The degree ports include the OMS layer, while the add/drop ports not.
    • The ILA ports include the OMS layer.

The preliminary agreement is the addition to TAPI 2.1.3 of the OMS augment to CEP:

The OmsConnectionEndPointSpec will be specified in a new module, TapiPlusPhotonicModel.

Preliminary agreement is that the requirement is to add the OMS spec to the already existing CEP instance with "UNSPECIFED" layer protocol qualifier (i.e. the CEP client of bottom-most NEP).

• In TAPI 2.4.1 RIA it is foreseen a dedicated CEP instance for OMS layer protocol qualifier, besides the OTS CEP instance.

Olivier shows a scheme where the connectivity matrix of the ROADM is represented by (internal) links between add/drop and degree blocks.

Nigel Davis highlights that the Node Rule Group model is a simplification of the explicit mesh representation, with additional features.

• For further discussion - evaluate whether TAPI RIA may include a more specific Node/NEP/Link pattern for ROADMs.

Olivier confirms that he is referring to TAPI 2.4.1 in case of local enhancements to implemented 2.1.3, i.e. the what will be.

Nigel Davis Side note on OTS Fiber Impairments, to be evaluated a better integration with equipment/strand model.