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.
Topology discovery (synchronous mode)
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:
Multi-layer connectivity service provisioning and connection generation
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 provisioning
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.
Topology discovery (synchronous mode)
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
Connectivity Service discovery (synchronous mode)
Similar issue in the workflow as UC 0b above.
The workflow will be amended.
Multi-domain OTN interdomain links discovery (Plug-id based on OTN TTI)
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 Mazzinipost meeting note: currently there is not any explicit relationship between a CS and the CSs created as side effect.
Other minor corrections.
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.