Subject: [5gangip] Network Slicing - a suggestion that we meet to discuss in Seoul

From: Stewart Bryant <[email-masked]>
Date: Tue, 1 Nov 2016 15:21:30 +0000

(Resent with correct draft alias)

Hi,

We were trying to pull together a problem statement for network slicing
in a 5G context to understand how well the current IETF protocols 
address this problem, what their short comings might be, and what IETF 
work is necessary to have a deployable protocol suite to address this need.

We have set down our first thoughts in
https://tools.ietf.org/html/draft-dong-network-slicing-problem-statement-00

We find that there are a number of groups doing similar work throughout 
the IETF.

The following comprehensive draft was directed at the ANIMA WG
https://datatracker.ietf.org/doc/draft-galis-anima-autonomic-slice-networking/

https://tools.ietf.org/html/draft-vonhugo-5gangip-ip-issues-00
is a detailed discussion the position of network slicing in a contest of 
next generation networks

https://tools.ietf.org/html/draft-xuan-dmm-multicast-mobility-slicing-00
looks at multicasting in a sliced context

and

https://tools.ietf.org/html/draft-ietf-teas-actn-framework-01
looks at slicing in a context of traffic engineering.

Our thoughts are that network slicing spans a number of deployment
scenarios, and has a number of diverse applications, ranging from
fragile applications, through to providing enhanced security and 
availability.

Elements of the problem and the resultant solution have a close affinity
to DETNET. There is clearly an affinity with VPN technologies, although
none of the existing VPNs provide the degree of isolation that we think
is required.

We note that there seems to be no natural home for all of the aspects
of this problem.

It therefore seems that if would be a good idea for those interested
in this problem to get together at some point during IETF to swap notes
and share our views on the problem space and how to move forward
with addressing it.

Is there any interest in meeting up to discuss this in Seoul?

Best regards

Stewart/Mach/Jie

---

From: Joe Touch <[email-masked]>
Date: Tue, 1 Nov 2016 09:55:14 -0700

Hi, all,

> work is necessary to have a deployable protocol suite to address this

I've seen this term around for a while, and continue to consider it
nonsensical.

It originally referred to a way of cutting OS resources and tying them
to a distributed system in PlanetLab, which had no support for network
virtualization. It has since been used to refer to E2E virtual nets
(distinct from VPNs, which often tether individual hosts to a private
net over the public Internet), but all networks have always had that
capability.

IMO, this term isn't related to the Internet architecture at all. It
needs to correctly tie the existing network overlays that the Internet
has supported for a very long time to OS resources.

I.e., most of the work in defining "network slicing" needs to happen
inside the OS, which is out of scope for the IETF. A properly defined
E2E virtual network terminates at (virtual) network interfaces, which is
compatible with either a sliced OS or a non-sliced OS.

Joe

---

From: Ca By <[email-masked]>
Date: Tue, 1 Nov 2016 10:27:17 -0700

> compatible with either a sliced OS or a non-sliced OS.

+1

Has there been a liason statement from the 3GPP requesting this work of the
IETF?

Not trying to limit innovation here, it just seems the problem statement is
not well defined in the IETF.... it is very well defined and being worked
in the 3GPP.  So, folks that have ideas on problems to solve in this space
may best spend their time in 3GPP where most of this work is being done.

CB

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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 1 Nov 2016 19:36:04 +0000

On 01/11/2016 17:27, Ca By wrote:
>
>
> On Tue, Nov 1, 2016 at 9:55 AM, Joe Touch <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi, all,
>
>
>     > work is necessary to have a deployable protocol suite to address
>     this
>     > need.
>
> Has there been a liason statement from the 3GPP requesting this work 
> of the IETF?
>
> Not trying to limit innovation here, it just seems the problem 
> statement is not well defined in the IETF.... it is very well defined 
> and being worked in the 3GPP.  So, folks that have ideas on problems 
> to solve in this space may best spend their time in 3GPP where most of 
> this work is being done.

3GPP cannot however change IETF protocols, such as the routing protocols 
or the network layer protocols to support this.

At this stage I am thinking of a discussion amongst interested parties 
to see what if anything needs doing in the IETF.

Stewart

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 1 Nov 2016 19:39:34 +0000

> compatible with either a sliced OS or a non-sliced OS.

Joe, we possibly have different ideas as to what network slicing is.

My assumption is that it is a way that we can create multiple virtually 
networks
over a common base network with a higher degree of isolation between
VPNs and much higher performance guarantees than we currently achieve.

If we need a new name, we need a new name, but the concept does not seem
to align with the definition you hints at.

- Stewart

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 1 Nov 2016 14:25:56 -0700

Network slicing has become de facto standard terminology in context of 5G.

It would be rather useful to:
-agree on terminology 
-discuss data modeling, interrelated technologies - radio, packet core, transport, optical to mention some and how they could work together/form in a "slice"
-bring together experts in these, rather disjointed domains.
-many other things 

Regards,
Jeff

> On Nov 1, 2016, at 12:39, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 
> My assumption is that it is a way that we can create multiple virtually networks
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 2 Nov 2016 10:23:31 -0500

Folks, sorry I reduced the cc list, our list distributor somehow does
not like long cc lists :-)

On Wed, Nov 2, 2016 at 9:05 AM, Joe Touch <[email-masked]> wrote:
>
>
>> On Nov 2, 2016, at 3:40 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
>>
>> Looks correct, Joe, but then overlays as we traditionally see them do not necessarily provide the degree of isolation that we seem to be after here.
>
> It seems like you're just noting that most Internet overlays don't bother with provisioning...
>
>>
>> And this is where DetNet comes into play. At the extreme of the definition, a deterministic flow will traverse the network is such a fashion that the influence from other flows is not observable on that flow, e.g., no jitter and no congestion loss induced by other flows holding or clogging a link somewhere down in the fabric. Which means that one overlay will experience the same connectivity as if the nodes that compose it were physically meshed with serial wires.
>
> If you're talking about a flow on an otherwise empty overlay, that is just a fully provisioned overlay. If you're talking about multiple flows within an overlay being isolated this way, it's not and Internet overlay. Maybe an ATM overlay.
>
> But these are still IMO examples of provisioning - the kind we have been dong since the phone network for over 50 years. No need for new marketing terms

 I agree with Joe.
I have a question though:
I think overlays are based on tunneling at the IP level, right?
Detnet flows that Pascal is talking about require Time Sensitive
Networking (TSN) switch support at Layer 2 as per 802.1 work.
I am not sure if detnet will end up defining a tunneling based IP layer for TSN?

---

From: Joe Touch <[email-masked]>
Date: Wed, 2 Nov 2016 08:30:31 -0700

> I think overlays are based on tunneling at the IP level, right?
Internet overlays are, but there are other overlays too.

> Networking (TSN) switch support at Layer 2 as per 802.1 work.

A tunnel is a link (see draft-ietf-intarea-tunnels). Any link that
supports the provisioning requirements of Detnet should suffice.

> I am not sure if detnet will end up defining a tunneling based IP layer for TSN?
It clearly *can*, as long as it has a way to ensure the provisioning.
But that's true for using Detnet over any link technology - whether
based on a tunnel or not.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Wed, 2 Nov 2016 10:23:56 -0700

> I think overlays are based on tunneling at the IP level, right?

Not always. For example, ILA is a technique that can be used to create
overlays without tunneling.

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 2 Nov 2016 13:28:36 -0400

> overlays without tunneling.

Is and EID/IP mapping within the OS a tunnel?  Or is an implicit tunnel 
the same in important ways as explicit tunnels?

---

From: nfinn <[email-masked]>
Date: Wed, 2 Nov 2016 10:31:59 -0700

You nailed it, Joe.

Overlays provide connectivity separation.

DetNet provides resource (bandwidth, latency) separation.

They could be used together, 1:1, to provide what some people, perhaps, think “rigid slicing” should be.

But, overlays for connectivity separation scale to much larger numbers of “slices" than does resource separation, IMO.  I’m not sure there is a match in expectations, so I wouldn’t call DetNet “the answer”.

If you’re talking about rigidly slicing AT&T vs. Verizon vs. T-Mobile, no problem.  If you’re talking about rigid slicing per VPN, I have doubts.

I think of TSN/DetNet as TDM-over-connectionless.  Expensive, but when you need it, nothing else will do.

So, perhaps “slicking” has different meaning, depending on the needs of the users of the slices.  It’s just overlays where that’s sufficient, and it’s CBR (overlay with a rigid BW/latency reservation) for those who need it enough to pay for it.

— Norm

> On Nov 2, 2016, at 8:30 AM, Joe Touch <[email-masked]> wrote:
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 2 Nov 2016 10:31:46 -0700

On 11/2/2016 10:28 AM, Robert Moskowitz wrote:
> Is and EID/IP mapping within the OS a tunnel?  Or is an implicit
> tunnel the same in important ways as explicit tunnels?
There are also tunnels that achieve the exact equivalent of
encapsulation through stateful translation and/or header compression. So
it's not always easy to identify what is a tunnel and what is not - the
key is whether it emulates the properties of a link.

Joe

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 2 Nov 2016 13:42:17 -0400

On 11/02/2016 01:31 PM, Joe Touch wrote:
> encapsulation through stateful translation and/or header compression. 
> So it's not always easy to identify what is a tunnel and what is not - 
> the key is whether it emulates the properties of a link.

'Emulates properties of a link'   Hmmm.  Good way to put a technical 
bound on 'tunneling'.

And it gets down to how it is implemented, not necessarily how it is 
described.

Bob

---

From: Tom Herbert <[email-masked]>
Date: Wed, 2 Nov 2016 10:44:31 -0700

On Wed, Nov 2, 2016 at 10:28 AM, Robert Moskowitz <[email-masked]> wrote:
>>>>> Looks correct, Joe, but then overlays as we traditionally see them do
>>>>> not necessarily provide the degree of isolation that we seem to be after
>>>>> here.
>>>>
>>>>> And this is where DetNet comes into play. At the extreme of the
>>>>> definition, a deterministic flow will traverse the network is such a fashion
>>>>> that the influence from other flows is not observable on that flow, e.g., no
>>>>> jitter and no congestion loss induced by other flows holding or clogging a
>>>>> link somewhere down in the fabric. Which means that one overlay will
>>>>> experience the same connectivity as if the nodes that compose it were
>>>>> physically meshed with serial wires.
>>>>
>>>> If you're talking about a flow on an otherwise empty overlay, that is
>>>> just a fully provisioned overlay. If you're talking about multiple flows
>>>> within an overlay being isolated this way, it's not and Internet overlay.
>>>> Maybe an ATM overlay.
>>>>
>>>> But these are still IMO examples of provisioning - the kind we have been
>>>> dong since the phone network for over 50 years. No need for new marketing
>>>> terms
>>>
>>>   I agree with Joe.
> Is and EID/IP mapping within the OS a tunnel?  Or is an implicit tunnel the
> same in important ways as explicit tunnels?
>
Implicit. For instance, in Linux it is implemented as host routes. For example:

./ip route add 3333::2000:0:0:2/128 encap ila 2222:0:0:2 dev eth0

So sending to destination address 3333::2000:0:0:2 gets translated to
2222:0:0:2:2000:0:0:2. At 2222:0:0:2: host reverse translation is done
to get back to  3333::2000:0:0:2.

Explicit tunnels could be created however there's really not a lot of
things that could be configured specifically for a tunnel. Also, we
expect devices to have large numbers of ILA routes to destinations and
set may be very dynamic, so creating a tunnel instance for each of
those might not scale.

Tom

---

From: Joe Touch <[email-masked]>
Date: Wed, 2 Nov 2016 10:48:34 -0700

On 11/2/2016 10:42 AM, Robert Moskowitz wrote:
> ...
IMO, the only difference between a tunnel and a link is that a link is real.

In every other way, they ought to be defined identically.

> And it gets down to how it is implemented, not necessarily how it is

Absolutely.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 2 Nov 2016 10:51:36 -0700

> Overlays provide connectivity separation.
IMO, overlays provide a network out of virtual links. They connect
systems that are not otherwise connected at that layer, the same way any
other layer or network does.

> DetNet provides resource (bandwidth, latency) separation.

That sounds like provisioning when done at the lowest (link/tunnel)
layer, or setting up automated subprovisioning when implemented at upper
layers (e.g., so protocols like RSVP can reserve those resources).

> But, overlays for connectivity separation scale to much larger numbers of “slices" than does resource separation, IMO.  I’m not sure there is a match in expectations, so I wouldn’t call DetNet “the…
Some overlay technologies scale whereas others don't.

I.e., I agree there may be limits to Detnet, but that's just a limit of
an instance of provisioning - not of the concept of provisioning.

Joe

---

From: Antoni Przygienda <[email-masked]>
Date: Wed, 2 Nov 2016 17:55:08 +0000

Thoughtful observations with which I fully agree, Norm …  Because a copy/paste of a ‘colored box representing a slice’ is cheap in PowerPoint it does not mean that it’s technically and even worse, economically feasible … overlays can be made cheap & plentiful (edge state synchronization) while in-network state a good tunnel represents cannot (otherwise we’ll be all speaking ATM today). 

The ‘tunneling with TDM’ part of the thread seems to be rehash of PWE largely …  And LISP-likes is a red herring here. It has a place but it’s a part of addressing solution, not transport solution in my view …  

--- tony

<[email-masked] on behalf of [email-masked]> spake:

    You nailed it, Joe.

    

    

    — Norm

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 2 Nov 2016 18:53:17 +0000

> IMO, the only difference between a tunnel and a link is that a link is real.

Well yes and no.

It is rather common to discover a degree of unanticipated virtualisation 
at the next layer down. So if your service provider takes your physical 
link and carries it over their network in a pseudowire, or over OTN is 
your link still a link according to your definition?

Stewart

---

From: Joe Touch <[email-masked]>
Date: Wed, 2 Nov 2016 12:01:45 -0700

On 11/2/2016 11:53 AM, Stewart Bryant wrote:
> It is rather common to discover a degree of unanticipated
> virtualisation at the next layer down. So if your service provider
> takes your physical link and carries it over their network in a
> pseudowire, or over OTN is your link still a link according to your
> definition?
That's precisely the point.

Yes, at that point the link isn't a link anymore, but it is a tunnel.

If they do it right, you won't (and can't) know the difference.

Joe

---

From: nfinn <[email-masked]>
Date: Wed, 2 Nov 2016 15:08:16 -0700

Hmm..  Sort of.  True for connectivity.  But, if you’re trying to guarantee 0 congestion loss and maximum latency, when you replace a physical link with a tunnel, the number of buffers you need increases, as well as the latency you can guarantee.  Same principle behind the math, in that even physical links have finite latency variation.  But the quantitative difference is very noticeable.  In particular, given the same exact physical network, abstracting some segment of the path as a higher-variation logical link will result in a worse end-to-end latency guarantee compared to a flat, no-tunnel model, because of ingress and/or egress buffers at the ends of the logical link.  At least, that’s what my work has led me to conclude.

Such aggregation is necessary for scaling, for sure.  But, I don’t think it comes for free, or is invisible.

— Norm

---

From: Joe Touch <[email-masked]>
Date: Wed, 2 Nov 2016 15:30:19 -0700

On 11/2/2016 3:08 PM, nfinn wrote:
> Hmm..  Sort of.  True for connectivity.  But, if you’re trying to guarantee 0 congestion loss and maximum latency, when you replace a physical link with a tunnel, the number of buffers you need increases, as well as the latency you can guarantee.  
Physical links sometimes have buffers too (analog repeaters, recoders,
etc.).

The need for buffers and latency guarantee always depends on what the
layers below you guarantee and what service they provide.
> Same principle behind the math, in that even physical links have finite latency variation.  But the quantitative difference is very noticeable.  In particular, given the same exact physical network, abstracting some segment of the path as a higher-variation logical link will result in a worse end-to-end latency guarantee compared to a flat, no-tunnel model, because of ingress and/or egress buffers at the ends of the logical link.  At least, that’s what my work has led me to conclude.
A flat, no-tunnel link can still have substantial latency variation -
e.g., when a WDM link is rerouted for call packing.

You may be more familiar with more stable physical links and more
variable tunnels, but that's not an inherent property of either.

> Such aggregation is necessary for scaling, for sure.  But, I don’t think it comes for free, or is invisible.

Nothing is free - including rendering a logical signal into the physical
domain (e.g., a bitstream into 4B/5B encoding). Every time you traverse
from one layer to another (including to the physical), a translation is
required that can introduce the need for buffers and variation in delay
and capacity is *possible*.

Joe

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 02 Nov 2016 15:42:14 -0700

In QoS discussions, there are tradeoffs.  You're right, nothing is
free.  In most networking situations, bandwidth efficiency must be
traded off for any improvements in latency, jitter and interactivity.  

Given radio, in what real world situations is this tradeoff a good
idea?

On Wed, 2016-11-02 at 15:30 -0700, Joe Touch wrote:
> > Hmm..  Sort of.  True for connectivity.  But, if you’re trying to
> > guarantee 0 congestion loss and maximum latency, when you replace a
> > physical link with a tunnel, the number of buffers you need
> > increases, as well as the latency you can guarantee.  
> > Same principle behind the math, in that even physical links have
> > finite latency variation.  But the quantitative difference is very
> > noticeable.  In particular, given the same exact physical network,
> > abstracting some segment of the path as a higher-variation logical
> > link will result in a worse end-to-end latency guarantee compared
> > to a flat, no-tunnel model, because of ingress and/or egress
> > buffers at the ends of the logical link.  At least, that’s what my
> > work has led me to conclude.
> > Such aggregation is necessary for scaling, for sure.  But, I don’t
> > think it comes for free, or is invisible.

---

From: Joe Touch <[email-masked]>
Date: Wed, 2 Nov 2016 15:51:31 -0700

> Given radio, in what real world situations is this tradeoff a good
I'm not sure what "given radio" means. Tunnels are a way to share a
single channel for multiple networks. Instead of using frequencies,
codes, or other physical representations of the raw data to keep the
information on the shared channel separate, we use headers and addresses
and demux within the logical information stream rather than in the
physical representation.

The trade-off is that a tunnel provides more flexibility than may be
available in the physical channel. But otherwise, they can be as
efficient (or not), as jittery (or not), as high delay (or not),
depending on the implementation of each.

Joe

---

From: nfinn <[email-masked]>
Date: Wed, 2 Nov 2016 16:42:31 -0700

I think we’re pretty much agreeing violently.

— Norm

> On Nov 2, 2016, at 3:30 PM, Joe Touch <[email-masked]> wrote:
> 
> 
>

---

From: Daniele Ceccarelli <[email-masked]>
Date: Thu, 3 Nov 2016 09:04:32 +0000

I agree with you Norm, and this is why I believe this is a cross issue between TEAS and DETNET. 

The problem here is to reserve resources, with given characteristics (e.g. resiliency and delay) and then guarantee 0 congestion loss and so on.

BR
Daniele  

> -----Original Message-----
> From: detnet [mailto:[email-masked]] On Behalf Of nfinn
> Sent: mercoledì 2 novembre 2016 23:08
> To: Joe Touch <[email-masked]>
> Cc: Tom Herbert <[email-masked]>; Robert Moskowitz <rgm@htt-
> consult.com>; Behcet Sarikaya <[email-masked]>; [email-masked];
> Stewart Bryant <[email-masked]>; [email-masked]
> Subject: Re: [Detnet] [5gangip] Network Slicing - a suggestion that we meet
> to discuss in Seoul
> 
> Hmm..  Sort of.  True for connectivity.  But, if you’re trying to guarantee 0
> congestion loss and maximum latency, when you replace a physical link with
> a tunnel, the number of buffers you need increases, as well as the latency
> you can guarantee.  Same principle behind the math, in that even physical
> links have finite latency variation.  But the quantitative difference is very
> noticeable.  In particular, given the same exact physical network, abstracting
> some segment of the path as a higher-variation logical link will result in a
> worse end-to-end latency guarantee compared to a flat, no-tunnel model,
> because of ingress and/or egress buffers at the ends of the logical link.  At
> least, that’s what my work has led me to conclude.
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 3 Nov 2016 08:29:46 -0400

>  Is there any interest in meeting up to discuss this in Seoul?

Please take a look at draft-ietf-detnet-use-cases and see if your use
case is (sufficiently covered).  If not, We can probably squeeze some
time (max 10min) to talk about the additions you'd like to see in the
use-case document as well as recap/close on any aspects of the on-list
discussion that make sense.

Just let us know and we'll see what we can do.

Lou