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

Dino Farinacci <farinacci@gmail.com> Tue, 22 December 2015 19:38 UTC

Return-Path: <farinacci@gmail.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 27CED1A8ABE; Tue, 22 Dec 2015 11:38:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 bOx_jKuP9SVL; Tue, 22 Dec 2015 11:38:04 -0800 (PST)
Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B4301A8ABC; Tue, 22 Dec 2015 11:38:04 -0800 (PST)
Received: by mail-pf0-x229.google.com with SMTP id u7so64394703pfb.1; Tue, 22 Dec 2015 11:38:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5I6V0VOMqStvItIaANw2gowojL+zzFDuGNE9tOzmSwI=; b=BdxXrUkBlliHSRaI2AzjAwuayVDWen96utlzvFG5T1SEEyCnQYQU5H2wIrjJ6q8pmp cK72/flr8v+26Ic1mJok4bkRZKBFT6ArYJB25muwpazLoS/5JqJyqgGP2Q8C2sD4h1xi bBVbIIeDhSAxJAibefqfWOL/cnG+zbhq9Vl1L5xqQx/j7vOp3ijHVe8kvF5a7jeXDJRB RAWFS9W+DWJ05UTQbp7sUt15Iq+Y7n7pD+tmdl1TgsYW9phLGZXxtGiNaBqxBj7llSsd pZhPdLFHmJIji4y1PW+oDYn7CXztQc385XP2r7XbFPTToG9fTmoL8SCn9fZf7xcGESLZ Lsug==
X-Received: by 10.98.70.12 with SMTP id t12mr11877717pfa.38.1450813084108; Tue, 22 Dec 2015 11:38:04 -0800 (PST)
Received: from [172.20.10.2] (mobile-166-171-251-206.mycingular.net. [166.171.251.206]) by smtp.gmail.com with ESMTPSA id ud10sm47657027pab.27.2015.12.22.11.38.02 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Dec 2015 11:38:02 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E20AF3BC87@szxeml559-mbs.china.huawei.com>
Date: Tue, 22 Dec 2015 11:38:03 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <D614CD81-744F-4F66-BDDF-BC20608F1FA4@gmail.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> <7AE6A4247B044C4ABE0A5B6BF427F8E20AF3BC87@szxeml559-mbs.china.huawei.com>
To: AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stackevo-discuss/mNJGR3pd3Qna1wM8-BAGjoaPPlQ>
X-Mailman-Approved-At: Wed, 30 Dec 2015 05:00:44 -0800
Cc: "icnrg@irtf.org" <icnrg@irtf.org>, Joe Touch <touch@isi.edu>, gaia <gaia@irtf.org>, "stackevo-discuss@iab.org" <stackevo-discuss@iab.org>, "marnew@iab.org" <marnew@iab.org>, Linda Dunbar <linda.dunbar@huawei.com>, Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>, "5gangip@ietf.org" <5gangip@ietf.org>, Nishanth Sastry <nishanth.sastry@kcl.ac.uk>, Dirk Kutscher <Dirk.Kutscher@neclab.eu>, "dtn-interest@irtf.org" <dtn-interest@irtf.org>
Subject: Re: [Stackevo-discuss] [5gangip] [gaia] 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:38:06 -0000

> Couple of comments from my perspective before disappearing for Xmas.
>  
> > Slices have the baggage that a process can belong to only one slice at a time.
>  
> Not always. A process which is implementing an air interface could in fact be implementing several slices in the same process. Or same core.

With LISP, if you assign an EID to either a VM, container, or app in a container, at each granularity, they can appear in different VPNs. For instance. If you had a container with IP address 1.1.1.1 and another IP address 2.2.2.2 say on a loopback address, the application that sourced from 2.2.2.2 could be in a different VPN than if the container itself sent packets (say a DNS lookup or any other background application that is sourcing from 1.1.1.1).

>  
> > Why does yet another term need to be defined for what has been traditionally called a multi-tenant VPN.
>  
> I believe a slice is much more than a VPN however VPN technologies are likely a component part of what a slice 'is'.
>  
> Here is a definition I have found helpful: 
>  
> To define a slice we need to look at it from the perspective of both the end devices (1) and the network (2) so:
>  
> (1)   From the perspective of the end devices it’s relatively simple. A slice is a way to group end devices that share common QOS/QOE and Administration/Geographic area etc.
>  
> (2)   From the perspective of the network a slice is much more complicated. Essentially a slice is a set of subsets of the all the network equipment that makes up the 5G network from Antennas through to core processing. Thus
> Slice_i =   Subset of(All_Antennas)        U 
>             subset of(All_Fronthaul)       U
>             Subset of(All CRAN fabric)     U
>             Subset of(All CRAN processing) U
>             Subset of(ALL Numerologies)    U
>             Subset of(All DC fabric)       U
>             Subset of(All DC processing) 
>  
> Where of course Subset(X) can contain all or none of the elements in X.
>  
> So to bring up a slice we need to allocate antennas, configure the fronthaul to the CRAN fabric, allocate the CRAN fabric, allocate processing resources ( shared or unique in the CRAN), populate those processing resources with the code (Numerology) that implements the RAT, then we need to allocate packet backhaul bandwidth in the CRAN or DC fabric, then assign compute resources (shared or stand alone for the packet core processing).
>  
> From this we can see that a multi tenant VPN can be used to implement a subset of a DC fabric and interconnect a subset of all DC processing. However there are a number of other areas of interest to the implementation of a slice that are well outside the scope of a VPN.
>  
> Note also that a slice can be isolated from another slice in time, space, frequency or statistically in each of those subsets and in particular the fronthaul and RAT require very hard boundaries between slices while as we get further towards packet processing the boundaries can be less ridgid.
>  
> Hence the need for a new term.

If you use the right network architecture, a VPN can have these properties.

Dino

>  
> Peter