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

["Adrian Farrel" <[e-mail]>]

> Oh, sorry I didn't realise you were skiing in the same places.

No way you could have known without stalking me on Twitter.

> You were probably skiing too fast past me for us to notice each other

Doppler shift?
Actually, I am getting old ☹
    
>> 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.
>
> Please tell me more about these payments to people in various 
> TEAS roles ( I feel like I may have missed out on something (

Technical advisor gets paid 37.2% of what WG chair gets paid.

>> 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).

That's fine except to note that the enhanced VPN framework (attempts to) does exactly that. I.e., provide definitions and concepts and point to existing tools.

> It is not a failure if we don't have to do much work!

Oh, I thought we were paid per line of Internet-Draft that we wrote.

> (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.

I guess I am asking that the definitions and concepts in VPN+ are brought to play and wheels are not re-invented. Obviously, if the VPN+ work turns out to be considerably in a different direction, then this is fine, but if the difference is minor, then we should work on fixing VPN+ not having two similar but different sets of terms and concepts.

> 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". 

Yes, I had noticed that. In fact, both of the slicing-related BoFs were rich with that behaviour.

> 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)

That sounds good. Thanks.

Although, is "hot feature label" itself a hot feature label?

Best,
Adrian