Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Admin
  • Publication of TR-547 RIA
    • Check next actions for final publication
  • Review/Consolidation of TR-548 RIA-Streaming
  • Plan of next steps regarding version 2.1.4
    • Copy TapiOam and TapiEthernet from "develop"/edge.
    • Check whether also TapiOdu can be copied from "develop"/edge.
    • Routing Constraints
    • Continue on Fault and Streaming Use Cases
    • Continue "LAG / Inverse Mux" discussion (is missing the CEP marked "mux")
    • Association orientation when applying the TAPI model to IP: possible evolution of OAM model (otcc2020.ND.018_TAPI-AssociationOrientationRationale.pptx)
    • Transmission Capability
  • Continue "Physical route of a connection" discussion (otcc2020.ND.019_TAPI-PhysicalRoute.pptx)
  • Addressing of elements within a TAPI entity to provide greater meaning to alarm notifications (otcc2020.ND.020_TAPI-AddressingSubElements.pptx)

Discussion items

5 minsAdministrative
  •  TAPI Call: 3 hours
  • Andrea will not be available on and  
10 mins

Publication of TR-547 RIA

  • Check next actions for final publication

Arturo Mayoral proposed accompanying text for TR-547 RIA publication:

“We are glad to announce the release of the TR-547 Reference Implementation Agreement for T-API v2.1.3 information model. This document is the result of several months of join collaboration between optical network providers and operators within the OTCC group at ONF, to come up with an standard reference specification for the implementation of T-API based management interfaces. This Reference Implementation Agreement presents an comprehensive guide for the development and implementation of different use cases ranging from optical networks discovery, service provisioning, HW inventory and fault management. The target audience for this document is both network providers implementing T-API as Northbound Interface of their Network Management Systems (NMS) or SDN solutions, and client layer applications and Operations Support Systems (OSS) consuming T-API.”

After a brief discussion, the team agrees the text, hence Lyndon Ong can proceed.

5 mins

Review/Consolidation of TR-548 RIA-Streaming

Arturo Mayoral will upload his comments to TAPI contribution page, Nigel Davis will check them.


20 mins

Plan of next steps regarding version 2.1.4

  • Copy TapiOam and TapiEthernet from "develop"/edge.
  • Check whether also TapiOdu can be copied from "develop"/edge.

Andrea Mazzini proposes to set up a dedicated call to do the job (copy TapiOam and TapiEthernet from "develop"/edge)

Agreed, on 2pm CEsT, invitation sent to:

Andrea Mazzini proposes to copy also TapiOdu, as the differences are only in the OAM part (see TAPI213vsNMR_20July.docx), where develop/edge model is more advanced and the team already agreed (2020-07-21 TAPI Meeting notes) that is acceptable having 2.1.4 OAM model not backward compatible with 2.1.3 OAM model.

  • No objections.
40 mins
  • Plan of next steps regarding version 2.1.4
    • Routing Constraints

Andrea Mazzini presents otcc2019.AM.006_TAPI_ConnectivityConstraints.pptx

  • Confirmed the agreement on option 1 (Recursive creation of Client/Server ConnectivityServices)
    • Further analysis of "subordinate-protection" SIPs is necessary, as they are inherently more fluid than boundary (e.g. UNI) SIPs.
    • Similar issue for "subordinate-OAM" SIPs.
  • Agreed the proposed model solution:

70 mins
  • Plan of next steps regarding version 2.1.4
    • Continue "LAG / Inverse Mux" discussion (is missing the CEP marked "mux")

Andrea Mazzini presents some possible alternative models for the multi-wavelength case.

  • Agreed that current model is oversimplifying the inverse mux feature.
  • After some discussion, found a preliminary agreement on the following scheme:

  • Malcolm Betts "the OTSiA Connectivity Service actually connects the OTUs, but it is not an OTU connectivity"
  • We need to find a better definition for what is now indicated as "OTU+OTSiA" qualifier.
  • Note that the server-connectivity-service-end-point is currently defined as 1:1 but needs to be generalized to 1:n (non-backward compatible on YANG side, acceptable as existing implementations are unlikely).
    • This is also necessary for MEF L1 ENNI/INNI protection use cases.