Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
    • Plan for dedicated RIA 1.1 review calls (ONF TAPI RIA)
    • Review the plan for 2.1.3 Release together with RIA 1.2
  • Pre-release v2.3.1
    • Review of last updates
    • Overview of Alarm and TCA spreadsheet

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 (solved - work ongoing on probable cause list)
    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 (solved)
  5. Path Computation Use Cases (blocking)

TAPI 2.3/2.4 and RIA 1.2

  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

15 minsAdministrative

All



Calls will tentatively restart on December for RIA 1.2 / TAPI 2.3.x

  • Invited Ramon, Nigel, Ronald, Pedro, Arturo. Please others interested to contact Andrea.
  • The revision process has included some Use Cases (e.g. Notification ones) which were never discussed in TAPI calls.
    • To save time, some decisions are taken during the review (specifically the relationship between Restconf and TAPI notification features).



TAPI weeky call

Preliminary agenda:

  • Consolidation of TAPI 2.3.1 release
  • Continue the “GNPy/CCAMP – TAPI alignment” activity
15 min

Review of last updates

All

Andrea Mazzini shows the updates to TapiFm agreed during last RIA review calls:

  • AlarmCategory enum, removed TCA entry as conceptually wrong.
    • ITU-T X.733 Event type has different semantic: “the quality of service alarm type: An alarm of this type is principally associated with a degradation in the quality of a service.” Not really a TCA.
  • Added NativeAlarmName and NativeAlarmInfo. Analogously for TCA.
  • TcaInfo and PmMetricInfo, added granularityPeriod in case the related OAM Job is not explicitly represented at the TAPI management interface.
30 mins

Overview of Alarm and TCA spreadsheet

All

Andrea Mazzini presents TR-547-TAPI_RIA_V1.1_Alarm_TCA_List_23112021.xlsx spreadsheet

  • Agreed that an alarm instance (or better a detector of a specific condition) is unambiguosly identified by the following keys:
    1. Alarm Name
    2. Target Object Identifier (global class) plus Target Object Name (local class)
    3. Alarm qualifier
  • An alarm instance is an occurence of an alarm detected by a given specific alarm detector. A LOS alarm conditon can be raised and cleared many times by the LOS detector on a device port.
  • Split the cases of version 2.1.3 where OTU layer is not foreseen (hence OTU alarms are raised by OTSi CEPs) from the cases of version 2.3.x where OTU layer is explicitly represented.
  • Split Alarms and TCAs into two distinct sheets.
  • Discussion on "location", i.e. near and far end counters.
    • TapiOdu: OduPmParameterName, UAS_BID changed to UAS. The “NE/FE/BID” qualification is already present in OduErrorPerformanceData and shall be added to TcaInfo and PmMetricInfo.
    • Nigel Davis by experience we may have several qualifiers for a given PM Parameter, e.g. NE/FE/TX/RX/Codirectional/Contradirectional etc.
    • Ronald proposes that Alarm Qualifier and TCA Qualifier shall be name-value pairs.
    • For further discussion how to code at least the NE/FE information.