TAPI Roadmap 2022-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.
TAPI reference version, in the document is currently mentioned 2.1.2, the issue is how to unambiguosly identify YANG files beloging to 2.1.1/2.1.2 and now 2.1.3 (+Eqp model), as revision dates in the documents are all the same. Stephane St-Laurent provides some suggestions (Google OpenConfig "tag" for revisions).
Agreed to send an email to Karthik Sethuramanfor further help on the topic (already sent briefly after this meeting).
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 ConnectionService class allows to select a layer protocol (also at server layers) and ending NEPs / Nodes, 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.
Post meeting note: ConnectionService needs NEP/Node 1) direction, 2) role, 3) protectionRole. More in general, a structure similar to CSEP...
This model is backward compatible with current definition.
Jonathan Sadler notes that the displayed model seems a mix of service definition and service instance management items. General agreement, the current model of ConnectivityService would need a deep reorganization, but this is somehow in conflict with backward compatibility requirements (several implementations are already ongoing) and available resources.