Skip to end of metadata
Go to start of metadata




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.1.3 and RIA 1.1

  1. OTU(+ODUCn) CEP/CSEP as single point for OTU/OTSiA ConnectivityService provisioning (solved)
  2. ENNI/INNI Asymmetric service provisioning for multi-domain scenarios, agree UCs (solved)
  3. Alarm / TCA notification (blocking, 1)
    1. Subscription
    2. Notification contents
      • Probable Causes / Elementary alarms (e.g. ITU-T cZZZ fault causes), including TCA PM Parameters
  4. OTS and OMS model (solved)
  5. Path Computation Use Cases (blocking, 2)

TAPI 2.3 and RIA 1.2

  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

10 minsAdministrative


Nigel Davis will set up an additional separate call for clarification regarding TR-548 scope, involving Jack Pugaczewski (MEF and TMF).

  • Nigel Davis had a chat with Jack, who confirmed that TR-548 (on Kafka) is used as reference, for further discussion the level of alignment, also including PM.

  • Delivery plan (State of RIA and 2.3)
    • Andrea Mazzini TAPI 2.3 RC1 - freeze model by the end of the week
    • Ramon Casellas RIA 1.1 - deliver draft for review by the end of the week. Plan the review on next week.
      • How to include the alarm spreadsheet in the delivered TR-547 pdf file: by reference to a separate read-only Excel file. For further analysis.

TAPI Call: 2 hours

20 mins

Review of OTU/FEC and related PM Metrics


Andrea Mazzini shows latest updates on OTU CSEP/CEP and MEP.

  • Agreed the OTU CSEP attribute: fecType.
  • Agreed the OTU MEP attributes: fecMonitoring, fecCorrectedErrorThreshold. Note that the thresholds of the other FEC related counters can be set through the generic OamProfile class.
  • Agreed to define as optional the farEndOduConters and bidirectionalUas attributes of OduErrorPerformanceData class.
  • Agreed to define as optional bbe, ses and uas of OduCounters data type.
  • OduCnErrorPerformanceData, agreed to add as object key the index of 2..n instances of ODUCn OH.

30 mins

Analysis of "Server Constraint" Use Cases and solutions


Andrea Mazzini  presents some slides on "server constraint" model solutions.

  • Agreed that the simplified solution on the right side is feasible.
  • The ServerConstraint pac seems
    • useful to indicate that the further augmentations are specific to server layers
    • necessary to allow the augmentation of multiple instances of a specific class
80 mins

Optical Impairments and Topology: presentation of GNPy workflow and database 

Huy Tran

Huy Tran presents the GNPy internal structure and an overview of GNPy database.

  • Ramon Casellas points out that the current limitation to "full load" for the OSNR estimation seems preventing the on-line usage of GNPy service computation.
    • Andrea Mazzini there are two aspects, the static evaluation of different load conditions and the possible on-line retrieval of updated load/measurements.
    • For further evaluation, also to understand whether ConnectivityService or PathComputationService is the appropriate mapping.
  • There are three main API and related schema:
    • gnpy-path-computation-simplified / requestDB, responseDB
    • gnpy-network-topology / elementDB
    • gnpy-eqpt-config / equipmentDB
  • Huy Tran shows the GNPy Data Bases:
    • elementDB: Edfa, Fiber, Roadm, Transceiver
    • equipmentDB: Edfa, Fiber, Roadm, Transceiver, RamanFiber, SI (Spectral Information), Span
    • networkDB: elements of elementDB, connections between elements (pure associations)
    • omsDB: description of Optical Multiplex Section (roadm-booster-fiber-[edfa-fiber]*-preamp-roadm)
    • requestDB (n x path requests)
    • responseDB
    • Andrea Mazzini we may augment the TAPI OMS Link with the omsDB data structure and/or distribute the omsDB parameters to more TAPI objects, according to the detailed topology and connectivity picture.
  • Nigel Davis asks whether the GNPy Equipment model is more oriented to physical aspects (like TAPI equipment model) or to functional aspects.
    • Huy Tran agrees that the focus is on functional aspects, e.g. a single amplifier "equipment" can be represented as two distinct EDFA instances, each one per each amplified L or C band.