Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.




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


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

Preliminary agenda:

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

Draft of Optical Impairment UML model

Andrea Mazzini 

Andrea Mazzini provides an overview of current draft model.


  • Agreed that TransceiverProfile (see diagram above) shall compose a list of standard/organizational/explicit modes.

Service Model (configuration):

  • Esther Le Rouzic clarifies that in ietf-optical-impairment-topology.yang the transponder is the device, which may include more transceivers (pluggables).
    • Also clarified that the transceiver data type describes the properties of a single OTSi. There is no description of OTSiA properties.
      • The OtsiCapabilityPac (see diagram above) has the maxNumberOfOtsi attribute, which represents the multiplexing capability of the transponder port.
      • Agreed that the OtsiCapabilityPac label is misleading, as the multiplexing capability regards the OTSiA.
      • Preliminary agreement that the OtsiServiceInterfacePointSpec and all its composed classes (see diagram above) will be removed and replaced by the OtsiProfile(s) referenced by the NEP.
  • Clarified that the min/max-central-frequency specify the transceiver range of tunability.
  • Agreed that the OTSi configuration shall not include any information regarding the spectrum. Spectrum is relevant for MC / OTSiMC.
    • Agreed to remove from the model (see diagram above) the OtsiSpectrConfigPac and the spectrumBandwidth property of OtsiFreqConfigPac.
    • The OTSi configuration will include the following writable parameters:
      • centralFrequency (including frequency constraints: adjustment granularity and grid type)
      • laserControl
      • transmitPower
      • totalPowerWarnThresholdUpper/Lower (the rx power parameters are applicable to profile and state/measurement)
      • reference to an OtsiProfile instance for all the other parameters (post meeting note: consider the read/write role in the provisioning scenario)
  • Arturo asks clarification regarding min-OSNR, min-Q-factor and fec-threshold parameters.
    • The ietf-optical-impairment-topology.yang comment is:
      • "min OSNR measured over 0.1 nm resolution bandwidth: if received OSNR at minimum Rx-power is lower than MIN-OSNR, an increased level of bit-errors post-FEC needs to be expected."
    • minimum Rx-power is specified by common-organizational-explicit-mode / rx-channel-power-min parameter.
    • Clarified that the noise is only Amplified Spontaneous Emission (ASE) noise.
    • Agreed that it would be useful some more explanation regarding the dependencies between these parameters.
  • Brief discussion on 3R types:
    • Back-to-back 3R Regenerator

    • Cross-3R Regenerator

  • TAPI possible logical model of Back-to-back 3R Regenerator:

  • Andrea Mazzini will provide an example of TAPI logical model of Cross-3R Regenerator.