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

[<[e-mail]>]

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.

Figure 1 - how does the layer (?) with the OS & TS arrows relate to the layer with the network pics?

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.

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.

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.

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

Best wishes,
phil