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

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 7 Jan 2020 09:38:34 -0000

Hi NS-DT,

I sent Jari a message way back in the last decade, but I know he has been busy skiing (curiously, on the same slopes as me, but not with me - perhaps I should have hunted him down).

I'm copying the message here to see whether anyone has any thoughts.

Thanks,
Adrian

-----Original Message-----
From: Adrian Farrel <[email-masked]> 
Sent: 27 December 2019 19:29
To: [email-masked]
Cc: [email-masked]
Subject: Progress of Slicing Design Team and overlap with existing TEAS work

Hi Jari,

Happy New Year!

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 😊

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). Even some of the team got so excited that they posted a "design team" draft that wasn't a design team draft!

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. 

Any thoughts on a way forward?

Thanks,
Adrian

---

From: Eric Gray <[email-masked]>
Date: Wed, 8 Jan 2020 16:47:14 +0000

Adrian,

              Hope you are finding the skiing good.

              I think there is a general agreement (at least in principal) that the intent should be to not go around re-inventing wheels.

              But you are correct that there is some tugging (and maybe even yanking) on the subject of goals for the DT.  Lou has even weighed in on the discussion at least once.

              I don't think there is anyone, however, who wants to duplicate the work being done on VPN+, or indulge in a turf-stealing effort in that area.

              Part of the reason for the efforts to steer the work down different avenues is because (I suspect) different folks on the DT had differing ideas about what the effort was started to achieve.  In at least a few cases, people felt that (at least some aspects of) the effort were driven by a perceived need to define how (whatever it is that we want to use for) transport (network) slices would be managed - for instance - in support of mobility service management for 3GPP defined Network Slicing.  Another example would be management for the virtual topologies that would exist as overlays in a DC, irrespective of the specific technologies (etc.) used to provide the overlay topologies (I'm sure we could all list of several candidate technologies).

              There is (I feel) agreement that there should be some sort of abstraction defined to separate the NS service requirements from the details of the underlying technology (or technologies).  Where there is not so much uniform agreement is in whether or not there is sufficient understanding in the DT of the undertake (at this time) the definition of a Northbound interface, and related information/data models, if any new ones are required, or even if it the task of this specific DT to undertake this work once there is sufficient understanding.

              And of course there is some effort in course-correction that relates to trying to steer the work toward stating a preference for (or possibly an endorsement of) specific technologies of choice (depending on who is choosing) - VPN+ for instance - to be used for transport (network) slices.

              We had made some strides in agreeing (or at least compromising) on terminology and definitions - though there is still work to do, and there is momentum to overcome (in the form of "DT drafts" that may not have used terminology and definitions consistent with the progress made).

              I am looking forward to re-starting the meetings this year and I appreciate your apparent effort to kick-off some discussion.

😊

--

Eric

-----Original Message-----
From: Teas-ns-dt <[email-masked]> On Behalf Of Adrian Farrel
Sent: Tuesday, January 7, 2020 4:39 AM
To: [email-masked]
Subject: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Hi NS-DT,

Thanks,

Adrian

-----Original Message-----

From: Adrian Farrel <[email-masked]<mailto:[email-masked]>>

To: [email-masked]<mailto:[email-masked]>

Cc: [email-masked]<mailto:[email-masked]>

Hi Jari,

Happy New Year!

Thanks,

Adrian

--

Teas-ns-dt mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/teas-ns-dt

---

From: Jari Arkko <[email-masked]>
Date: Thu, 9 Jan 2020 15:53:39 +0000

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 Alp…

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

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 9 Jan 2020 19:05:45 -0000

> 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

---

From: John E Drake <[email-masked]>
Date: Thu, 9 Jan 2020 20:14:40 +0000

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

> Sent: Thursday, January 9, 2020 2:06 PM
> To: 'Jari Arkko' <[email-masked]>; [email-masked]
> Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with
> existing TEAS work
> 
> > 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.
> >
> > 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.
> >
> > We've talked about this -- from going forward the drafts with personal
> > perspective will be named in a personal fashion, not draft-nsdt.
> 
> 😊
> 
> >> 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.
> 
> > (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".
> 
> > 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)
> 
> [email-masked]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/teas-ns-
> dt__;!!NEt6yMaO-
> gk!XjoY6jVt8eF7ggCzvg3UFYRcEYmIo8AMsRvMwcvU2PeHAQwxX2qnI7WA4cTRj
> dc$

---

From: John E Drake <[email-masked]>
Date: Thu, 9 Jan 2020 21:24:20 +0000

And copying Stewart

Yours Irrespectively,

John

> From: John E Drake
> Sent: Thursday, January 9, 2020 3:15 PM
> To: [email-masked]; 'Jari Arkko' <[email-masked]>; teas-ns-
> [email-masked]
> Subject: RE: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with
> existing TEAS work
> 
> 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
> 
> 
> > Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and
> > overlap with existing TEAS work
> >
> > >> of pulling in different directions from the members of the team
> > >> with some talking about making a "Northbound Interface" for
> > >> describes what slicing is (presumably from the perspective of the
> > >> IP network and not the 5G service).
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > 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
> > > We've talked about this -- from going forward the drafts with
> > > personal perspective will be named in a personal fashion, not draft-nsdt.
> >
> > 😊
> >
> > >> 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.
> > >>
> > >> the output of the Design Team where each set of authors updates
> > >> their document to steal turf from the
> > >> 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.
> > >
> > > involved in that as well. I don't yet however have a personal view
> > > on the enhanced VPN proposal.
> > >
> > > 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
> > > 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.
> >
> > 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.
> >
> > > used a lot in justifying particular proposals. "Our thing provides
> > > the hot feature that everyone is talking about".
> >
> > > 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)
> >

---

From: Eric Gray <[email-masked]>
Date: Fri, 10 Jan 2020 15:33:12 +0000

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 <[email-masked]> On Behalf Of John E Drake
Sent: Thursday, January 9, 2020 3:15 PM
To: [email-masked]; Jari Arkko <[email-masked]>; [email-masked]
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Yours Irrespectively,

John

> From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of Adrian

> Farrel

> To: 'Jari Arkko' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

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

> > vs. trying to create a lot of new technology so that a particular view of slicing can be provided.

> https://protect2.fireeye.com/v1/url?k=e5f72a64-b97ef16b-e5f76aff-0cc47

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

--

Teas-ns-dt mailing list

---

From: Eric Gray <[email-masked]>
Date: Fri, 10 Jan 2020 16:14:09 +0000

Jari,

I suspect that John is actually trying to push his draft (https://tools.ietf.org/html/draft-drake-bess-enhanced-vpn) rather than the base VPN+ draft (https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn) – 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.

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=[email-masked]>; [email-masked]; Jari Arkko <[email-masked]>; [email-masked]
Cc: Stewart Bryant <[email-masked]>
Subject: RE: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Hi John,

--

Eric

-----Original Message-----
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of John E Drake
Sent: Thursday, January 9, 2020 3:15 PM
To: [email-masked]<mailto:[email-masked]>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Yours Irrespectively,

John

--

Teas-ns-dt mailing list

---

From: Kiran Makhijani <[email-masked]>
Date: Fri, 10 Jan 2020 20:28:02 +0000

Hi,
My thoughts on draft-ietf-teas-enhanced-vpn-03. It’s framework approach is bottom-up and data plane centric, which to me will make it a technology-specific solution. Whereas, in our discussions we have adopted  (at least to my assumption) a top-down approach which is primarily technology agnostic. That is why the focus is on interfaces, data models and not protocols.

The framework discussion on this mailing list should bring clarity on  what data, capabilities and operations are needed or necessary. The topic of enhancements in data plane is little too early to me  as it will “assume” certain things. In teas-ns-dt calls, the interest is on  documenting and hopefully agree on those “assumptions” first.

Having said that, it was good to know this draft, if we find ourselves repeating something– better to refer those sections from the ongoing drafts.

-Kiran

From: Teas-ns-dt <[email-masked]> on behalf of Eric Gray <eric.gray=[email-masked]>
Date: Friday, January 10, 2020 at 8:14 AM
To: John E Drake <jdrake=[email-masked]>, "[email-masked]" <[email-masked]>, Jari Arkko <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: Stewart Bryant <[email-masked]>
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://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-drake-bess-enhanced-vpn&data=02%7C01%7Ckiranm%40futurewei.com%7C5674a15ba8fe466fe5d708d795e82b8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637142696742025176&sdata=Evh46t7lvBpIhYB3WGrikcj%2Bd%2BDX09ECs7xksVImD8c%3D&reserved=0>) rather than the base VPN+ draft (https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-teas-enhanced-vpn&data=02%7C01%7Ckiranm%40futurewei.com%7C5674a15ba8fe466fe5d708d795e82b8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637142696742035140&sdata=ELFHs1bEnJC2BsHBecSncIVTbVRKrK0Vzt6T62bwgrM%3D&reserved=0>) – 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.

--
Eric

From: Eric Gray

Hi John,

--

Eric

-----Original Message-----
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of John E Drake
Sent: Thursday, January 9, 2020 3:15 PM
To: [email-masked]<mailto:[email-masked]>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Yours Irrespectively,

John

> https://protect2.fireeye.com/v1/url?k=e5f72a64-b97ef16b-e5f76aff-0cc47<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3De5f72a64-b97ef16b-e5f76aff-0cc47&data=02%7C01%7Ckiranm%40futurewei.com%7C5674a15ba8fe466fe5d708d795e82b8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637142696742035140&sdata=p2xiC9ENgQHHqoJDOWmrFR6Bbt37vu2k9deVBk9R85o%3D&reserved=0>

--

Teas-ns-dt mailing list

https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas-ns-dt&data=02%7C01%7Ckiranm%40futurewei.com%7C5674a15ba8fe466fe5d708d795e82b8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637142696742045096&sdata=EeNm0c0XvmNt9VNJi%2FqMOELvMxOWMSqXMOHs7brUhiE%3D&reserved=0>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 10 Jan 2020 20:28:04 -0000

Well, I have not been paying attention to the detailed discussion here, but (to me, obviously) a network slice is both an underlay and an overlay.

The slice uses parts of the physical network resources and provides a “virtual network” over the physical network. It is an overlay.

The slice is used by applications that use and or deliver connectivity services. It is an underlay.

To one turtle, the turtle below may seem like an underlay. But it is turtles all the way down. So you cannot use the terms underlay and overlay as definitive concepts: they are relative concepts and the terms only have meaning when associated with a context.

Adrian

From: Eric Gray <[email-masked]> 
Sent: 10 January 2020 16:14
To: John E Drake <jdrake=[email-masked]>; [email-masked]; Jari Arkko <[email-masked]>; [email-masked]
Cc: Stewart Bryant <[email-masked]>
Subject: RE: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Jari,

--

Eric

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

Hi John,

--

Eric

-----Original Message-----
From: Teas-ns-dt <[email-masked] <mailto:[email-masked]> > On Behalf Of John E Drake
Sent: Thursday, January 9, 2020 3:15 PM
To: [email-masked] <mailto:[email-masked]> ; Jari Arkko <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Yours Irrespectively,

John

> From: Teas-ns-dt < <mailto:[email-masked]> [email-masked]> On Behalf Of Adrian 

> To: 'Jari Arkko' < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]

>  <mailto:[email-masked]> [email-masked]

>  <https://protect2.fireeye.com/v1/url?k=e5f72a64-b97ef16b-e5f76aff-0cc47> https://protect2.fireeye.com/v1/url?k=e5f72a64-b97ef16b-e5f76aff-0cc47

--

Teas-ns-dt mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/teas-ns-dt> https://www.ietf.org/mailman/listinfo/teas-ns-dt

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 10 Jan 2020 20:38:44 -0000

Hi Kiran,

This is an interesting email. 

As something of an outside observer, I have been trying to work out what the focus of the DT is.

You say “the focus is on interfaces, data models and not protocols” and that is a message I have heard before. But I was unclear that this was the view held by whole of the DT.

If this *is* the focus, then I think things will be very much clearer for everyone. Terminology will, of course, be necessary, but frameworks and architectures are less important when we are talking about interfaces and data models for requesting and monitoring network slices.

So, back to some questions I asked a few emails back: What is the focus of the DT? What is it seeking to produce?

Thanks,

Adrian

From: Kiran Makhijani <[email-masked]> 
Sent: 10 January 2020 20:28
To: Eric Gray <eric.gray=[email-masked]>; John E Drake <jdrake=[email-masked]>; [email-masked]; Jari Arkko <[email-masked]>; [email-masked]
Cc: Stewart Bryant <[email-masked]>
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Hi,

-Kiran

Jari,

I suspect that John is actually trying to push his draft (https://tools.ietf.org/html/draft-drake-bess-enhanced-vpn <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-drake-bess-enhanced-vpn&data=02%7C01%7Ckiranm%40futurewei.com%7C5674a15ba8fe466fe5d708d795e82b8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637142696742025176&sdata=Evh46t7lvBpIhYB3WGrikcj%2Bd%2BDX09ECs7xksVImD8c%3D&reserved=0> ) rather than the base VPN+ draft (https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-teas-enhanced-vpn&data=02%7C01%7Ckiranm%40futurewei.com%7C5674a15ba8fe466fe5d708d795e82b8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637142696742035140&sdata=ELFHs1bEnJC2BsHBecSncIVTbVRKrK0Vzt6T62bwgrM%3D&reserved=0> ) – 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.

--

Eric

From: Eric Gray 

Hi John,

--

Eric

-----Original Message-----
From: Teas-ns-dt <[email-masked] <mailto:[email-masked]> > On Behalf Of John E Drake
Sent: Thursday, January 9, 2020 3:15 PM
To: [email-masked] <mailto:[email-masked]> ; Jari Arkko <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> 
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Yours Irrespectively,

John

>  <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3De5f72a64-b97ef16b-e5f76aff-0cc47&data=02%7C01%7Ckiranm%40futurewei.com%7C5674a15ba8fe466fe5d708d795e82b8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637142696742035140&sdata=p2xiC9ENgQHHqoJDOWmrFR6Bbt37vu2k9deVBk9R85o%3D&reserved=0> https://protect2.fireeye.com/v1/url?k=e5f72a64-b97ef16b-e5f76aff-0cc47

--

Teas-ns-dt mailing list

 <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas-ns-dt&data=02%7C01%7Ckiranm%40futurewei.com%7C5674a15ba8fe466fe5d708d795e82b8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637142696742045096&sdata=EeNm0c0XvmNt9VNJi%2FqMOELvMxOWMSqXMOHs7brUhiE%3D&reserved=0> https://www.ietf.org/mailman/listinfo/teas-ns-dt

---

From: Kiran Makhijani <[email-masked]>
Date: Fri, 10 Jan 2020 21:19:45 +0000

Hi Adrian,
So, back to some questions I asked a few emails back: What is the focus of the DT? What is it seeking to produce?
^^^
I would let someone else answer this or perhaps join the regular calls which are more lively than the mailing list itself.

But, yes terminology is the first step. I prefer to have initial framework very lean and simple to explain interfaces and the basic structure. My assumption is that post-DT output – a lot more detailed work need to be done within the TEAS or other WGs. But they will all be able to point to a common understanding of transport slices.
-Kiran

From: Adrian Farrel <[email-masked]>
Organization: Old Dog Consulting
Reply-To: "[email-masked]" <[email-masked]>
Date: Friday, January 10, 2020 at 12:39 PM
To: Kiran Makhijani <[email-masked]>, 'Eric Gray' <eric.gray=[email-masked]>, 'John E Drake' <jdrake=[email-masked]>, 'Jari Arkko' <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: 'Stewart Bryant' <[email-masked]>
Subject: RE: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Hi Kiran,

Thanks,
Adrian

Hi,

-Kiran

Jari,

I suspect that John is actually trying to push his draft (https://tools.ietf.org/html/draft-drake-bess-enhanced-vpn<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-drake-bess-enhanced-vpn&data=02%7C01%7Ckiranm%40futurewei.com%7C5026514b045a4f2375eb08d7960d1ac4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637142855376127695&sdata=0G5blOdp33DYSAf3RbgEuuguvqiyE0hMjvlPKQWrzok%3D&reserved=0>) rather than the base VPN+ draft (https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-teas-enhanced-vpn&data=02%7C01%7Ckiranm%40futurewei.com%7C5026514b045a4f2375eb08d7960d1ac4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637142855376137688&sdata=O13oXgv4%2BO4o2mfMvRhGqdQL2dJEQxy6G215JYw5vi4%3D&reserved=0>) – 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.

--
Eric

From: Eric Gray

Hi John,

--

Eric

-----Original Message-----
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of John E Drake
Sent: Thursday, January 9, 2020 3:15 PM
To: [email-masked]<mailto:[email-masked]>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Yours Irrespectively,

John

> https://protect2.fireeye.com/v1/url?k=e5f72a64-b97ef16b-e5f76aff-0cc47<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3De5f72a64-b97ef16b-e5f76aff-0cc47&data=02%7C01%7Ckiranm%40futurewei.com%7C5026514b045a4f2375eb08d7960d1ac4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637142855376137688&sdata=5TbswsJW5j%2F9m3T0LLfjOepkr9uNtHkgVyOSO3WLbjw%3D&reserved=0>

--

Teas-ns-dt mailing list

https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas-ns-dt&data=02%7C01%7Ckiranm%40futurewei.com%7C5026514b045a4f2375eb08d7960d1ac4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637142855376147682&sdata=WN1JrQ45QE8H8YU70uz9vDURtEHTkn945tms8HFsXzg%3D&reserved=0>

---

From: "Rokui, Reza (Nokia - CA/Ottawa)" <[email-masked]>
Date: Fri, 10 Jan 2020 21:28:13 +0000

Hi Adrian,

I agree with Kiran’s point of view. The main objective of Network Slicing DT is transport slice definition, its NBI interface(s) and its data model.

In addition the framework document might also give some guidelines on mapping the NBI to specific Transport Slice Realization along with a few use-cases to make the concept clear without mandating any particular solution.

Cheers,

Reza

From: Teas-ns-dt <[email-masked]> on behalf of Adrian Farrel <[email-masked]>
Organization: Old Dog Consulting
Reply-To: "[email-masked]" <[email-masked]>
Date: Friday, January 10, 2020 at 3:38 PM
To: 'Kiran Makhijani' <[email-masked]>, 'Eric Gray' <eric.gray=[email-masked]>, 'John E Drake' <jdrake=[email-masked]>, 'Jari Arkko' <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: 'Stewart Bryant' <[email-masked]>
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Hi Kiran,

Thanks,
Adrian

Hi,

-Kiran

Jari,

--
Eric

From: Eric Gray

Hi John,

--

Eric

-----Original Message-----
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of John E Drake
Sent: Thursday, January 9, 2020 3:15 PM
To: [email-masked]<mailto:[email-masked]>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Yours Irrespectively,

John

--

Teas-ns-dt mailing list

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 10 Jan 2020 13:29:05 -0800

Same here!

Cheers,
Jeff

---

From: John E Drake <[email-masked]>
Date: Fri, 10 Jan 2020 21:29:32 +0000

Hi,

Comments inline

Yours Irrespectively,

John

Juniper Business Use Only
From: Eric Gray <eric.gray=[email-masked]>
Sent: Friday, January 10, 2020 11:14 AM
To: John E Drake <[email-masked]>; [email-masked]; Jari Arkko <[email-masked]>; [email-masked]
Cc: Stewart Bryant <[email-masked]>
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.

--
Eric

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

Hi John,

--

Eric

-----Original Message-----
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of John E Drake
Sent: Thursday, January 9, 2020 3:15 PM
To: [email-masked]<mailto:[email-masked]>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Yours Irrespectively,

John

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

--

Teas-ns-dt mailing list

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

---

From: John E Drake <[email-masked]>
Date: Fri, 10 Jan 2020 21:38:37 +0000

Hi,

Comments inline

Yours Irrespectively,

John

Hi John,

[JD]  What I was proposing was an evolution of what is in the VPN+ and BGP-LS Filters drafts. Viz, a network slice is a set of underlay network resources that connect a set of endpoints, w/ either homogeneous or heterogeneous SLAs between endpoint pairs.  Overlay network services, such as VPNs, are then offered to this set of endpoints.

With this in mind, what I was proposing was:

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.  *****JD  This has been modified to indicate that there may be different SLAs between endpoint pairs  *****JD  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.

So, what we might want to consider is moving the material which is underlay network specific from the VPN+ draft to the network slicing framework draft and recasting the VPN+ draft as defining how VPN overlay services use network slices.

--

Eric

-----Original Message-----
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of John E Drake
Sent: Thursday, January 9, 2020 3:15 PM
To: [email-masked]<mailto:[email-masked]>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Yours Irrespectively,

John

> 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!RvyLM7lEiKpdSsZFsuQvTvevxa0B_R3MyBhJrYxHNBB1k6glHiWxMPQSN7i8pko$>

--

Teas-ns-dt mailing list

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

---

From: John E Drake <[email-masked]>
Date: Fri, 10 Jan 2020 21:50:23 +0000

Hi,

The point of my emails yesterday was that if one considers a network slice to be an underlay network construct, i.e., connectivity between a set of endpoints with a set of one or more SLAs between pairs of endpoints,  then the vast majority of the text in the VPN+ draft is directly applicable to this underlay network construct and should be moved to a network slicing framework draft.  The remaining VPN+ text would then be a description of how VPN network overlay services use network slices.

Yours Irrespectively,

John

Juniper Business Use Only
From: Kiran Makhijani <[email-masked]>
Sent: Friday, January 10, 2020 3:28 PM
To: Eric Gray <[email-masked]>; John E Drake <[email-masked]>; [email-masked]; Jari Arkko <[email-masked]>; [email-masked]
Cc: Stewart Bryant <[email-masked]>
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Hi,

-Kiran

From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> on behalf of Eric Gray <eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>>
Date: Friday, January 10, 2020 at 8:14 AM
To: John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Jari Arkko <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
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:/nam03.safelinks.protection.outlook.com/?url=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-drake-bess-enhanced-vpn&data=02*7C01*7Ckiranm*40futurewei.com*7C5674a15ba8fe466fe5d708d795e82b8f*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637142696742025176&sdata=Evh46t7lvBpIhYB3WGrikcj*2Bd*2BDX09ECs7xksVImD8c*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!UrSGpTPNXFkqHTpey7VocppuRSfPHwmYdkgIaogdzjP4T2FFwqCbjBiLRmj0HnU$>) rather than the base VPN+ draft (https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn<https://urldefense.com/v3/__https:/nam03.safelinks.protection.outlook.com/?url=https*3A*2F*2Ftools.ietf.org*2Fhtml*2Fdraft-ietf-teas-enhanced-vpn&data=02*7C01*7Ckiranm*40futurewei.com*7C5674a15ba8fe466fe5d708d795e82b8f*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637142696742035140&sdata=ELFHs1bEnJC2BsHBecSncIVTbVRKrK0Vzt6T62bwgrM*3D&reserved=0__;JSUlJSUlJSUlJSUlJSU!!NEt6yMaO-gk!UrSGpTPNXFkqHTpey7VocppuRSfPHwmYdkgIaogdzjP4T2FFwqCbjBiL8JAeHow$>) – 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.

--
Eric

From: Eric Gray

Hi John,

--

Eric

-----Original Message-----
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of John E Drake
Sent: Thursday, January 9, 2020 3:15 PM
To: [email-masked]<mailto:[email-masked]>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Yours Irrespectively,

John

> https://protect2.fireeye.com/v1/url?k=e5f72a64-b97ef16b-e5f76aff-0cc47<https://urldefense.com/v3/__https:/nam03.safelinks.protection.outlook.com/?url=https*3A*2F*2Fprotect2.fireeye.com*2Fv1*2Furl*3Fk*3De5f72a64-b97ef16b-e5f76aff-0cc47&data=02*7C01*7Ckiranm*40futurewei.com*7C5674a15ba8fe466fe5d708d795e82b8f*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637142696742035140&sdata=p2xiC9ENgQHHqoJDOWmrFR6Bbt37vu2k9deVBk9R85o*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!UrSGpTPNXFkqHTpey7VocppuRSfPHwmYdkgIaogdzjP4T2FFwqCbjBiL1sA2hNY$>

--

Teas-ns-dt mailing list

https://www.ietf.org/mailman/listinfo/teas-ns-dt<https://urldefense.com/v3/__https:/nam03.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fteas-ns-dt&data=02*7C01*7Ckiranm*40futurewei.com*7C5674a15ba8fe466fe5d708d795e82b8f*7C0fee8ff2a3b240189c753a1d5591fedc*7C1*7C0*7C637142696742045096&sdata=EeNm0c0XvmNt9VNJi*2FqMOELvMxOWMSqXMOHs7brUhiE*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJQ!!NEt6yMaO-gk!UrSGpTPNXFkqHTpey7VocppuRSfPHwmYdkgIaogdzjP4T2FFwqCbjBiL0hX47fQ$>

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 10 Jan 2020 14:43:47 -0800

Worth to be noted - overlay is always relative to its underlay, the definitions are not absolute but rather relative to each other, e.g MPLS is an overlay on top of optical transport, while xVPN is an overlay on top of MPLS/any other transport, etc.

Every network (sub)slice exists in two dimensions:
horizontal - GW2GW that limit a particular domain
vertical (bottom up) optical->ethernet->MPLS->VPN (not complete and not necessarily in this order)

It would be beneficial for further discussion to keep this in mind.

Cheers,
Jeff

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sat, 11 Jan 2020 08:29:22 +0000

Hi all,

Based on the discussion, it seems that the design team mainly wants to work on the definition, northbound interface and data models of transport network slice. I think this is a reasonable scope for the DT, and it would reduce the possible overlap with existing work such as VPN+ framework.

Best regards,
Jie

From: Teas-ns-dt [mailto:[email-masked]] On Behalf Of Jeff Tantsura
Sent: Saturday, January 11, 2020 5:29 AM
To: [email-masked]; Kiran Makhijani <[email-masked]>; Eric Gray <eric.gray=[email-masked]>; John E Drake <jdrake=[email-masked]>; Jari Arkko <[email-masked]>; [email-masked]; Stewart Bryant <[email-masked]>; Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]>
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Same here!

Cheers,
Jeff
On Jan 10, 2020, 1:28 PM -0800, Rokui, Reza (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>>, wrote:

Hi Adrian,

Cheers,

Reza

From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> on behalf of Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Organization: Old Dog Consulting
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 10, 2020 at 3:38 PM
To: 'Kiran Makhijani' <[email-masked]<mailto:[email-masked]>>, 'Eric Gray' <eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>>, 'John E Drake' <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>, 'Jari Arkko' <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: 'Stewart Bryant' <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Hi Kiran,

Thanks,
Adrian

From: Kiran Makhijani <[email-masked]<mailto:[email-masked]>>
Sent: 10 January 2020 20:28
To: Eric Gray <eric.gray=[email-masked]<mailto:eric.gray=[email-masked]>>; John E Drake <jdrake=[email-masked]<mailto:jdrake=[email-masked]>>; [email-masked]<mailto:[email-masked]>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Stewart Bryant <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Hi,

-Kiran

Jari,

--
Eric

From: Eric Gray

Hi John,

--

Eric

-----Original Message-----
From: Teas-ns-dt <[email-masked]<mailto:[email-masked]>> On Behalf Of John E Drake
Sent: Thursday, January 9, 2020 3:15 PM
To: [email-masked]<mailto:[email-masked]>; Jari Arkko <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and overlap with existing TEAS work

Yours Irrespectively,

John

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

--

Teas-ns-dt mailing list

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 12 Jan 2020 14:06:20 -0800

Jie,

IMO the our work should be to create a framework that other frameworks , such as VPN+ (but not limited to) would refer to, there should not be overlap since context is different, the relationship is hierarchical rather than horizontal.
This should also help other frameworks to focus, rather than trying to be everything to everyone (boiling the ocean).

Cheers,
Jeff

---

From: Xufeng Liu <[email-masked]>
Date: Sun, 12 Jan 2020 21:44:39 -0500

Agree with what Jeff said.
In term of "the focus is on interfaces, data models and not protocols", my
understanding is:
Because we are working with a "top-down" approach, we start with the
definitions and concepts, and then work on the requirements and
decompositions.  "interfaces" is the initial focus, and we are working
towards to the framework, which is also important. The scope of the DT work
would not reach the level of the details of the VPN+ framework document, so
there is this hierarchical relationship.

Thanks,
- Xufeng

On Sun, Jan 12, 2020 at 5:06 PM Jeff Tantsura <[email-masked]>
wrote:

> Jie,
>
> IMO the our work should be to create a framework that other frameworks ,
> such as VPN+ (but not limited to) would refer to, there should not be
> overlap since context is different, the relationship is hierarchical rather
> than horizontal.
> This should also help other frameworks to focus, rather than trying to be
> everything to everyone (boiling the ocean).
>
> Cheers,
> Jeff
> Based on the discussion, it seems that the design team mainly wants to
> work on the definition, northbound interface and data models of transport
> network slice. I think this is a reasonable scope for the DT, and it would
> reduce the possible overlap with existing work such as VPN+ framework.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* Teas-ns-dt [mailto:[email-masked]] *On Behalf Of*
> Jeff Tantsura
> *Sent:* Saturday, January 11, 2020 5:29 AM
> *To:* [email-masked]; Kiran Makhijani <[email-masked]>; Eric
> Gray <eric.gray=[email-masked]>; John E Drake <jdrake=
> [email-masked]>; Jari Arkko <[email-masked]>;
> [email-masked]; Stewart Bryant <[email-masked]>; Rokui,
> Reza (Nokia - CA/Ottawa) <[email-masked]>
> *Subject:* Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and
> I agree with Kiran’s point of view. The main objective of Network Slicing
> DT is transport slice definition, its NBI interface(s) and its data model.
>
>
>
> In addition the framework document might also give some guidelines on
> mapping the NBI to specific Transport Slice Realization along with a few
> use-cases to make the concept clear without mandating any particular
> solution.
>
>
>
> *Cheers,*
>
>
>
> *Reza*
>
>
>
>
>
> *From:* Teas-ns-dt <[email-masked]> on behalf of Adrian
> Farrel <[email-masked]>
> *Organization:* Old Dog Consulting
> *Reply-To:* "[email-masked]" <[email-masked]>
> *Date:* Friday, January 10, 2020 at 3:38 PM
> *To:* 'Kiran Makhijani' <[email-masked]>, 'Eric Gray' <
> eric.gray=[email-masked]>, 'John E Drake' <
> jdrake=[email-masked]>, 'Jari Arkko' <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Cc:* 'Stewart Bryant' <[email-masked]>
> *Subject:* Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and
> You say “the focus is on interfaces, data models and not protocols” and
> that is a message I have heard before. But I was unclear that this was the
> view held by whole of the DT.
>
>
>
> If this **is** the focus, then I think things will be very much clearer
> for everyone. Terminology will, of course, be necessary, but frameworks and
> architectures are less important when we are talking about interfaces and
> data models for requesting and monitoring network slices.
>
>
>
> *From:* Kiran Makhijani <[email-masked]>
> *Sent:* 10 January 2020 20:28
> *To:* Eric Gray <eric.gray=[email-masked]>; John E Drake <
> jdrake=[email-masked]>; [email-masked]; Jari Arkko <
> [email-masked]>; [email-masked]
> *Cc:* Stewart Bryant <[email-masked]>
> *Subject:* Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and
> My thoughts on draft-ietf-teas-enhanced-vpn-03. It’s framework approach is
> bottom-up and data plane centric, which to me will make it a
> technology-specific solution. Whereas, in our discussions we have adopted
>  (at least to my assumption) a top-down approach which is primarily
> technology agnostic. That is why the focus is on interfaces, data models
> and not protocols.
>
>
>
> The framework discussion on this mailing list should bring clarity on
>  what data, capabilities and operations are needed or necessary. The topic
> of enhancements in data plane is little too early to me  as it will
> “assume” certain things. In teas-ns-dt calls, the interest is on
>  documenting and hopefully agree on those “assumptions” first.
>
>
>
> Having said that, it was good to know this draft, if we find ourselves
> repeating something– better to refer those sections from the ongoing drafts.
>
>
>
> -Kiran
>
>
>
>
>
> *From:* Teas-ns-dt <[email-masked]> on behalf of Eric Gray <
> eric.gray=[email-masked]>
> *Date:* Friday, January 10, 2020 at 8:14 AM
> *To:* John E Drake <jdrake=[email-masked]>, "
> [email-masked]" <[email-masked]>, Jari Arkko <
> [email-masked] <[email-masked]>>, "[email-masked]"
> <[email-masked]>
> *Cc:* Stewart Bryant <[email-masked]>
> *Subject:* Re: [Teas-ns-dt] FW: Progress of Slicing Design Team and
> I suspect that John is actually trying to push his draft (
> https://tools.ietf.org/html/draft-drake-bess-enhanced-vpn
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-drake-bess-enhanced-vpn&data=02%7C01%7Ckiranm%40futurewei.com%7C5674a15ba8fe466fe5d708d795e82b8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637142696742025176&sdata=Evh46t7lvBpIhYB3WGrikcj%2Bd%2BDX09ECs7xksVImD8c%3D&reserved=0>)
> rather than the base VPN+ draft (
> https://tools.ietf.org/html/draft-ietf-teas-enhanced-vpn
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-teas-enhanced-vpn&data=02%7C01%7Ckiranm%40futurewei.com%7C5674a15ba8fe466fe5d708d795e82b8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637142696742035140&sdata=ELFHs1bEnJC2BsHBecSncIVTbVRKrK0Vzt6T62bwgrM%3D&reserved=0>)
> – 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.
>
>
>
> 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=[email-masked]>;
> [email-masked]; Jari Arkko <[email-masked]>;
> [email-masked]
> *Cc:* Stewart Bryant <[email-masked]>
> *Subject:* RE: [Teas-ns-dt] FW: Progress of Slicing Design Team and
>               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 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.
>
>
>
>    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
>
>
>
> 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
>
>
>
>
>
> > From: Teas-ns-dt <[email-masked]> On Behalf Of Adrian
>
> > Farrel
>
> > >> 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.
>
> > >
>
> 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).
>
> > >
>
> > >> Even some of the team got so excited that they posted a "design
> team" draft that wasn't a design team draft!
>
> > >
>
> > >> 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.
>
> > >>
>
> 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.
>
> > >
>
> > Oh, I thought we were paid per line of Internet-Draft that we wrote...
>
> >
>
> 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.
>
> >
>
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fprotect2.fireeye.com%2Fv1%2Furl%3Fk%3De5f72a64-b97ef16b-e5f76aff-0cc47&data=02%7C01%7Ckiranm%40futurewei.com%7C5674a15ba8fe466fe5d708d795e82b8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637142696742035140&sdata=p2xiC9ENgQHHqoJDOWmrFR6Bbt37vu2k9deVBk9R85o%3D&reserved=0>
>
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteas-ns-dt&data=02%7C01%7Ckiranm%40futurewei.com%7C5674a15ba8fe466fe5d708d795e82b8f%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637142696742045096&sdata=EeNm0c0XvmNt9VNJi%2FqMOELvMxOWMSqXMOHs7brUhiE%3D&reserved=0>
>
> --
> Teas-ns-dt mailing list
> [email-masked]