Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

[Jari Arkko <[e-mail]>]

Oh, sorry I didn't realise you were skiing in the same places. You were probably skiing too fast past me for us to notice each other (
    
>  I confess, I have not been following "your" Design Team closely. I should because I'm paid so very much to be the TEAS Technical Advisor. But I have also been overcome by the need to be in the Alps 😊

Please tell me more about these payments to people in various TEAS roles ( I feel like I may have missed out on something (

> I'm a little puzzled where the DT is going. There seems to be a lot of pulling in different directions from the members of the team with some talking about making a "Northbound Interface" for requesting/managing slices, and some talking about a framework that describes what slicing is (presumably from the perspective of the IP network and not the 5G service).

There's certainly multiple directions people want to take things, as is quite natural. But I think the northbound interface, framework, and definitions are more about the different sides of the same coin than different directions. 

Some of the pulling to different directions that we've seen involves incorporating a very narrow networking-only view of slicing vs. a more inclusive all-functions view. Or viewing TEAS slicing as a 5G oriented exercise vs. more IP network issue. Or emphasizing particular features that their favourite implementation technology can do vs. attempting to provide more boring standard features. Or perhaps most importantly, trying explain how to use current things vs. trying to create a lot of new technology so that a particular view of slicing can be provided.

But, on the background, the team has come to understand an architectural model, of having a relatively narrow and IP networking-centric transport definition for a slice, and that it fits in an architecture that involves requests (perhaps represented as an instance of a data model) sent to a controller, which maps these requests to an implementation using one or more specific implementation technologies.

> Even some of the team got so excited that they posted a "design team" draft that wasn't a design team draft!

We've talked about this -- from going forward the drafts with personal perspective will be named in a personal fashion, not draft-nsdt. 
  
> You're no doubt aware of draft-ietf-teas-enhanced-vpn. I've been trying to nurture this and direct the authors to do good things with it. The document is not a technology solution, but a set of observations and a framework that explains how the concept of a "slice" looks very much like a VPN (in that it is a connectivity service between a set of end points with some guarantee of service) but offers more specific service behaviours.
> 
> I would like not to get into an "arms race" between this draft and the output of the Design Team where each set of authors updates their document to steal turf from the other: that might produce a lot of good thought and work, but would also involve a fair bit of stress and duplicated effort. Instead there is probably some potential for synergy. But I am struggling to know exactly what the DT is intending to produce. The charter and the most recent status (in Singapore) seems to suggest that the DT is still in the phase of working out what it needs to / should document. 

I'm aware of the document, and many of our contributors are quite involved in that as well. I don't yet however have a personal view on the enhanced VPN proposal.

I do think though that it is fundamentally *not* incompatible at all that the TEAS WG might have some technology(ies) that can be used for slicing. One possible outcome of the DT work is a framework that provides definitions and concepts, and points to existing tools (not just enhanced VPN but perhaps also other underlying technologies, data models, etc). It is not a failure if we don't have to do much work! ( Another possible outcome is a that the DT does the definitions and framework, as well as some enhancements that are perceived as necessary. A third outcome is that more work is needed.

Also note that hot technologies (such as 5G, or slicing) tend to be used a lot in justifying particular proposals. "Our thing provides the hot feature that everyone is talking about". I think we should resist the temptation to go down this path a bit. Usually there are several approaches to providing a particular useful function, and slightly differing definitions of what that useful function actually is. If the enhanced VPN draft and other IETF technologies can accurately describe what function they provide in networking terms, then we are on a good path, and then other work can refer to them and say that they are sufficient for this or that function. I don't think the design team will be shy of saying that we can use a particular technology to implement slicing in the way that we perceive it, if that's the case. In fact, I think that would be a happy outcome. We certainly wouldn't start to replicate any existing or ongoing work -- that would be silly, and could seriously cut down the time available for skiing ( That being said, I also prefer that we at the IETF work on narrowly defined, technically-defined concepts that limit the number of hot feature labels that they use (

Jari