Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • 2021-03-30 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

30 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).

Ramon Casellas plans to provide an updated RIA 1.1 draft by the virtual meeting.


 TAPI Call: 2 hours

30 mins

Review 16a/b Alarm/TCA notification

  • Probable Causes, follow up discussion on defects vs. fault causes (e.g. AIS/FDI vs. SSF)
All

Andrea Mazzini presents TR-547-TAPI RIA V1.1 Alarms.xlsx

  • Nigel Davis highlights that the AlarmName column is not yet specifying the exact coding (e.g. Enumeration/Identity entry)
  • Agreed to add an "alias" column where to list the agreed aliases of AlarmName, e.g. ODU-AIS, ODU-SSF.
  • Nigel Davis proposes the definition of a machine readable version of the TR-547-TAPI RIA V1.1 Alarms.xlsx spreadsheet.
    • Client Controllers are so allowed to learn the alarm name aliases.
    • This is different from "supportable alarm list" and "currently supported alarm list". This last is related to the operational state of sensors/detectors.
      • Currently defined sensor/detector are the MEP and MIP classes.
30 mins

Review 16a/b Alarm/TCA notification

All

Continued the analysis of the new TapiAlarm module.

  • Agreed to combine Alarm and TCA lifecycle attributes in an unique "package":

  • Nigel Davis suggests to add sub-optionality specifications.
  • Nigel Davis the temperature sensor/detector may have its own operational state, it may be relevant to communicate the inability to measure the temperature.
    • It may also happen that the communication between the sensor and the processing entities is broken.
    • Another parameter is the aging of the measure, e.g. if the temperature value is unchanged since too much time.
30 mins

Alarms from Access Ports, either associated to NEP or not.

Nigel Davis

Nigel Davis highlights the need of a linkage between the internal of the equipment and the effects on forwarding. Considering the figure below, also AccessPorts which are not related to a NEP (internal AccessPorts) shall raise alarms and the mapping to supported connections shall be known.



Ramon Casellas recalls that in TIP there is an ongoing PoC on TAPI & GNPy, where TAPI is augmented with main focus on the provisioning of amplifiers, e.g. gain and tilt.

  • Two stages amplifiers with VOA are also considered.

Andrea Mazzini we may consider to add recursion to the Device managed object class. Introduce the "Device Type" to build a topology of functions.

Nigel Davis suggests to review the TR-512 Core Model, appendix A.4 - AnalogueAndMediaExamples-L0 (https://opennetworking.org/wp-content/uploads/2018/12/TR-512_v1.4_OnfCoreIm-info.zip)