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

["Dongjie (Jimmy)" <[e-mail]>]

Agree that some explanation about the terms would be needed.

It seems a little odd that the “transport slice endpoints” refers to the nodes “gNB, UPF…” which are outside the transport domain, while the “service endpoints” are actually the nodes which are the border nodes of the transport network.

Best regards,
Jie

From: Teas-ns-dt [mailto:[e-mail]] On Behalf Of Eric Gray
Sent: Tuesday, February 25, 2020 10:40 PM
To: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>om>; Jari Arkko <[e-mail]>om>; [e-mail]
Subject: Re: [Teas-ns-dt] Pull-request #8: Reza’s proposed text addition to the controller section

I agree that more explanation is needed somewhere.  For one thing, we need to agree on the definition for “Service Endpoints” (and whether ot not they are – or can be – distinct from slice end points.

I suspect that this needs to be handled in the definitions draft.  See also my detailed comments in separate mail – which address a disconnect in the figure you used in your explanation…

From: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 25, 2020 8:45 AM
To: Jari Arkko <[e-mail]<mailto:[e-mail]>>; Eric Gray <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]<mailto:[e-mail]>>
Subject: Re: Pull-request #8: Reza’s proposed text addition to the controller section
Importance: High

Jari,
My response is inline.

Reza



From: Jari Arkko <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 25, 2020 at 11:20 AM
To: Reza Rokui <[e-mail]<mailto:[e-mail]>>, Eric Gray <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Pull-request #8: Reza’s proposed text addition to the controller section

FWIW, I’m happy with the conclusions your Reza and Eric drew. But this one requires further thinking:

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

Jari: I think this is still confusing, at least to me. From what I can understand there needs to be two things:


  *   At the NBI, the requester needs to tell the controller what endpoints it wants the transport slice to be connecting. This I think we already say. So, for instance, I want this virtual ethernet in this computer connected with a transport slice Slice1 at 10 gbit/s with another virtual ethernet in that other computer.
  *   The controller needs to maintain an internal mapping of how a given slice is realized, so that, for instance, Slice1 in the first computer corresponds to VLAN 123 on physical interface ethx on that computer, switch configuration for VLAN 123, and again VLAN 123 and physical interface ethy on the second computer.

But I’m confused whether your text above talks about the first or the second bullet. In fact it seems to talk about some other function, where the controller somehow analyses abstract topologies to find some endpoints… why? Sorry, maybe not enough caffeinated drinks this morning but I don’t understand ☹

Maybe this would work better:

The controller maintains the connections of the transport slice to the endpoints specified by the consumer. In addition, it will keep track of how communication from those endpoints is mapped to specific underlying components of the realization of the transport slice (such as VPN tunnel endpoints or MPLS labels).

[Reza] It is mainly option 2 above. I am fine with your text Jari but it definitely needs more explanations somewhere either in this draft or other drafts. This is basically related to Section-6 of the original Definition draft which was removed. At that time we wanted to include them in Framework draft.

Jari