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

[Eric Gray <[e-mail]>]

Reza,

              Thanks for this reply.  See my comment(s) about your explanation, below.  Note that I have cut out the pieces where we have agreement…

--
Eric

From: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
Sent: Monday, February 24, 2020 8:49 PM
To: Eric Gray <[e-mail]>om>; Eric Gray <eric.gray=[e-mail]>rg>; Jari Arkko <jari.arkko=[e-mail]>rg>; [e-mail]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
Subject: Re: Pull-request #8: Reza’s proposed text addition to the controller section
Importance: High

See inline for my comments.

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

Reza

--- [ SNIP ] ---


    * 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

I strongly suspect that this figure is at the crux of the confusion.
In one possible view, one might assume that the higher-level controller (or application) asks the TSC to connect a gNB to a UPF.  In this view, the TSC needs to determine which ER is connected to the correct gNB and which ER is connected to the correct UPF – hence the need to “find the Service endpoints” (because this view assume the service end-points are the edge routers).

This becomes slightly more understandable, if we assume that the higher-level controller actually asks for a Transport Slice connection from one IP (Ethernet, Geneve, etc.) addressed end-point to another – without specifying what these end points are as logical RAN/Core Mobility functions (TMI for the TSC).

But that is simply one view, and – IMO – a view that borrows complexity.

In another view (or way of looking at it), the higher-level entity asks the TSC to connect two or more addressable entities providing both connectivity and SLO parameters, where (at least from the perspective of the higher-level entity, the service terminates at each of the addressable entities included in the request to the TSC.  In this view, the links connecting any ER in the transport service  to the specific entities are part of the requested service – hence any edge router involvement is within the service, not a termination point for the service.  Also, in this view, “finding” the appropriate edge router is not any different from finding the path (or route) for the connection.  This applies during creation of, maintenance or and deletion of the Slice – hence this view is actually the simplest one to use in discussion.  Also note that this view may be significantly more correct, in any case where any specific connected entity may be reached via more than one link.

Treating the slice end points as if they are distinct from the service endpoints is an arbitrary, complicating and possibly outright incorrect distinction.

Finally, I don’t really care about the “abstract topology” part but I do not see that it adds any value.

  --- [ SNIP ] ---