TAPI Roadmap 2023 updated including a new version 2.3 which purpose is to anticipate a selection of 3.0 features. Selection is made on less impacting features, specially considering backward compatibility.
Constraint model is outlined in the following slide:
Andrea Mazzini proposes this model to enhance the constraining capabilities of a ConnectivityService
with respect to potential Connections
and their resiliency schemes
and their resiliency routes
The idea is to reuse existing constraint classes (Topology/ Routing/ Resilience Constraint) for Connection level, and further reuse only TopologyConstraints for Route level. The SubordinateConnectivityService class allows to select a layer protocol (also at server layers) and ending NEPs / Nodes (through SubordinateCsep class), to delimitate the potential scope of a resulting Connection. It is so possible to specify a full range of constraints, for any number of potential Connections at any layer. Similarly for Routes, where the unique delimiting scope is their priority.
This model is backward compatible with current definition.
In the slide below is shown the parallelism between ConnectivityService and SubordinateConnectivityService, and between CSEP and SubordinateCsep. Considering the original proposal by Stephane St-Laurent (otcc2019.SSL.002.TAPI ConnectivityMediaModel.pptx) where ConnectivityService is recursively reused to provide "connection" constraints, the key point regards the availability of Service Interface Points. In other words, it is possible to specify more detailed constraints reusing ConnectivityService if SIPs are available also in "the middle" of the network - i.e. the server provides the information of all available "points of service" (for connectivity, OAM, resiliency, etc.). Traditionally the SIPs are available at the UNI or ENNI demarcation points, which are more related to geographical/administrative boundaries. In the otcc2019.AM.002-Multilayer_Scenarios.pptx has been proposed "internal" SIPs for infrastructure trails, to allow the provisioning - through ConnectivityService - of the network infrastructure (e.g. ODU4 trails).
Two possible options:
everything as a service: SIPs are supplied for any possible management feature
could be unpractical, e.g. OAM could be available on vast majority of "points" in the network
could apply to protection schemes supported by specific/costly hardware
constraints can be provisioned on available "resources", e.g. Nodes, NEPs.
easier but less clean, model is nearly duplicated:
Nigel Davis to be specified the lifecycle of "subordinate connectivity services", e.g. is the supporting trail(s) removed when supported service is removed?
Malcolm Betts recalls that TAPI is designed for application at different levels of management, hence is reasonable to include both "opaque view" and "detailed constraining" modes of operation.
Jonathan Sadler it is possible to provision a ConnectivityService in "opaque view" mode, i.e. just end points, layer, capacity, but in a subsequent time update it to modify the route, specifying detailed constraints.
Hing-Kam Lam shall the pointers to routing/resilience/topology constraints remain in ConnectivityService class? Andrea Mazzini agree that may be redundant (but backward compatible). If all these pointers are moved to SubordinateConnectivityService, then this object must always be included in case such constraints are specified - even at ConnectivityService level only. In this light, the SubordinateConnectivityService class could be renamed, e.g. LayeredConstraints.
