Versions Compared


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


Discussion items

5 minsAdministrative
  •  TAPI Call: 3 hours
  • Andrea attending MEF Q3 Meeting, Nigel Davis will lead the call.
5 mins

Review of TR-547-TAPI v2.1.3 Reference Implementation Agreement_Rev1__PAMARAL_am.docx

Arturo ran through the document comments and resolutions. All comments were dealt with on the call. The document has been uploaded at TR-547-TAPI v2.1.3 Reference Implementation Agreement.docx.

Nigel stated to the team that any further comments will go into the next version. There was no objection.

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.

Xiaobing to check notes/comments in YANG

3.18.1 Nigel: add description of monitoring the delay of the client: Add description of log compaction policy

3.18.2 Nigel - describe the distinction between emulated compaction and normal compaction

4.2 Nigel improve text

4.5 Nigel: Add material on functions and identify which functions are mandatory. Send early text to Xiaobing for comment

20 mins

TAPI 2.3 vs 2.1.3

  • Discuss the two alternative solutions proposed during call of last week

From last week....

  • Current TAPI maintenance streams:

Image Removed

  • 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.

Andrea Mazzinito verify with Karthik Sethuraman the best procedure to copy TapiOam and TapiEthernet from "develop"/edge.

20 mins

TAPI 2.3 vs 2.1.3

  • TAPI ODU deltas

From last week

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 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 environmentAndrea Mazzini it is easier when there is a reference standard, like ITU-T for OTN and Carrier Ethernet30 mins
    Nigel Davis

    Nigel ran through the contribution in detail. 

    There were several requests for clarification that were resolved during the discussion. No specific changes were requested to the model at this stage. 

    In general the group accepted the need and that the approach seemed reasonable. Clearly further discussion will be required.

    0 mins

    Team agreed to end the meeting early.