Re: [Teas] Comments on draft-nsdt-teas-transport-slice-definition

[<[e-mail]>]

Reza – couple of follow-ups – thanks!
phil

From: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
Sent: 11 November 2019 10:41
To: Eardley,PL,Philip,TUD1 R <[e-mail]>; [e-mail]
Cc: Rokui, Reza (Nokia - CA/Ottawa) <[e-mail]>
Subject: Re: [Teas] Comments on draft-nsdt-teas-transport-slice-definition

Hi Phil.

Thanks for your feedback.
My responses are inline.

Reza



From: Teas <[e-mail]<mailto:[e-mail]>> on behalf of "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, November 7, 2019 at 4:47 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [Teas] Comments on draft-nsdt-teas-transport-slice-definition

Hi design team,
thanks for the draft https://datatracker.ietf.org/doc/draft-nsdt-teas-transport-slice-definition/

Some comments:

I liked the later parts of the draft – less so the early parts. The examples helped illustrate about a transport slice and how it can be realised – including that there are different options for how to realise something with the same “black box” behaviour (Scenario 3 showing it can be implemented as a single slice or a hierarchy of slices) (Scenario 1 shows an edge-to-end slice is effectively a sub-component of the end-to-end slice)

One thing I didn’t like about the early part of the document is that you don’t explain the difference between a transport slice and a network slice. What is it?

For me, a slice involves 3 aspects: Performance, Connectivity, Functionality (as in VNFs etc). Your examples illustrate: Performance (10 Mbps bandwidth or < 30 msecs latency) ; Connectivity (an upload connection for all the CCTVs in new york) ; Functionality (5G RAN network functions for instance gNB, eNB). By implication of your examples, I think you’re saying that a transport slice is a type of slice that has no “functionality” aspect – it is purely about performance and a connectivity pattern. This works for me.

[Reza] That is correct. A Transport slice is a group of connections between various endpoints with specific SLA. In 5G use-case, it is also associated to specific customer (aka Tenant) and service type (e.g URLLC, CCTV etc)
For the description of e2e network slice, please refer to following draft.

https://tools.ietf.org/html/draft-rokui-5g-transport-slice-00

The following definition is taken from the draft:
In specific, E2E 5G network slices are separate independent logical network E2E from user equipment (UE) to applications in a  common infrastructure where each logical network has dedicated SLA.  It is an E2E concept which spans multiple network domains (e.g. radio, transport and core), and in some cases more than one administrative domain.

[phil] Actually my question was about the difference between a “network slice” and a “transport slice”. S1 states that a “network slice” runs to endpoints. So I don’t see any difference between their definitions.
Also, you have another term “Other slice”, with examples “5G RAN slice” and “5G Core slice”. Are these specialist sorts of network slice / transport slice? Or something different?

Figure 1 – how does the layer (?) with the OS & TS arrows relate to the layer with the network pics?
[Reza] They are independent. You can have a single networks-1 where there are multiple transport slices are created.
Or reverse. You can multiple networks-1 to network-p where a single transport slice is created across them. All depends on the use-case.

[phil] OK. I think it would be better to replace Fig 1 with a couple of pictures illustrating these different possibilities.
(Perhaps it’s just me, but I expect layers in a picture to relate to each other. For instance, the “E2E NS” arrow at the top runs between the EU_x and EU-y in the bottom layer. In a similar way, I’d expect that slices in the middle layer to relate to something in the bottom layer, to illustrate what entities the slices run between. A couple of pics could illustrate some of the range of possibilities.

Your slicing example has “city of NY” as the customer. This matches my impression that slicing is something targeted at large customers. I don’t see why this needs to be so, although it does seem to be the general assumption.

[Reza] No this is not the intention. An E2E network slice can be targeted to an Enterprise for example as well. “City of NY” is JUST an example to demonstrate the idea.

[phil] Good! (It doesn’t match my impression of what 5G is assuming.)

S3 defines a slice in terms of connecting “endpoints”. I think some care would be good here. As this isn’t (necessarily) end hosts or end users. It’s really just the ends of the virtual network.

[Reza] It is not just the end point of the virtual network as you stated. During the 5G Design team discussion, we agreed to refrain from using the team network and network function for each end of the connections. Instead we use “endpoint”. So, a transport slice is a set of distinct connection between various endpoints. See chapter 3 of the draft for definition.
As an example, a transport slice can be a set of connections between a few physical network functions (PNF).
Anther transport slice can be a set of connections between VNFs and PNFs.
Or any other examples.

Figure 10 – the example shows that slices can be hierarchical. For this to work simply, it should be the same north-bound interface for every slice. But the figure shows a different style of message coming into the orchestrator and coming into the transport slice manager/controller – they should be the same.
In my opinion it’s a critical aspect to make sure that slices can “recurse” as this makes it easier to build a system with clear lines of responsibility, allows flexibility in service provision and vendor supply, and means only a single north‐south API needs to be defined /standardised.

[Reza] As shown below, the intention was not the hierarchical transport slice but rather the number of transport slices and how the transport slice controller can trigger them.
The concept of “reuse” shall be investigated more. We can discuss this f2f next week.

[phil] What I meant was: the orchestrator is acting as a slice controller. It is receiving a request to create a slice between ER1 and ER2 with latency 30 msec. The arrow on the northbound side of the Orchestrator shouldn’t be “Requirements on communication between ER1 and ER2” but instead “Create slice between ER1 and ER2, with latency 30 [msec]”. Then the slices can recurse, ie you can have as many layers as the scenario needs, all with the same northbound interface.  Your example also illustrates that the lowest layer has technology-specific messages that reflect the actual physical technology.
I’m not going to Singapore unfortunately.

[cid:image002.png@01D5993A.31A2BF80]

Minor comments:
NVVI? DCI?
There are quite a few typos

Best wishes,
phil