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

10 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
60 mins

Layering recommendations

Andrea Mazzini provides an overview of the preliminary agreements reached during TAPI/RIA calls of last week:

  • The introduction of new layer rate qualifier OTS_MEDIA replacing UNSPECIFIED, OTS and OTS_OMS ones.
  • Deprecate OTSi layer rate qualifier:
    • The currently specified OTSi CEP will become an OTSiMC CEP with Termination State = PERMANENTLY_TERMINATED (to be checked).
    • The currently specified OTSiMC CEP will have Termination State = CAN_NEVER_TERMINATE (to be checked).


  • Below an example applicable to "aggregated" scenario, with the MC Connection ending on the Degree Port of the ROADM:

  • Below an example applicable to "disaggregated" scenario, with the MC connection ending on the Add/Drop Port of the ROADM (i.e. MC Connection is the result of MC ConnectivityService provisioning):


  • Ramon Casellas the following case, where MC ends on the transponder, seems not applicable for currently known use cases:


  • Preliminary agrement to avoid OTS_MEDIA / OMS CEP instances specific per C, L etc. bands.
    • Esther Le Rouzic, each vendor has different definition of bands.
50 mins

Draft of Optical Impairment UML model

Andrea Mazzini 

Andrea Mazzini presents the updated UML diagram of Photonic Profiles.

  • All data structures defined by ietf-optical-impairment-topology.yang have been included in the diagram, either in classes or mentioned in the comments.
  • Left part:

  • Right part:


  • Ramon Casellas notes that e.g. the actual-gain is a parameter which cannot be part of a profile, rather it is a property (state/config) of a given managed amplifier of the network.
    • Andrea Mazzini right, each construct shall find its right place, either in a Profile or in an already defined TAPI topological or connectivity object. Now we have an unique diagram to parse.
  • Clarified that the IETF OMS Link is equivalent to either OMS Connection or MC Link in TAPI.
    • Agreed that IETF oms-element provides a description of the topology between ROADMs (amplifiers and fibers).
  • Andrea Mazzini shows an early draft of a possible use case "get all OMS Connection/MC Link Impairments".
    • It shall be completed by the optical impairment parameters which will be added to topological or connectivity objects: