Re: [Stackevo-discuss] [5gangip] 5G: It's the Network, Stupid

Bill Gage <Bill.Gage@huawei.com> Tue, 22 December 2015 19:18 UTC

Return-Path: <Bill.Gage@huawei.com>
X-Original-To: stackevo-discuss@ietfa.amsl.com
Delivered-To: stackevo-discuss@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9BE01A8A9A for <stackevo-discuss@ietfa.amsl.com>; Tue, 22 Dec 2015 11:18:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 276awK1R53wG for <stackevo-discuss@ietfa.amsl.com>; Tue, 22 Dec 2015 11:18:43 -0800 (PST)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75EBA1A8A99 for <stackevo-discuss@iab.org>; Tue, 22 Dec 2015 11:18:43 -0800 (PST)
Received: from 172.18.9.243 (EHLO dfweml701-chm.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLF48391; Tue, 22 Dec 2015 13:18:41 -0600 (CST)
Received: from YYZEML702-CHM.china.huawei.com (10.218.33.72) by dfweml701-chm.china.huawei.com (10.193.5.50) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 22 Dec 2015 11:18:41 -0800
Received: from YYZEML703-CHM.china.huawei.com ([169.254.5.88]) by YYZEML702-CHM.china.huawei.com ([169.254.6.3]) with mapi id 14.03.0235.001; Tue, 22 Dec 2015 14:18:40 -0500
From: Bill Gage <Bill.Gage@huawei.com>
To: Joe Touch <touch@isi.edu>, Dino Farinacci <farinacci@gmail.com>
Thread-Topic: [5gangip] [Stackevo-discuss] 5G: It's the Network, Stupid
Thread-Index: AQHRPOnL4GHQc/i6uEm4Ce0nQEgit57XX8/A
Date: Tue, 22 Dec 2015 19:18:39 +0000
Message-ID: <26426B4FF145B449A3D1FAC13C6B297833BBDB31@YYZEML703-CHM.china.huawei.com>
References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <CAEeTej+pHehyX7+qteogQcAkCcJKYhZoQKStuXGmAzWRj1_rXQ@mail.gmail.com> <F8355406-91C7-4B96-995C-1AD9D7997DC1@kcl.ac.uk> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> <56789156.2020704@isi.edu> <6EE22057-5EB9-4489-A50D-7B92DA2B96AF@gmail.com> <5679857D.9000602@isi.edu>
In-Reply-To: <5679857D.9000602@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.193.60.93]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0201.5679A212.00AF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.88, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 81e4325eab48a4823c921bbc22b71395
Archived-At: <http://mailarchive.ietf.org/arch/msg/stackevo-discuss/s5xBK_zys38mipfZCuxzRDxLp60>
X-Mailman-Approved-At: Wed, 30 Dec 2015 05:00:44 -0800
Cc: "stackevo-discuss@iab.org" <stackevo-discuss@iab.org>, "5gangip@ietf.org" <5gangip@ietf.org>
Subject: Re: [Stackevo-discuss] [5gangip] 5G: It's the Network, Stupid
X-BeenThere: stackevo-discuss@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IP Stack Evolution Discussion List <stackevo-discuss.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stackevo-discuss/>
List-Post: <mailto:stackevo-discuss@iab.org>
List-Help: <mailto:stackevo-discuss-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/stackevo-discuss>, <mailto:stackevo-discuss-request@iab.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Dec 2015 19:18:45 -0000

In the (5G) wireless world, a "network slice" means a collection of service functions, network resources and radio access configurations that are combined together to meet the requirements of a specific use case or business model. For example, there may be a network slice for video traffic, a slice for M2M traffic, and a slice for regular web browsing traffic. 

Each network slice may involve a specific set of (virtual) network functions and each slice is designed to operate in isolation so that operations in one slice do not negatively impact services in other slices. It is essentially a traffic- and service-management tool.

So yes, a slice is a form of virtual network but not a VPN per se (in the enterprise or multi-tenant sense). A slice may be something that a mobile operator uses internally to manage different types of traffic, or it may be something used to provide a VPN-like service to a particular customer (e.g. for an MVNO overlay).

Like it or not, "network slice" seems to the name that various organisations have given to this concept.

Cheers ...

[I tried to trim the receiver list just a little :-]


> -----Original Message-----
> From: Joe Touch [mailto:touch@isi.edu]
> Sent: Tuesday, December 22, 2015 12:17 PM
> Subject: Re: [5gangip] [Stackevo-discuss] [gaia] 5G: It's the Network,
> Stupid
> 
> VPNs often have a lot of baggage, notably that an end system can belong
> to only one at a time.
> 
> Slices have the baggage that a process can belong to only one slice at a
> time.
> 
> I don't know if we strictly need a new term - virtual networks seems
> fine to me (which, IMO, are synonymous with overlays) - but VPNs of all
> types and slices have this baggage that is useful to avoid.
> 
> Joe
> 
> On 12/22/2015 8:57 AM, Dino Farinacci wrote:
> > Why does yet another term need to be defined for what has been
> traditionally called a multi-tenant VPN.
> >
> > Dino
> >
> >> On Dec 21, 2015, at 3:55 PM, Joe Touch <touch@isi.edu> wrote:
> >>
> >>
> >>
> >> On 12/17/2015 9:49 AM, Linda Dunbar wrote:
> >>> 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
> >>