1. Pages
2. …
3. Open Transport Configuration and Control Home
4. TAPI
5. TAPI Call-in Details and Notes
6. 2020-07-21 TAPI Meeting notes

Page History

Andrea Mazzini

Nigel Davis

• 28 Jul 2020 TAPI Call: 3 hours
• Andrea attending MEF Q3 Meeting, Nigel Davis will lead the call.
  • Consolidation of TR-547-TAPI v2.1.3 Reference Implementation Agreement_Rev1.docx
  • Review/Consolidation of TR-548 RIA-Streaming
  • Continue on Fault Use Cases

Andrea Mazzini

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:

• qianjia noted an inconsistency in Table 20, Andrea Mazzini uploaded further commented version TR-547-TAPI v2.1.3 Reference Implementation Agreement_Rev1__PAMARAL_am.docx 

Nigel Davis

Arturo Mayoral

Jonathan Sadler

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.

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

•  Andrea Mazzinito commit the corrected TapiOdu

Andrea Mazzini

Nigel Davis has approved and closed the pull request.

Andrea Mazzini

Arturo Mayoral

Nigel Davis

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

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

Andrea Mazzini

Nigel Davis

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.

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.