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
30 mins

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

qianjia presented TR-5XX.Y-TAPI_v2.1.3_ReferenceImplementation-Streaming_v0.1 - jq.docx

  • Summary of agreements:
    1. "Few direct client (~2)", Nigel Davis clarifies that is intended as order of magnitude, i.e. are not expected several tens of clients.
    2. "The TAPI realization assumes a reliable...", "Is highly reliable..." agreed that some more explanations would help. Also agreed that it is better to distinguish between "normative" part of a specification and generic qualitative requirements. In other words either the requirement is clear/detailed enough to be measurable in an implementation or can be moved to e.g. a non normative appendix.
    3. Some clarifications regarding key time settings, "only the last modification of the thing which is meaningful to keep", e.g. the deletion of a Connection will be never superseded by the creation of another Connection, because the new Connection will have at least a different UUID.
    4. Paragraph 3.7.1, it is missing an augmentation (compacted-log-details)

Agreed to wait for another week before to proceed with publication.

10 mins

Plan of next steps regarding version 2.1.4

  • 2.1.3 corrections

qianjiafound a duplication in TapiPhotonicMedia model:

  • power-properties and power-properties-pac
  • Agreed to remove the PowerPropertiesPac class from 2.1.x UML, replacing it with the PowerProperties data type
    • After review of current (YANG) definitions, agreed that the modification is backward compatible.
50 mins

Plan of next steps regarding version 2.1.4

  • Alignment to 2.3 / Next Major Release
Andrea Mazzini

Andrea Mazzini presents TAPI213vsNMR_13July.docx

  • Current TAPI maintenance streams:

  • Orange branch ("develop"/edge) Common, Topology and Connectivity have small differences wrt blue branch (2.1.3)
  • Orange branch ("develop"/edge) Oam and Eth are aligned to MEF PRESTO and are more advanced than 2.1.3
  • Orange branch ("develop"/edge) Odu is more advanced than 2.1.3 (analysis to be completed)
  • Orange branch ("develop"/edge) Photonic can be aligned to 2.1.3 (2.1.3 is more advanced)
  • Streaming should be more advanced in 2.1.3
  • Equipment is same
  • After some discussion, agreed the following alternatives:
    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
    2. Move from 2.1.3 to 2.3
      • Common, Topology, Connectivity, Oam and Ethernet not backward compatible
        • Stop of 2.1.x branch: meaningful simplification of TAPI maintenance and evolution
15 mins

Association orientation when applying the TAPI model to IP: possible evolution of OAM model

Brief discussion on the subject.

  • Karthik Sethuraman suggests to remove any mentioning of IP technology unless we plan to develop it.
  • Karthik Sethuraman highlights that in MEF the focus is moving towards API, i.e. the preference is to develop more APIs, even similar, but optimized per each different consuming application. Conceptually this may translate into "all bidir" associations.
  • Andrea Mazzini recalls that in general for interoperability is more important the static model (classes/attributes/data types) with respect to the dynamic model (operations). Another important aspect is how to limit the compositions, i.e. if and where to stop the propagation of "included by value" items.
  • Karthik Sethuraman the main property of a Connection is exactly the set of its Connection End Points, this is also intuitive. Reversing the association may be not understood.

  • No labels