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

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

And copying Stewart

Yours Irrespectively,

John


Juniper Business Use Only

> -----Original Message-----
> From: John E Drake
> Sent: Thursday, January 9, 2020 3:15 PM
> To: [e-mail]; 'Jari Arkko' <[e-mail]>om>; teas-ns-
> [e-mail]
> Subject: RE: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with
> existing TEAS work
> 
> 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$