Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section

[Eric Gray <[e-mail]>]

Jari, et al,

My annotations below.  The “key” is as follows:

Red text, highlighted in Yellow should not be included (as is) at all.
Text highlighted in Cyan needs significant rewording to be included.

See Purple (Bold/Italic) text for explanation.

Note: an ongoing issue – raised on the list earlier – with at least a few of these contributions has to do with the “presumption” of the existence of an SBI that the TSC maps explicitly to.  The issue with this is that – if we do not allow at least a possibility that the TSC is an entirely proprietary implementation – then we are definitely getting ahead of ourselves.

We are (not yet) being asked to define a “standard TSC.”

Consequently, it is certainly within the realm of possibility that any such “proprietary implementation” will use the NBI of lower-level entities (a YANG model for virtual or physical devices, for example) it is a long way too presumptuous to assume that the TSC will offer an corresponding SBI – even for this case.  It is also likely that a proprietary TSC implementation may manage some subset of logical/physical devices using some non-standard interface – or might even be collocated with one or more logical/physical network entities.

From: Teas-ns-dt <[e-mail]> On Behalf Of Jari Arkko
Sent: Sunday, February 23, 2020 3:10 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
Cc: [e-mail]
Subject: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section

This email concerns Pull-request #8: Reza’s proposed text addition to
the controller section. This review is again a personal review, not
holding any hats, just providing my opinion.

This is overall good text and relatively ready for inclusion.

I really liked the way that the section explained not just
the initial mapping but the mapping of telemetry etc. Good work!

There are some places where one can cut a bit unnecessary text, and a few
sentences where a more matter-of-fact style would work better in an
IETF document. I also think we need to be careful in not making the
controller section too long. It may be useful to add some specific
discussions elsewhere under the considerations section of the
framework document. And some discussions may not  be needed
in this document, in my opinion, such as the part about closed loop
optimizations - that's an important topic but we don't need to talk about
it to explain the framework. And I don't think we want to get to the
discussion of e2e slices. Transport slices are components of those,
but we can leave  it at that.

I also wondered how well the controller and mapping sections
complement each other; the editors should probably do a pass to ensure
that each section has the right content. Eric, John: feel free to move
text around if it fits better the other section!

I left a few TODOs in the text that I'd propose we use. There were
a couple of unclear points, mostly related to concepts not introduced
earlier and/or whose need to be included was unclear to me.

I'd use this text, edited from Reza's original:

# Transport Slice Controller (TSC)

    The transport slice controller takes abstract requests for
    transport slices and implements them using a suitable underlying
    technology.  A transport slice controller is the key building
    block for control and management of the transport slice.  It
    provides the creation/modification/deletion, monitoring and
    optimization of transport Slices in a multi-domain, a
    multi-technology and multi-vendor environment.

    The controller provides the following functions:

    * Provides a technology-agnostic NBI for creation/modification/
      deletion of the transport slices.  The attributes of this
      interface will be discussed in section sssss.  In summary, the
      API exposed by this NBI communicates the endpoints of the
      transport slice, transport slice SLO, various policies, and
      provides a way to monitor the slice.

EG > We should not include text that attempts to point to other text that does not yet exist, and this is a bullet and should not include a “summary.”

    * Using the network abstract topology, it provides mechanism to find
      the Service endpoints (these are technology specific).
      (TODO: this seems unclear. What endpoints are these, are why
      are they different from endpoints discussed earlier?)

EG > Obviously.  IMO, the requesting application (higher-level controller, for example) MUST specify the end-points for the transport service, at least using some abstraction (e.g. – name), and the precise technology of the connecting interface.  This is fairly obvious as the request is based on some knowledge about what is connecting to the Transport Slice at each end that the TSC controller cannot know a priori.  Since this information MUST be in the “API” request, there should be nothing for the TSC to “discover.”

    * Provides "Mapping Functions" for realization of transport slices.
      In other words, it will use the mapping functions which map
      technology-agnostic NBI request to technology-specific SBIs.

EG > This “restatement” adds no value, and refers to a presumed “SBI” – which we should not include here (see general observation at the top of this mail).

    * On its southbound interface, the controller monitors Telemetry
      data (e.g.  OAM results, Statistics, States etc.) for all
      technology-specific services/paths/tunnels which are used to
      realize the transport slice.

EG > Again refers to a presumed SBI.  This might be restated as a function the TSC provides relative to the devices and connections used in its abstract topology.

    * Aggregates all the Telemetry data of underlying realization of a
      transport slice (i.e. services/paths/tunnels) and calculate the
      current "Transport Slice SLO" and exposes them to "Higher level
      system" through its NBI.  It also raises a notification in case
      the transport slice is out of SLO.

EG > The highlighted text needs re-wording; the TSC will – under no circumstances – be expected to “calculate [any] SLO” but would instead be given the parameters that MUST be met.  Similarly, the TSC MUST be given “threshold values” at which a notification to the “higher level system” (application, etc.) would be provided – or no such notification should be expected.  The TSC itself is almost certainly not in a position to determine this information, and a notification of an out of SLO condition is too late to be useful (it is not typically something a service provider wants, simply because – instead of proactively warning when the out of SLO condition may soon arise – it instead provides a notification when the provider is obligated to pay a penalty for being out of contract).

    * Provides the abstract network topology and in specific the "inter-
      domain" links between multiple network domains.
      (TODO: This is unclear, at least to me.)

EG > As currently worded, it is more than unclear – it is wrong. While it is true that the TSC will likely create an abstract topology, to meet the requested connectivity and service requirements, an NBI would describe only the connectivity and service requirements.  In order for the user of the NBI to construct an “abstract topology” it would need to be privy to an inappropriate amount of information about the underlying transport network.  Note that the NBI would need to be able to inform the requesting higher-level entity when it cannot provide some service or connectivity requested in sufficient detail to allow the higher-level entity the flexibility to make a modified request – but the level of detail MUST NOT include specific topological restrictions (beyond “requested connectivity to X” cannot be provided, or “service Y cannot be provided in connecting end-point ‘p’ to end-point ‘q’).  If the intent in this wording is that – by “topology” – what is meant is “the connectivity and service requirements” then this should be explicitly stated.