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

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

Hi,

Comments inline

Yours Irrespectively,

John



Juniper Business Use Only
From: Eric Gray <eric.gray=[e-mail]>
Sent: Friday, January 10, 2020 11:14 AM
To: John E Drake <[e-mail]>; [e-mail]; Jari Arkko <[e-mail]>; [e-mail]
Cc: Stewart Bryant <[e-mail]>
Subject: RE: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Jari,

I suspect that John is actually trying to push his draft (https://tools.ietf.org/html/draft-drake-bess-enhanced-vpn<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-drake-bess-enhanced-vpn__;!!NEt6yMaO-gk!SHWVe4w7S8QvkMMwLrdbWtdekvheKaZzHJRRj7gur71FVzqwSrG_JIRmOZr76lc$>) rather than the base VPN+ draft (https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-teas-enhanced-vpn__;!!NEt6yMaO-gk!SHWVe4w7S8QvkMMwLrdbWtdekvheKaZzHJRRj7gur71FVzqwSrG_JIRmVzPMr7E$>) – and I just pointed out to him that his draft actually seems to say the exact opposite of what he has been saying on the TEAS-NS-DT mailing list.  That is, he has been trying to argue that a NS provides the underlay network, while his draft says a NS is an overlay.

[JD]  I would appreciate it if you did not put words in my mouth.  There is one piece of errant text in the draft, for which Adrian will be disciplined, which mentions overlay networks.  The main thrust of the draft, which is consistent with the VPN+ draft is:   “ That is, each network slice, VPN, or set of VPNs gets a subset, either dedicated or shared, of the resources in the underlay network.”

What I was proposing in my emails yesterday was an evolution of this, viz:

The current definition of a network slice is, I think, an underlay network MP2MP connection between a set of endpoints with an SLO which is met between any pair of endpoints.  What I think we can then say is that a variety of services are provided to those endpoints.  I.e., a network slice is strictly an underlay network construct over which a variety of overlay network services are offered to individual tenants.  Currently, the IETF defines overlay network services such as EVPN, L3VPN, and SFC (either separately or in combination), but this underlay/overlay separation would allow us to easily incorporate other services including those that are 5G specific.

I.e.,  a network slice is an underlay network construct that is used by overlay networks such as VPNs, SFCs, and any other services we define.

Both drafts assume an overly simplistic view of the relationship between VPNs and Network Slices, though his draft recognizes that there is not a 1:1 correspondence.

His draft deals with “isolation” in a slightly more palatable way.  It is also a “framework” draft that bears a closer look in the NS-DT.

--
Eric

From: Eric Gray
Sent: Friday, January 10, 2020 10:33 AM
To: John E Drake <jdrake=[e-mail]<mailto:jdrake=[e-mail]>>; [e-mail]<mailto:[e-mail]>; Jari Arkko <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Stewart Bryant <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work


Hi John,



              It looks like you may have forgotten to add Stewart to the CC list; I did that in this reply, in case he is not already on the TEAS-NS-DT mailing list.



              I couldn't really be sure from the tail-thread in your mail exactly what Adrian said.  I was looking for something in what he said that implied that Network Slicing as an "underlay network" is what we should be focusing on.  So I went back to his actual mail reply to Jari, which is what you replied to below.



              Rather than repeat what Adrian said in his most recent reply, I am going to highlight it in your mail below.  Apologies to anyone whose mail browser doesn’t support HTML.



              Having done that, I see nothing (so far) that implies anything nearly as technical as what you suggest – unless it is subtly embedded in some unshared understanding of the VPN+ work.



So, I went back further to the E-Mail Adrian sent initially that both Jari and I replied to.  Similarly to the other mail, rather than repeat it, I am highlighting that earlier mail in your mail below as well.



The only technical part in that mail is the part that says:



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.



              If that is the basis for your view, I have a few issues with that.

  1.  First of all, trying to derive an overlay/underlay relationship for Network Slices from this statement seems quite a large stretch.
  2.  Being “very much like a VPN” is not the same as being exactly like a VPN, whether enhanced or not.  Operators may wish to carry several network slices over a single VPN (if certain SLOs are similar for those network slices), or each network slice over different VPNs (if that is needed in order to meet possibly conflicting SLOs), or any subset or combination of either or both.  Scaling is very likely to be a driving consideration.
  3.  While it is almost certainly the case that a Network Slice is an underlay used to carry some application’s traffic, I very much disagree that this is an area that this NS-DT should focus on.  Applications (such  as 5G) dictate connectivity and other requirements that apply to each Network Slice and what we need to describe is how the behavioral requirements associated with each Network Slice can be mapped to a set of SLOs for a Transport (Network) Slice such that the transport service can support the requirements of the Network Slices.
  4.  In this sense, Transport (Network) Slices provide the virtual network connectivity and services over an underlay network.
  5.  Hence the focus of the NS-BT work should be on the requirements for carrying network slices over IETF-defined networks – without explicitly binding the management needed and the services thus provided to any specific technology.



--

Eric



-----Original Message-----
From: Teas-ns-dt <[e-mail]<mailto:[e-mail]>> On Behalf Of John E Drake
Sent: Thursday, January 9, 2020 3:15 PM
To: [e-mail]<mailto:[e-mail]>; Jari Arkko <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Adrian

> Farrel

> Sent: Thursday, January 9, 2020 2:06 PM

> To: 'Jari Arkko' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[e-mail]>

> https://protect2.fireeye.com/v1/url?k=e5f72a64-b97ef16b-e5f76aff-0cc47<https://urldefense.com/v3/__https:/protect2.fireeye.com/v1/url?k=e5f72a64-b97ef16b-e5f76aff-0cc47__;!!NEt6yMaO-gk!SHWVe4w7S8QvkMMwLrdbWtdekvheKaZzHJRRj7gur71FVzqwSrG_JIRmTjgopv0$>

> ad93e1a-9551d273f14dac89&q=1&e=eb6faec2-fb36-4d38-b496-132bb09449a0&u=

> https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmai

> lman%2Flistinfo%2Fteas-ns-

> dt__;!!NEt6yMaO-

> gk!XjoY6jVt8eF7ggCzvg3UFYRcEYmIo8AMsRvMwcvU2PeHAQwxX2qnI7WA4cTRj

> dc$

--

Teas-ns-dt mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/teas-ns-dt__;!!NEt6yMaO-gk!SHWVe4w7S8QvkMMwLrdbWtdekvheKaZzHJRRj7gur71FVzqwSrG_JIRmpRkVIZs$>