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

Date

Attendees

Goals

  • General update
  • Review the Feature priority for TAPI "2.5"
    • Hypothesis to postpone Path Computation to a future delivery
  • Progresses in gNMI streaming and delta streaming
  • Continue the discussion of adding OMS CEP spec to version 2.1.3
    • Backporting of Active (Alarm) Conditions feature
    • Evaluate more in detail which part of 2.4.1 optical impairments model could be candidate for backporting in 2.1.4
  • Model of the internal connectivity matrix of a ROADM
  • AOB

Agreed Items & Priority

Discussion items

5 minsAdministrative

All



See TAPI Call-in Details and Notes for the RIA Review call coordinates.

Warning: in these weeks the RIA editors are changing or deleting some of these sessions.


TAPI weeky call

Preliminary agenda:

  • Review the Feature priority for TAPI "2.5"
    • Confirm the postponing of Path Computation to a future delivery
    • Photonic OAM?
  • Progresses in gNMI streaming and delta streaming
  • Continue the discussion of adding OMS CEP spec to version 2.1.3
  • Model of the internal connectivity matrix of a ROADM
30 mins

Review the Feature priority for TAPI "2.5"

All

Assigned the red font to the features with higher priority. See the updated Feature priority for TAPI "2.5" page.

  • Preliminary agreement to postpone Path Computation to a future delivery.
    • Andrea Mazzini it is still unclear the added value with repect to the current TAPI definitions.
      • E.g. the routing constraints for the Connectivity Service may be specified for each single (resiliency) Route.
      • Nigel Davis so far the only clear distinction is that the Path Service does not reserve network resources.
        • Which could be implemented by an additional "compute only" state of the Connectivity Service.
    • Andrea Mazzini no contributions appeared in the last years.
    • Nigel Davis concludes that in any case it will be difficult/impossible to fit the feature in 2.5 timeframe.
  • Regarding the item:
    • Enhancements to existing features e.g., protection, oam etc.
      • Added the sub bullet Active Condition retrieval use case (RIA)
      • Andrea Mazzini shall check if and which OAM enhancements were discussed in previous calls.
      • Post meeting note: Photonic OAM!
5 mins

Progresses in gNMI streaming and delta streaming

Nigel Davis 

Nigel Davis has uploaded the otcc2023.ND.003_DeltaStreaming.docx, for review.

  • The plan is to include the text in future version of TR-548.

Target for next week is to progress on efficient streaming.

30 mins

Continue the discussion of adding OMS CEP spec to version 2.1.3

  • Backporting of Active (Alarm) Conditions feature
All

Andrea Mazzini shows for comparison the UML diagrams of 2.1.3 and 2.4.1 regarding Notification.

  • 2.1.3:


  • 2.4.1:

Briefly reviewed the relevant parameters to evaluate how to augment TAPI 2.1.3 to backport the Active Condition feature.

Roshan Joyce will check whether the 2.1.3 Notification, AlarmInfo and TcaInfo object parameters satisfy the requirements or any further parameter is necessary, also considering the 2.4.1 parameters for reference.

  • E.g. whether we need to add also the Layer Protocol Qualifier to the 2.1.3 Notification object.
20 mins

Continue the discussion of adding OMS CEP spec to version 2.1.3

  • Evaluate more in detail which part of 2.4.1 optical impairments model could be candidate for backporting in 2.1.4
All

Andrea Mazzini shows some excerpts from draft-ietf-ccamp-optical-path-computation-yang, the augmentations of /te:tunnels-path-compute/te:input/te:path-compute-info of:

  • module: ietf-wson-path-computation
  • module: ietf-flexi-grid-path-computation

The target is to map the CCAMP defined optical routing constraints to TAPI Connectivity Service constraints.

  • The result of this analysis may be applied to both 2.5 and 2.1.4 future deliveries.

Andrea Mazzini asks about the meaning of priority parametes, e.g.:

     augment /te:tunnels-path-compute/te:input/te:path-compute-info

               /tepc:path-request/tepc:path-in-segment

               /tepc:label-restrictions/tepc:label-restriction:

       +-- grid-type?   identityref

       +-- priority?    uint8

Gabriele Galimberti suggests to check with other IETF folks.

30 mins
  • Model of the internal connectivity matrix of a ROADM
All

Andrea Mazzini presents the slide with the agreed definitions:

Confirmed that the "colorless" or "not colorless" property is a (add/drop) NEP property.

The first, simple example of connectivity constraints:

Gabriele Galimberti suggests to consider also the grid type (fixed or flexi) as connectivity constraints.

  • Recalled that in case of flexi grid, the M parameter represents the slot width granularity, and typically the frequency adjustment is half of the slot width.
  • Agreed that it is reasonable to assume that the grid type is on Node base, in other words all Node NEPs share same grid type.
    • Mentioned the possible interworking between Nodes with different grid types.
    • As far as the grid type is currently specified by the NEPs, the Client Controller is allowed to check consistency and tuning in case of hybrid Links, i.e. Links between NEPs with different grid types. Gabriele Galimberti this is true in case of centralized Controller, in case of GMPLS it is more difficult to get the network knowledge.
    • Shall we move the grid type to the (photonic) Node?
      • Post meeting note: Not backward compatible. Similar feature could be achieved through Transmission Capability Profile. FFS.