Skip to end of metadata
Go to start of metadata




Discussion items

5 minsAdministrative
5 minsConsolidation of TR-547-TAPI v2.1.3 Reference Implementation Agreement.docx

Review of TR-547-TAPI v2.1.3 Reference Implementation Agreement_Rev1__PAMARAL.docx  postponed as Pedro could not join the call.

Post meeting note:

10 mins

Review TR-5XX.Y-TAPI_v2.1.3_ReferenceImplementation-Streaming_v0.1.docx

Nigel Davis is performing final editing this week.

  • Arturo Mayoralto inform whether further comments will be provided by Telefonica.
  • Jonathan Sadler is ok with the document contents, with the proposal to add (e.g. in a future version) some broader considerations regarding client multiplicity, because in micro services architecture the clients can be >> 2.
  • Also noted that the streaming application is in principle independent from the used transport protocol.
5 mins

2.1.3 corrections

Andrea Mazzini

Andrea Mazzini found a corrupted augmentation in TapiOdu (odu-mep augment of mep, was wrongly on CEP)

5 mins

TAPI 2.3 vs 2.1.3

Nigel Davis has approved and closed the pull request.

20 mins

TAPI 2.3 vs 2.1.3

  • Discuss the two alternative solutions proposed during call of last week
  • Current TAPI maintenance streams:

  • Agreed to proceed with option 1 (see also 2020-07-14 TAPI Meeting notes)
    1. Version 2.1.4 will copy TapiOam and TapiEthernet from "develop"/edge
      • Oam and Ethernet not backward compatible, mitigations:
        • No knowledge of any TAPI OAM and Ethernet implementation
        • Provide guide to differences
  • Option 2 (Move from 2.1.3 to 2.3) will be performed in a later stage.
20 mins

TAPI 2.3 vs 2.1.3

  • TAPI ODU deltas

Andrea Mazzinishows the TapiOdu deltas between 2.1.3 and develop/edge (TAPI213vsNMR_20July.docx)

  • Nigel Davis recalls that in YANG modules some cardinalities of the UML associations are lost, because not relevant in YANG. Hence it is better to consider also UML to preserve the semantics.
  • Nigel Davis points out that one of the main differences between 2.3 and 2.1.3 regards ENUM vs. IDENTITY.
    • Concerning both backward compatibility and (vendor) extensibility, the two types are essentially equivalent.
    • Is there a MEF position regarding these two alternative types?
    • Andrea Mazzinito check whether MEF recommends the usage of ENUM or IDENTITY.
50 mins

Plan of next steps regarding version 2.1.4

  • Continue on Fault and Streaming Use Cases
Arturo Mayoral

Arturo Mayoral presents the new TAPI Use Cases, which will become part of next version of TR-547.

  • Analysis of Alarm Notification parameters
    • Clarified that Notification Id is the unique identifier of the Notification itself, not of the "occurred alarm event"
    • Alarm categories based on ITU-T X.733
      • Categories defined in a past ecosystem, now we should rely on a well defined model of "resources which can raise alarms"
      • The risk is to define an additional model in the alarm parameters
      • Agreed that the X.733 categories can be used to drive the discussion
    • To structure the alarm parameters in Common, Specific Networking and Specific Security parts improves modularity and extensibility.
    • Nigel Davis ideally the alarm parameters should be similar/same for both Notification and Streaming mechanisms.
    • Agreed to add the "status" information, to clarify whether the notification regards an alarm raising or an alarm clearing event.
      • This will make redundant the traditional "CLEARED" severity
      • Discussion whether the notification of a clearing alarm shall include the information of original severity - for further analysis
    • Long discussion on Probable Causes (LOS, LOF, SSF etc.), how to align multi-vendor environment
      • Andrea Mazzini it is easier when there is a reference standard, like ITU-T for OTN and Carrier Ethernet.
  • No labels