Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Date

Attendees

Goals

Discussion items

5 minsAdministrative

Next Review Call:  osing OIMT slots D and E.


1TAPI 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.


2RESTCONF

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.

  • Arturo Mayoralwill add a dedicated section "Protocol Performance Considerations".

3TR-527

Agreed that TR-527 needs to be updated, as a part of TAPI 2.4 plan regarding documentation enhancement, see TAPI Roadmap.


4

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.

5Notification

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):

  1. TAPI implementation is not restricted to YANG, e.g. could also be Open API
  2. Backward compatibility, at most the RPC can be removed in version 3.0

6OTSiG and OTSiAAgreed to use only OTSiA in the document, as OTSiG appears redundant for management purposes.

7Transitional Link

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.


8NEP PoolAgreed to postpone the discussion, TAPI model needs some enhancements.

9Node Rule GroupAs 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.

10PHOTONIC_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.


11OTS layer

Agreed that OTS PhotonicLayerQualifier is not applied to the document. The idea is to collapse

  • physical
  • OTS
  • OMS

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.


12ConnectivityService 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_supportedClientLinkCurrent 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.

14_lowerConnection

Agreed that TAPI definition regards only partitioning (see comment on _lowerConnection property of Connection)

Further discussion on Top Connection postponed to detailed review of Use Cases.


15to be continued
























Action items

  •  





  • No labels