Next Review Call: osing OIMT slots D and E.
|1||TAPI Delivery plan|
Arturo Mayoral asks for a plan of 2.1.3 delivery, for further discussion as it would be better to avoid adding many features to a "temporary" fork.
General agreement on possible performance issues.
Arturo Mayoral clarifies that the focus of the document is more on the way Server organizes its network model, rather than on implementation details of the API.
Pedro Amaral, as far as this is a "Reference Implementation Agreement" document, API implementations are in the scope.
Agreed that TR-527 needs to be updated, as a part of TAPI 2.4 plan regarding documentation enhancement, see TAPI Roadmap.
Table 3: Minimum subset required of TAPI RESTCONF Data API
|Agreed that only ConnectivityService allows "write" operations (POST, PUT, PATCH, DELETE). All other entities are GET only.|
Agreed to remove the option to use the RPC create-notification-subscription-service, leaving only option the standard RESTCONF notification subscription mechanism. Agreed that RESCONF notification mechanism is a common industry choice.
Nevertherless agreed to keep the RPC in the TAPI UML, because (Karthik Sethuraman):
|6||OTSiG and OTSiA||Agreed to use only OTSiA in the document, as OTSiG appears redundant for management purposes.|
Besides Transitional Link, this version of the document introduces an alternative model for the OTSi - ODU transition, the multi layer Node, where OTSi CEP will have ODU NEP as client-node-edge-point.
Nigel Davis asks whether Client Controller shall potentially manage both options, answer is yes.
|8||NEP Pool||Agreed to postpone the discussion, TAPI model needs some enhancements.|
|9||Node Rule Group||As far as the specified Use Cases do not foresee path computation by Client (i.e. Client always delegates routing to the Server), it is agreed that Node Rule Group feature is simply not applicable. Agreed to leave it as optional feature. Also noted that in "flat topology", the Node Rule Group cannot apply to whole network, as there is no "network" Node defined.|
|10||PHOTONIC_MEDIA split into "MEDIA" and "OTSi"|
Agreed that the proposed change (https://github.com/OpenNetworkingFoundation/TAPI/issues/455) is currently outside the scope of the document.
Agreed that OTS PhotonicLayerQualifier is not applied to the document. The idea is to collapse
in a single layer qualifier, for now reusing OMS for backward compatibility. This will avoid duplication of OTS and OMS links and NEP/CEP, while moving the related, layered monitoring functions to dedicated OAM classes like MEP and MIP.
|12||ConnectivityService and Connections|
Agreed that a ConnectivityService MUST always include a reference to a supporting Connection. Transient conditions are not considered.
Agreed to explicitly exclude the "pure opaque view" option, where only SIP and ConnectivityServices are shown and topology is not included.
|13||_supportedClientLink||Current definition of Connection foresees a 1 to 0, 1 or many supported client links, which seems wrong, because a Trail always support one and only one Link. Discussion postponed.|
Agreed that TAPI definition regards only partitioning (see comment on _lowerConnection property of Connection).
Further discussion on Top Connection definitions is postponed to detailed review of Use Cases.
Agreement to revisit "18.104.22.168 Option B: Per layer top-connection modelling without inter-layer referencing" as follows: