Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
    • Plan for dedicated RIA 1.2 / 2.0 review calls (ONF TAPI RIA)
  • Brief review of pull request #519
    • The Physical Route Model
  • Continue the development of Optical Impairment UML model (depending on audience)
  • Continue the discussion on potential CTPs/CEPs model (transmission capability)

Agreed Items & Priority

Discussion items

10 minsAdministrative

All



TAPI RIA 1.2/2.0:

  • Scheduled two additional, official, dedicated TAPI calls:
  • Added a third non-official call on Thu 10:00-12:00 CET
    • Andrea Mazzini will send the invitation to anyone who wants to participate.

Easter 2022: Nigel is ooo the first week of April, Ramon the second week. We will anyway proceed with the RIA review.


TAPI weeky call

Preliminary agenda:

  • Continue the development of Optical Impairment UML model
  • Capability model
40

Brief review of pull request #519

  • The Physical Route Model
All

Andrea Mazzini shows the pull request #519 contents.

  • Karthik Sethuraman will review the changes, and suggests that somebody else shall review the TapiPhotonicMedia model, given the amount of updates/enhancements.
    • Karthik Sethuraman suggests to use Visual Studio Code to compare the versions of YANG modules.
    • Ramon Casellas volunteers to review the TapiPhotonicMedia model, adding the consideration that the detailed review will be anyway performed together with related RIA Use Cases.
  • Andrea Mazzini provides an overview of the physical route model. The Connection is augmented by the list of its physical routes.

  • Ramon Casellas clarifies that
    • the order of PhysicalRouteElements of the PhysicalRoute indicates the forwarding direction,
    • the Use case 0c.1: Mapping Connections to Physical Route, already available in current ONF TAPI RIA, only considers the physical route for MC, OMS and OTS Top Connections.
50 minsDraft of Optical Impairment UML modelAll

Andrea Mazzini shows the updated draft model. Added all the data types and comments.

Below the draft of Transceiver Profiles:

Discussion on TransceiverTerminationType:

  • Esther Le Rouzic clarifies that this parameter describes how the transponder can be configured, either as client to line transponder or as regenerator transponder or both cases.
  • After some discussions, agreed that the current TAPI model cannot easily adopt this parameter, because it regards the mode of configuration of an equipment function, possibly implemented by more TAPI Equipment instances (e.g. FRUs). Currently TAPI includes a logical model of forwarding, we may consider the development of a logical model of equipment (e.g. transponder, regenerator, amplifier, WSS, etc. managed objects).

Discussion on Regenerator model:

  • Preliminary agreement that a simple, unique forwarding model may be adopted to represent the different equipment configurations supporting the regenerator function (e.g. back-to-back and cross-3R).
  • Andrea Mazzini will provide a picture where the 3R function is more correctly embedded into a unique ROADM node.


Below the draft of amplification function model:

  • Agreed that TAPI 2.4 will not include any configuration of amplification parameters.
    • Future versions shall include Use Cases for the detailed/declarative provisioning of an OTSiA or, in the OLS case, a MC ConnectivityService, including the amplification parameters.
15 mins

Continue the discussion on potential CTPs/CEPs model (transmission capability)

All

Last week we started a discussion on potential CTPs, a possible model to represent payload capability of a NEP.

  • Karthik Sethuraman points out that you should be able to set up your ConnectivityService from the SIP.
    • In other words, all the necessary information regarding the service feasibility should be provided by the SIP.
  • In fact the model has grown in a different way, now the SIP is more a duplication of the NEP. We shall reconsider this aspect.
  • There are challenges on which capabilities and how to represent them, the risk is to replicate the resource state model.
  • Discussion to be continued.