Skip to end of metadata
Go to start of metadata




Discussion items

10 minsAdministrative
  • Andrea will not be available on and  
  • Nigel will not be available on
  • Agreed to cancel call
  • Tentatively Nigel can run the  
10 mins

Review/Consolidation of TR-548 RIA-Streaming

Nigel Davis reviewing the comments is taking longer than expected, there are meaningful improvements to the document. Planned another couple of weeks to complete the review process.

40 mins

Plan of next steps regarding version 2.1.4

  • Outcomes from dedicated call held Friday 7

Andrea Mazzini provides a summary of the call planned last week (see 2020-08-04 TAPI Meeting Notes) to discuss detailed procedure of 2.1.x and develop/edge alignment and way forward. Attendees Arturo Mayoral, Karthik Sethuraman , Nigel Davis , Andrea Mazzini.

  1. Edge TapiOam cannot replace 2.1.3 TapiOam, because of different relationship with TapiNotification and usage of Identity rather than Enum.
  2. TAPI 2.1.4 will be a backward compatible version of 2.1.3
  3. A number of “modification for alignment” patches will be performed on both 2.1.x and Edge (2.1.x shall be bkw compatible, Edge not), to align as much as possible the two streams, e.g.
    1. 2.1.x TapiCommon: Remove resource and service spec classes
    2. Edge TapiConnectivity: Edge: Node/_nodeEdgePoint, modify to Node/_ownedNodeEdgePoint (aligned to 2.1.x)
  4. In 2.1.x some non-backward compatible modifications can be agreed and performed in case there is a clear added value (new feature / better model), e.g.
    1. Move from Enum to Identity.
  5. Replicate features of Edge (e.g. of TapiOam/TapiEth/TapiOdu) to 2.1.x, following the agreements of future discussions.
  6. Replicate new features of 2.1.x to Edge, to maintain general alignment.
90 mins
  • Plan of next steps regarding version 2.1.4
    • Review of possible modifications for controlled alignment

Andrea Mazzini presents TAPI213vsNMR_10Aug.docx

  1. protection/resilience type, agreed that develop/edge will roll back to single attribute, aligning to 2.1.x
    • It is more useful to enhance the comments rather than split the enum listing protection and restoration types.
  2. develop/edge has Topology/boundary-node-edge-point (TopologyExposesBoundaryNEPs), 2.1.3 not
    • Agreed that unless there is a specific use case, we can remove the association from develop/edge, aligning to 2.1.x
    • Check with Karthik Sethuraman
  3. develop/edge has NEP/availableCepLayerProtocol, which is richer than simple supportedLayers of 2.1.3
    • Agreed that improvements are envisaged regarding this feature (Transmission Capability, including inverse mux).
    • Arturo Mayoral in 2.1.x we may add a new, richer attribute to the NEP, keeping supportedLayers for backward compatibility (with "deprecated" stereotype).
    • Nigel Davishighlights the distinction between rules and usage, rules are fixed and typically input to planning tools, usage reflects dynamic allocation of resources.
    • Agreed that would be highly beneficial for the industry that SPs provide requirements concerning the rationalization of the languages adopted by provisioning and planning tools.
  4. Discussion on alarms and TCAs.
    1. Arturo Mayoral clarifies that a major requirement is the independence of notifications (and streaming) from TapiOam definitions.
      • develop/edge has moved from TapiNotification to TapiOam a number of definitions, e.g. tca-info, alarm-info. Doing so, alarm and TCA related notifications can be supported only if also TapiOam is supported by server controller.
      • It is then proposed to roll back to the model of 2.1.x, where all OAM related definitions are centralized in TapiNotification. This would allow a soft transition between basic OAM management (e.g. only alarm notifications) to more sophisticated provisioning of OAM jobs, etc.
      • Andrea Mazzini in this way we are distributing some OAM functions to e.g. TapiConnectivity and TapiEquipment. In other words, an ODU CEP can raise alarms, independently from TapiOam support. So far the assumption was that only MEP/MIP can raise alarms/TCA.
        • Arturo Mayoral we may think of a simple boolean like "can raise alarms".
      • Agreed that MEP/MIP model is applicable to ODU Tandem Connection feature.
      • Agreed that TapiOam is oriented to the monitoring of flows, not applicable e.g. to equipment.
      • Noted that TapiNotification needs to import only TapiCommon: augments of base types (e.g. OtnAlarmConditionName which augments AlarmConditionName), defined in specific models (e.g. TapiOdu, ) occur eventually in TapiCommon.