Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

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.3/2.4 and RIA 1.2/2.0

  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

5 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.


TAPI weeky call (Karthik Sethuraman at OFC)

Preliminary agenda:

  • Review of updated TAPI Roadmap
  • Continue the development of Optical Impairment UML model
  • Continue the discussion on layering recommendations
10 mins

Plan for dedicated RIA 1.2 / 2.0 review calls (ONF TAPI RIA)

Ramon Casellas 

Ramon Casellas highlights that these weeks the RIA review process is focused on OAM Use Cases.

  • Also recalled the effort done to specify the guidelines related to Notifications, considering e.g. the different object relationships.
20 mins

Review of updated TAPI Roadmap

Nigel Davis presents the updated TAPI Roadmap:

  • Pruned out stuff to the "Tentative additional features" chapter and some clean up.
  • Path Computation:
    • Nigel Davis there could be not enough time to discuss e.g. the two aspects, the Path as sequence of Links and the Service pre-provisioning / feasibility use case.
    • Arturo would prefer to keep the feature in the 2.4 version, as it was present since early stages of the specification.
    • Karthik Sethuraman which is the current completion state of all these features?
      • Karthik Sethuraman volunteers to restructure the roadmap page, introducing a table including the feature definition, its completion state and related available contributions.
    • Ramon Casellas proposes:
      • Two next weeks dedicated to OAM
      • Then optical impairments and physical route
40 mins

Review of contribution otcc2022.ND.001_TapiOptionalityChallenges.pptx

Nigel Davis 

Nigel Davis provides an overview of otcc2022.ND.001_TapiOptionalityChallenges.pptx

  • Recalled that in the RIA review we are moving towards "conditional mandatory" statements.
  • Challenge dealing with a real device:

  • Extending conditionality across the model:

  • Hence instantiating the attributes in the spec only when really supported.
  • Karthik Sethuraman this is the top down approach, are we sure it is realistic to include all the path from UML to YANG?
    • Nigel Davis this is for further evaluation, it is not a short term target.
  • Esther Le Rouzic, how to communicate that e.g. a given temperature measurement is not supported by the device? We have seen examples of negative gain values when the information is actually not available.
  • Andrea Mazzini the description of capabilities can be more or less explicit (declaration vs. implicit). In the implicit case, it may be unclear whether the information is missing because e.g.
    • never supported
    • not supported now (operational state disabled of the device supporting the measure)
    • error in the management chain
    • etc.
  • General agreement to continue the analysis in the next phases of the interface development.
40 mins

Review of OAM technology agnostic model

All

Andrea Mazzini uses the below diagram for discussion:


Andrea Mazzini briefly recalls that the model allows two distinct provisioning modes of OAM:

  1. Through the creation of OamService (which leads to the creation of Meg and its Mep/Mip instances) and OamJob (which will include the Current and History Data PM).
  2. Embedded in the ConnectivityService, i.e. all OAM Service and OAM Job parameters are provisioned as direct augments of resp. CSEP and ConnectivityService.
    • See in the diagram above the ConnectivityOamServicePoint and ConnectivityOamJob augments.

Summary of agreements:

  1. ConnectivityOamJob will augment CSEP rather than ConnectivityService.
    • Karthik Sethuraman this is more in line with OamJob focus on points, allowing more precise provisioning in case of asymmetricity.
  2. In case of embedded provisioning:
    1. All OAM job related parameters can be specified (included in the CSEP, see item 1)
    2. As a result, an instance of OamJob is created. In this case the OamJob lifecycle coincides with its ConnectivityService lifecycle, i.e. when CS is deleted, OamJob is deleted (by server) as well.
      • Karthik Sethuraman further persistency of the measurements can be delegated to the server archiving features.
  3. In case of embedded provisioning, Meg/Mep/Mip instances are NOT created. The MEP/MIP information is modeled only by CEP technology specific augments.
    • Ramon Casellas this is more in line with the embedded/lightweight approach.
    • Karthik Sethuraman without OamService instance, it's consistent to not have Meg instances either.
10 mins

Draft of Optical Impairment UML model

All

Andrea Mazzini briefly shows the updated draft model.

Service Model (configuration):


  • Ramon Casellas Agreed that the OtsiProfile is read-only, hence at provisioning time can be simply referred by name and never by value.
  • Karthik Sethuraman regarding the Application Identifier Types, these were agreed after long discussions in the past, hence better keep them in addition to CCAMP ones.