Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


10 minsAdministrative


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


Agreed to update the TAPI Roadmap 20212022-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


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.