Open Transport Configuration & Control
Space shortcuts
Expand all   Collapse all
Child pages
  • 2019-07-09 TAPI Meeting Notes

Versions Compared

Old Version 5

changes.mady.by.user Karthik Sethuraman

Saved on

compared with

New Version Current

changes.mady.by.user Karthik Sethuraman

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

...

TimeItemWhoNotes
5 minsAdministrative

Karthik Sethuraman

10 mins TAPI 2.x Release Plan
 Nigel Davis

Andrea Mazzini

Arturo Mayoral

Karthik Sethuraman

 TAPI 2.2 Release update
  • RC1 - Released on April 8, 2019Included items:
    • Equipment inventory model (new feature)
    • Routing & Resilience Constraints fixes/updates
      • Some of the constraints were changed to read-write from read-only
      • Minor structural changes (related Topology/Connectivity constraints)
    • OAM, Notification Framework updates
      • OAM Job structure refactoring and renaming
      • OAM/Threshold profile
      • Threshold/PM parameter
      • Alarm/TCA linkage to Threshold/PM parameter
    • Topology Model update
      • added TopologyAggregatesNEP association
      • marked NodeAggregatesNEP as deprecated
      • renamed Node.ownedNodeEdgePoint to Node.nodeEdgePoint
    • ETH Technology model updates
      • mainly OAM based on MEF NRM-OAM requirements, review and feedback
    • Photonic model updates
      • mainly power control management & photonic-layer-qualifier labels
  • RC2 - Released on May 24, 2019
    • Includes UML, YANG, Tree files only.
      • TAPI yang currently does not include any Yang 1.1 features/modules - so we can state that we use 1.0
      • As far as using leafref within a read-write tree to point to read-only attributes, we should use Yang 1.1 require-instance, but if we want to stick to Yang 1.0, we can use uuid instead of leafref
  • RC3 - Released last week

TAPI 2.1.2 Release plan

60 minsRoute/Switch enhancements discussions: Backup/Nominal Routes

Arturo Mayoral

Nigel Davis

Andrea Mazzini

Karthik Sethuraman

  • Continue Connectivity Service/Connection Route/Switch enhancements discussions: Backup/Nominal Routes

  • Summary: Three distinct concerns/topics

    • Conveying resilience/protection intent to the TAPI provider (SDN Controller) during provisioning of Connectivity Service
      • In TAPI approach, the ConnectivityService just conveys overall intent and the TAPI server/controller is free to realize that intent in any manner it sees fit
      • Conveying Route priority/preference via Topology Constraints - TopologyConstraint has a constraintWeight attribute that loosely maps to Route.selectionPriority - in simple cases of disjoint completely constrained routes, it could be 1-1,
      • Conveying overall resilience scheme for the Connectivity using the ResilienceConstraint - Currently only possible to specify overalll expectation and TAPI provider/controller is free to provision multiple SwitchControls to realize this - but currently TAPI has no support to indvidually manage the SwitchControls by the TAPI clients
    • TAPI Connection holds a list of Routes (all routes) and the Switch.selectedRoute attribute reflects the active Route(s)
      • Need to also capture the Route priority/state- Nominal/working, etc
      • Core IM has an Route selectionPriority and routeSelectionReason attributes that should have been transferred into TAPI Route
    • Effecting manual switching - need an new feature (SwitchControlService?) to manually control the various Switches provisioned by the TAPI provider (SDN controller) in response to a ConnectivityService request.
  •  Karthik Sethuraman Nigel Davis : Collect all SwitchControl/Resilience/Protection presentations/material from past TAPI/OIMT discussions in one place

Action items

  •