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:


TAPI weeky call

Preliminary agenda:

  • Continue the development of Optical Impairment UML model
  • Continue the discussion on layering recommendations
  • Continue the discussion on physical topology
10 minsNotes on roadmapNigel Davis 
120 mins

Draft of Optical Impairment UML model

Andrea Mazzini 

Andrea Mazzini presents a proposal for the correlation of the amplification parameters to the OMS CEP:



  • Arturo shows an alternative model proposal which foresees a "next hop/amplifier" relationship between all the amplifiers in the MC Link (IETF OMS-attributes / oms-element / amplifier). Something similar to the:

  • but for all amplifiers in the MC Link.
    • Having the explicit topological picture of the amplifiers facilitates the parsing/navigation of optical impairments data structures, avoiding any ambiguity regarding the directions.
    • Esther Le Rouzic, the "next hop" between amplifiers is useful when only the oms-elements are considered.
    • Nigel Davis as far as the controller shall already be able to navigate the TAPI topology (Nodes, NEPs, CEPs, Connections and Links), then the duplication of amplifier topology seems redundant.
    • Preliminary agreement on the proposal by Andrea, who will refine the descriptions.

Discussion on the profile aspect of amplifiers (impairments).

  • Agreed that a set of attributes can be centralized, avoiding to repeat them per each instance of the amplification function, e.g.:


  • Esther Le Rouzic, in a managed network we have 1800 amplifiers of 20 types.
  • Similar consideration for transceivers, several attributes can be centralized.
    • Ramon Casellas the tx-channel-power-min, tx-channel-power-max, rx-channel-power-min, rx-channel-power-max, rx-total-power-max are all capabilities, cannot be configured.
      • min-central-frequency, max-central-frequency, central-frequency-step may be not suitable for centralization, for further analysis.
  • Esther Le Rouzic, there is the risk of misalignment between the catalog/library of amplifiers and the amplifier instances (config/state) shown in the network topology.
    • Ramon Casellas this issue has been observed in the Candi POC, where the amplifier profile catalog/library was stored separately from the database of network resources.
      • This issue shall not occur in TAPI, because all information is available at the same management interface. The server controller has the responsability to keep the database consistent.
  • Ramon Casellas which amplifier types shall we consider? Also the ones defined by GNPy?
    • In theory we shall include GNPy ones - for further analysis.
  • Ramon Casellas proposes that the amplifier profile is referenced by the amplification parameter instance, agreed.