Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • 2020-10-13 TAPI Meeting Notes
Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
    • Consolidate the dates of next virtual meetings
  • Review/Consolidation of TR-548 RIA-Streaming
  • Review proposed update of ODU OAM model
  • 2.1.x / Edge: alignment of OAM model
  • Continue update of TAPI Roadmap

Discussion items

10 minsAdministrative

Andrea Mazzini

Karthik Sethuraman

Nigel Davis


Two sessions of 3 days / 5 hours (1pm - 6pm CET) - with the option to add some extra hours on Thursday

Draft agenda: 2020Q3 TAPI Virtual Meeting Agenda and Notes Oct. 19/20/21 and Nov. 09/10/11

  • Session 1:  
  • Session 2:  

Please add the link to your contributions to the agenda page

10 mins

Review/Consolidation of TR-548 RIA-Streaming

Nigel Davis


Nigel Davis the available draft ( TR-548-TAPI_v2.1.3_ReferenceImplementation-Streaming_v1.0-fourth-draft.docx) now includes all use cases.

Nigel Davisasks Arturo Mayoral to check off line if his comments have been correctly addressed.

90 mins

Review proposed update of ODU OAM model

Andrea Mazzini

Karthik Sethuraman

Malcolm Betts

Hing-Kam Lam

Nigel Davis



Andrea Mazzini presents the UML Papyrus diagram of alternative ODU OAM model.

  • Two distinct approaches for the ODU OAM model: Reuse the common pattern defined in TapiOam (OAM Service, OAM Job, MEG/MEP/MIP) for 

     1) both ODU+OTU Path (NCM, Network Connection Monitoring) and TCM, Tandem Connection Monitoring, see below diagram from main branch/edge version:


   2) only TCM, decorating the OAM ODU+OTU CEP and CSEP with OAM related properties as depicted below:

      Below only the TCM MEP/MIP augment generic MEP/MIP:

  • Discussion on pros and cons:
    • Solution 1 is leveraging the TAPI common part, but may appear more complex than necessary.
    • Solution 2 appears more efficient and in line with traditional approach for the specific technology, but doing so the TAPI common patterns may become empty shells.
  • Nigel Davis it should be possible to create a Connectivity Service together with its related OAM Service.
  • Karthik Sethuraman in MEF the trend is to uniform, hence focus is on common patterns. In TAPI we designed the common parts because we recognized that there are common (management) patterns across technologies. E.g. MEP and TCM has many common properties.
  • Karthik Sethuraman adds that eventually both solutions 1 and 2 are translated into "tables", hence the complexity of solution 1 is likely only apparent.
    • Andrea Mazzinito clean up and update the current TAPI edge ODU OAM model (solution 1), to allow a more detailed comparison wrt solution 2 (note that a "NCM+Delay" entry of OduOamJobType could be useful).
  • Solution 2, discussion on OduOamCommon object, which is read/write or read-only depending on context, i.e. if is part of CSEP is R/W, while if is parts of CEP is read-only. How to formalize these types of restrictions?
  • Andrea Mazzini some attributes defined by G.875 may be not applicable to TAPI, as apparently more related to eqp/node view. Nigel Davis also true that TAPI can potentially be applicable at any level of the management hierarchy. Malcolm Betts confirms that all G.875 attributes are useful. G.7044 is the reference for HAO (Hitless adjustment of ODUflex).
  • Hing-Kam Lam indicates the Appendix I of G.875 for clarification about position sequence attribute, which specifies the positions of the TCM and GCC processing functions within the ODU(-h) CTP/TTP.
  • Discussion on user management, agreed that is typically performed on user interface side, not through TAPI. Malcolm Betts, Nigel Davis authentication is the key.