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

["Rokui, Reza (Nokia - CA/Ottawa)" <[e-mail]>]

See inline for my comments.

Note that my responses are for final Green re-wording statements which goes to the draft.

Reza



From: Eric Gray <[e-mail]>
Date: Monday, February 24, 2020 at 6:34 PM
To: Eric Gray <eric.gray=[e-mail]>rg>, Jari Arkko <jari.arkko=[e-mail]>rg>, Reza Rokui <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: RE: Pull-request #8: Reza’s proposed text addition to the controller section

I provide suggested re-wording below.

From: Teas-ns-dt <[e-mail]> On Behalf Of Eric Gray
Sent: Monday, February 24, 2020 8:36 AM
To: Jari Arkko <jari.arkko=[e-mail]>rg>; Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
Cc: [e-mail]
Subject: Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section

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.

Note: As discussed during the meeting today, we agree that – as long as we are referring to a logical south-bound interface (that may or may not actually exist), then we can use “SBI” as a way to avoid having to refer to an unnamed concept along the lines of “whatever it is that the TSC maps service and connectivity requests to virtual or physical devices and connections.”  We need to verify that this is consistent with the wording in the definitions draft.

[Reza] Agreed


From: Teas-ns-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of Jari Arkko
Sent: Sunday, February 23, 2020 3:10 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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.”

Rewording:

  *   Provides a technology-agnostic NBI for creation/modification/deletion of transport slices. The NBI communicates the endpoints of the transport slice, transport slice SLO, and applicable policies, and provides a way to monitor slices.

[Reza] Agreed


    * 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.”

Rewording:

  *   Provides requested services and endpoint connectivity.

[Reza] Modified rewording:

  *   Using the abstract topology of the interconnected networks and provided transport slice endpoints , it will find the Service endpoints.

Explanation:
The concept is shown in our  original Definition draft which later has been removed due to number of pages of the draft to be included in framework draft (or other drafts).
This picture is for 5G use-case but demonstrates the idea.
In summary, the transport slice request is between “transport slice endpoints” gNB1, gNB2, UPF1, UPF2 and UPF3 where the realization of this transport slice is between “service endpoints” ER1, ER2 and ER3.
So, it is clear that the “transport slice endpoints” are different from  “service endpoints”.


                        | Create Transport slice 20 between “transport slice endpoints” gNB1 & gNB2
                        | to UPF1 & UPF2 & UPF3  with SLO  latency
                        | 10 ms or better
                        v
       +---------------------------------------------+
       |Operator-Y Transport Slice Controller (TSC)  |
       +---------------------------------------------+
                        | Implement (Realize) transport slice 20
                        | between “Service endpoints” ER1, ER2 and ER3 with SLA latency
                        | 10 ms  or  better
                        v                          +----+
                      .----.                       +UPF1|
    [gNB1] +----+    (      )---.                 /+--=-+
         \ |    |===========================[ER2]+
          \| ER1|  (      Network       )          +----+
          /|    |===========================[ER3]+-|UPF2|
         / +----+    `----------------'         +  +----+
    [gNB2]                                       \
                                                  \+----+
                                                   +UPF3|
                                                   +----+
    Legends
      === : Tunnels & Services
      ER: Edge Router



    * 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).

Rewording:

  *   Provides a mapping function for the realization of transport slices.

[Reza] Agreed


    * 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. Note: even if we assume that SBI is a logical concept that may or may not exist, referring tot the TSC’s “southbound interface” – as a singular thing – begs the concept to have a “singular” real definition.  To illustrate this point, what does it mean to refer to the TSC southbound interface in the case where no such interface actually exists?

Rewording:

  *   The controller collects Telemetry data (e.g. OAM results, Statistics and State information, etc.)for all technology-specific services, paths, tunnels – etc. – that are used to realize the transport slice.

[Reza] Agreed

    * 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).

Rewording:

  *   Evaluates transport slice performance in comparison with the SLO parameters extant for the transport slice and exposes this aggregate information to the requesting higher-level system (or application through its NBI.  This may include notifications requested based on thresholds, policies, etc.

[Reza] Agreed with a following modification

  *   Using the collected Telemetry data for all technology-specific services, paths, tunnels, evaluates transport slice performance in comparison with the SLO parameters extant for the transport slice and exposes this aggregate information to the requesting higher-level system (or application through its NBI.  This may include notifications requested based on thresholds, policies, etc.


    * 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.

I would omit this bullet as it merely restates what has already been said in terms of “realization of transport slices.”

[Reza] Agreed