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

2023-05-02 TAPI Meeting notes

All

Preliminary agenda:

• Continue the Path Computation UCs analysis
• Model of the internal connectivity matrix of a ROADM
• OAM and Protobuf/gNMI encoding
• Continue the investigation on TAPI-IETF navigation
• Access to the photonic plug

Andrea Mazzini 

Andrea Mazzini recalls that TAPI 2.4.1 and RIA 2.1 have been officially delivered.

• This 2.4.1 version is candidate for adoption and implementation.

Andrea Mazzini shows the Arturo's email with the TIP MUST position, copied below:

The MUST group has been informed about the proposal raised by Telefonica to the ONF TAPI group to extend the TAPI v2.1.3 branch to cover the following uses cases:

• • • OAM Hybrid: OAM Job (2.4) on CEP (2.1.3)
      • OAM Job exists in TAPI 2.1.3 but it was related to MEP and MIP only.
    • physical-route-list (2.4) on tapi-connection (2.1.3)
    • access-port-supports-sip (2.4) on SIP (2.1.3)

We understand that the proposal includes some augments which will not introduce backward compatibility issues with current v2.1.3 implementations.

The group should still analyze the proposal in more detail and agree upon its adoption within MUST Technical Requirements for Optical/O-OLS SDN Controller NBI. Furthermore, the group does not commit to fostering the adoption of this new release rather than v2.4 and v2.5 releases. However, the group acknowledges the technical validity of the proposal and its purpose to accelerate certain use cases driven by business needs. 

Esther adds that it is not the intention of TIP MUST to block this initiative.

• ONF OTCC will follow up with TIP MUST on the subject.

Confirmed that it is necessary to distinguish between different natures of the modeled items:

• 1. Configuration parameters
  2. Stable resource state parameters (e.g. configured mapping types, thresholds, etc.) in general the resource state parameters driven (mainly) by the configuration parameters
  3. Not stable / extremely unstable resource state parameters (e.g. operational state, PM Metrics, etc.) in general the resource state parameters driven (mainly) by network events
• Each parameter type requires different access methods.
• Andrea Mazzini this approach shall be reflected in the proper sections of the RIA.
  • Future evolution of the model shall improve the decoupling of parameters having different natures, to facilitate the differentiation of the access methods.

Andrea Mazzini recalls the existing documentation regarding Path Computation:

1. otcc2020.ND.010_TAPI-ConnectivityServiceComputationService.pptx

2. otcc2021.RC.001_TAPI-PathComputation.pptx

3. RIA 2.1 UCs:
   • Use case 12a: Path Computation
   • Use case 12b: Simultaneous pre-calculation of two disjoint paths
   • Use case 12c: Multiple simultaneous path computation (Bulk request processing)

Ramon Casellas recalls that one of the possible original sources of the Path Computation model is IETF PCEP (RFC 5440)

• The Explicit Route Object (RFC 3209) is an ordered list of numbered or unnumbered interfaces - something similar to a list of TAPI NEPs or CEPs if considering the (G/MPLS) label.
• Andrea Mazzini in general we need to identify and review the IETF references, for a better understanding of the original requirements.
• Agreed that the TAPI model shall allow the specification of label/timeslot/wavelength constraints, besides Link/NEP.
• Discussion on Layer Protocol Name and Qualifier of the Path Computation Service.
  
  • Preliminary agreement that the layer attributes shall indicate the preferred or unique layer of the Link/NEP composing the resulting Paths, e.g.
    • ODU4 LPQ shall drive the creation of Path(s) composed by Links supported by ODU4 Connections (or equivalent NEPs), see top left Link in the figure: