Child pages
  • 2021-07-05..09 Review week of TR-547 - Meeting Notes
Skip to end of metadata
Go to start of metadata

Date

-  

Attendees

Goals

Agreed Items & Priority

  • Priority on UC applicable to TAPI 2.1.3
  • Consider also OAM UC applicable to TAPI 2.1.3 possibly avoiding disruptions wrt TAPI 2.3 OAM management

Discussion items

Monday
60 minsGeneral

All



Empty lists, agreed general expected behavior:

  • In case of empty list, it is not expected to get the empty [ ] notation, simply the empty list does not exist.
  • Similarly for container which includes only empty list(s), the container does not exist.
    • E.g. cep-list does not augment the NEP if no CEP instances are supported.
    • E.g. connectivity-context does not augment tapi-context if neither CS nor Connections are present.
  • Otherwise introduce "presence" statement to force the presence of even empty containers:
    • E.g. for lifecycle consideration, it is expected that the list will not always be empty.
  • Another option is that Client is required to manage both cases, i.e. empty list either missing or anyway present.
  • Preliminary agreement that all the GET on list are intended C - Conditional if empty.
45 mins

UC 0a

Context & Service Interface Points discovery (polling mode)

All

Clarification regarding NetworkTopologyService class:

  • Its purpose is to identify the subset of Topology instances which are relevant for management (i.e. where CS can be provisioned).
    • If agreed add comment in the UML - rediscussed on Tuesday, agreed that current comment is correct:
      • "A NetworkTopologyService represents an "intent-like" request for topology related provisioning, for future developments. The NetworkTopologyService is a container for topology request details and is distinct from the Topology that realize the request."

  • Multi-layer SIP is not foreseen by the model.
    • Option could be to have more single-layer SIP instances per same multi-layer NEP instance, for further study.

RW/RO, PowerManagementCapabilityPac is RW in UML - which seems not correct - check/amend TAPI 2.3 - agreed on Tuesday, all attributes now RO.

45 mins

UC 0b

Topology discovery (synchronous mode)

All

The GET loop seems not strictly necessary (sort of flow control on Client side).

  • Added a note, Restconf should allow "bulk" retrieval.

Inconsistency between workflow diagram and general rule regarding the GET of lists:

  • The GET in the diagram should be as per Table 3:
    • GET /restconf/data/api-common:context/tapi-tapology:topology-context/nw-topology-service?fields=topology
Tuesday

Multi-layer connectivity service provisioning and connection generation

All

Question on which Top Connections shall be included in the ConnectivityService list.

  • Arturo, the idea was to stop at MC layer, because server Connections at OTS/OMS layer follow same route (but in case of OLP/OMS protection schemes).
  • Arturo also clarifies that navigating from OTSi Connection to MC Connection is complex, because of disaggregated model, i.e. the case of the theoretical Link connecting the OTSi NEP (on line side of transponder) and the MC NEP (on add/drop side of ROADM).

Added the note:

  • NOTE: This RIA does not require the inclusion the OMS/OTS objects in the list of connections that are listed in the connectivity service.

CS UUID provisioningAll

The general agreement is that CS UUID is provisioned by the Client - as specified by Restconf.

  • Agreed that in case of CS autonomously created by Server (to support provisioned CS) its UUID is assigned by the Server.
  • Agreed to remove the following requirements, too vague:
    • TAPI-CONN-MODEL-REQ-21: The Connectivity Service (CS) provisioning can cause the creation of server Connectivity Services. As a general rule, a   CS will be created for each supporting Top Connection, to allow editing of all network layers. E.g., a   DSR CS provisioning will cause the creation of: 1.DSR Top Connection, 2.ODU4 CS and its ODU4 Top Connection, 3.OTSi CS and its OTSi Top Connection, 4.MC CS and its MC Top Connection.
    • TAPI-CONN-MODEL-REQ-22: The deletion of a   CS does not imply the deletion of any server CS (controlled behavior). This allows to reuse CS as routing constraints of new client CS. For further evaluation a possible exception in case e.g., no multiplexing, deletion of DSR 10G CS may imply deletion of unique, dedicated server ODU2 CS.
  • Being replaced by the note:
    • NOTE: Lifetime issues and interactions between client and server connectivity services will be addressed in a subsequent version of this RIA specification. The current version does not mandate any specific behavior other than the one specified in REQ-23:
      • The deletion of a CS is rejected if any client CS exists. Further versions of T-API MAY add a in-use state to the Connectivity Service object.
  • Note that there are UCs where the provisioning of server layer constraints makes complex the creation of server CSs. For further discussion.

UC 0b

Topology discovery (synchronous mode)

All

Wrong comment of the list of layer protocol names of a Link (now in 2.3 UML is "The layer protocol(s) of the Link"). Agreed to add the following note in the RIA:

  • Minimum list size is 1. Unless specified otherwise this RIA assumes that a given link has only ONE layer protocol name.

Agreed to add this note to Link direction:

  • NOTE: TAPI v2.1.3 description "Is applicable to simple Links where all LinkEnds are BIDIRECTIONAL (the Link will be BIDIRECTIONAL) or UNIDIRECTIONAL (the Link will be UNIDIRECTIONAL)" is deprecated (TAPI 2.3 UML updated).
  • The agreement is to allow alternatives like:
    • 2 unidirectional Links between 2 bidirectional NEPs
    • 1 bidirectional Link between 4 unidirectional NEPs

UC 0c

Connectivity Service discovery (synchronous mode)

All

Similar issue in the workflow as UC 0b above.

  • The workflow will be amended.

UC 0d

Multi-domain OTN interdomain links discovery (Plug-id based on OTN TTI)

AllSome discussion, continued in the TAPI call, see 2021-07-06 TAPI Meeting Notes
Wednesday

Layering, PartitioningAll

Discussion on "Lower Connections of a Connection" and "Connections of a ConnectivityService".

  • "Lower Connections of a Connection" is partitioning, i.e. within same layer rate and qualifier.
  • "Connections of a ConnectivityService" shall include all Top Connections at all server layers.
    • OMS/OTS Top Connections have not been discussed so far. It is allowed to not list them.
    • Nigel Davis proposal:
      • the long term solution is that a connectivity service MUST provide one-way-navigable references to:

        • all top level connections at the layer of the service that were created as a result of the connectivity-service creation
        • any other top level connections (at other layers) created as a result of the service (that have no other related connectivity-service (accounting for creation of multiple connectivity-services triggered by a single connectivity-service request))
      • The connectivity-service could (but really should not) provide one-way-navigable references to connections that were already in place as a result of other connectivity services (or other intent, e.g., OMS which does not have a connectivity-service although it clearly has an intent (this appears to be a problem in itself)).

    • Andrea Mazzini post meeting note: currently there is not any explicit relationship between a CS and the CSs created as side effect.

Other minor corrections.


PlanAll

We are proceeding slowly - but a detailed review is anyway necessary.

  • Next couple of weeks Andrea Mazzini is not available, we plan another week of calls starting on July 26. Maybe 3 hours per day...
  • Target is to deliver by end of July/first week of August.