| 45 mins | TAPI 2.x Release Plan | | - 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
- LLDP defferred to v2.3 or later
- Includes UML, YANG, Tree files only.
- OpenAPI & RI will be included in RC3 (not normative)
- RC2 - Planned for today - Mainly includes
- OAM & ETH OAM updates due to MEF CfC feedback
- Equipment RPCs
- Reverted Node.aggregatedNodeEdgePoint removal.
- Plan to do TAPI 2.1.2 release which does not include any backward-incompatible changes and only minor bug fixes, mainly
- Topology Constraints change from RO to RW
- Notification SUbscription change from RO to RW
- YANG 1.0 v/s 1.1
- 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
- Decision: Replace pointer references in TopologyConstraint with UUID references for both 2.1.2 as well 2.2.0.
|
| Multi-layer Topology & Connectivity use case & mode | | - https://github.com/OpenNetworkingFoundation/TAPI/issues/419
- The intention of TAPI 2.x is to support the use case on the "Right side" of the above figure.
- The use case similar to one on the "left-side was discussed at the Beijing F2F and was deferred to TAPI 3.0 as further discussions are needed. This is because it was acknowledged that "Node.aggregatedNodeEdgePoint" is not the best way to support it and it would be better served to have a direct association "NEPIsSupportedByLowerLevelNEP" between the "cloned" NEP in the higher-level Topology and the one in the lowest-level Topology.
- Finally it was noted that the reason to use transition link is to flatten (combine?) different layer network typologies (not different levels) to create a single (multi-layer) topology for path computation purposes.
  - The above figures depicts the original intent of TAPI 2.x for using Node.aggregatedNodeEdgePoint
- The bottom figure depicts the recursive connection relationships in the above topology.
- It was noted that the association "ConnectionIsBoundedByNode" is now missing and is to be added into TAPI 2.x
- This will result in an pointer/reference attribute in connection to the bounding Node.
- Further discussion on (Thursday 6AM PDT OIMT call) the multiplicity of the Node-end of the association - whether it is exactly 1 or 0..1. If it is exactly 1, then the TAPI provider/server will have to expose at least 2-level topology (top-level with a single Node and entire network at next level) if it wants to describe an end-to-end connection.
- Karthik Sethuraman to update UML & generate Yang for 2.1.2 & 2.2.0 with multiplicity 1 and can revise it in RC3 if needed
|