Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • 2021-04-06 TAPI Meeting Notes
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.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 (blocking, 2)
  5. Path Computation Use Cases (blocking, 3)

TAPI 2.3 and RIA 1.2

  1. MEP/MIP model vs. direct inclusion of OAM parameters in the CEP (blocking, 1)
    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



Next TAPI virtual meeting:


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


 TAPI Call: 2 hours

  TAPI Call: canceled - week of Q2 MEF Meeting

10 mins

Other Admin

All

Agreed to update the TAPI Roadmap 2023 with RIA plan (TR-547, TR-548).

Updated the 2021Q2 TAPI Virtual Meeting Agenda and Notes Apr. 12/13/15 with:

  • mention of GNPy,
  • additional column with applicable TAPI release.

Brief discussion on GNPy:

  • Which are the input needed by GNPy?
  • Which input shall extend TAPI?
  • Noted also that GNPy has some limitations, for further analysis.
  • ODTN is evaluating GNPy input and definining the list of amplifier types.
100 mins

Optical Impairments and Topology

All

Andrea Mazzini provides an overview of draft-ietf-ccamp-optical-impairment-topology-yang-06 and RFC 8795.

  • The Optical Impairment Topology is defined as a profile of three unidirectional path types: Express Path, Add Path, Drop Path. Each Node/NE instance has the impairments defined on these generic path types.
  • Karthik Sethuraman reminds that in past discussions the IETF folks considered the TAPI ConnectivityService as mostly similar to the TE-Tunnel, i.e. a potential/intent for connectivity. Post meeting note: The TE-Tunnel can be considered also similar to a TAPI Link - i.e. the result of a planned/provisioned Trail.
  • After some discussion, agreed that:
    • Device object has been introduced mainly to model the (simplified) Control Domain concept.
    • There is no need to introduce Device recursion, because the AccessPort has a relationship with supporting Equipment.
    • The AccessPort is represented when useful / relevant to describe the topology internal to the Device, e.g. in case of cabling and/or monitoring capability.
    • An AccessPort instance may be supported by more Equipment instances, e.g. to abstract a cascade of unidirectional mux/demux.
    • The "physical route" Use Case can be fulfilled by the list of involved AccessPorts.
    • The AccessPort instances supported by a given Equipment instance(s) are considered as all potentially interconnectable - in analogy with the NEPs of a Node. Hence the dotted lines can be removed.