Skip to end of metadata
Go to start of metadata

Date

Attendees

Goals

  • Continue Review of TR-5XX.1-TAPI v2.1.2 Reference Implementation_v0.5.docx
  • 2.1.3 version freeze, tentative target March 20: review of modifications and open issues
  • OTSiMCA/MCA CSEP attributes
  • Multi-layer model / capabilities: at least in the scope of TR-5XX.1-TAPI v2.1.2 Reference Implementation
  • OAM model for ODU and Photonic

Discussion items

5 minsAdministrative
  • Next F2F TAPI meeting, hosted by Telefonica/Madrid:
    • -  
    • but at least Andrea is not allowed to travel. Let's see evolution of coronavirus.

  • Call slot assignment: last week we were preempted by another ONF meeting overlapping last scheduled hour
    • ONF TAPI Call is scheduled by ONF admin from 3pm to 5pm CET
    • easonably we can ask to extend to four hours - with option for two additional hours "on demand".
    • Issue is temporary solved by ODTN project moving its call to Monday

  • TAPI Call: 4 hours, note that US is in daylight saving time, call will start at 2pm CET 
    • Proceed on 2.1.3 version freeze, tentative target March 20: review of modifications and open issues
    • OTSiMCA/MCA CSEP attributes
    • Multi-layer model / capabilities: at least in the scope of TR-5XX.1-TAPI v2.1.2 Reference Implementation
    • Preparation of May f2f agenda
10 mins

Node Rule Group, Streaming

Nigel Davis

Nigel Davis notes that the current Node Rule Group model is lacking some capabilities regarding:

  1. Direction
  2. Role

Uploaded presentation on Node Capability, not reviewed in this session: otcc2020.ND.007_TAPI-onf2016.296_MwdFdCapability.pptx

Also proposed to add Streaming model to 2.1.3 version.

20 minsTAPI VersionsKarthik Sethuraman

Karthik Sethuraman highlights that formally a "x.y.z" version should foresee only bug fixings and minor changes, while 2.1.3 is adding features like Equipment model. Furthermore the 2.1.3 is the release subject of TR-5XX.1-TAPI v2.1.2 Reference Implementation_v0.5.docx, hence should follow the ONF review process, i.e. at least an RC1 before consolidation. Agreed to deliver 2.1.3 RC1 before end of March, ready to be used for implementation - with the assumption that only very necessary modifications will be performed before official final release.

80 minsTAPI 2.1.3 modifications

Arturo Mayoralpresents c2020.AMLL.001_TAPI v2.1.3 extension proposal.pptx

  • Summary of agreements:
    1. agreed all proposed enhancements, which shall be performed maintaining backward compatibility
      • do not remove OtsConnectionEndPointSpec
      • do not "move", rather "duplicate" FEC parameters
      • document in both UML and Yang the "to be deprecated" features
    2. but do not introduce any new OAM feature, i.e. OAM will be managed by a subsequent TAPI version - if we want to respect end of March deadline for 2.1.3 delivery

    3. Recalled that the Equipment model of 2.1.3 is not exactly equal to 2.2 one, two minor changes have been made to maintain backward compatibility:
      1. "supporting-access-port" augmentation path (..../tapi-topology:owned-node-edge-point).

      2. tapi-common: OBJECT_TYPE based identities (v2.2.0) defined in tapi-equipment model and used in tapi-notifications have been converted to the previous "typedef/enum" format and placed locally in tapi-notification model.

    4. Agreed that 2.1.3 version shall include also UML Equipment model, as currently is only defined by Yang modules.
    5. Agreed that the reference GitHub branch is https://github.com/OpenNetworkingFoundation/TAPI/tree/v2.1-bug-fixes
80 minsLayering & PartitioningArturo Mayoral

Arturo Mayoralpresents otcc2020.AMLL.001_RI_Connectivity_modelling.pptx

  • Summary of agreements:
    1. In the Reference Implementation is defined the:

      1. Flat Topology: there is one instance of (root) Topology, which encompasses all the Nodes. The Nodes do not encapsulate any lower level Topology. The NEPs are all "owned" by the Nodes.

      2. Top Connection: a Connection which spans the (root) Topology. A Top Connection is partitioned in (Cross) Connections spanning the Nodes encompassed in the (root) Topology.

    2. Keep only "6.1.1.2 Option B: Per layer top-connection modelling without inter-layer referencing" of TR-5XX.1-TAPI v2.1.2 Reference Implementation_v0.5.docx, and
      • remove the requirement that all Top Connections must point to their supporting Link. Inter-Layer navigation can be performed through NEP/CEP stacks and Links. It is assumed that the Link instances are always available but in the case of redundancy.
    3. Add a dedicated operation for the get of resiliency routes of a (Top) Connection.

Action items

  •