Next Review Call: osing using OIMT slots D and E.
|0||Introduction to the document|
Arturo Mayoral presents the document and its scope:
|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 possibly "temporary" fork.
General agreement on possible performance issues.
Arturo Mayoral clarifies that the focus of the document is more on the way a 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 may be 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.
SIP is editable only to change its Administrative State, according to a MEF original requirement.
Agreed to remove the option to use the RPC create-notification-subscription-service, leaving as only option the standard RESTCONF notification subscription mechanism. Agreed that RESCONF RESTCONF notification mechanism is/will be a common industry choice.
Nevertherless agreed to keep the RPC in the TAPI UML, because (as Karthik Sethuraman) suggests:
|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 |
Given that 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 useful for filtering feature but 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 Links and OMS links and NEP/CEP at OTS and OMS layers, 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.
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 definition is postponed to the detailed review of Use Cases.
Agreement to revisit "184.108.40.206 Option B: Per layer top-connection modelling without inter-layer referencing" as follows: