Subject: [dtn-interest] 5G: It's the Network, Stupid

From: Dirk Kutscher <[email-masked]>
Date: Wed, 16 Dec 2015 18:41:13 +0000

[apologies for cross-posting]

Hi,

I have written up a few thoughts on current discussions around 5G and network evolution. I might publish this as paper later, but wanted to get it out early and ask for comments - so would be grateful for any feedback. It's not very polished and slightly long, but hopefully understandable enough. Take it as a "position paper" for now.

Abstract:
Current 5G network discussion are often focusing on providing more comprehensive and integrated orchestration and management functions in order to improve "end-to-end" managebility and programmability, derived from NGMN and similar requirements. While these are important challenges, this memo takes the perspective that in order to arrive at a more powerful network, it is important to understand the pain points and the reasons for certain design choices of today's networks. Understanding the drivers for traffic management systems, middleboxes, CDNs and other application-layer overlays should be taken as a basis for analyzing 5G uses cases and their requirements. In this memo, I am making the point that many of today's business needs and the ambitious 5G use cases do call for a more powerful data forwarding plane, taking ICN as an example. Features of such a forwarding plane would include better support for heterogeneous networks (access networks and whole network deployments), multi-path communication, in-network storage and implementation of operator policies. This would help to avoid overlay silos and finally simplify network management.

http://dirk-kutscher.info/posts/5g-its-the-network-stupid/

Thanks,
Dirk

---

From: Dirk Kutscher <[email-masked]>
Date: Thu, 17 Dec 2015 09:34:06 +0000

Hi Ingemar,

thanks for the feedback.

Yes, as far as I remember the UPCON work was rather on the traffic management side and may not have addressed the actual performance aspects (through AQM and ECN) sufficiently.

For ConEx, there haven't been enough experiments yet, unfortunately, but in my opinion the concept of "application-independent congestion accountability" for various use cases is really more promising than fine-granular traffic management. One of the use cases (that Bob came up with) is performance isolation in virtual networks, which would allow for a more flexible capacity sharing in data centers.

My point was if we are thinking about virtual slices, let's not introduce static QoS, bw reservations etc. for those applications that do not actually need it - there are other ways to share capacity.

Cheers,
Dirk

From: Ingemar Johansson S [mailto:[email-masked]]
Sent: Donnerstag, 17. Dezember 2015 08:26
To: Dirk Kutscher; [email-masked]; [email-masked]; gaia; [email-masked]; [email-masked]; [email-masked]
Cc: Ingemar Johansson S
Subject: RE: [5gangip] 5G: It's the Network, Stupid

Hi

Thanks for an interesting blog post. Parts of this is above my head so I only comment on the parts that I know well
AQM and ECN : Agree fully, there seems to be a general tendency to overlook the basic elements in congestion management in networks. Quite often  one see reports of roundtrip times of 1 second or more in LTE networks. High RTT was also part of the problem formulation in the UPCON WI but as I recall it, the role of (lack of) AQM and ECN  was missed.
ConEx : What is your view of ConEx ?. The work is wrapping up, but as I see it the interest in the "end to end" ConEx is quite modest. Do you envision more local deployments like what is outlined in draft-ietf-conex-mobile ?.

/Ingemar

From: Dirk Kutscher [mailto:[email-masked]]
Sent: den 16 december 2015 19:41
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; gaia; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [5gangip] 5G: It's the Network, Stupid

Hi,

Abstract:

Thanks,
Dirk

---

From: Dirk Kutscher <[email-masked]>
Date: Thu, 17 Dec 2015 09:43:50 +0000

Yes, good point. That was actually a notion I had in mind, too, but forgot to mention: Don’t have assumptions in the architecture on where the network ends.

IoT is illustrating the need for that to some extent already.

Regarding security, unless we want to introduce “trusted middleboxes”, object encryption and authentication seems to be the way. Of course there are other challenges for that, too – key management for example.

--
Dirk

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jon Crowcroft
Sent: Donnerstag, 17. Dezember 2015 08:57
To: Dirk Kutscher
Cc: [email-masked]; [email-masked]; [email-masked]; gaia; [email-masked]; [email-masked]
Subject: Re: [gaia] 5G: It's the Network, Stupid

Great article...one thing about the 4g..5g evolution is increasing cooperation in forwarding and relaying signal, bits, packets (shared cell tower/base station/antennae across provider). So direct,mesh,adhoc stop just being edge notions, but are all first class part of the architecture ("don't fear the edge"). There is huge tension between this trend, and e2e security....I have not seen anyone address how to resolve that tension...
On 16 Dec 2015 6:42 pm, "Dirk Kutscher" <[email-masked]<mailto:[email-masked]>> wrote:
[apologies for cross-posting]

Hi,

I have written up a few thoughts on current discussions around 5G and network evolution. I might publish this as paper later, but wanted to get it out early and ask for comments – so would be grateful for any feedback. It’s not very polished and slightly long, but hopefully understandable enough. Take it as a “position paper” for now.

Abstract:
Current 5G network discussion are often focusing on providing more comprehensive and integrated orchestration and management functions in order to improve “end-to-end” managebility and programmability, derived from NGMN and similar requirements. While these are important challenges, this memo takes the perspective that in order to arrive at a more powerful network, it is important to understand the pain points and the reasons for certain design choices of today’s networks. Understanding the drivers for traffic management systems, middleboxes, CDNs and other application-layer overlays should be taken as a basis for analyzing 5G uses cases and their requirements. In this memo, I am making the point that many of today’s business needs and the ambitious 5G use cases do call for a more powerful data forwarding plane, taking ICN as an example. Features of such a forwarding plane would include better support for heterogeneous networks (access networks and whole network deployments), multi-path communication, in-network storage and implementation of operator policies. This would help to avoid overlay silos and finally simplify network management.

Thanks,
Dirk

_______________________________________________
gaia mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/gaia

---

From: Dirk Kutscher <[email-masked]>
Date: Thu, 17 Dec 2015 10:10:30 +0000

> > Regarding security, unless we want to introduce “trusted middleboxes”,
> 
> Why not?

No e2e security.

That may be OK for some use cases, like IoT or home GWs, but could be less convincing for accessing public network services -- for example, if you extend the network with multiple hops of device-to-device communication, data mules etc.

Dirk

> 
> 
> > object encryption and authentication seems to be the way. Of course there are
> other challenges for that, too – key management for example.
> >
> > --
> > Dirk
> >
> > Great article...one thing about the 4g..5g evolution is increasing cooperation
> in forwarding and relaying signal, bits, packets (shared cell tower/base
> station/antennae across provider). So direct,mesh,adhoc stop just being edge
> notions, but are all first class part of the architecture ("don't fear the edge").
> There is huge tension between this trend, and e2e security....I have not seen
> anyone address how to resolve that tension...
> >
> > On 16 Dec 2015 6:42 pm, "Dirk Kutscher" <[email-masked]> wrote:
> > I have written up a few thoughts on current discussions around 5G and
> network evolution. I might publish this as paper later, but wanted to get it out
> early and ask for comments – so would be grateful for any feedback. It’s not
> very polished and slightly long, but hopefully understandable enough. Take it as
> a “position paper” for now.
> >
> > Abstract:
> > Current 5G network discussion are often focusing on providing more
> comprehensive and integrated orchestration and management functions in
> order to improve “end-to-end” managebility and programmability, derived from
> NGMN and similar requirements. While these are important challenges, this
> memo takes the perspective that in order to arrive at a more powerful network,
> it is important to understand the pain points and the reasons for certain design
> choices of today’s networks. Understanding the drivers for traffic management
> systems, middleboxes, CDNs and other application-layer overlays should be
> taken as a basis for analyzing 5G uses cases and their requirements. In this
> memo, I am making the point that many of today’s business needs and the
> ambitious 5G use cases do call for a more powerful data forwarding plane,
> taking ICN as an example. Features of such a forwarding plane would include
> better support for heterogeneous networks (access networks and whole
> network deployments), multi-path communication, in-network storage and
> implementation of operator policies. This would help to avoid overlay silos and
> finally simplify network management.
> >
> > [email-masked]
> > Stackevo-discuss mailing list
> > [email-masked]
> > https://www.iab.org/mailman/listinfo/stackevo-discuss
> 
> [email-masked]

---

From: Dirk Kutscher <[email-masked]>
Date: Thu, 17 Dec 2015 10:53:23 +0000

Hi,

Let's continue the discussion on one list only -- otherwise we are flooding too many mailboxes.

I have tried to set Reply-To to [email-masked] -- let's just use that.

(If you intend to reply, consider subscribing to the list first...)

Thanks,
Dirk

> -----Original Message-----
> From: Michael Welzl [mailto:[email-masked]]
> Sent: Donnerstag, 17. Dezember 2015 11:19
> To: Dirk Kutscher
> Cc: [email-masked]; gaia; [email-masked]; [email-masked]; Jon
> Crowcroft; [email-masked]; [email-masked]
> Subject: Re: [gaia] [Stackevo-discuss] 5G: It's the Network, Stupid
> 
> 
> > On 17 Dec 2015, at 11:10, Dirk Kutscher <[email-masked]> wrote:
> >
> >>> Regarding security, unless we want to introduce "trusted middleboxes",
> >>
> >> Why not?
> >
> > No e2e security.
> >
> > That may be OK for some use cases, like IoT or home GWs, but could be less
> convincing for accessing public network services -- for example, if you extend
> the network with multiple hops of device-to-device communication, data mules
> etc.
> 
> Hm.... just because you trust them to do certain tasks for you doesn't mean you
> trust them with everything?  We trust routers to forward our data and can even
> set the DSCP for them  (in theory - yes i know the rtcweb/DSCP story and DART)
> 
> And you can still have e.g. e2e encryption and e2e authentication on top, right?
> So what is the real trust problem here?

---

From: Arjuna Sathiaseelan <[email-masked]>
Date: Fri, 18 Dec 2015 07:25:26 +0000

Hello Dirk -
(only added ICNRG, DTNWG and GAIA for relevance)

Thanks for this. Its an excellent article. I have some thoughts related to
GAIA but I will write about this latter. The 5G story is highly relevant to
GAIA..

In the meantime, I think our paper at the forthcoming ACM CCR on the role
of ICN and DTN to solve the problems associated with GAIA may be
interesting. The paper presents an integrated architecture and discusses
why such an architecture could be a potential problem solver..

Comments welcome.

Regards

On 16 December 2015 at 18:41, Dirk Kutscher <[email-masked]> wrote:

> network evolution. I might publish this as paper later, but wanted to get
> it out early and ask for comments – so would be grateful for any feedback.
> It’s not very polished and slightly long, but hopefully understandable
> enough. Take it as a “position paper” for now.
>
>
>
> Abstract:
>
> order to improve “end-to-end” managebility and programmability, derived
> from NGMN and similar requirements. While these are important challenges,
> this memo takes the perspective that in order to arrive at a more powerful
> network, it is important to understand the pain points and the reasons for
> certain design choices of today’s networks. Understanding the drivers for
> traffic management systems, middleboxes, CDNs and other application-layer
> overlays should be taken as a basis for analyzing 5G uses cases and their
> requirements. In this memo, I am making the point that many of today’s
> business needs and the ambitious 5G use cases do call for a more powerful
> data forwarding plane, taking ICN as an example. Features of such a
> forwarding plane would include better support for heterogeneous networks
> (access networks and whole network deployments), multi-path communication,
> in-network storage and implementation of operator policies. This would help
> to avoid overlay silos and finally simplify network management.
>
>
>
> dtn-interest mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>
>

-- 
Arjuna Sathiaseelan
Personal: http://www.cl.cam.ac.uk/~as2330/
N4D Lab: http://www.cl.cam.ac.uk/~as2330/n4d

---

From: Michael Welzl <[email-masked]>
Date: Thu, 17 Dec 2015 11:18:36 +0100

> That may be OK for some use cases, like IoT or home GWs, but could be less convincing for accessing public network services -- for example, if you extend the network with multiple hops of device-to…

Hm.... just because you trust them to do certain tasks for you doesn't mean you trust them with everything?  We trust routers to forward our data and can even set the DSCP for them  (in theory - yes i know the rtcweb/DSCP story and DART)

And you can still have e.g. e2e encryption and e2e authentication on top, right?  So what is the real trust problem here?

---

From: "David Michael Taht" <[email-masked]>
Date: Thu, 17 Dec 2015 14:49:11 +0100

Dear Dirk:

Reading this blog post cheered me up, thank you.

I am still frustrated, of course, that those doing wifi, other forms of 
wireless (802.11ad, 802.11ak) or homeplug (network over powerline) 
technologies don't seem to be paying even half as much attention to the 
details you raise, as the 5g-ers are.

[https://www.irtf.org/mailman/listinfo/gaia]

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 17 Dec 2015 17:49:24 +0000

I strongly support the concept of network slicing for Applications or IoT networks. 
But it is not realistic to expect operators networks to take control requests from individual users/handsets. There has to be an authenticated application controller that makes requests/commands to the sliced network. 

My two cents. 

Linda 

-----Original Message-----
From: Stackevo-discuss [mailto:[email-masked]] On Behalf Of Nishanth Sastry
Sent: Thursday, December 17, 2015 6:43 AM
To: Jon Crowcroft
Cc: [email-masked]; gaia; [email-masked]; Dirk Kutscher; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid

E2E security in 5G can be addressed through network slicing, another concept which seems to be included in many 5G proposals. If each application has its own slice, it can screw up but wont be able to affect other applications. Within each slice, E2E security can be enforced in an application specific manner. Even better would be if we can make each flow be its own slice. This may seem to be overly heavyweight, but is along the lines of what Bromium  is trying to do for desktops, isolating processes and data from each other using
"microvisors": http://www.bromium.com/why-bromium/how-we-do-it.html We just need to do it for networks :)

nishanth
—
CD-GAIN: http://bit.ly/cd-gain
S4S: http://www.space4sharingstudy.org/
REACH: http://www.eu-india.net

5G Norma: https://5g-ppp.eu/5g-norma
VirtuWind: https://5g-ppp.eu/virtuwind/

On 17 Dec 2015, at 7:56, Jon Crowcroft wrote:

> Great article...one thing about the 4g..5g evolution is increasing
> cooperation in forwarding and relaying signal, bits, packets (shared 
> cell
> tower/base station/antennae across provider). So direct,mesh,adhoc 
> stop
> just being edge notions, but are all first class part of the 
> architecture
> ("don't fear the edge"). There is huge tension between this trend, and 
> e2e
> security....I have not seen anyone address how to resolve that 
> tension...

---

From: Ingemar Johansson S <[email-masked]>
Date: Thu, 17 Dec 2015 07:25:37 +0000

Hi

/Ingemar

From: Dirk Kutscher [mailto:[email-masked]]
Sent: den 16 december 2015 19:41
To: [email-masked]; [email-masked]; gaia; [email-masked]; [email-masked]; [email-masked]
Subject: [5gangip] 5G: It's the Network, Stupid

Hi,

Abstract:

Thanks,
Dirk

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 17 Dec 2015 07:56:59 +0000

Great article...one thing about the 4g..5g evolution is increasing
cooperation in forwarding and relaying signal, bits, packets (shared cell
tower/base station/antennae across provider). So direct,mesh,adhoc stop
just being edge notions, but are all first class part of the architecture
("don't fear the edge"). There is huge tension between this trend, and e2e
security....I have not seen anyone address how to resolve that tension...

---

From: Michael Welzl <[email-masked]>
Date: Thu, 17 Dec 2015 10:49:40 +0100

> On 17 Dec 2015, at 10:43, Dirk Kutscher <[email-masked]> wrote:
> 

Why not?

Cheers,
Michael

> object encryption and authentication seems to be the way. Of course there are other challenges for that, too – key management for example.
>  
> --
> Dirk
>

---

From: Nishanth Sastry <[email-masked]>
Date: Thu, 17 Dec 2015 12:42:38 +0000

E2E security in 5G can be addressed through network slicing, another 
concept which seems to be included in many 5G proposals. If each 
application has its own slice, it can screw up but wont be able to 
affect other applications. Within each slice, E2E security can be 
enforced in an application specific manner. Even better would be if we 
can make each flow be its own slice. This may seem to be overly 
heavyweight, but is along the lines of what Bromium  is trying to do for 
desktops, isolating processes and data from each other using 
"microvisors": http://www.bromium.com/why-bromium/how-we-do-it.html We 
just need to do it for networks :)

nishanth
—

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 17 Dec 2015 19:39:03 +0000

That is only true if stat mux transport is not used for backhaul/midhaul. If OTN or DWDM is used for isolation of slices then of course no interference is possible however with a packet mix there is the possibility of DOS or at the least Denial of QOS (DOQ?) but in general you are right that properly sliced there should be minimal security impacts between slices.

Peter

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Nishanth Sastry
Sent: Thursday, December 17, 2015 7:43 AM
To: Jon Crowcroft
Cc: [email-masked]; gaia; [email-masked]; Dirk Kutscher; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] [gaia] 5G: It's the Network, Stupid

nishanth
—

_______________________________________________
5gangip mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/5gangip

---

From: Nishanth Sastry <[email-masked]>
Date: Thu, 17 Dec 2015 21:21:32 +0000

Agree. If we were to do flow level isolation, I would imagine it would 
be a realised as a trusted application requesting new per-flow slices on 
a given operator's network, or, if we go down the bromium route, the 
network itself spinning up a new "micro-slice" for every new flow rather 
than the user or UE obtaining slices on demand.

[However, the academic in me wants to note that user identities are much 
stronger in cellular networks than in the fixed-line Internet, so it is 
not impossible to have a model where the operators networks are simply a 
platform for creating new slices and hosting application-specific VMs, 
and the user creates and is charged per slice (one could have S/M/L/XL 
slices which are differently priced). The user (or an app on the user's 
behalf) then decides which flows can interfere with each other, and 
derive stat muxing benefits, and which flows need to be isolated from 
each other in different slices. Different users' slices would by default 
be in different slices, which brings back the "Silos in the Network" 
problem that Dirk talks about in his article. :-)]

nishanth
—

On 17 Dec 2015, at 17:49, Linda Dunbar wrote:

> But it is not realistic to expect operators networks to take control 
> requests from individual users/handsets. There has to be an 
> authenticated application controller that makes requests/commands to 
> the sliced network.
>
> My two cents.
>
> Linda
>
> Cc: [email-masked]; gaia; [email-masked]; Dirk Kutscher; 
> [email-masked]; [email-masked]; [email-masked]
> heavyweight, but is along the lines of what Bromium  is trying to do 
> for desktops, isolating processes and data from each other using
>>> network evolution. I might publish this as paper later, but wanted 
>>> to
>>> get

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 17 Dec 2015 21:42:03 +0000

Kirk,

Thanks for the interesting blog.

One comment on your writing: you notion of SDN is too narrowly focused.  SDN doesn't have to be OpenFlow.

SDN can be Application Controller (such as the CDN controller) using various hooks from the underlay network to achieve more efficient control of their own traffic.
The centralized controller will be service oriented. CDN's central controller is different from the Real Media central controller.

Linda Dunbar

From: Stackevo-discuss [mailto:[email-masked]] On Behalf Of Dirk Kutscher
Sent: Thursday, December 17, 2015 3:34 AM
To: Ingemar Johansson S; [email-masked]; [email-masked]; gaia; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Stackevo-discuss] [5gangip] 5G: It's the Network, Stupid

Hi Ingemar,

thanks for the feedback.

Cheers,
Dirk

From: Ingemar Johansson S [mailto:[email-masked]]
Sent: Donnerstag, 17. Dezember 2015 08:26
To: Dirk Kutscher; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; gaia; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: Ingemar Johansson S
Subject: RE: [5gangip] 5G: It's the Network, Stupid

Hi

/Ingemar

Hi,

Abstract:

Thanks,
Dirk

---

From: AshwoodsmithPeter <[email-masked]>
Date: Fri, 18 Dec 2015 14:15:17 +0000

I tend to agree. A slice per user, except in exceptional cases would seem unlikely. Since a slice requires multiple resources be allocated end to end the concept most likely will work best for a set of users that share a common QOS/QOE/Admin requirement.

Essentially QOS/QOE within a slice will still have to be addressed with the tools we already have.

Peter

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Thursday, December 17, 2015 12:49 PM
To: Nishanth Sastry; Jon Crowcroft
Cc: [email-masked]; gaia; [email-masked]; Dirk Kutscher; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid

My two cents. 

Linda 

-----Original Message-----
From: Stackevo-discuss [mailto:[email-masked]] On Behalf Of Nishanth Sastry
Sent: Thursday, December 17, 2015 6:43 AM
To: Jon Crowcroft
Cc: [email-masked]; gaia; [email-masked]; Dirk Kutscher; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid

nishanth
—

On 17 Dec 2015, at 7:56, Jon Crowcroft wrote:

> cell tower/base station/antennae across provider). So 
> direct,mesh,adhoc stop just being edge notions, but are all first 
> class part of the architecture ("don't fear the edge"). There is huge 
> tension between this trend, and e2e security....I have not seen anyone 
> address how to resolve that tension...
>> network evolution. I might publish this as paper later, but wanted to 
>> get it out early and ask for comments – so would be grateful for any 
>> feedback.
>> It’s not very polished and slightly long, but hopefully 
>> understandable enough. Take it as a “position paper” for now.
>>
>>
>>
>> Abstract:
>>
>> comprehensive and integrated orchestration and management functions 
>> in order to improve “end-to-end” managebility and programmability, 
>> derived from NGMN and similar requirements. While these are important 
>> challenges, this memo takes the perspective that in order to arrive 
>> at a more powerful network, it is important to understand the pain 
>> points and the reasons for certain design choices of today’s 
>> networks. Understanding the drivers for traffic management systems, 
>> middleboxes, CDNs and other application-layer overlays should be 
>> taken as a basis for analyzing 5G uses cases and their requirements. 
>> In this memo, I am making the point that many of today’s business 
>> needs and the ambitious 5G use cases do call for a more powerful data 
>> forwarding plane, taking ICN as an example. Features of such a 
>> forwarding plane would include better support for heterogeneous 
>> networks (access networks and whole network deployments), multi-path 
>> communication, in-network storage and implementation of operator 
>> policies. This would help to avoid overlay silos and finally simplify 
>> network management.
>>
>>
>>

---

From: Joe Touch <[email-masked]>
Date: Mon, 21 Dec 2015 15:55:02 -0800

> I strongly support the concept of network slicing for Applications or IoT networks. 

FWIW, I do not - in specific, I support the notion of per-service
overlays, but would not call them "slices".

Slices are an artifact of an OS-view of the network. It's a network
partitioning model that considers cross-overlay interaction only as a
violation of the model itself.

We should be careful to consider that networks end at network interfaces
and network interface names, not OS partitions - and OS partitions are
the baggage that comes with the term "slice".

Joe

---

From: Theodore V Faber <[email-masked]>
Date: Tue, 22 Dec 2015 15:48:44 +0000

>violation of the model itself.

Just to defend my tribe a bit, I’d say more of a telco-view of the
network.  Providing isolated strictly defined services - e.g. 3kHz voice
channels - lets you reason about partitioning and service development both
at the cost of maintaining a stranglehold on what gets deployed.  Slices
only enforce their isolation and guarantees if all the equipment has
capabilities and is management appropriate to it.

Yeah, there’s an OS/distributed systems feel to that, but because the
constraints now extend out of a chassis and beyond a LAN, telco analogies
make more sense to me.

I know you (Joe) know that, but I think it’s worth saying to the group
because the more strictly you adhere to a slicing model the more
constraints you put on your equipment and management.  In a small network
- that might be as big as a municipality - those constraints seem more
reasonable to me than in the capital-I Internet.  The cost of enforcing or
even encouraging those constraints across many providers (of equipment and
service) starts to get prohibitive.  It had better be worth it, and to me
there are few cases where it is.

That leaves aside arguments that diversity of equipment and management may
be good for the Internet.  Innovation often comes from letting people
loose in a lightly constrained playground.

-- 
Ted Faber <[email-masked]>
Engineering Specialist
Computer Systems Research Department
310-336-7373