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

[John E Drake <[e-mail]>]

Hi,

Snipped, comments inline

Yours Irrespectively,

John

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 whe
re any specific connected entity may be reached via more than one link.

[JD]  I completely agree with Eric on this.  Transport endpoints are between CEs, and any PE functions, e.g., VPNs, service chains, or 5G specific functions, are part of the service offered to them.  This has been the IETF model for over twenty years.

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.

[JD]  I also agree with Eric on this.

  --- [ SNIP ] ---


Juniper Business Use Only