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

30 minsAdministrative

All



TAPI RIA 1.2/2.0:

  • Scheduled two additional, official, dedicated TAPI calls:
    • Wed 1:00-3:00pm and Fri 10:30-12:30 CET
    • Calendar files available in the reminder email sent on January 10th.


TAPI weeky call

Preliminary agenda:

  • Continue the discussion on layering recommendations
  • Continue the discussion on relationships between layers
  • Continue the development of Optical Impairment UML model
  • Continue the discussion on physical topology
10 minNotes on TAPI 2.3.x / RIA 1.2Ramon Casellas 

Ramon Casellas with reference to RIA 1.2/2.0 review, the end of March 2022 deadline seems optimistic.

  • Andrea Mazzini to limit the delay, we may need further prioritization of use cases, together with commitment to some homework besides the call time.

Andrea Mazzini invites attendees to check the currently defined TAPI and RIA plans at TAPI Roadmap 2022-2023.

60 mins

Layering recommendations

Nigel Davis presents otcc2021.ND.001_TapiLayers.pptx illustrating a number of possible layering cases applicable to known scenarios:

It is recommended to explicitly represent OMS and OTS CEPs and NEPs:

  • This allows to adopt a unique pattern.
  • There should be no cardinality issues at photonic layer (very different order of magnitude wrt e.g. Ethernet CEPs).

Below a recommended layering for a transponder port.

  • Note that the encapsulation of OTSi and OTSiMC is already foreseen in the current model (spectrum info in OtsiTerminationPac), but not explicitly described.
  • Note that OTSiMC connection points span the whole transponder to transponder network.

  • MC NEP/CEP are useful/necessary only in case of multi-carrier configuration. Evaluate whether is preferable the optionality or the fixed pattern (i.e. MC NEP/CEP always represented):

  • Noted that the MC can "terminate" on:
    • Transponders (multi-channel / super-channel case).
    • ROADMs, for aggregation/blending of optical carriers.
  • The presentation includes some interconnecting examples. The target is to simplify interworking avoiding too much flexibility.
  • Ramon Casellas we also need to consider Links. So far we have identified two extreme cases:
    • All Links are explicitly represented.
    • Only bottom-most Links are represented.
  • Ramon Casellas maybe we can consider as mandatory the representation of at least one Link layer per each technology (Photonic, Digital OTN, DSR, ETH).
  • Karthik Sethuraman in general, if you show a multi-layer topology domain, then most or all of the Links shall be represented.
    • Further analysis is necessary.
  • The contents of otcc2021.ND.001_TapiLayers.pptx have been preliminary agreed. The document will be used as reference for the next version of the RIA.
20 mins

First draft of Optical Impairment UML model

Andrea Mazzini 

Andrea Mazzini presents some UML diagrams with the first draft of optical impairment model.

  • TapiCommon: The Profile class belongs to TapiContext.

  • TapiTopology: The NEP refers (by name) to the supported Profiles (description of capability).


  • TapiPhotonicMedia: The MC NEP refers the McProfile.


  • Karthik Sethuraman notes that some structures seems describing a parallel "impairment topology", hence diverging from the "profile" approach.
    • Andrea Mazzini right, each construct shall find its right place, either in a Profile or in an already defined TAPI topological or connectivity object.