Skip to end of metadata
Go to start of metadata




Discussion items

5 minsAdministrative

Next Review Call:  using OIMT slots D and E.

0Introduction to the document

Arturo Mayoral presents the document and its scope:

  • Developed in a 6 / 8 months timeframe.
  • Is a Reference Implementation Agreement, trying to reach the best compromise between available model definiton and implementable management solution.
  • It complements TR-527, which specifies TAPI general concepts and requirements.

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 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, API implementations may be in the scope.

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


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


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

  1. TAPI implementation is not restricted to YANG, e.g. could also be Open API
  2. Backward compatibility, at most the RPC could 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 Group

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.

10PHOTONIC_MEDIA split into "MEDIA" and "OTSi"

Agreed that the proposed change ( is useful for filtering feature but 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, and
  • OMS

in a single layer qualifier, for now reusing OMS for backward compatibility. This will avoid duplication of Links and NEP/CEP at OTS and OMS layers, 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.


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 definition is postponed to the detailed review of Use Cases.

Agreement to revisit " Option B: Per layer top-connection modelling without inter-layer referencing" as follows:

  • ConnectivityService will include the list of UUIDs of all server Connections (i.e. all Top and Infrastructure Connections at partitioning level 1, where at partitioning level 0 there are the "cross" Connections)
  • Connection will include only lower level "cross" Connections, i.e. only partitioning view.

  • Agreement to remove OTS (see also above)
  • Agreement that the model at photonic layer shall always foresee one bidirectional (N)MC ConnectivityService and three different options for the (N)MC Connections:
    1. Unidirectional (N)MC Connections, with one bidirectional NEP Pool on drop side, composed by the two unidirectional NEPs, which client CEPs resp. end the unidir (N)MC Connections.
    2. Bidirectional (N)MC Connection, with a three ended "cross" Connection between one bid CEP (drop side) and the two unidir CEPs.
    3. Bidirectional OMS

Action items