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

[John E Drake <[e-mail]>]

Hi (and copying Stewart),

My crossing email w/ the annotations seems to be in line w/ what Adrian is saying in his email, below, viz, treat network slicing as an underlay network construct, move all of the underlay network specific material from the VPN+ draft to the network slicing framework draft, and recast the VPN+ draft as describing how EVPN, L3VPN, and SFC (either alone or in combination) overlay network services make use of network slicing.  

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: Teas-ns-dt <[e-mail]> On Behalf Of Adrian Farrel
> Sent: Thursday, January 9, 2020 2:06 PM
> To: 'Jari Arkko' <[e-mail]>om>; [e-mail]
> Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with
> existing TEAS work
> 
> > 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
> 
> 
> 
> 
> --
> Teas-ns-dt mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas-ns-
> dt__;!!NEt6yMaO-
> gk!XjoY6jVt8eF7ggCzvg3UFYRcEYmIo8AMsRvMwcvU2PeHAQwxX2qnI7WA4cTRj
> dc$