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

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

Hi Phil.

Thanks for your feedback.
My responses are inline.

Reza



From: Teas <[e-mail]> on behalf of "[e-mail]" <[e-mail]>
Date: Thursday, November 7, 2019 at 4:47 PM
To: "[e-mail]" <[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.


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.

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.

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.

[cid:image001.png@01D598B7.1F956820]

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

Best wishes,
phil