Issue 1: Distinction between nominal and backup paths Applies to Restoration and protection connectivity-services Currently there is not distinction between which is the "Nominal" or "Primary" route and the rest of backup routes, for a given connection. There are more than one point to tackle here: Currently in TAPI, the “tapi-connectivity:connection/switch-control/switch/selected-route” object, is the data node in TAPI designed to specify which is the active route for a given connection which implements the switch control between two lower-level connections. Is this assumption correct? The route object does not contain any attribute which may help to identify it as the nominal or primary route for a given connection. E.g., in case of a restorable service has changed its original (nominal or primary route), there not a way in TAPI to revert manually that connection to its original route.

Issue 2: Ordered Route’s connection-end-points Applies to any connectivity-service Currently the connection/route/ connection-end-point list is (by default) modelled in YANG as ordered-by-system. Someone could argue that the system is not responsible of maintaining a logical order of CEPs. Is there any convention of the order that it should be maintained by the TAPI server for connection/route/ connection-end-point elements? E.g., Telefonica has defined within its specification: The server is responsible of maintaining an ordered list starting from the CEP associated to the NEP associated to the SIP element included in the first element of the tapi- connectivity:connectivity-service/end-point list, and terminating into the CEP associated to the NEP associated to the SIP element included in the last element of the same list. The order of CEPs between these two must follow the routing path selected by the service across the layer. Apply this rule only on those CSs between two CSEPs.

Issue 3: Conflict between connectivity-service topology constrains Applies to any connectivity-service The tapi-connectivity:connectivity-service/diversity-policy and the tapi- connectivity:connectivity-service/topology/node/link-inclusion constrains can be potentially incompatible. In general the usage of some diversity-policies defined is not clear: NODE, LINK policies -> My assumption is when you include this policy within a connectivity-service, that service should be disjoint to the list of NODE/LINKs another service’s (within diversity-exclusion attribute?) route travels across. SRLG, SRNG-> In general the definition of SRGs is not clear to me. SNG -> ????

Applies to any connectivity-service Issue 4: Allow the TAPI user to enable/disable the use of network resources Applies to any connectivity-service Currently TAPI does not allow users to enable/disable resources to prevent them to be used. The most clear case is to block a link/node/node-edge-point for a maintenance operation. From current definition it seems the "admin-state" attribute associated to many TAPI objects would be the appropriate element to modify the state of a resource ( LOCKED/UNLOCKED), however is not configurable in the model. It is needed to evaluate how this use case can be implemented, a possible solution would be to define a new "intent-alike" structure within "OAM" tapi service, to allow the user to put a resource in maintenance