Subject: [Nfvrg] 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: nfinn <[email-masked]>
Date: Tue, 1 Nov 2016 10:03:16 -0700

Stewart,

Two comments on draft-dong-network-slicing-problem-statement-00 that may be of interest:

1. In your discussion of dedicated vs. hybrid vs. shared control plane, I would have added, to the sentence describing the advantages of the dedicated control plane, the expense of duplicated effort across slices, e.g.link failure detection (BFD).

2. Although not explicitly discussed in the DetNet documents, IEEE 802.1 Time-Sensitive Networking has the ability, to configure synchronized rotating input and output schedules, with nanosecond granularity, that can erect time-based barriers among a modest number of network slices.

— Norm

> On Nov 1, 2016, at 8:21 AM, Stewart Bryant <[email-masked]> wrote:
> 
> 
> 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 find that there are a number of groups doing similar work throughout the IETF.
> 
> is a detailed discussion the position of network slicing in a contest of next generation networks
> 
> fragile applications, through to providing enhanced security and availability.
> 
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet

---

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 1 Nov 2016 15:35:12 -0700

> to align with the definition you hints at. 

Right. That's because you're describing an overlay.

Overlays have varying degrees of isolation and performance (and
isolation and performance assurance), and always have.

There's no new term needed for that.

Joe

---

From: Joe Touch <[email-masked]>
Date: Tue, 1 Nov 2016 22:57:15 -0700

> On Nov 1, 2016, at 2:25 PM, Jeff Tantsura <[email-masked]> wrote:
> 

In that vein, if you're familiar with 5G terminology, can you explain how "network slicing" differs from overlay provisioning? (Where provisioning is the more commonly used IETF term for configuring resources of a network to ensure predictable service).

Joe

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 2 Nov 2016 10:40:35 +0000

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. 

Cheers,

Pascal

-----Original Message-----
From: detnet [mailto:[email-masked]] On Behalf Of Joe Touch
Sent: mardi 1 novembre 2016 23:35
To: Stewart Bryant <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: Dongjie (Jimmy) <[email-masked]>; Mach Chen <[email-masked]>
Subject: Re: [Detnet] [5gangip] Network Slicing - a suggestion that we meet to discuss in Seoul

On 11/1/2016 12:39 PM, Stewart Bryant wrote:
> 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.

Overlays have varying degrees of isolation and performance (and isolation and performance assurance), and always have.

Joe

---

From: Joe Touch <[email-masked]>
Date: Wed, 2 Nov 2016 07:05:28 -0700

> On Nov 2, 2016, at 3:40 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 

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…

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.

Joe

---

From: Do Truong Xuan <[email-masked]>
Date: Thu, 3 Nov 2016 16:37:11 +0900

Hi !

+1

In the next generation network, IETF protocols and functions could be
changed and managed in a different way.
Network slicing is not just normal virtual private network but with
different requirements (high availability, latency ..) and various
functions.
It's worthy describing this topic in IETF too.

Brs,

On Wed, Nov 2, 2016 at 12:21 AM, Stewart Bryant <[email-masked]>
wrote:

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

-- 

*Truong-Xuan, Do*

PHD Candidate

DCN Lab, Soongsil University

(+82) 10 4473 6869

[email-masked]

---

From: Alex Galis <[email-masked]>
Date: Sat, 5 Nov 2016 12:57:37 +0000

Hi All 

The followings are some additional clarifications and issues related to Slice Networking.

Slice Networking has evolved from a simple network overlay concept used in the last 10 years in distributed and federated testbed research [GENI - http://groups.geni.net/geni/wiki/GENIConcepts] and active networks research to an end-to-end concept covering the radio and non-radio networks inclusive of access, core and edge / enterprise networks.

Key Characteristics:

- It enables the concurrent deployment of multiple logical, self-contained and independent shared or partitioned networks on a common infrastructure platform.

- It enables enabling dynamic multi-service support, multi-tenancy and the integration means for vertical market players.

- Slice Networking is abstracting different physical infrastructures into a logical network that contains shared resources, or dedicated core network equipment, and virtual network functions obtained by breaking down single physical equipment into multiple instances, which are isolated from each other. In addition virtualization of network functions allow to decouple network node functions from hardware appliances in order to create distinct building blocks that can be flexibly chained to create new communication services.

- The separation of different functions by abstractions simplifies the provisioning of services, manageability of networks and the integration and operational challenges especially for supporting communication services.

- It facilitates the use of the principles of software-defined networks and network function virtualization in order to fulfill the business requirements.

- Network operators / ISP can exploit network slicing for reducing significantly operations expenditures, allowing also programmability and innovation, necessary to enrich the offered services from simple communications services to a wider range of business services.

-  It enables Network Operators to offer tailored services and means for network programmability to OTT providers and other market players without changing the physical infrastructure.

As such Slice Networking would considerably transform the networking perspective and enhance Internet architecture by abstracting, isolating, orchestrating and separating logical network behaviors from the underlying physical network resources. 

An initial unified Slice Networking definition that take advantage of the above impactful characteristics is drafted in (*) https://datatracker.ietf.org/doc/draft-galis-anima-autonomic-slice-networking/.

Slice networking is also fully adopted in the context  of 5G research, development and standardisation [see (*)].

It looks like that now is the best timing that this (revised) networking concept be fully evaluated and elaborated in the IETF.

I would be happy to contribute with your support to the creation of a BoF next year at IETF98.   
Such a BoF would cover the impact of slice networking in the data plane, control plane, management plane, topology, routing, traffic engineering, data models, operations, multi-domain, security, life-cycle management of slices (creation, composition, deletion, dimensioning), orchestration, terminology, etc.

I am  happy also to participate in a common meeting at IETF97.

I hope that the above would be of help to you.

See some of you in Seoul

Best Regards

Prof. Alex Galis
University College London (UCL)

 

> On 3 Nov 2016, at 07:37, Do Truong Xuan <[email-masked]> wrote:
> 
> Hi !
> 
> +1
> 
> In the next generation network, IETF protocols and functions could be changed and managed in a different way.
> Network slicing is not just normal virtual private network but with different requirements (high availability, latency ..) and various functions. 
> On Wed, Nov 2, 2016 at 12:21 AM, Stewart Bryant <[email-masked] <mailto:[email-masked]>> wrote:
> 
> https://tools.ietf.org/html/draft-dong-network-slicing-problem-statement-00 <https://tools.ietf.org/html/draft-dong-network-slicing-problem-statement-00>
> 
> https://datatracker.ietf.org/doc/draft-galis-anima-autonomic-slice-networking/ <https://datatracker.ietf.org/doc/draft-galis-anima-autonomic-slice-networking/>
> 
> https://tools.ietf.org/html/draft-vonhugo-5gangip-ip-issues-00 <https://tools.ietf.org/html/draft-vonhugo-5gangip-ip-issues-00>
> https://tools.ietf.org/html/draft-xuan-dmm-multicast-mobility-slicing-00 <https://tools.ietf.org/html/draft-xuan-dmm-multicast-mobility-slicing-00>
> https://tools.ietf.org/html/draft-ietf-teas-actn-framework-01 <https://tools.ietf.org/html/draft-ietf-teas-actn-framework-01>
> Truong-Xuan, Do <>
> [email-masked] <mailto:[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Sat, 5 Nov 2016 16:38:32 -0700

On 11/5/2016 5:57 AM, Alex Galis wrote:
> Slice Networking has evolved from a simple network overlay concept
> used in the last 10 years in distributed and federated testbed
> research [GENI - http://groups.geni.net/geni/wiki/GENIConcepts]

Slicing originated in PlanetLab. There, it is a distributed set of OS
resources that are grouped together.

GENI adds VLAN tagged links. That's it (OK, maybe more sophisticated OS
resource reservation). There's no concept of a network, no overlay, no
network architecture.

A slice thus isn't a network concept at all, and never has been. It is,
at best, a set of resources that a user can configure into a distributed
application. It exists in two testbeds and a lot of marketing material.

An overlay, by contrast, is a network abstraction that has been
developed since the late 1990s with formal definitions.

Joe