From nobody Mon Dec 7 14:30:50 2015 Return-Path: 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 732521B29FF for ; Mon, 7 Dec 2015 14:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 KnOHUECVNwSD for ; Mon, 7 Dec 2015 14:30:46 -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 76FC71B29F5 for ; Mon, 7 Dec 2015 14:30:46 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml706-chm.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTQ77120; Mon, 07 Dec 2015 16:30:44 -0600 (CST) Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0235.001; Mon, 7 Dec 2015 14:30:40 -0800 From: Linda Dunbar To: "stackevo-discuss@iab.org" Thread-Topic: When provider networks don't t trust the stack set by the end points .... Thread-Index: AdExPua6p20KTYEoSD+piZoHokKNhA== Date: Mon, 7 Dec 2015 22:30:40 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657DADD4A@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.76] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657DADD4Adfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0201.56660895.006E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c8c975176b8e039eb145729279cbe8c5 Archived-At: Subject: [Stackevo-discuss] When provider networks don't t trust the stack set by the end points .... X-BeenThere: stackevo-discuss@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IP Stack Evolution Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 22:30:49 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657DADD4Adfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I find the use cases for SPUD are very real and definitely need a good appr= oach to make it happen. However, a lot of discussions have been centered around the SPUD layer bein= g encoded by End Points, and expect the network to apply certain rules for = those traffic. Having an In-band standard signaling among end points and ne= twork has its advantages: allowing network to treat packets without getting= into the encrypted payload, and not requiring any extra components across= the networks between the end points. However, Virtually all traffic today go through provider networks (most li= kely multiple). Provider network usually don't (can't) trust the signaling = or requests from end points because any end points can set their own traffi= c as "requiring the least latency" or "passing through the network". Provi= der network set traffic based on the SLA clients pay. For example all the = DiffServ set by the endpoints are ignored by the provider network, instead = Provider Network set its own DiffServ based on the SLA from the customers. The Network Service Header (NSH) introduced by SFC (http://datatracker.ietf= .org/doc/draft-ietf-sfc-nsh/ ) is effectively another layer of stack added = to the packets (added by the ingress node). My question is: Should SPUD allow multiple types of layer added to data packets? Or only fo= cusing on the layer end points can add? My two cents. Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F657DADD4Adfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I find the use case= s for SPUD are very real and definitely need a good approach to make it hap= pen.

 

However, a lot of d= iscussions have been centered around the SPUD layer being encoded by End Po= ints, and expect the network to apply certain rules for those traffic. Havi= ng an In-band standard signaling among end points and network has its advantages: allowing network to treat packe= ts without getting into the encrypted payload, and not requiring any  = extra components across the networks between the end points.

 

However,  Virt= ually all traffic today go through provider networks (most likely multiple)= . Provider network usually don’t (can’t) trust the signaling or= requests from end points because any end points can set their own traffic as “requiring the least latency” or R= 20;passing through the network”.  Provider network set traffic b= ased on the SLA clients pay.  For example all the DiffServ set by the = endpoints are ignored by the provider network, instead Provider Network set its own DiffServ based on the SLA from the customers.

 

The Network Service= Header (NSH) introduced by SFC (http://datatracker.ietf.org/doc/draft-ietf= -sfc-nsh/ ) is effectively another layer of stack added to the packets (add= ed by the ingress node). 

 

My question is:

Should SPUD allow m= ultiple types of layer added to data packets? Or only focusing on the layer= end points can add?

 

My two cents. =

 

Linda Dunbar

 

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657DADD4Adfweml701chm_-- From nobody Tue Dec 8 00:56:05 2015 Return-Path: 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 8EEAE1A90C7 for ; Tue, 8 Dec 2015 00:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 92hKLIKvNWGi for ; Tue, 8 Dec 2015 00:56:02 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 19C931A90C8 for ; Tue, 8 Dec 2015 00:56:02 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 1C3371A0213; Tue, 8 Dec 2015 09:56:01 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_62E66371-350D-4F98-B2B5-E3E4023048FC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Brian Trammell In-Reply-To: Date: Tue, 8 Dec 2015 09:55:59 +0100 Message-Id: <6689CCA2-CDC4-44AF-BFD4-270EA6E154F4@trammell.ch> References: To: Tom Herbert X-Mailer: Apple Mail (2.2104) Archived-At: Cc: stackevo-discuss@iab.org Subject: Re: [Stackevo-discuss] Scope of stackevo and ossification in DC X-BeenThere: stackevo-discuss@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IP Stack Evolution Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 08:56:04 -0000 --Apple-Mail=_62E66371-350D-4F98-B2B5-E3E4023048FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Tom, (apologies on the delay getting back to this thread -- i'm finally done = traveling, just in time to go off for the holidays...) > On 17 Nov 2015, at 19:49, Tom Herbert wrote: >=20 > [ Reposting from stackevo list] >=20 > Hello, >=20 > Similar to the use of protocols on the Internet we are hitting the > transport protocol ossification problem in the data center. > Specifically, performance optimizations in networking devices only > support TCP or UDP, and without these optimizations this negatively > impacts our use of other protocols. Right. But this is a fundamental problem, I think. NIC offloads reach = pretty deeply into the transport protocol, and as such won't work with = new transports whether they're encrypted or not until those new = transports. A question: for NIC offload, how much of the win comes from = segmentation offloading, and how much comes from other trickery? If the = biggest win really is bundling a bunch of packets into a single context = switch, then how would the performance of the current offload = architecture compare with a smart library on top of approaches like = netmap? > One example of this is the need > for fine grained ECMP which has become driver behind many of the > foo-over-UDP proposals (e.g. MPLS/UDP, GRE/UDP, ...). So this is a separate issue -- ECMP is a (semi-elegant) hack, predicated = on the assumption that things on a five-tuple need to stay together and = things on separate five-tuples don't. NAT + TCP (any = reordering-intolerant transport, really) makes this assumption more or = less hold. Driving it in the opposite direction -- using knowledge that = there's ECMP on path to do cheap traffic engineering -- leads to the = unintended consequences that foo-over-udp brings with it. What you really want architecturally is a way for the network layer (at = a gateway) to explicitly say "keep these packets together" and "it's = okay to split these packets apart". It'd be even better if we had a way = to request/measure/enforce actual path diversity without manually = managing tunnels, but this is sadly explicitly a non-feature of our = routing protocols. In any case this seems to have a harder incremental = deployment story than simple transport state exposure. > This problem is likely a proper subset of the general problem, but > might be more amenable to some "simpler" solutions. Is this within > scope of stackevo? It very much seems to be, yes. Let's keep this discussion going on this = list... Thanks, cheers, Brian > Thanks, > Tom >=20 > _______________________________________________ > Stackevo-discuss mailing list > Stackevo-discuss@iab.org > https://www.iab.org/mailman/listinfo/stackevo-discuss --Apple-Mail=_62E66371-350D-4F98-B2B5-E3E4023048FC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWZpsgAAoJEIoSt78L6kajYeEP/3iZtr349rMz1FndewDQpVzY i8dLd33WFt75iPkmVPLWxezAt2RM4X+NHesYzGPaD7t09mepXvZ6VheX5lpq43w7 ILIr5O0wkSadDjtgXc9h63aU8fA8KNpEY7/r24DygrOXxWR2CeoT+LbeoZc1m130 i1WkHyVbfDd8A1A8U96AzaLAPSaIiNEriFlSs9M3Mx9nSOg3oHZX8o4p4WEE/8lC oZ8HLygGwsJ8zxsZC29DGws2WeWIThCzPaPU5fZv0LMX7RyvBdMGA3pP3SPFMlpX UC2jtdQjJ37YF/AjGDwvok8w0nsMy4kybPntvDTzbsOvXWlRRfFpawLuu6zHmf15 J2lK79RwzbLXs6SPV+bnNOphZ4aniHv5Nkv0YUAOXOR5DPwHa7MFDvNIeNy49ZXJ RetfWPsf6JDqvubth21GeYK0Bhd8xmO01uUUo0oAjH0EgxtTTTxcwUCuTVVnhEQI N0EYDjd1x39AvtXJ40jnkZ2LPf8HBbtgHTTKdj6ELreL+fqIUpEEz+OYDUGjWr2H SHoRjYqjqqFRia71FXJOfypLD6roSmTXi01Bd5Kz8hF4pdc/oZs/N38BUvjJKJMY tWKEBHl/ZB+lzeKvN9+bpaLz+bhF2ImUCEp5z+6feREFabsWiBliEx/uc8trwp7G gKxSgtGVSaTUCApViWSo =EAjU -----END PGP SIGNATURE----- --Apple-Mail=_62E66371-350D-4F98-B2B5-E3E4023048FC-- From nobody Tue Dec 8 01:57:22 2015 Return-Path: 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 052C51AC3CF for ; Tue, 8 Dec 2015 01:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 VzSIaVHRyPpM for ; Tue, 8 Dec 2015 01:57:17 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C06F1AC3D8 for ; Tue, 8 Dec 2015 01:57:17 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-71-5666a97a49b6 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F7.62.05041.A79A6665; Tue, 8 Dec 2015 10:57:14 +0100 (CET) Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0248.002; Tue, 8 Dec 2015 10:57:14 +0100 From: Szilveszter Nadas To: Linda Dunbar , "stackevo-discuss@iab.org" Thread-Topic: When provider networks don't t trust the stack set by the end points .... Thread-Index: AdExPua6p20KTYEoSD+piZoHokKNhAAWebBg Date: Tue, 8 Dec 2015 09:57:13 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F657DADD4A@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DADD4A@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_EA4C43BE752A194597B002779DF69BAE23F20C3AESESSMB303erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAIsWRmVeSWpSXmKPExsUyM2K7t27VyrQwgyn79C3utkxksji0fAeT A5NHy5G3rB63rr5kDmCK4rJJSc3JLEst0rdL4Mq4cSSw4E5IxYSm/awNjCs9uxg5OSQETCQ+ dC9lgrDFJC7cW8/WxcjFISRwmFFi1dd5zBDOIkaJOesfsoNUsQlYSDSs3MwGYosIJEvMOb+c EcRmFnCUeHTuDTOILSwQIbFo2xpWiJpIiX1/D0HVG0l8mnSRBcRmEVCRmDrlBthMXgFfif7p 58DqhQRcJE51rQSzOQVcJeY+ug52HSPQdd9PrWGC2CUucevJfKirBSSW7DnPDGGLSrx8/I8V wlaUaH/aAHVbvsTpswfZIHYJSpyc+YRlAqPoLCSjZiEpm4WkDCKuJ3Fj6hQ2CFtbYtnC18wQ tq7EjH+HWJDFFzCyr2IULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIjLeDW35b7WA8+NzxEKMA B6MSD6/B9dQwIdbEsuLK3EOMEhzMSiK8vLPSwoR4UxIrq1KL8uOLSnNSiw8xSnOwKInzNjM9 CBUSSE8sSc1OTS1ILYLJMnFwSjUwFlpfaPjNuvb0mZ8rm45Ou+qgIWZ552qn3efVTzdNatlV faQt+1nEnVcHEjYIT87dvqf3Y2rL/Hv7j2f/vsPatXrRnbsGC87nr3gXd6JietCjCis5fR9D pjscmrYTuDVYTPbMEstbetWbceHMST8uHHHc0ZubNO2WIeehvUlyF7z/9R2S0V02uV+JpTgj 0VCLuag4EQCbJPq4swIAAA== Archived-At: Cc: =?iso-8859-1?Q?Attila_Mih=E1ly?= Subject: Re: [Stackevo-discuss] When provider networks don't t trust the stack set by the end points .... X-BeenThere: stackevo-discuss@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IP Stack Evolution Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 09:57:21 -0000 --_000_EA4C43BE752A194597B002779DF69BAE23F20C3AESESSMB303erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Regarding the trust issue in the SPUD signaling, that can be solved by havi= ng consequences of a choice and communicating that to an endpoint. Though t= hat is not really declarative communication anymore but at least it is safe= to ignore. We summarized such considerations in this position paper: https://www.iab.org/wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_16.pdf When it comes to multiple layers in SPUD, I am not sure I understand your p= oint. I do not see a problem with middleboxes adding additional information= to e.g. the CBOR map in the SPUD header (as long as that does not cause MT= U problems). With a well-defined key any header can be added, it is quite f= lexible. If there are MTU issues then a separate SPUD signaling PDU can be = created. This is valid for the SPUD prototype protocol, when it comes to th= e general SPUD concept there is no consensus: some people think that we sha= ll limit the possible types (and length) of metadata as much as possible. Cheers, Szilveszter From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On Behalf = Of Linda Dunbar Sent: Monday, December 07, 2015 23:31 To: stackevo-discuss@iab.org Subject: [Stackevo-discuss] When provider networks don't t trust the stack = set by the end points .... I find the use cases for SPUD are very real and definitely need a good appr= oach to make it happen. However, a lot of discussions have been centered around the SPUD layer bein= g encoded by End Points, and expect the network to apply certain rules for = those traffic. Having an In-band standard signaling among end points and ne= twork has its advantages: allowing network to treat packets without getting= into the encrypted payload, and not requiring any extra components across= the networks between the end points. However, Virtually all traffic today go through provider networks (most li= kely multiple). Provider network usually don't (can't) trust the signaling = or requests from end points because any end points can set their own traffi= c as "requiring the least latency" or "passing through the network". Provi= der network set traffic based on the SLA clients pay. For example all the = DiffServ set by the endpoints are ignored by the provider network, instead = Provider Network set its own DiffServ based on the SLA from the customers. The Network Service Header (NSH) introduced by SFC (http://datatracker.ietf= .org/doc/draft-ietf-sfc-nsh/ ) is effectively another layer of stack added = to the packets (added by the ingress node). My question is: Should SPUD allow multiple types of layer added to data packets? Or only fo= cusing on the layer end points can add? My two cents. Linda Dunbar --_000_EA4C43BE752A194597B002779DF69BAE23F20C3AESESSMB303erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

Regarding the trust is= sue in the SPUD signaling, that can be solved by having consequences of a c= hoice and communicating that to an endpoint. Though that is not really decl= arative communication anymore but at least it is safe to ignore. We summarized such considerations in this posi= tion paper:

https://www.= iab.org/wp-content/IAB-uploads/2015/08/MaRNEW_1_paper_16.pdf=

 

When it comes to multi= ple layers in SPUD, I am not sure I understand your point. I do not see a p= roblem with middleboxes adding additional information to e.g. the CBOR map = in the SPUD header (as long as that does not cause MTU problems). With a well-defined key any header can be ad= ded, it is quite flexible. If there are MTU issues then a separate SPUD sig= naling PDU can be created. This is valid for the SPUD prototype protocol, w= hen it comes to the general SPUD concept there is no consensus: some people think that we shall limit the p= ossible types (and length) of metadata as much as possible.

 

Cheers,

Szilveszter=

 

From: Stackevo= -discuss [mailto:stackevo-discuss-bounces@iab.org] On Behalf Of Linda Dunbar
Sent: Monday, December 07, 2015 23:31
To: stackevo-discuss@iab.org
Subject: [Stackevo-discuss] When provider networks don't t trust the= stack set by the end points ....

 

I find the use case= s for SPUD are very real and definitely need a good approach to make it hap= pen.

 

However, a lot of d= iscussions have been centered around the SPUD layer being encoded by End Po= ints, and expect the network to apply certain rules for those traffic. Havi= ng an In-band standard signaling among end points and network has its advantages: allowing network to treat packe= ts without getting into the encrypted payload, and not requiring any  = extra components across the networks between the end points.

 

However,  Virt= ually all traffic today go through provider networks (most likely multiple)= . Provider network usually don’t (can’t) trust the signaling or= requests from end points because any end points can set their own traffic as “requiring the least latency” or R= 20;passing through the network”.  Provider network set traffic b= ased on the SLA clients pay.  For example all the DiffServ set by the = endpoints are ignored by the provider network, instead Provider Network set its own DiffServ based on the SLA from the customers.

 

The Network Service= Header (NSH) introduced by SFC (http://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ ) is effectively another layer of stack added to the packets (added by the ingress node).  =

 

My question is:

Should SPUD allow m= ultiple types of layer added to data packets? Or only focusing on the layer= end points can add?

 

My two cents. =

 

Linda Dunbar

 

 

 

--_000_EA4C43BE752A194597B002779DF69BAE23F20C3AESESSMB303erics_-- From nobody Tue Dec 8 04:29:58 2015 Return-Path: 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 B39111A92BA for ; Tue, 8 Dec 2015 04:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, 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 vpE72mL1ehR0 for ; Tue, 8 Dec 2015 04:29:54 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 404B11A1B82 for ; Tue, 8 Dec 2015 04:29:53 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 6BFB11A0213; Tue, 8 Dec 2015 13:29:22 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7BE1C10D-4156-47E4-A6B7-A44BFAA8BA29"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Brian Trammell In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DADD4A@dfweml701-chm> Date: Tue, 8 Dec 2015 13:29:21 +0100 Message-Id: <2DB15837-8F2D-4BD9-A0DE-C11E2CE32446@trammell.ch> References: <4A95BA014132FF49AE685FAB4B9F17F657DADD4A@dfweml701-chm> To: Linda Dunbar X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "stackevo-discuss@iab.org" Subject: Re: [Stackevo-discuss] When provider networks don't t trust the stack set by the end points .... X-BeenThere: stackevo-discuss@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IP Stack Evolution Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 12:29:56 -0000 --Apple-Mail=_7BE1C10D-4156-47E4-A6B7-A44BFAA8BA29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Linda, > On 07 Dec 2015, at 23:30, Linda Dunbar = wrote: >=20 > I find the use cases for SPUD are very real and definitely need a good = approach to make it happen. >=20 > However, a lot of discussions have been centered around the SPUD layer = being encoded by End Points, and expect the network to apply certain = rules for those traffic. As presently envisioned in the stackevo-explicit-coop draft, this is not = so much an expectation that the network will apply certain rules, as an = exposure of information about traffic in the hope that the network will = use that information, together with network-specific policy, to make = better decisions about how to handle the traffic. > Having an In-band standard signaling among end points and network has = its advantages: allowing network to treat packets without getting into = the encrypted payload, and not requiring any extra components across = the networks between the end points. >=20 > However, Virtually all traffic today go through provider networks = (most likely multiple). Provider network usually don=E2=80=99t (can=E2=80=99= t) trust the signaling or requests from end points because any end = points can set their own traffic as =E2=80=9Crequiring the least = latency=E2=80=9D or =E2=80=9Cpassing through the network=E2=80=9D. = Provider network set traffic based on the SLA clients pay. For example = all the DiffServ set by the endpoints are ignored by the provider = network, instead Provider Network set its own DiffServ based on the SLA = from the customers. Yep. A big issue here, in my opinion, is that DSCP provides an = imperative signaling facility, where each codepoint is tied to some = particular "type" of traffic (see table 2 in RFC 4594), such that (1) = most of the treatments expected can disadvantage other traffic on the = same paths and (2) there is an incentive to mark "better" treatment than = required for a given application. Removing incentives to over-mark would be one way to make this work in = an interdomain environment. There are several approaches here: First, = markings that are declarative ("this traffic has property X") as opposed = to imperative ("reserve 300kb/s for this flow"), such that the endpoint = cannot predict the outcome of the marking, would tend to reduce = incentives to lie. One could also define markings in terms of tradeoffs = as opposed to priorities: latency-sensitive traffic generally has higher = loss tolerance. Markings for "worse than standard" treatment could be = used for loss- and-latency tolerant bulk transfer transports, as well, = trading off something against nothing. > The Network Service Header (NSH) introduced by SFC = (http://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/ ) is effectively = another layer of stack added to the packets (added by the ingress node). >=20 > My question is: > Should SPUD allow multiple types of layer added to data packets? Or = only focusing on the layer end points can add? Not sure what you mean by multiple types of layer. Certainly, a lot of = the thought that's gone in to SPUD as of the present set of requirements = is end-to-end, but there's no reason the mechanisms couldn't be applied = to two tunnel endpoints as opposed to application endpoints. Thanks, cheers, Brian --Apple-Mail=_7BE1C10D-4156-47E4-A6B7-A44BFAA8BA29 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJWZs0iAAoJEIoSt78L6kajx0cP/2ScYwJvmGGUX/sIgfbZoQrZ zfiGumlCfC0jW1Rhrp+YP2k/o9NY/KdylC9nAsQGpAYPcQlMkyaKo9kltCJHCLz0 ZhGbFaK2m6kgl6dBR+N0yCFs1LgHnwFiEOrQVDCblu8gSvG2V3rOfx9ow8oaY6iR UWKxXMT8LJ/QBk4+dDet/CidhxKdTkVNt4WwEJTwm98frnRi3zeVKc5XmtwZG21a rhWs9SNxi/AlZmdTSSIfDBQH7hn/wi4NB9y/vAYwDav2YtyxII4JYwEI9UTjcIEV gDcRITg2Ltws17tQCyKw7A+3eWj9tZEv9zGvMvY+Aiazv5qwUlJ19KjzqJINKmcy sz+k02mlenGVdtJPn9yGD83OEVixMxJMRj4gGilSDbmbbjkRLVdaAM7s0hcaz/SR lmDrFwFZyHfKYGxOmZIy/bEtfgqIzKkoqxTb4mBXnPH10lD7fjFRmNeRWyivERJ0 6LptFNxh6nvE5+x45KToDCzYt7e5UJIGlT5yXHl6I/W3eKuTwKWrJxpIMn2900tm EPADwqP737wZJCZSrsxZZ51VCE4jK2AEkM+rbtAvofWnpD4JNyOHfOEPznrAhBP3 kyV5JvkQm2sNUY4Ep8ZtNu16YxZpCHUNUkXRgrhDkj86Pyfox7PNth3HLi3Nw9yH Q2UNShQmtv/jyDchgBGg =UgFw -----END PGP SIGNATURE----- --Apple-Mail=_7BE1C10D-4156-47E4-A6B7-A44BFAA8BA29-- From nobody Wed Dec 16 10:41:53 2015 Return-Path: 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 022041A8822; Wed, 16 Dec 2015 10:41:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 jQVevzZ3ESKz; Wed, 16 Dec 2015 10:41:49 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A0FD1A87A7; Wed, 16 Dec 2015 10:41:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 89E7410B4FF; Wed, 16 Dec 2015 19:41:47 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8k32f1C9bBZ; Wed, 16 Dec 2015 19:41:47 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 566AD10B4FE; Wed, 16 Dec 2015 19:41:35 +0100 (CET) Received: from HYDRA.office.hd ([169.254.4.101]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Wed, 16 Dec 2015 19:41:14 +0100 From: Dirk Kutscher To: "icnrg@irtf.org" , "dtn-interest@irtf.org" , gaia , "5gangip@ietf.org" <5gangip@ietf.org>, "marnew@iab.org" , "stackevo-discuss@iab.org" Thread-Topic: 5G: It's the Network, Stupid Thread-Index: AdE4MC4YYpSof3RGRdK/YSjH5J56uA== Date: Wed, 16 Dec 2015 18:41:13 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.102] Content-Type: multipart/alternative; boundary="_000_82AB329A76E2484D934BBCA77E9F5249A682F744Hydraofficehd_" MIME-Version: 1.0 Archived-At: Subject: [Stackevo-discuss] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2015 18:41:53 -0000 --_000_82AB329A76E2484D934BBCA77E9F5249A682F744Hydraofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [apologies for cross-posting] Hi, I have written up a few thoughts on current discussions around 5G and netwo= rk 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 n= ot very polished and slightly long, but hopefully understandable enough. Ta= ke it as a "position paper" for now. Abstract: Current 5G network discussion are often focusing on providing more comprehe= nsive and integrated orchestration and management functions in order to imp= rove "end-to-end" managebility and programmability, derived from NGMN and s= imilar requirements. While these are important challenges, this memo takes = the perspective that in order to arrive at a more powerful network, it is i= mportant to understand the pain points and the reasons for certain design c= hoices of today's networks. Understanding the drivers for traffic managemen= t systems, middleboxes, CDNs and other application-layer overlays should be= taken as a basis for analyzing 5G uses cases and their requirements. In th= is 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, t= aking ICN as an example. Features of such a forwarding plane would include = better support for heterogeneous networks (access networks and whole networ= k deployments), multi-path communication, in-network storage and implementa= tion of operator policies. This would help to avoid overlay silos and final= ly simplify network management. http://dirk-kutscher.info/posts/5g-its-the-network-stupid/ Thanks, Dirk --_000_82AB329A76E2484D934BBCA77E9F5249A682F744Hydraofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[apologies for cross-posting]

 

Hi,

 

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

 

Abstract:

Current 5G network discussion a= re often focusing on providing more comprehensive and integrated orchestrat= ion and management functions in order to improve “end-to-end” m= anagebility 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, i= t is important to understand the pain points and the reasons for certain de= sign choices of today’s networks. Understanding the drivers for traffic management systems, middleboxes, CDN= s and other application-layer overlays should be taken as a basis for analy= zing 5G uses cases and their requirements. In this memo, I am making the po= int that many of today’s business needs and the ambitious 5G use cases do call for a more powerful data forw= arding plane, taking ICN as an example. Features of such a forwarding plane= would include better support for heterogeneous networks (access networks a= nd 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 manage= ment.

 

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

 

Thanks,

Dirk

 

--_000_82AB329A76E2484D934BBCA77E9F5249A682F744Hydraofficehd_-- From nobody Thu Dec 17 01:43:47 2015 Return-Path: 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 F1E2A1A874A; Thu, 17 Dec 2015 01:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 MfKpZfoJG2Lp; Thu, 17 Dec 2015 01:43:42 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6A61A873A; Thu, 17 Dec 2015 01:43:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 9012F10B51E; Thu, 17 Dec 2015 10:34:21 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnLdd54lzNnE; Thu, 17 Dec 2015 10:34:21 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 625A710B51D; Thu, 17 Dec 2015 10:34:07 +0100 (CET) Received: from HYDRA.office.hd ([169.254.4.101]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Thu, 17 Dec 2015 10:34:07 +0100 From: Dirk Kutscher To: Ingemar Johansson S , "icnrg@irtf.org" , "dtn-interest@irtf.org" , gaia , "5gangip@ietf.org" <5gangip@ietf.org>, "marnew@iab.org" , "stackevo-discuss@iab.org" Thread-Topic: [5gangip] 5G: It's the Network, Stupid Thread-Index: AdE4MC4YYpSof3RGRdK/YSjH5J56uAAY4/yAAAYu8OA= Date: Thu, 17 Dec 2015 09:34:06 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F5249A683459F@Hydra.office.hd> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <81564C0D7D4D2A4B9A86C8C7404A13DA414EF289@ESESSMB208.ericsson.se> In-Reply-To: <81564C0D7D4D2A4B9A86C8C7404A13DA414EF289@ESESSMB208.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.102] Content-Type: multipart/alternative; boundary="_000_82AB329A76E2484D934BBCA77E9F5249A683459FHydraofficehd_" MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 09:43:45 -0000 --_000_82AB329A76E2484D934BBCA77E9F5249A683459FHydraofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ingemar, thanks for the feedback. Yes, as far as I remember the UPCON work was rather on the traffic manageme= nt 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 accountabili= ty" for various use cases is really more promising than fine-granular traff= ic management. One of the use cases (that Bob came up with) is performance = isolation in virtual networks, which would allow for a more flexible capaci= ty sharing in data centers. My point was if we are thinking about virtual slices, let's not introduce s= tatic 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:ingemar.s.johansson@ericsson.com] Sent: Donnerstag, 17. Dezember 2015 08:26 To: Dirk Kutscher; icnrg@irtf.org; dtn-interest@irtf.org; gaia; 5gangip@iet= f.org; marnew@iab.org; stackevo-discuss@iab.org 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 on= ly 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 RT= T 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:Dirk.Kutscher@neclab.eu] Sent: den 16 december 2015 19:41 To: icnrg@irtf.org; dtn-interest@irtf.org; gaia; 5gangip@ietf.org; marne= w@iab.org; stackevo-discuss@iab.org Subject: [5gangip] 5G: It's the Network, Stupid [apologies for cross-posting] Hi, I have written up a few thoughts on current discussions around 5G and netwo= rk 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 n= ot very polished and slightly long, but hopefully understandable enough. Ta= ke it as a "position paper" for now. Abstract: Current 5G network discussion are often focusing on providing more comprehe= nsive and integrated orchestration and management functions in order to imp= rove "end-to-end" managebility and programmability, derived from NGMN and s= imilar requirements. While these are important challenges, this memo takes = the perspective that in order to arrive at a more powerful network, it is i= mportant to understand the pain points and the reasons for certain design c= hoices of today's networks. Understanding the drivers for traffic managemen= t systems, middleboxes, CDNs and other application-layer overlays should be= taken as a basis for analyzing 5G uses cases and their requirements. In th= is 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, t= aking ICN as an example. Features of such a forwarding plane would include = better support for heterogeneous networks (access networks and whole networ= k deployments), multi-path communication, in-network storage and implementa= tion of operator policies. This would help to avoid overlay silos and final= ly simplify network management. http://dirk-kutscher.info/posts/5g-its-the-network-stupid/ Thanks, Dirk --_000_82AB329A76E2484D934BBCA77E9F5249A683459FHydraofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ingemar,=

 

thanks for the feedbac= k.

 

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.

&n= bsp;

For Con= Ex, there haven’t been enough experiments yet, unfortunately, but in = my opinion the concept of “application-independent congestion account= ability” 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 f= or a more flexible capacity sharing in data centers.

&n= bsp;

My poin= t was if we are thinking about virtual slices, let’s not introduce st= atic QoS, bw reservations etc. for those applications that do not actually = need it – there are other ways to share capacity.

&n= bsp;

Cheers,=

Dirk

&n= bsp;

 

Ingem= ar Johansson S [mailto:ingemar.s.johansson@ericsson.com]
Sent: Donnerstag, 17. Dezember 2015 08:26
To: Dirk Kutscher; icnrg@irtf.org; dtn-interest@irtf.org; gaia; 5gan= gip@ietf.org; marnew@iab.org; stackevo-discuss@iab.org
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 comm= ent on the parts that I know well

AQM and= ECN : Agree fully, there seems to be a general tendency to overlook the ba= sic elements in congestion management in networks. Quite often  one se= e 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  w= as 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 env= ision more local deployments like what is outlined in draft-ietf-conex-mobile ?.

&n= bsp;

/Ingema= r

&n= bsp;

Dirk = Kutscher [mailto:Dirk.Kutscher@neclab.eu= ]
Sent: den 16 december 2015 19:41
To: icnrg@irtf.org; dtn-interest@irtf.org; gaia; 5gangi= p@ietf.org; marnew@iab.org; stackevo-discuss@iab.org
Subject: [5gangip] 5G: It's the Network, Stupid

 

[apologies for cross-posting]

 

Hi,

 

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

 

Abstract:

Current 5G network discussion a= re often focusing on providing more comprehensive and integrated orchestrat= ion and management functions in order to improve “end-to-end” m= anagebility 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, i= t is important to understand the pain points and the reasons for certain de= sign choices of today’s networks. Understanding the drivers for traffic management systems, middleboxes, CDN= s and other application-layer overlays should be taken as a basis for analy= zing 5G uses cases and their requirements. In this memo, I am making the po= int that many of today’s business needs and the ambitious 5G use cases do call for a more powerful data forw= arding plane, taking ICN as an example. Features of such a forwarding plane= would include better support for heterogeneous networks (access networks a= nd 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 manage= ment.

 

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

 

Thanks,

Dirk

 

--_000_82AB329A76E2484D934BBCA77E9F5249A683459FHydraofficehd_-- From nobody Thu Dec 17 01:44:31 2015 Return-Path: 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 04F3D1A8756; Thu, 17 Dec 2015 01:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 ZLOHF2dbT45J; Thu, 17 Dec 2015 01:44:27 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD321A874E; Thu, 17 Dec 2015 01:44:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 7799410B517; Thu, 17 Dec 2015 10:44:26 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzEx-8BNfu2i; Thu, 17 Dec 2015 10:44:26 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 543B610B4BB; Thu, 17 Dec 2015 10:44:12 +0100 (CET) Received: from HYDRA.office.hd ([169.254.4.101]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Thu, 17 Dec 2015 10:43:51 +0100 From: Dirk Kutscher To: Jon Crowcroft Thread-Topic: [gaia] 5G: It's the Network, Stupid Thread-Index: AdE4MC4YYpSof3RGRdK/YSjH5J56uAAZ/GyAAAWAjeA= Date: Thu, 17 Dec 2015 09:43:50 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F5249A683460E@Hydra.office.hd> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.102] Content-Type: multipart/alternative; boundary="_000_82AB329A76E2484D934BBCA77E9F5249A683460EHydraofficehd_" MIME-Version: 1.0 Archived-At: Cc: "icnrg@irtf.org" , gaia , "stackevo-discuss@iab.org" , "marnew@iab.org" , "5gangip@ietf.org" <5gangip@ietf.org>, "dtn-interest@irtf.org" Subject: Re: [Stackevo-discuss] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 09:44:30 -0000 --_000_82AB329A76E2484D934BBCA77E9F5249A683460EHydraofficehd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBnb29kIHBvaW50LiBUaGF0IHdhcyBhY3R1YWxseSBhIG5vdGlvbiBJIGhhZCBpbiBtaW5k LCB0b28sIGJ1dCBmb3Jnb3QgdG8gbWVudGlvbjogRG9u4oCZdCBoYXZlIGFzc3VtcHRpb25zIGlu IHRoZSBhcmNoaXRlY3R1cmUgb24gd2hlcmUgdGhlIG5ldHdvcmsgZW5kcy4NCg0KSW9UIGlzIGls bHVzdHJhdGluZyB0aGUgbmVlZCBmb3IgdGhhdCB0byBzb21lIGV4dGVudCBhbHJlYWR5Lg0KDQpS ZWdhcmRpbmcgc2VjdXJpdHksIHVubGVzcyB3ZSB3YW50IHRvIGludHJvZHVjZSDigJx0cnVzdGVk IG1pZGRsZWJveGVz4oCdLCBvYmplY3QgZW5jcnlwdGlvbiBhbmQgYXV0aGVudGljYXRpb24gc2Vl bXMgdG8gYmUgdGhlIHdheS4gT2YgY291cnNlIHRoZXJlIGFyZSBvdGhlciBjaGFsbGVuZ2VzIGZv ciB0aGF0LCB0b28g4oCTIGtleSBtYW5hZ2VtZW50IGZvciBleGFtcGxlLg0KDQotLQ0KRGlyaw0K DQpGcm9tOiBjcm93Y3JvZnRAZ21haWwuY29tIFttYWlsdG86Y3Jvd2Nyb2Z0QGdtYWlsLmNvbV0g T24gQmVoYWxmIE9mIEpvbiBDcm93Y3JvZnQNClNlbnQ6IERvbm5lcnN0YWcsIDE3LiBEZXplbWJl ciAyMDE1IDA4OjU3DQpUbzogRGlyayBLdXRzY2hlcg0KQ2M6IGR0bi1pbnRlcmVzdEBpcnRmLm9y Zzsgc3RhY2tldm8tZGlzY3Vzc0BpYWIub3JnOyBpY25yZ0BpcnRmLm9yZzsgZ2FpYTsgbWFybmV3 QGlhYi5vcmc7IDVnYW5naXBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbZ2FpYV0gNUc6IEl0J3Mg dGhlIE5ldHdvcmssIFN0dXBpZA0KDQoNCkdyZWF0IGFydGljbGUuLi5vbmUgdGhpbmcgYWJvdXQg dGhlIDRnLi41ZyBldm9sdXRpb24gaXMgaW5jcmVhc2luZyBjb29wZXJhdGlvbiBpbiBmb3J3YXJk aW5nIGFuZCByZWxheWluZyBzaWduYWwsIGJpdHMsIHBhY2tldHMgKHNoYXJlZCBjZWxsIHRvd2Vy L2Jhc2Ugc3RhdGlvbi9hbnRlbm5hZSBhY3Jvc3MgcHJvdmlkZXIpLiBTbyBkaXJlY3QsbWVzaCxh ZGhvYyBzdG9wIGp1c3QgYmVpbmcgZWRnZSBub3Rpb25zLCBidXQgYXJlIGFsbCBmaXJzdCBjbGFz cyBwYXJ0IG9mIHRoZSBhcmNoaXRlY3R1cmUgKCJkb24ndCBmZWFyIHRoZSBlZGdlIikuIFRoZXJl IGlzIGh1Z2UgdGVuc2lvbiBiZXR3ZWVuIHRoaXMgdHJlbmQsIGFuZCBlMmUgc2VjdXJpdHkuLi4u SSBoYXZlIG5vdCBzZWVuIGFueW9uZSBhZGRyZXNzIGhvdyB0byByZXNvbHZlIHRoYXQgdGVuc2lv bi4uLg0KT24gMTYgRGVjIDIwMTUgNjo0MiBwbSwgIkRpcmsgS3V0c2NoZXIiIDxEaXJrLkt1dHNj aGVyQG5lY2xhYi5ldTxtYWlsdG86RGlyay5LdXRzY2hlckBuZWNsYWIuZXU+PiB3cm90ZToNClth cG9sb2dpZXMgZm9yIGNyb3NzLXBvc3RpbmddDQoNCkhpLA0KDQpJIGhhdmUgd3JpdHRlbiB1cCBh IGZldyB0aG91Z2h0cyBvbiBjdXJyZW50IGRpc2N1c3Npb25zIGFyb3VuZCA1RyBhbmQgbmV0d29y ayBldm9sdXRpb24uIEkgbWlnaHQgcHVibGlzaCB0aGlzIGFzIHBhcGVyIGxhdGVyLCBidXQgd2Fu dGVkIHRvIGdldCBpdCBvdXQgZWFybHkgYW5kIGFzayBmb3IgY29tbWVudHMg4oCTIHNvIHdvdWxk IGJlIGdyYXRlZnVsIGZvciBhbnkgZmVlZGJhY2suIEl04oCZcyBub3QgdmVyeSBwb2xpc2hlZCBh bmQgc2xpZ2h0bHkgbG9uZywgYnV0IGhvcGVmdWxseSB1bmRlcnN0YW5kYWJsZSBlbm91Z2guIFRh a2UgaXQgYXMgYSDigJxwb3NpdGlvbiBwYXBlcuKAnSBmb3Igbm93Lg0KDQpBYnN0cmFjdDoNCkN1 cnJlbnQgNUcgbmV0d29yayBkaXNjdXNzaW9uIGFyZSBvZnRlbiBmb2N1c2luZyBvbiBwcm92aWRp bmcgbW9yZSBjb21wcmVoZW5zaXZlIGFuZCBpbnRlZ3JhdGVkIG9yY2hlc3RyYXRpb24gYW5kIG1h bmFnZW1lbnQgZnVuY3Rpb25zIGluIG9yZGVyIHRvIGltcHJvdmUg4oCcZW5kLXRvLWVuZOKAnSBt YW5hZ2ViaWxpdHkgYW5kIHByb2dyYW1tYWJpbGl0eSwgZGVyaXZlZCBmcm9tIE5HTU4gYW5kIHNp bWlsYXIgcmVxdWlyZW1lbnRzLiBXaGlsZSB0aGVzZSBhcmUgaW1wb3J0YW50IGNoYWxsZW5nZXMs IHRoaXMgbWVtbyB0YWtlcyB0aGUgcGVyc3BlY3RpdmUgdGhhdCBpbiBvcmRlciB0byBhcnJpdmUg YXQgYSBtb3JlIHBvd2VyZnVsIG5ldHdvcmssIGl0IGlzIGltcG9ydGFudCB0byB1bmRlcnN0YW5k IHRoZSBwYWluIHBvaW50cyBhbmQgdGhlIHJlYXNvbnMgZm9yIGNlcnRhaW4gZGVzaWduIGNob2lj ZXMgb2YgdG9kYXnigJlzIG5ldHdvcmtzLiBVbmRlcnN0YW5kaW5nIHRoZSBkcml2ZXJzIGZvciB0 cmFmZmljIG1hbmFnZW1lbnQgc3lzdGVtcywgbWlkZGxlYm94ZXMsIENETnMgYW5kIG90aGVyIGFw cGxpY2F0aW9uLWxheWVyIG92ZXJsYXlzIHNob3VsZCBiZSB0YWtlbiBhcyBhIGJhc2lzIGZvciBh bmFseXppbmcgNUcgdXNlcyBjYXNlcyBhbmQgdGhlaXIgcmVxdWlyZW1lbnRzLiBJbiB0aGlzIG1l bW8sIEkgYW0gbWFraW5nIHRoZSBwb2ludCB0aGF0IG1hbnkgb2YgdG9kYXnigJlzIGJ1c2luZXNz IG5lZWRzIGFuZCB0aGUgYW1iaXRpb3VzIDVHIHVzZSBjYXNlcyBkbyBjYWxsIGZvciBhIG1vcmUg cG93ZXJmdWwgZGF0YSBmb3J3YXJkaW5nIHBsYW5lLCB0YWtpbmcgSUNOIGFzIGFuIGV4YW1wbGUu IEZlYXR1cmVzIG9mIHN1Y2ggYSBmb3J3YXJkaW5nIHBsYW5lIHdvdWxkIGluY2x1ZGUgYmV0dGVy IHN1cHBvcnQgZm9yIGhldGVyb2dlbmVvdXMgbmV0d29ya3MgKGFjY2VzcyBuZXR3b3JrcyBhbmQg d2hvbGUgbmV0d29yayBkZXBsb3ltZW50cyksIG11bHRpLXBhdGggY29tbXVuaWNhdGlvbiwgaW4t bmV0d29yayBzdG9yYWdlIGFuZCBpbXBsZW1lbnRhdGlvbiBvZiBvcGVyYXRvciBwb2xpY2llcy4g VGhpcyB3b3VsZCBoZWxwIHRvIGF2b2lkIG92ZXJsYXkgc2lsb3MgYW5kIGZpbmFsbHkgc2ltcGxp ZnkgbmV0d29yayBtYW5hZ2VtZW50Lg0KDQpodHRwOi8vZGlyay1rdXRzY2hlci5pbmZvL3Bvc3Rz LzVnLWl0cy10aGUtbmV0d29yay1zdHVwaWQvDQoNClRoYW5rcywNCkRpcmsNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZ2FpYSBtYWlsaW5nIGxp c3QNCmdhaWFAaXJ0Zi5vcmc8bWFpbHRvOmdhaWFAaXJ0Zi5vcmc+DQpodHRwczovL3d3dy5pcnRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dhaWENCg== --_000_82AB329A76E2484D934BBCA77E9F5249A683460EHydraofficehd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0 IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJERSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMsIGdv b2QgcG9pbnQuIFRoYXQgd2FzIGFjdHVhbGx5IGEgbm90aW9uIEkgaGFkIGluIG1pbmQsIHRvbywg YnV0IGZvcmdvdCB0byBtZW50aW9uOiBEb27igJl0IGhhdmUgYXNzdW1wdGlvbnMgaW4gdGhlIGFy Y2hpdGVjdHVyZSBvbiB3aGVyZSB0aGUNCiBuZXR3b3JrIGVuZHMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPklvVCBpcyBpbGx1c3RyYXRpbmcgdGhlIG5lZWQgZm9yIHRoYXQg dG8gc29tZSBleHRlbnQgYWxyZWFkeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+UmVnYXJkaW5nIHNlY3VyaXR5LCB1bmxlc3Mgd2Ugd2FudCB0byBpbnRyb2R1Y2Ug4oCcdHJ1 c3RlZCBtaWRkbGVib3hlc+KAnSwgb2JqZWN0IGVuY3J5cHRpb24gYW5kIGF1dGhlbnRpY2F0aW9u IHNlZW1zIHRvIGJlIHRoZSB3YXkuIE9mIGNvdXJzZSB0aGVyZQ0KIGFyZSBvdGhlciBjaGFsbGVu Z2VzIGZvciB0aGF0LCB0b28g4oCTIGtleSBtYW5hZ2VtZW50IGZvciBleGFtcGxlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+RGlyazxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2E+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBjcm93Y3JvZnRAZ21haWwuY29tIFttYWlsdG86Y3Jvd2Ny b2Z0QGdtYWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9uIENyb3djcm9mdDxicj4NCjxi PlNlbnQ6PC9iPiBEb25uZXJzdGFnLCAxNy4gRGV6ZW1iZXIgMjAxNSAwODo1Nzxicj4NCjxiPlRv OjwvYj4gRGlyayBLdXRzY2hlcjxicj4NCjxiPkNjOjwvYj4gZHRuLWludGVyZXN0QGlydGYub3Jn OyBzdGFja2V2by1kaXNjdXNzQGlhYi5vcmc7IGljbnJnQGlydGYub3JnOyBnYWlhOyBtYXJuZXdA aWFiLm9yZzsgNWdhbmdpcEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2dhaWFd IDVHOiBJdCdzIHRoZSBOZXR3b3JrLCBTdHVwaWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cD5HcmVhdCBhcnRpY2xlLi4ub25lIHRoaW5nIGFib3V0IHRoZSA0Zy4uNWcgZXZvbHV0aW9uIGlz IGluY3JlYXNpbmcgY29vcGVyYXRpb24gaW4gZm9yd2FyZGluZyBhbmQgcmVsYXlpbmcgc2lnbmFs LCBiaXRzLCBwYWNrZXRzIChzaGFyZWQgY2VsbCB0b3dlci9iYXNlIHN0YXRpb24vYW50ZW5uYWUg YWNyb3NzIHByb3ZpZGVyKS4gU28gZGlyZWN0LG1lc2gsYWRob2Mgc3RvcCBqdXN0IGJlaW5nIGVk Z2Ugbm90aW9ucywgYnV0IGFyZSBhbGwgZmlyc3QNCiBjbGFzcyBwYXJ0IG9mIHRoZSBhcmNoaXRl Y3R1cmUgKCZxdW90O2Rvbid0IGZlYXIgdGhlIGVkZ2UmcXVvdDspLiBUaGVyZSBpcyBodWdlIHRl bnNpb24gYmV0d2VlbiB0aGlzIHRyZW5kLCBhbmQgZTJlIHNlY3VyaXR5Li4uLkkgaGF2ZSBub3Qg c2VlbiBhbnlvbmUgYWRkcmVzcyBob3cgdG8gcmVzb2x2ZSB0aGF0IHRlbnNpb24uLi48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxNiBEZWMgMjAxNSA2OjQy IHBtLCAmcXVvdDtEaXJrIEt1dHNjaGVyJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86RGlyay5L dXRzY2hlckBuZWNsYWIuZXUiPkRpcmsuS3V0c2NoZXJAbmVjbGFiLmV1PC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPlthcG9sb2dpZXMgZm9yIGNyb3NzLXBvc3RpbmddPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBoYXZlIHdyaXR0ZW4gdXAg YSBmZXcgdGhvdWdodHMgb24gY3VycmVudCBkaXNjdXNzaW9ucyBhcm91bmQgNUcgYW5kIG5ldHdv cmsgZXZvbHV0aW9uLiBJIG1pZ2h0IHB1Ymxpc2ggdGhpcyBhcyBwYXBlciBsYXRlciwgYnV0IHdh bnRlZCB0byBnZXQgaXQgb3V0IGVhcmx5IGFuZA0KIGFzayBmb3IgY29tbWVudHMg4oCTIHNvIHdv dWxkIGJlIGdyYXRlZnVsIGZvciBhbnkgZmVlZGJhY2suIEl04oCZcyBub3QgdmVyeSBwb2xpc2hl ZCBhbmQgc2xpZ2h0bHkgbG9uZywgYnV0IGhvcGVmdWxseSB1bmRlcnN0YW5kYWJsZSBlbm91Z2gu IFRha2UgaXQgYXMgYSDigJxwb3NpdGlvbiBwYXBlcuKAnSBmb3Igbm93Ljwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPkFic3RyYWN0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkN1cnJlbnQgNUcgbmV0d29yayBkaXNjdXNzaW9u IGFyZSBvZnRlbiBmb2N1c2luZyBvbiBwcm92aWRpbmcgbW9yZSBjb21wcmVoZW5zaXZlIGFuZCBp bnRlZ3JhdGVkIG9yY2hlc3RyYXRpb24gYW5kIG1hbmFnZW1lbnQgZnVuY3Rpb25zIGluIG9yZGVy IHRvIGltcHJvdmUg4oCcZW5kLXRvLWVuZOKAnQ0KIG1hbmFnZWJpbGl0eSBhbmQgcHJvZ3JhbW1h YmlsaXR5LCBkZXJpdmVkIGZyb20gTkdNTiBhbmQgc2ltaWxhciByZXF1aXJlbWVudHMuIFdoaWxl IHRoZXNlIGFyZSBpbXBvcnRhbnQgY2hhbGxlbmdlcywgdGhpcyBtZW1vIHRha2VzIHRoZSBwZXJz cGVjdGl2ZSB0aGF0IGluIG9yZGVyIHRvIGFycml2ZSBhdCBhIG1vcmUgcG93ZXJmdWwgbmV0d29y aywgaXQgaXMgaW1wb3J0YW50IHRvIHVuZGVyc3RhbmQgdGhlIHBhaW4gcG9pbnRzIGFuZCB0aGUg cmVhc29ucw0KIGZvciBjZXJ0YWluIGRlc2lnbiBjaG9pY2VzIG9mIHRvZGF54oCZcyBuZXR3b3Jr cy4gVW5kZXJzdGFuZGluZyB0aGUgZHJpdmVycyBmb3IgdHJhZmZpYyBtYW5hZ2VtZW50IHN5c3Rl bXMsIG1pZGRsZWJveGVzLCBDRE5zIGFuZCBvdGhlciBhcHBsaWNhdGlvbi1sYXllciBvdmVybGF5 cyBzaG91bGQgYmUgdGFrZW4gYXMgYSBiYXNpcyBmb3IgYW5hbHl6aW5nIDVHIHVzZXMgY2FzZXMg YW5kIHRoZWlyIHJlcXVpcmVtZW50cy4gSW4gdGhpcyBtZW1vLCBJDQogYW0gbWFraW5nIHRoZSBw b2ludCB0aGF0IG1hbnkgb2YgdG9kYXnigJlzIGJ1c2luZXNzIG5lZWRzIGFuZCB0aGUgYW1iaXRp b3VzIDVHIHVzZSBjYXNlcyBkbyBjYWxsIGZvciBhIG1vcmUgcG93ZXJmdWwgZGF0YSBmb3J3YXJk aW5nIHBsYW5lLCB0YWtpbmcgSUNOIGFzIGFuIGV4YW1wbGUuIEZlYXR1cmVzIG9mIHN1Y2ggYSBm b3J3YXJkaW5nIHBsYW5lIHdvdWxkIGluY2x1ZGUgYmV0dGVyIHN1cHBvcnQgZm9yIGhldGVyb2dl bmVvdXMgbmV0d29ya3MNCiAoYWNjZXNzIG5ldHdvcmtzIGFuZCB3aG9sZSBuZXR3b3JrIGRlcGxv eW1lbnRzKSwgbXVsdGktcGF0aCBjb21tdW5pY2F0aW9uLCBpbi1uZXR3b3JrIHN0b3JhZ2UgYW5k IGltcGxlbWVudGF0aW9uIG9mIG9wZXJhdG9yIHBvbGljaWVzLiBUaGlzIHdvdWxkIGhlbHAgdG8g YXZvaWQgb3ZlcmxheSBzaWxvcyBhbmQgZmluYWxseSBzaW1wbGlmeSBuZXR3b3JrIG1hbmFnZW1l bnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cDovL2Rpcmsta3V0c2NoZXIu aW5mby9wb3N0cy81Zy1pdHMtdGhlLW5ldHdvcmstc3R1cGlkLyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly9kaXJrLWt1dHNjaGVyLmluZm8vcG9zdHMvNWctaXRzLXRoZS1uZXR3b3JrLXN0dXBpZC88 L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkRpcms8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmdhaWEgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmdhaWFAaXJ0Zi5vcmciPmdhaWFAaXJ0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nYWlhIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nYWlh PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_82AB329A76E2484D934BBCA77E9F5249A683460EHydraofficehd_-- From nobody Thu Dec 17 01:50:13 2015 Return-Path: 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 EE3281A8760; Thu, 17 Dec 2015 01:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 V4bfBy5ucwc2; Thu, 17 Dec 2015 01:49:48 -0800 (PST) Received: from mail-out4.uio.no (mail-out4.uio.no [IPv6:2001:700:100:10::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5155D1A8737; Thu, 17 Dec 2015 01:49:48 -0800 (PST) Received: from mail-mx4.uio.no ([129.240.10.45]) by mail-out4.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1a9VBt-0003LQ-AX; Thu, 17 Dec 2015 10:49:41 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx4.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1a9VBs-0007p5-NT; Thu, 17 Dec 2015 10:49:41 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <82AB329A76E2484D934BBCA77E9F5249A683460E@Hydra.office.hd> Date: Thu, 17 Dec 2015 10:49:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9E220CD1-5C20-4568-8A8D-6461C317BE11@ifi.uio.no> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <82AB329A76E2484D934BBCA77E9F5249A683460E@Hydra.office.hd> To: Dirk Kutscher X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 2 sum rcpts/h 10 sum msgs/h 3 total rcpts 36544 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 246663B5C33AF7D705BD2436825B22C7207FF9F7 X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 8810 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "icnrg@irtf.org" , gaia , "stackevo-discuss@iab.org" , "marnew@iab.org" , Jon Crowcroft , "5gangip@ietf.org" <5gangip@ietf.org>, "dtn-interest@irtf.org" Subject: Re: [Stackevo-discuss] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 09:49:51 -0000 > On 17 Dec 2015, at 10:43, Dirk Kutscher = wrote: >=20 > Yes, good point. That was actually a notion I had in mind, too, but = forgot to mention: Don=E2=80=99t have assumptions in the architecture on = where the network ends. > =20 > IoT is illustrating the need for that to some extent already. > =20 > Regarding security, unless we want to introduce =E2=80=9Ctrusted = middleboxes=E2=80=9D, Why not? Cheers, Michael > object encryption and authentication seems to be the way. Of course = there are other challenges for that, too =E2=80=93 key management for = example. > =20 > -- > Dirk > =20 > From: crowcroft@gmail.com [mailto:crowcroft@gmail.com] On Behalf Of = Jon Crowcroft > Sent: Donnerstag, 17. Dezember 2015 08:57 > To: Dirk Kutscher > Cc: dtn-interest@irtf.org; stackevo-discuss@iab.org; icnrg@irtf.org; = gaia; marnew@iab.org; 5gangip@ietf.org > Subject: Re: [gaia] 5G: It's the Network, Stupid > =20 > 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... >=20 > On 16 Dec 2015 6:42 pm, "Dirk Kutscher" = wrote: > [apologies for cross-posting] > =20 > Hi, > =20 > 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 =E2=80=93 so would be grateful for = any feedback. It=E2=80=99s not very polished and slightly long, but = hopefully understandable enough. Take it as a =E2=80=9Cposition paper=E2=80= =9D for now. > =20 > Abstract: > Current 5G network discussion are often focusing on providing more = comprehensive and integrated orchestration and management functions in = order to improve =E2=80=9Cend-to-end=E2=80=9D 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=E2=80=99s = 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=E2=80=99s 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. > =20 > http://dirk-kutscher.info/posts/5g-its-the-network-stupid/ > =20 > Thanks, > Dirk > =20 >=20 > _______________________________________________ > gaia mailing list > gaia@irtf.org > https://www.irtf.org/mailman/listinfo/gaia >=20 > _______________________________________________ > Stackevo-discuss mailing list > Stackevo-discuss@iab.org > https://www.iab.org/mailman/listinfo/stackevo-discuss From nobody Thu Dec 17 02:11:29 2015 Return-Path: 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 94EF71A87EC; Thu, 17 Dec 2015 02:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 pMhYKWTC_lHQ; Thu, 17 Dec 2015 02:11:10 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C66621A87E2; Thu, 17 Dec 2015 02:11:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8A8B710B51F; Thu, 17 Dec 2015 11:11:08 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ts7FZpj3NwLW; Thu, 17 Dec 2015 11:11:08 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 6B19E10B517; Thu, 17 Dec 2015 11:10:52 +0100 (CET) Received: from HYDRA.office.hd ([169.254.4.101]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Thu, 17 Dec 2015 11:10:31 +0100 From: Dirk Kutscher To: Michael Welzl Thread-Topic: [gaia] [Stackevo-discuss] 5G: It's the Network, Stupid Thread-Index: AQHROLBPlVNkrkRTBkOaPzNEJWjMrZ7O8rew Date: Thu, 17 Dec 2015 10:10:30 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F5249A6835717@Hydra.office.hd> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <82AB329A76E2484D934BBCA77E9F5249A683460E@Hydra.office.hd> <9E220CD1-5C20-4568-8A8D-6461C317BE11@ifi.uio.no> In-Reply-To: <9E220CD1-5C20-4568-8A8D-6461C317BE11@ifi.uio.no> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.102] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "icnrg@irtf.org" , gaia , "stackevo-discuss@iab.org" , Jon Crowcroft , "5gangip@ietf.org" <5gangip@ietf.org>, "marnew@iab.org" , "dtn-interest@irtf.org" Subject: Re: [Stackevo-discuss] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 10:11:15 -0000 PiA+IFJlZ2FyZGluZyBzZWN1cml0eSwgdW5sZXNzIHdlIHdhbnQgdG8gaW50cm9kdWNlIOKAnHRy dXN0ZWQgbWlkZGxlYm94ZXPigJ0sDQo+IA0KPiBXaHkgbm90Pw0KDQpObyBlMmUgc2VjdXJpdHku DQoNClRoYXQgbWF5IGJlIE9LIGZvciBzb21lIHVzZSBjYXNlcywgbGlrZSBJb1Qgb3IgaG9tZSBH V3MsIGJ1dCBjb3VsZCBiZSBsZXNzIGNvbnZpbmNpbmcgZm9yIGFjY2Vzc2luZyBwdWJsaWMgbmV0 d29yayBzZXJ2aWNlcyAtLSBmb3IgZXhhbXBsZSwgaWYgeW91IGV4dGVuZCB0aGUgbmV0d29yayB3 aXRoIG11bHRpcGxlIGhvcHMgb2YgZGV2aWNlLXRvLWRldmljZSBjb21tdW5pY2F0aW9uLCBkYXRh IG11bGVzIGV0Yy4NCg0KRGlyaw0KDQo+IA0KPiANCj4gPiBvYmplY3QgZW5jcnlwdGlvbiBhbmQg YXV0aGVudGljYXRpb24gc2VlbXMgdG8gYmUgdGhlIHdheS4gT2YgY291cnNlIHRoZXJlIGFyZQ0K PiBvdGhlciBjaGFsbGVuZ2VzIGZvciB0aGF0LCB0b28g4oCTIGtleSBtYW5hZ2VtZW50IGZvciBl eGFtcGxlLg0KPiA+DQo+ID4gLS0NCj4gPiBEaXJrDQo+ID4NCj4gPiBGcm9tOiBjcm93Y3JvZnRA Z21haWwuY29tIFttYWlsdG86Y3Jvd2Nyb2Z0QGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIEpvbg0K PiBDcm93Y3JvZnQNCj4gPiBTZW50OiBEb25uZXJzdGFnLCAxNy4gRGV6ZW1iZXIgMjAxNSAwODo1 Nw0KPiA+IFRvOiBEaXJrIEt1dHNjaGVyDQo+ID4gQ2M6IGR0bi1pbnRlcmVzdEBpcnRmLm9yZzsg c3RhY2tldm8tZGlzY3Vzc0BpYWIub3JnOyBpY25yZ0BpcnRmLm9yZzsgZ2FpYTsNCj4gbWFybmV3 QGlhYi5vcmc7IDVnYW5naXBAaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBSZTogW2dhaWFdIDVHOiBJ dCdzIHRoZSBOZXR3b3JrLCBTdHVwaWQNCj4gPg0KPiA+IEdyZWF0IGFydGljbGUuLi5vbmUgdGhp bmcgYWJvdXQgdGhlIDRnLi41ZyBldm9sdXRpb24gaXMgaW5jcmVhc2luZyBjb29wZXJhdGlvbg0K PiBpbiBmb3J3YXJkaW5nIGFuZCByZWxheWluZyBzaWduYWwsIGJpdHMsIHBhY2tldHMgKHNoYXJl ZCBjZWxsIHRvd2VyL2Jhc2UNCj4gc3RhdGlvbi9hbnRlbm5hZSBhY3Jvc3MgcHJvdmlkZXIpLiBT byBkaXJlY3QsbWVzaCxhZGhvYyBzdG9wIGp1c3QgYmVpbmcgZWRnZQ0KPiBub3Rpb25zLCBidXQg YXJlIGFsbCBmaXJzdCBjbGFzcyBwYXJ0IG9mIHRoZSBhcmNoaXRlY3R1cmUgKCJkb24ndCBmZWFy IHRoZSBlZGdlIikuDQo+IFRoZXJlIGlzIGh1Z2UgdGVuc2lvbiBiZXR3ZWVuIHRoaXMgdHJlbmQs IGFuZCBlMmUgc2VjdXJpdHkuLi4uSSBoYXZlIG5vdCBzZWVuDQo+IGFueW9uZSBhZGRyZXNzIGhv dyB0byByZXNvbHZlIHRoYXQgdGVuc2lvbi4uLg0KPiA+DQo+ID4gT24gMTYgRGVjIDIwMTUgNjo0 MiBwbSwgIkRpcmsgS3V0c2NoZXIiIDxEaXJrLkt1dHNjaGVyQG5lY2xhYi5ldT4gd3JvdGU6DQo+ ID4gW2Fwb2xvZ2llcyBmb3IgY3Jvc3MtcG9zdGluZ10NCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4g SSBoYXZlIHdyaXR0ZW4gdXAgYSBmZXcgdGhvdWdodHMgb24gY3VycmVudCBkaXNjdXNzaW9ucyBh cm91bmQgNUcgYW5kDQo+IG5ldHdvcmsgZXZvbHV0aW9uLiBJIG1pZ2h0IHB1Ymxpc2ggdGhpcyBh cyBwYXBlciBsYXRlciwgYnV0IHdhbnRlZCB0byBnZXQgaXQgb3V0DQo+IGVhcmx5IGFuZCBhc2sg Zm9yIGNvbW1lbnRzIOKAkyBzbyB3b3VsZCBiZSBncmF0ZWZ1bCBmb3IgYW55IGZlZWRiYWNrLiBJ dOKAmXMgbm90DQo+IHZlcnkgcG9saXNoZWQgYW5kIHNsaWdodGx5IGxvbmcsIGJ1dCBob3BlZnVs bHkgdW5kZXJzdGFuZGFibGUgZW5vdWdoLiBUYWtlIGl0IGFzDQo+IGEg4oCccG9zaXRpb24gcGFw ZXLigJ0gZm9yIG5vdy4NCj4gPg0KPiA+IEFic3RyYWN0Og0KPiA+IEN1cnJlbnQgNUcgbmV0d29y ayBkaXNjdXNzaW9uIGFyZSBvZnRlbiBmb2N1c2luZyBvbiBwcm92aWRpbmcgbW9yZQ0KPiBjb21w cmVoZW5zaXZlIGFuZCBpbnRlZ3JhdGVkIG9yY2hlc3RyYXRpb24gYW5kIG1hbmFnZW1lbnQgZnVu Y3Rpb25zIGluDQo+IG9yZGVyIHRvIGltcHJvdmUg4oCcZW5kLXRvLWVuZOKAnSBtYW5hZ2ViaWxp dHkgYW5kIHByb2dyYW1tYWJpbGl0eSwgZGVyaXZlZCBmcm9tDQo+IE5HTU4gYW5kIHNpbWlsYXIg cmVxdWlyZW1lbnRzLiBXaGlsZSB0aGVzZSBhcmUgaW1wb3J0YW50IGNoYWxsZW5nZXMsIHRoaXMN Cj4gbWVtbyB0YWtlcyB0aGUgcGVyc3BlY3RpdmUgdGhhdCBpbiBvcmRlciB0byBhcnJpdmUgYXQg YSBtb3JlIHBvd2VyZnVsIG5ldHdvcmssDQo+IGl0IGlzIGltcG9ydGFudCB0byB1bmRlcnN0YW5k IHRoZSBwYWluIHBvaW50cyBhbmQgdGhlIHJlYXNvbnMgZm9yIGNlcnRhaW4gZGVzaWduDQo+IGNo b2ljZXMgb2YgdG9kYXnigJlzIG5ldHdvcmtzLiBVbmRlcnN0YW5kaW5nIHRoZSBkcml2ZXJzIGZv ciB0cmFmZmljIG1hbmFnZW1lbnQNCj4gc3lzdGVtcywgbWlkZGxlYm94ZXMsIENETnMgYW5kIG90 aGVyIGFwcGxpY2F0aW9uLWxheWVyIG92ZXJsYXlzIHNob3VsZCBiZQ0KPiB0YWtlbiBhcyBhIGJh c2lzIGZvciBhbmFseXppbmcgNUcgdXNlcyBjYXNlcyBhbmQgdGhlaXIgcmVxdWlyZW1lbnRzLiBJ biB0aGlzDQo+IG1lbW8sIEkgYW0gbWFraW5nIHRoZSBwb2ludCB0aGF0IG1hbnkgb2YgdG9kYXni gJlzIGJ1c2luZXNzIG5lZWRzIGFuZCB0aGUNCj4gYW1iaXRpb3VzIDVHIHVzZSBjYXNlcyBkbyBj YWxsIGZvciBhIG1vcmUgcG93ZXJmdWwgZGF0YSBmb3J3YXJkaW5nIHBsYW5lLA0KPiB0YWtpbmcg SUNOIGFzIGFuIGV4YW1wbGUuIEZlYXR1cmVzIG9mIHN1Y2ggYSBmb3J3YXJkaW5nIHBsYW5lIHdv dWxkIGluY2x1ZGUNCj4gYmV0dGVyIHN1cHBvcnQgZm9yIGhldGVyb2dlbmVvdXMgbmV0d29ya3Mg KGFjY2VzcyBuZXR3b3JrcyBhbmQgd2hvbGUNCj4gbmV0d29yayBkZXBsb3ltZW50cyksIG11bHRp LXBhdGggY29tbXVuaWNhdGlvbiwgaW4tbmV0d29yayBzdG9yYWdlIGFuZA0KPiBpbXBsZW1lbnRh dGlvbiBvZiBvcGVyYXRvciBwb2xpY2llcy4gVGhpcyB3b3VsZCBoZWxwIHRvIGF2b2lkIG92ZXJs YXkgc2lsb3MgYW5kDQo+IGZpbmFsbHkgc2ltcGxpZnkgbmV0d29yayBtYW5hZ2VtZW50Lg0KPiA+ DQo+ID4gaHR0cDovL2Rpcmsta3V0c2NoZXIuaW5mby9wb3N0cy81Zy1pdHMtdGhlLW5ldHdvcmst c3R1cGlkLw0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IERpcmsNCj4gPg0KPiA+DQo+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBnYWlhIG1haWxp bmcgbGlzdA0KPiA+IGdhaWFAaXJ0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pcnRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2dhaWENCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gU3RhY2tldm8tZGlzY3VzcyBtYWlsaW5nIGxpc3QNCj4g PiBTdGFja2V2by1kaXNjdXNzQGlhYi5vcmcNCj4gPiBodHRwczovL3d3dy5pYWIub3JnL21haWxt YW4vbGlzdGluZm8vc3RhY2tldm8tZGlzY3Vzcw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZ2FpYSBtYWlsaW5nIGxpc3QNCj4gZ2FpYUBp cnRmLm9yZw0KPiBodHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dhaWENCg== From nobody Thu Dec 17 02:18:48 2015 Return-Path: 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 41A481A883C; Thu, 17 Dec 2015 02:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oastSy9obVO1; Thu, 17 Dec 2015 02:18:41 -0800 (PST) Received: from mail-out5.uio.no (mail-out5.uio.no [IPv6:2001:700:100:10::17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244921A8845; Thu, 17 Dec 2015 02:18:41 -0800 (PST) Received: from mail-mx2.uio.no ([129.240.10.30]) by mail-out5.uio.no with esmtp (Exim 4.80.1) (envelope-from ) id 1a9Vdu-0004Wz-Ol; Thu, 17 Dec 2015 11:18:38 +0100 Received: from boomerang.ifi.uio.no ([129.240.68.135]) by mail-mx2.uio.no with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) user michawe (Exim 4.80) (envelope-from ) id 1a9Vdu-0000WF-D1; Thu, 17 Dec 2015 11:18:38 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Michael Welzl In-Reply-To: <82AB329A76E2484D934BBCA77E9F5249A6835717@Hydra.office.hd> Date: Thu, 17 Dec 2015 11:18:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9EB6564A-45B0-4164-8D78-0737BBAA0C9F@ifi.uio.no> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <82AB329A76E2484D934BBCA77E9F5249A683460E@Hydra.office.hd> <9E220CD1-5C20-4568-8A8D-6461C317BE11@ifi.uio.no> <82AB329A76E2484D934BBCA77E9F5249A6835717@Hydra.office.hd> To: Dirk Kutscher X-Mailer: Apple Mail (2.2104) X-UiO-SPF-Received: X-UiO-Ratelimit-Test: rcpts/h 9 msgs/h 2 sum rcpts/h 13 sum msgs/h 3 total rcpts 36553 max rcpts/h 54 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, T_RP_MATCHES_RCVD=-0.01, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: 5661BA6D88474325754B7997327D9A6E187F0C4F X-UiO-SPAM-Test: remote_host: 129.240.68.135 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 2 total 8812 max/h 17 blacklist 0 greylist 0 ratelimit 0 Archived-At: Cc: "icnrg@irtf.org" , gaia , "stackevo-discuss@iab.org" , Jon Crowcroft , "5gangip@ietf.org" <5gangip@ietf.org>, "marnew@iab.org" , "dtn-interest@irtf.org" Subject: Re: [Stackevo-discuss] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 10:18:43 -0000 > On 17 Dec 2015, at 11:10, Dirk Kutscher = wrote: >=20 >>> Regarding security, unless we want to introduce =E2=80=9Ctrusted = middleboxes=E2=80=9D, >>=20 >> Why not? >=20 > No e2e security. >=20 > 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 nobody Thu Dec 17 02:53:51 2015 Return-Path: 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 824211A90C8; Thu, 17 Dec 2015 02:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.612 X-Spam-Level: X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 LAyHdy1s9HH2; Thu, 17 Dec 2015 02:53:42 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98DC11A90B7; Thu, 17 Dec 2015 02:53:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id EE45010B530; Thu, 17 Dec 2015 11:53:40 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3mljuKHkSQi; Thu, 17 Dec 2015 11:53:40 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id BE10210B526; Thu, 17 Dec 2015 11:53:24 +0100 (CET) Received: from HYDRA.office.hd ([169.254.4.101]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0210.002; Thu, 17 Dec 2015 11:53:24 +0100 From: Dirk Kutscher To: Michael Welzl Thread-Topic: [gaia] [Stackevo-discuss] 5G: It's the Network, Stupid Thread-Index: AQHROLBPlVNkrkRTBkOaPzNEJWjMrZ7O8rew///zuQCAABf6gA== Date: Thu, 17 Dec 2015 10:53:23 +0000 Message-ID: <82AB329A76E2484D934BBCA77E9F5249A683592D@Hydra.office.hd> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <82AB329A76E2484D934BBCA77E9F5249A683460E@Hydra.office.hd> <9E220CD1-5C20-4568-8A8D-6461C317BE11@ifi.uio.no> <82AB329A76E2484D934BBCA77E9F5249A6835717@Hydra.office.hd> <9EB6564A-45B0-4164-8D78-0737BBAA0C9F@ifi.uio.no> In-Reply-To: <9EB6564A-45B0-4164-8D78-0737BBAA0C9F@ifi.uio.no> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.102] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "icnrg@irtf.org" , gaia , "stackevo-discuss@iab.org" , Jon Crowcroft , "5gangip@ietf.org" <5gangip@ietf.org>, "marnew@iab.org" , "dtn-interest@irtf.org" Subject: Re: [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid X-BeenThere: stackevo-discuss@iab.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "icnrg@irtf.org" List-Id: IP Stack Evolution Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 10:53:44 -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 icnrg@irtf.org -- let's just use that. (If you intend to reply, consider subscribing to the list first...) Thanks, Dirk > -----Original Message----- > From: Michael Welzl [mailto:michawe@ifi.uio.no] > Sent: Donnerstag, 17. Dezember 2015 11:19 > To: Dirk Kutscher > Cc: icnrg@irtf.org; gaia; stackevo-discuss@iab.org; marnew@iab.org; Jon > Crowcroft; 5gangip@ietf.org; dtn-interest@irtf.org > Subject: Re: [gaia] [Stackevo-discuss] 5G: It's the Network, Stupid >=20 >=20 > > On 17 Dec 2015, at 11:10, Dirk Kutscher 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 l= ess > convincing for accessing public network services -- for example, if you e= xtend > the network with multiple hops of device-to-device communication, data mu= les > etc. >=20 > Hm.... just because you trust them to do certain tasks for you doesn't me= an 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) >=20 > And you can still have e.g. e2e encryption and e2e authentication on top,= right? > So what is the real trust problem here? From nobody Thu Dec 17 06:11:37 2015 Return-Path: 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 C087D1A885F; Wed, 16 Dec 2015 23:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable 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 mYxHraxBtPkj; Wed, 16 Dec 2015 23:25:42 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2561B2A72; Wed, 16 Dec 2015 23:25:40 -0800 (PST) X-AuditID: c1b4fb30-f79296d00000141d-45-56726372be8f Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 47.99.05149.27362765; Thu, 17 Dec 2015 08:25:38 +0100 (CET) Received: from ESESSMB208.ericsson.se ([169.254.8.196]) by ESESSHC011.ericsson.se ([153.88.183.51]) with mapi id 14.03.0248.002; Thu, 17 Dec 2015 08:25:38 +0100 From: Ingemar Johansson S To: Dirk Kutscher , "icnrg@irtf.org" , "dtn-interest@irtf.org" , gaia , "5gangip@ietf.org" <5gangip@ietf.org>, "marnew@iab.org" , "stackevo-discuss@iab.org" Thread-Topic: [5gangip] 5G: It's the Network, Stupid Thread-Index: AQHRODxhlKikVHnEwUWUubUpup+USZ7OwoVQ Date: Thu, 17 Dec 2015 07:25:37 +0000 Message-ID: <81564C0D7D4D2A4B9A86C8C7404A13DA414EF289@ESESSMB208.ericsson.se> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> In-Reply-To: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: multipart/alternative; boundary="_000_81564C0D7D4D2A4B9A86C8C7404A13DA414EF289ESESSMB208erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMIsWRmVeSWpSXmKPExsUyM2K7sW5RclGYwZ2HBhanvt5ls3j4KN3i 5NazzBb/z71nsdg5eyeTxcvlh5ktDi3fweTA7nHr6ktmjyVLfjJ5TN54mM1jxrGX7AEsUVw2 Kak5mWWpRfp2CVwZN1YuZilo8KvYd/QZcwPjTucuRk4OCQETiRdvJ7NC2GISF+6tZ+ti5OIQ EjjMKPHt0CEWCGcJo8SlKd+YQarYBGwkVh76zghiiwjMYZJ41VsOYjMLWEl8Of4XrEZYwFhi 0bNeJogaE4kbM55D2UYS3y48AtvGIqAqMefKYzYQm1fAV+LK1TMsILaQgJvE/ms7wOZwCrhL XFlwBMxmFJCVuP/9HgvELnGJW0/mM0FcLSCxZM95ZghbVOLl439Q3yhK7DzbzgxRny+x69QF VohdghInZz5hmcAoOgvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGEWL U4uTctONjPRSizKTi4vz8/TyUks2MQKj9uCW3wY7GF8+dzzEKMDBqMTD++FNYZgQa2JZcWXu IUYJDmYlEd7ve4BCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeZuZHoQKCaQnlqRmp6YWpBbBZJk4 OKUaGCWuFqZPjYo7Xpqv5vaDYfG1/Zz6Z+XuprVe0lZUeTr9qudGD91P35b9W53RtVzLoVjY P+PjjVcL0wJYPsxSPHSCp982K4+/R+vbxGVPZOJmnD/MrLFmTT3HN5bGoKa1DeHCj6/fsW8Q Nd15P/TaBeuAWRYf15yr65bJZxE4ppPssCn7asU0cSWW4oxEQy3mouJEAOBkbLfWAgAA Archived-At: X-Mailman-Approved-At: Thu, 17 Dec 2015 06:11:34 -0800 Cc: Ingemar Johansson S 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 07:25:44 -0000 --_000_81564C0D7D4D2A4B9A86C8C7404A13DA414EF289ESESSMB208erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Thanks for an interesting blog post. Parts of this is above my head so I on= ly 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 RT= T 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:Dirk.Kutscher@neclab.eu] Sent: den 16 december 2015 19:41 To: icnrg@irtf.org; dtn-interest@irtf.org; gaia; 5gangip@ietf.org; marnew@i= ab.org; stackevo-discuss@iab.org Subject: [5gangip] 5G: It's the Network, Stupid [apologies for cross-posting] Hi, I have written up a few thoughts on current discussions around 5G and netwo= rk 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 n= ot very polished and slightly long, but hopefully understandable enough. Ta= ke it as a "position paper" for now. Abstract: Current 5G network discussion are often focusing on providing more comprehe= nsive and integrated orchestration and management functions in order to imp= rove "end-to-end" managebility and programmability, derived from NGMN and s= imilar requirements. While these are important challenges, this memo takes = the perspective that in order to arrive at a more powerful network, it is i= mportant to understand the pain points and the reasons for certain design c= hoices of today's networks. Understanding the drivers for traffic managemen= t systems, middleboxes, CDNs and other application-layer overlays should be= taken as a basis for analyzing 5G uses cases and their requirements. In th= is 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, t= aking ICN as an example. Features of such a forwarding plane would include = better support for heterogeneous networks (access networks and whole networ= k deployments), multi-path communication, in-network storage and implementa= tion of operator policies. This would help to avoid overlay silos and final= ly simplify network management. http://dirk-kutscher.info/posts/5g-its-the-network-stupid/ Thanks, Dirk --_000_81564C0D7D4D2A4B9A86C8C7404A13DA414EF289ESESSMB208erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

Thanks = for an interesting blog post. Parts of this is above my head so I only comm= ent on the parts that I know well

AQM and= ECN : Agree fully, there seems to be a general tendency to overlook the ba= sic elements in congestion management in networks. Quite often  one se= e 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  w= as 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 env= ision more local deployments like what is outlined in draft-ietf-conex-mobile ?.

&n= bsp;

/Ingema= r

&n= bsp;

Dirk = Kutscher [mailto:Dirk.Kutscher@neclab.eu]
Sent: den 16 december 2015 19:41
To: icnrg@irtf.org; dtn-interest@irtf.org; gaia; 5gangip@ietf.org; m= arnew@iab.org; stackevo-discuss@iab.org
Subject: [5gangip] 5G: It's the Network, Stupid

 

[apologies for cross-posting]

 

Hi,

 

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

 

Abstract:

Current 5G network discussion a= re often focusing on providing more comprehensive and integrated orchestrat= ion and management functions in order to improve “end-to-end” m= anagebility 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, i= t is important to understand the pain points and the reasons for certain de= sign choices of today’s networks. Understanding the drivers for traffic management systems, middleboxes, CDN= s and other application-layer overlays should be taken as a basis for analy= zing 5G uses cases and their requirements. In this memo, I am making the po= int that many of today’s business needs and the ambitious 5G use cases do call for a more powerful data forw= arding plane, taking ICN as an example. Features of such a forwarding plane= would include better support for heterogeneous networks (access networks a= nd 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 manage= ment.

 

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

 

Thanks,

Dirk

 

--_000_81564C0D7D4D2A4B9A86C8C7404A13DA414EF289ESESSMB208erics_-- From nobody Thu Dec 17 06:11:38 2015 Return-Path: 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 B479D1A88A3; Wed, 16 Dec 2015 23:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no 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 q_BXY4KerID9; Wed, 16 Dec 2015 23:57:03 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (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 5556C1B2A5E; Wed, 16 Dec 2015 23:57:01 -0800 (PST) Received: by mail-lb0-x22a.google.com with SMTP id yq9so21195322lbb.3; Wed, 16 Dec 2015 23:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=j/kOPBx7939r7rIxxmhzKwVR++aUQBD7wIdyafGXtFo=; b=wkAj51QuRT2slZabiAXk0y8iEu4P5Upf5n1ndVMSqlPDcRymYaOYk4Bm+efxxm3del dHULNB1eg17OpS6S7IxP88YDRAsTsY11rvh+/f2NtTCBjIZ4+2JCmebTqI1iOmRf6/zb nYhebOJH/sqDyWabma5+n9OjonOTAaJ9wRGmd+cTvAv+CHjkX1TnOXVPZV6r3haPmWaZ kwwgIMLKwcu6ELyoWwBIl1CFeJj7aMdxbL51Ci8x+YmNM6xrj/X+lrCBiPIbTTOtQCfX iqXS9v1kPO/3axIToU/TjTODOlIPLixUJPNNIeSLFzij05v+6SQWnkxZr9MV+dJ2Et5M ep5w== MIME-Version: 1.0 X-Received: by 10.112.134.66 with SMTP id pi2mr20268171lbb.83.1450339019409; Wed, 16 Dec 2015 23:56:59 -0800 (PST) Sender: crowcroft@gmail.com Received: by 10.25.21.200 with HTTP; Wed, 16 Dec 2015 23:56:59 -0800 (PST) Received: by 10.25.21.200 with HTTP; Wed, 16 Dec 2015 23:56:59 -0800 (PST) In-Reply-To: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> Date: Thu, 17 Dec 2015 07:56:59 +0000 X-Google-Sender-Auth: FDziwolWoCyRyoFZxP6ArIGC0os Message-ID: From: Jon Crowcroft To: Dirk Kutscher Content-Type: multipart/alternative; boundary=047d7b3a8bf00e53ec0527135e8e Archived-At: X-Mailman-Approved-At: Thu, 17 Dec 2015 06:11:34 -0800 Cc: "icnrg@irtf.org" , gaia , "stackevo-discuss@iab.org" , "marnew@iab.org" , "5gangip@ietf.org" <5gangip@ietf.org>, "dtn-interest@irtf.org" Subject: Re: [Stackevo-discuss] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 07:57:04 -0000 --047d7b3a8bf00e53ec0527135e8e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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" 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 =E2=80=93 so would be grateful for any = feedback. > It=E2=80=99s not very polished and slightly long, but hopefully understan= dable > enough. Take it as a =E2=80=9Cposition paper=E2=80=9D for now. > > > > Abstract: > > Current 5G network discussion are often focusing on providing more > comprehensive and integrated orchestration and management functions in > order to improve =E2=80=9Cend-to-end=E2=80=9D managebility and programmab= ility, derived > from NGMN and similar requirements. While these are important challenges, > this memo takes the perspective that in order to arrive at a more powerfu= l > network, it is important to understand the pain points and the reasons fo= r > certain design choices of today=E2=80=99s networks. Understanding the dri= vers 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=E2= =80=99s > 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 he= lp > to avoid overlay silos and finally simplify network management. > > > > http://dirk-kutscher.info/posts/5g-its-the-network-stupid/ > > > > Thanks, > > Dirk > > > > _______________________________________________ > gaia mailing list > gaia@irtf.org > https://www.irtf.org/mailman/listinfo/gaia > > --047d7b3a8bf00e53ec0527135e8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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

On 16 Dec 2015 6:42 pm, "Dirk Kutscher"= ; <Dirk.Kutscher@neclab.eu> wrote:

[apologies for cross-posting]

=C2=A0

Hi,

=C2=A0

I have written up a few thought= s on current discussions around 5G and network evolution. I might publish t= his as paper later, but wanted to get it out early and ask for comments =E2= =80=93 so would be grateful for any feedback. It=E2=80=99s not very polished and slightly long, but hopefully understand= able enough. Take it as a =E2=80=9Cposition paper=E2=80=9D for now.<= u>

=C2=A0

Abstract:<= /p>

Current 5G network discussion a= re often focusing on providing more comprehensive and integrated orchestrat= ion and management functions in order to improve =E2=80=9Cend-to-end=E2=80= =9D 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, i= t is important to understand the pain points and the reasons for certain de= sign choices of today=E2=80=99s networks. Understanding the drivers for traffic management systems, middleboxes, CDN= s and other application-layer overlays should be taken as a basis for analy= zing 5G uses cases and their requirements. In this memo, I am making the po= int that many of today=E2=80=99s business needs and the ambitious 5G use cases do call for a more powerful data forw= arding plane, taking ICN as an example. Features of such a forwarding plane= would include better support for heterogeneous networks (access networks a= nd 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 manage= ment.

=C2=A0

http://dirk-kutsc= her.info/posts/5g-its-the-network-stupid/

=C2=A0

Thanks,

Dirk

=C2=A0


_______________________________________________
gaia mailing list
gaia@irtf.org
https://www.irtf.org/mailman/listinfo/gaia

--047d7b3a8bf00e53ec0527135e8e-- From nobody Thu Dec 17 06:11:40 2015 Return-Path: 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 375DB1B2C06; Thu, 17 Dec 2015 04:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.209 X-Spam-Level: X-Spam-Status: No, score=0.209 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_DBL_ABUSE_REDIR=0.001] autolearn=no 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 Kg8tgrgyTzGJ; Thu, 17 Dec 2015 04:43:04 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::713]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4222E1B2C07; Thu, 17 Dec 2015 04:43:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emc.kcl.ac.uk; s=selector1-kcl-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bZReGdAR25ZyqVIz7ZawwAZlixecxWIT5mjaRXGF3aA=; b=dDJtIOh/tznyFIHDwsv5mTPB1phDXet9x0k4zjKXHUzEsvmvQB1tAnjurm7jbyV52Wf5VN5eD52BbZgwddjhPpawnYjaH721bMsBVhZ9lX3L2EbH3DZLQCOiHis1PUv0CRq6pnJjIMLoi5aV7EM/5JAfR88Yx1pyLOSFs8Kv5tI= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=nishanth.sastry@kcl.ac.uk; Received: from [192.168.0.7] (82.1.229.138) by VI1PR03MB1229.eurprd03.prod.outlook.com (10.163.165.26) with Microsoft SMTP Server (TLS) id 15.1.361.13; Thu, 17 Dec 2015 12:42:42 +0000 From: Nishanth Sastry To: Jon Crowcroft Date: Thu, 17 Dec 2015 12:42:38 +0000 Message-ID: In-Reply-To: References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.3r5187) X-Originating-IP: [82.1.229.138] X-ClientProxiedBy: AM2PR09CA0068.eurprd09.prod.outlook.com (25.160.228.164) To VI1PR03MB1229.eurprd03.prod.outlook.com (25.163.165.26) X-Microsoft-Exchange-Diagnostics: 1; VI1PR03MB1229; 2:ROiAizGdwunBcRM7Fm9cqhazGBIyksHenDCc3ceBvh6BDPnVdemjqD5/ECS8ejFcdTV5oFlloASYC0lDN4Ojcyk0AUO8CiKow99qUYO/jJvzIzJvs9OMA2unHpKIUb7w9Pp0XMyIJg2eGeHdfbUjNQ==; 3:h3YgqESFufC3Yja0DTAemYVTOBiZt1Hz73IlHt2GfX3TxZQTtMktuU9zrMKKkfEWRK9fH8VUT178hstL6sNAZwmWeHovc6d+SMArarw/1gIwqfgKI+AcoFQHhgei3Cit; 25:BvuCyifObN2Uc6HD0zPozycNjN4PK8ji+TscfD2qbTVUljiBgx85RyBTQR1m/uwkOqXKavENMQU13vEUM4XaRpP3xENLYy0ebDgrVHljysOoTWbTfqLcmLFhge7SFbwwGiLWovX4qz2T2omSRviMFVfO/GeYrlTye2ePbjTVB9Jyux40aA19YnjK0cnBfUk5f2prPOFgaFIpSfkphEMJitBfWTfYCH25mMbzOtBYD93DDuXD0YboG5QqrTeAT/CcPmSTGq5QLLlwD8Nl7OemnA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1229; X-Microsoft-Exchange-Diagnostics: 1; VI1PR03MB1229; 20:CXwS/saU9u24wyp2B2aKw5SH8PSQjNOwjvagcbGogfpoJ+igN8O7tQ02VC1tJM+87uvFY4+ot4U31rTtX8tHVarcPd86T0d4egB3U07aZ4rCz5D8k0PeOwBUrdOnzjzrZY/aqiwx5wOBMm8AMVmy0EmBRiSuLlLNvhcJoQnrjyPMDDSLRyw4VvSNxYfA89HAAXeekeC+X3hvM6VVM531cyr0l3Iwzj0Fypz520/iw5Yi4bcRmC1VtfcBCFVe4lTfEi+Or5oEPwBE5ZG3HG/g4FZ8W6OVxKxGlIhyoJ44hqfx8fTUjgN09wAHfXo6edMo2k1FigMBhlv9X8j9aCOKIU3eAdBHuDyfgmA3sxQ2p2ATMk9bgAu7sQgL/iCK/tcE4GME6dE/H70DXpUkg6l056ZVHYJeZZw+2D9CRZUq/uR5sKYJVCKMgZPIcpEG8MDZT1eosb6jH+J/wlDtzSQOr1n1CSDIZxvi0JsD3xmIIsdHTLVR8KHZpWOxniUrPMyp; 4:nyCjH0hbTFuCL4khcpTHOR6pxgL5bXrqHDBhKAAdCNuAVMXcYMthzM4s9JCpWOZyXGT9hPE3LgTupJ+gCGYGXY+tvnGZN0Y0iLA3/jOhbBiVHiqPKqjVPCknQrscJJX8Kv8h6F3+yYwB+G7ZK2mvM2p/UdOdCLvAnHyFH41NQJjIxBCVn9ay9mjaKBs8fGJejLJes29NMxJFObofju3Bcl9+jyXXIFOZ4GQX4hEcWIqcDbSMIX8WbbauX7Ga3jcho7LOmldwK/YP3BlkLUH41f371UGrKljSpBFmxxj1DfuyZQh+8BcykuO92/QqQsVxPJ5wrCZEdSP0uhkiMjMkH3ObbTLggOWZatCu1OTRV/P9mqyCsRwoalpoxZM+f4xM X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001)(10201501046); SRVR:VI1PR03MB1229; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1229; X-Forefront-PRVS: 07935ACF08 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(209900001)(199003)(377454003)(24454002)(164054003)(189002)(15395725005)(92566002)(5004730100002)(122386002)(81156007)(189998001)(76176999)(50986999)(74826001)(19580405001)(50466002)(19580395003)(86362001)(74482002)(40100003)(97736004)(50226001)(110136002)(87976001)(105586002)(106356001)(2950100001)(47776003)(83716003)(66066001)(15975445007)(16601075003)(1720100001)(36756003)(5001960100002)(77096005)(117156001)(33656002)(1096002)(23676002)(6116002)(3846002)(42186005)(82746002)(15198665003)(586003)(5008740100001)(101416001)(104396002)(493534005)(19477635001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR03MB1229; H:[192.168.0.7]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: kcl.ac.uk does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjAzTUIxMjI5OzIzOjFXL2UvNXQzZGNJb2g3Vjd0d0VTbHpHYlFG?= =?utf-8?B?QkJleURoSkFVd1hEa01rMnFHSzBCN2RCcTh0d0tya3V0SVk1c29LQWVtRXhY?= =?utf-8?B?MDlRUitUSTJwODhlbnExM3pSQXRnYWE1elBwMzdHVjdqMXJKdmJpOStaVDZm?= =?utf-8?B?eDNrV0IwbFpyZkxXalZhOXZBSmdHU1orMUFudGYxOXRiaFVpczA5MWVhaml6?= =?utf-8?B?ekRFVzV2Sy9KdXNLY21FUWhveDFqaXQ3UlpnUlB6RGNNdjF3aElKTUFhRFpy?= =?utf-8?B?MGEwanlhS2lUTEhpSDdSaHBNK1ZtOS9IVXNKcjBzZXVFTDhCNko3OHV1Y1p3?= =?utf-8?B?R3hLYU5kM0U0MEs3czV1VzhhZEpnaGdzRGJDT3pNZ3lJNS9rVWNmKzRveHNk?= =?utf-8?B?UVcxTFFUdEt0QXF5U3hLNyswR0R2WTRadzZOZnFxcWh2Y1lnNzZYak12dVBh?= =?utf-8?B?ZURJVmdiK2lZZS84T3R1N3RkWmxSeFM1Z1JQaDd3TkNsTEoreDNWeVZPc2ho?= =?utf-8?B?Q1M3cEN4MFdBRHZWRnZnR25CKzlycTgxWkRSK1J1cGpXamZ2cmpMYnUrTW5W?= =?utf-8?B?YURBYk5XZDNmMkFKaTZMRUtRMVR2N1NBUStlY3IybTc4RUxaKzZYdVZDSlNw?= =?utf-8?B?SWxsT3V4UFE1b2srYzFBOUhIZlU4OWd6WnpHd2UzTVNQUUdoaFRibFQzSC8x?= =?utf-8?B?VFhGZ1M0NFIxVHVSOVZMbU1BN0pVamlRbEN0a252QTZVeE5ZdmtTdm0vd2lK?= =?utf-8?B?Tmo4YXhBbHJoN1BMV3l3bGt4eFdFTnNXVkxTcW9FNC9PWkxoT0JoS2h5czMx?= =?utf-8?B?Ylltb01DNXFDSXJkUUZjdVNwdkdJRXFTZ25zZHBrVDROWi8xNm4xZnhUbTJE?= =?utf-8?B?bkRzQVVReDFUNXBiYXBtNSs5QVNpemlRUmFvZlJvcWNNUXp3VUdlci9GR2M4?= =?utf-8?B?dlJEc0lNRExNQzFhaGpaeTNRYm0vaEpUVWlpV1dKU2w3NWhOWUd3d2tBWnNs?= =?utf-8?B?dWpsZTdIYUowSFpYZkVsa3ZObndJVFBRQlY1Ni9RaFJPZmU0ZkZlQ1FHbHQ1?= =?utf-8?B?VkdEWTZHTG5GaGFWYXRuZmUzcmRkdzlrLzJMQThMMWZ3RmdrRlNxM3puZEdP?= =?utf-8?B?UjlmSnE3Y0taMk1qWTQ4aGhzSitOYlJtRU9YRE45dVhvRXdxc1h2T2RVdnFO?= =?utf-8?B?U1FUL3JCaUxJa0VRb3NSQTNmMmh6MVc5YTBCYTBucm5Id0NYV2U2VlVxMFNr?= =?utf-8?B?U3ptbzNBMHFhWmJXSjV6TjRnakcyVXYwdXRjY0Y2WWY0UW5KNzY4TXYvZmFx?= =?utf-8?B?UzIxZVpLMHZUZWM0ZzVkQjVRSVF5cElaYWhlNDJzRC9mMG1YcXovSmx1aFQv?= =?utf-8?B?SHAvTjNqNGttYkwrMnZHSllqbW00S3FOaW9aM1NlN3J3SDhiMnNOMWVMYWR0?= =?utf-8?B?Wk5yQVhNM0pqeUljN2NzOXVNOC96YkFheHgrM3NadzhuMTNxT2Zhek92dzRJ?= =?utf-8?B?N01BSHlINEROOWFhZGozWW5NNGlmaGZZeko0ait5bDFLTTlZZWtNQm9NRjlJ?= =?utf-8?B?NUx1QU1WTTdRbEVQZHhMNnV5TlR3MCsrN0dlQ0VsSE4wRFF4c3c4OXRlRkhF?= =?utf-8?B?ckNXVjZ2VmFaOFF0N1FqaG1aNlFsbjlOOWd0WGQ3QitwOTBHUFZybzFJNkha?= =?utf-8?B?RTMxNGo3a3dOdTVCOWNMVW9JaXBjZ3lEQVEzSXEzZ0J1K1RtbkNxWGVSZyt2?= =?utf-8?B?OVFHUUQvZjNLbGJhWHJWaThqUHVEZjhic29PdExYR1ViZUlWd1dTMDZYejAw?= =?utf-8?B?S1VaY1lrWTB4dGNkR2ZhOUJqYkRMekFNR1I1b1J4cWJtOWxxdVlnQURmSHZI?= =?utf-8?B?SEpkNDdJQThKazJBcDYzU2ZKb01TelFBQ0FkdktOa0dBOWptSjg1Z3kzcXI0?= =?utf-8?B?TU9HdmJtN1RBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR03MB1229; 5:KI6P4Oh1sRhKf3bngU7ZmqonJQHTBmsPHcdHHihWsvixyaC2euVgJ30fJEi6T7gzpYHJRYiWjnpd0LjnWaHgHGmW9lCCPhoDqZBxGyv++LLPnFCamdcMx//pb/QBim9n2XX+K+Cg08mMAdgGPeTXBw==; 24:M2LPt0tNDt1UbFoWkB3omtu8GjmvC/uCqA9gjggVHijsgKuYLRgZFByB5garSkpdJA24Zv5C//8Fg+0EB2Zy7OyHyt/KMVR9TVXXW4ISevI= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: kcl.ac.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2015 12:42:42.2644 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1229 Archived-At: X-Mailman-Approved-At: Thu, 17 Dec 2015 06:11:34 -0800 Cc: "icnrg@irtf.org" , gaia , "stackevo-discuss@iab.org" , Dirk Kutscher , "marnew@iab.org" , "5gangip@ietf.org" <5gangip@ietf.org>, "dtn-interest@irtf.org" Subject: Re: [Stackevo-discuss] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 12:43:06 -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 — 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... > On 16 Dec 2015 6:42 pm, "Dirk Kutscher" > 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. >> >> >> >> http://dirk-kutscher.info/posts/5g-its-the-network-stupid/ >> >> >> >> Thanks, >> >> Dirk >> >> >> >> _______________________________________________ >> gaia mailing list >> gaia@irtf.org >> https://www.irtf.org/mailman/listinfo/gaia >> >> > _______________________________________________ > gaia mailing list > gaia@irtf.org > https://www.irtf.org/mailman/listinfo/gaia From nobody Thu Dec 17 06:11:42 2015 Return-Path: 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 56A791B2DEB; Thu, 17 Dec 2015 05:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] 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 mhzQz_JKS2N8; Thu, 17 Dec 2015 05:57:37 -0800 (PST) Received: from tiger.dc.kau.se (smtp.kau.se [193.10.220.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3CAB1B2DEA; Thu, 17 Dec 2015 05:57:36 -0800 (PST) X-Spam-Processed: mail.kau.se, Thu, 17 Dec 2015 14:49:13 +0100 (not processed: spam filter heuristic analysis disabled) X-MDHelo: WorldClient X-MDArrival-Date: Thu, 17 Dec 2015 14:49:13 +0100 X-Authenticated-Sender: davitaht@kau.se X-Return-Path: david.taht@kau.se X-Envelope-From: david.taht@kau.se Date: Thu, 17 Dec 2015 14:49:11 +0100 From: "David Michael Taht" To: "Dirk Kutscher" , "Jon Crowcroft" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1217-1349-11-03-PART_BREAK" Message-ID: X-Mailer: WorldClient 15.5.2 In-Reply-To: <82AB329A76E2484D934BBCA77E9F5249A683460E@Hydra.office.hd> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <82AB329A76E2484D934BBCA77E9F5249A683460E@Hydra.office.hd> Archived-At: X-Mailman-Approved-At: Thu, 17 Dec 2015 06:11:34 -0800 Cc: icnrg@irtf.org, gaia , stackevo-discuss@iab.org, marnew@iab.org, 5gangip@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 13:57:38 -0000 --1217-1349-11-03-PART_BREAK Content-Type: text/plain; charset="us-ascii" 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] --1217-1349-11-03-PART_BREAK Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
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 hom= eplug (network over powerline) technologies don't seem to be paying eve= n half as much attention to the details you raise, as the 5g-ers are.
 
 
--1217-1349-11-03-PART_BREAK-- From nobody Thu Dec 17 09:49:47 2015 Return-Path: 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 AC1FB1B3005; Thu, 17 Dec 2015 09:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_ABUSE_REDIR=0.001] autolearn=unavailable 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 ygWDQlhrso4J; Thu, 17 Dec 2015 09:49:42 -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 F05E21A6FEE; Thu, 17 Dec 2015 09:49:41 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml705-chm.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTY97222; Thu, 17 Dec 2015 11:49:29 -0600 (CST) Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Thu, 17 Dec 2015 09:49:25 -0800 From: Linda Dunbar To: Nishanth Sastry , Jon Crowcroft Thread-Topic: [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid Thread-Index: AQHROKCBFOy+4JcsRU6TQySMUk3qa57Ppa0A///OtjA= Date: Thu, 17 Dec 2015 17:49:24 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.107] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0205.5672F5AA.0045, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9ad4ca32d9666d7a144bd444959ab881 Archived-At: Cc: "icnrg@irtf.org" , gaia , "stackevo-discuss@iab.org" , Dirk Kutscher , "marnew@iab.org" , "5gangip@ietf.org" <5gangip@ietf.org>, "dtn-interest@irtf.org" Subject: Re: [Stackevo-discuss] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 17:49:43 -0000 SSBzdHJvbmdseSBzdXBwb3J0IHRoZSBjb25jZXB0IG9mIG5ldHdvcmsgc2xpY2luZyBmb3IgQXBw bGljYXRpb25zIG9yIElvVCBuZXR3b3Jrcy4gDQpCdXQgaXQgaXMgbm90IHJlYWxpc3RpYyB0byBl eHBlY3Qgb3BlcmF0b3JzIG5ldHdvcmtzIHRvIHRha2UgY29udHJvbCByZXF1ZXN0cyBmcm9tIGlu ZGl2aWR1YWwgdXNlcnMvaGFuZHNldHMuIFRoZXJlIGhhcyB0byBiZSBhbiBhdXRoZW50aWNhdGVk IGFwcGxpY2F0aW9uIGNvbnRyb2xsZXIgdGhhdCBtYWtlcyByZXF1ZXN0cy9jb21tYW5kcyB0byB0 aGUgc2xpY2VkIG5ldHdvcmsuIA0KDQpNeSB0d28gY2VudHMuIA0KDQpMaW5kYSANCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN0YWNrZXZvLWRpc2N1c3MgW21haWx0bzpzdGFj a2V2by1kaXNjdXNzLWJvdW5jZXNAaWFiLm9yZ10gT24gQmVoYWxmIE9mIE5pc2hhbnRoIFNhc3Ry eQ0KU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDE3LCAyMDE1IDY6NDMgQU0NClRvOiBKb24gQ3Jv d2Nyb2Z0DQpDYzogaWNucmdAaXJ0Zi5vcmc7IGdhaWE7IHN0YWNrZXZvLWRpc2N1c3NAaWFiLm9y ZzsgRGlyayBLdXRzY2hlcjsgbWFybmV3QGlhYi5vcmc7IDVnYW5naXBAaWV0Zi5vcmc7IGR0bi1p bnRlcmVzdEBpcnRmLm9yZw0KU3ViamVjdDogUmU6IFtTdGFja2V2by1kaXNjdXNzXSBbZ2FpYV0g NUc6IEl0J3MgdGhlIE5ldHdvcmssIFN0dXBpZA0KDQpFMkUgc2VjdXJpdHkgaW4gNUcgY2FuIGJl IGFkZHJlc3NlZCB0aHJvdWdoIG5ldHdvcmsgc2xpY2luZywgYW5vdGhlciBjb25jZXB0IHdoaWNo IHNlZW1zIHRvIGJlIGluY2x1ZGVkIGluIG1hbnkgNUcgcHJvcG9zYWxzLiBJZiBlYWNoIGFwcGxp Y2F0aW9uIGhhcyBpdHMgb3duIHNsaWNlLCBpdCBjYW4gc2NyZXcgdXAgYnV0IHdvbnQgYmUgYWJs ZSB0byBhZmZlY3Qgb3RoZXIgYXBwbGljYXRpb25zLiBXaXRoaW4gZWFjaCBzbGljZSwgRTJFIHNl Y3VyaXR5IGNhbiBiZSBlbmZvcmNlZCBpbiBhbiBhcHBsaWNhdGlvbiBzcGVjaWZpYyBtYW5uZXIu IEV2ZW4gYmV0dGVyIHdvdWxkIGJlIGlmIHdlIGNhbiBtYWtlIGVhY2ggZmxvdyBiZSBpdHMgb3du IHNsaWNlLiBUaGlzIG1heSBzZWVtIHRvIGJlIG92ZXJseSBoZWF2eXdlaWdodCwgYnV0IGlzIGFs b25nIHRoZSBsaW5lcyBvZiB3aGF0IEJyb21pdW0gIGlzIHRyeWluZyB0byBkbyBmb3IgZGVza3Rv cHMsIGlzb2xhdGluZyBwcm9jZXNzZXMgYW5kIGRhdGEgZnJvbSBlYWNoIG90aGVyIHVzaW5nDQoi bWljcm92aXNvcnMiOiBodHRwOi8vd3d3LmJyb21pdW0uY29tL3doeS1icm9taXVtL2hvdy13ZS1k by1pdC5odG1sIFdlIGp1c3QgbmVlZCB0byBkbyBpdCBmb3IgbmV0d29ya3MgOikNCg0KbmlzaGFu dGgNCuKAlA0KQ0QtR0FJTjogaHR0cDovL2JpdC5seS9jZC1nYWluDQpTNFM6IGh0dHA6Ly93d3cu c3BhY2U0c2hhcmluZ3N0dWR5Lm9yZy8NClJFQUNIOiBodHRwOi8vd3d3LmV1LWluZGlhLm5ldA0K DQo1RyBOb3JtYTogaHR0cHM6Ly81Zy1wcHAuZXUvNWctbm9ybWENClZpcnR1V2luZDogaHR0cHM6 Ly81Zy1wcHAuZXUvdmlydHV3aW5kLw0KDQpPbiAxNyBEZWMgMjAxNSwgYXQgNzo1NiwgSm9uIENy b3djcm9mdCB3cm90ZToNCg0KPiBHcmVhdCBhcnRpY2xlLi4ub25lIHRoaW5nIGFib3V0IHRoZSA0 Zy4uNWcgZXZvbHV0aW9uIGlzIGluY3JlYXNpbmcNCj4gY29vcGVyYXRpb24gaW4gZm9yd2FyZGlu ZyBhbmQgcmVsYXlpbmcgc2lnbmFsLCBiaXRzLCBwYWNrZXRzIChzaGFyZWQgDQo+IGNlbGwNCj4g dG93ZXIvYmFzZSBzdGF0aW9uL2FudGVubmFlIGFjcm9zcyBwcm92aWRlcikuIFNvIGRpcmVjdCxt ZXNoLGFkaG9jIA0KPiBzdG9wDQo+IGp1c3QgYmVpbmcgZWRnZSBub3Rpb25zLCBidXQgYXJlIGFs bCBmaXJzdCBjbGFzcyBwYXJ0IG9mIHRoZSANCj4gYXJjaGl0ZWN0dXJlDQo+ICgiZG9uJ3QgZmVh ciB0aGUgZWRnZSIpLiBUaGVyZSBpcyBodWdlIHRlbnNpb24gYmV0d2VlbiB0aGlzIHRyZW5kLCBh bmQgDQo+IGUyZQ0KPiBzZWN1cml0eS4uLi5JIGhhdmUgbm90IHNlZW4gYW55b25lIGFkZHJlc3Mg aG93IHRvIHJlc29sdmUgdGhhdCANCj4gdGVuc2lvbi4uLg0KPiBPbiAxNiBEZWMgMjAxNSA2OjQy IHBtLCAiRGlyayBLdXRzY2hlciIgPERpcmsuS3V0c2NoZXJAbmVjbGFiLmV1PiANCj4gd3JvdGU6 DQo+DQo+PiBbYXBvbG9naWVzIGZvciBjcm9zcy1wb3N0aW5nXQ0KPj4NCj4+DQo+Pg0KPj4gSGks DQo+Pg0KPj4NCj4+DQo+PiBJIGhhdmUgd3JpdHRlbiB1cCBhIGZldyB0aG91Z2h0cyBvbiBjdXJy ZW50IGRpc2N1c3Npb25zIGFyb3VuZCA1RyBhbmQNCj4+IG5ldHdvcmsgZXZvbHV0aW9uLiBJIG1p Z2h0IHB1Ymxpc2ggdGhpcyBhcyBwYXBlciBsYXRlciwgYnV0IHdhbnRlZCB0byANCj4+IGdldA0K Pj4gaXQgb3V0IGVhcmx5IGFuZCBhc2sgZm9yIGNvbW1lbnRzIOKAkyBzbyB3b3VsZCBiZSBncmF0 ZWZ1bCBmb3IgYW55IA0KPj4gZmVlZGJhY2suDQo+PiBJdOKAmXMgbm90IHZlcnkgcG9saXNoZWQg YW5kIHNsaWdodGx5IGxvbmcsIGJ1dCBob3BlZnVsbHkgDQo+PiB1bmRlcnN0YW5kYWJsZQ0KPj4g ZW5vdWdoLiBUYWtlIGl0IGFzIGEg4oCccG9zaXRpb24gcGFwZXLigJ0gZm9yIG5vdy4NCj4+DQo+ Pg0KPj4NCj4+IEFic3RyYWN0Og0KPj4NCj4+IEN1cnJlbnQgNUcgbmV0d29yayBkaXNjdXNzaW9u IGFyZSBvZnRlbiBmb2N1c2luZyBvbiBwcm92aWRpbmcgbW9yZQ0KPj4gY29tcHJlaGVuc2l2ZSBh bmQgaW50ZWdyYXRlZCBvcmNoZXN0cmF0aW9uIGFuZCBtYW5hZ2VtZW50IGZ1bmN0aW9ucyANCj4+ IGluDQo+PiBvcmRlciB0byBpbXByb3ZlIOKAnGVuZC10by1lbmTigJ0gbWFuYWdlYmlsaXR5IGFu ZCBwcm9ncmFtbWFiaWxpdHksIA0KPj4gZGVyaXZlZA0KPj4gZnJvbSBOR01OIGFuZCBzaW1pbGFy IHJlcXVpcmVtZW50cy4gV2hpbGUgdGhlc2UgYXJlIGltcG9ydGFudCANCj4+IGNoYWxsZW5nZXMs DQo+PiB0aGlzIG1lbW8gdGFrZXMgdGhlIHBlcnNwZWN0aXZlIHRoYXQgaW4gb3JkZXIgdG8gYXJy aXZlIGF0IGEgbW9yZSANCj4+IHBvd2VyZnVsDQo+PiBuZXR3b3JrLCBpdCBpcyBpbXBvcnRhbnQg dG8gdW5kZXJzdGFuZCB0aGUgcGFpbiBwb2ludHMgYW5kIHRoZSANCj4+IHJlYXNvbnMgZm9yDQo+ PiBjZXJ0YWluIGRlc2lnbiBjaG9pY2VzIG9mIHRvZGF54oCZcyBuZXR3b3Jrcy4gVW5kZXJzdGFu ZGluZyB0aGUgDQo+PiBkcml2ZXJzIGZvcg0KPj4gdHJhZmZpYyBtYW5hZ2VtZW50IHN5c3RlbXMs IG1pZGRsZWJveGVzLCBDRE5zIGFuZCBvdGhlciANCj4+IGFwcGxpY2F0aW9uLWxheWVyDQo+PiBv dmVybGF5cyBzaG91bGQgYmUgdGFrZW4gYXMgYSBiYXNpcyBmb3IgYW5hbHl6aW5nIDVHIHVzZXMg Y2FzZXMgYW5kIA0KPj4gdGhlaXINCj4+IHJlcXVpcmVtZW50cy4gSW4gdGhpcyBtZW1vLCBJIGFt IG1ha2luZyB0aGUgcG9pbnQgdGhhdCBtYW55IG9mIA0KPj4gdG9kYXnigJlzDQo+PiBidXNpbmVz cyBuZWVkcyBhbmQgdGhlIGFtYml0aW91cyA1RyB1c2UgY2FzZXMgZG8gY2FsbCBmb3IgYSBtb3Jl IA0KPj4gcG93ZXJmdWwNCj4+IGRhdGEgZm9yd2FyZGluZyBwbGFuZSwgdGFraW5nIElDTiBhcyBh biBleGFtcGxlLiBGZWF0dXJlcyBvZiBzdWNoIGENCj4+IGZvcndhcmRpbmcgcGxhbmUgd291bGQg aW5jbHVkZSBiZXR0ZXIgc3VwcG9ydCBmb3IgaGV0ZXJvZ2VuZW91cyANCj4+IG5ldHdvcmtzDQo+ PiAoYWNjZXNzIG5ldHdvcmtzIGFuZCB3aG9sZSBuZXR3b3JrIGRlcGxveW1lbnRzKSwgbXVsdGkt cGF0aCANCj4+IGNvbW11bmljYXRpb24sDQo+PiBpbi1uZXR3b3JrIHN0b3JhZ2UgYW5kIGltcGxl bWVudGF0aW9uIG9mIG9wZXJhdG9yIHBvbGljaWVzLiBUaGlzIA0KPj4gd291bGQgaGVscA0KPj4g dG8gYXZvaWQgb3ZlcmxheSBzaWxvcyBhbmQgZmluYWxseSBzaW1wbGlmeSBuZXR3b3JrIG1hbmFn ZW1lbnQuDQo+Pg0KPj4NCj4+DQo+PiBodHRwOi8vZGlyay1rdXRzY2hlci5pbmZvL3Bvc3RzLzVn LWl0cy10aGUtbmV0d29yay1zdHVwaWQvDQo+Pg0KPj4NCj4+DQo+PiBUaGFua3MsDQo+Pg0KPj4g RGlyaw0KPj4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IGdhaWEgbWFpbGluZyBsaXN0DQo+PiBnYWlhQGlydGYub3JnDQo+PiBo dHRwczovL3d3dy5pcnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dhaWENCj4+DQo+Pg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBnYWlhIG1haWxp bmcgbGlzdA0KPiBnYWlhQGlydGYub3JnDQo+IGh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4v bGlzdGluZm8vZ2FpYQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KU3RhY2tldm8tZGlzY3VzcyBtYWlsaW5nIGxpc3QNClN0YWNrZXZvLWRpc2N1c3NA aWFiLm9yZw0KaHR0cHM6Ly93d3cuaWFiLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N0YWNrZXZvLWRp c2N1c3MNCg== From nobody Thu Dec 17 11:44:54 2015 Return-Path: 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 478911A889C; Thu, 17 Dec 2015 11:39:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_ABUSE_REDIR=0.001] autolearn=unavailable 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 YaeJfwOithnF; Thu, 17 Dec 2015 11:39:52 -0800 (PST) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8676D1A889A; Thu, 17 Dec 2015 11:39:48 -0800 (PST) Received: from 172.24.1.49 (EHLO szxeml431-hub.china.huawei.com) ([172.24.1.49]) by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYF72763; Fri, 18 Dec 2015 03:39:18 +0800 (CST) Received: from szxeml559-mbs.china.huawei.com ([169.254.2.89]) by szxeml431-hub.china.huawei.com ([10.82.67.208]) with mapi id 14.03.0235.001; Fri, 18 Dec 2015 03:39:04 +0800 From: AshwoodsmithPeter To: Nishanth Sastry , Jon Crowcroft Thread-Topic: [5gangip] [gaia] 5G: It's the Network, Stupid Thread-Index: AdE4MC4YYpSof3RGRdK/YSjH5J56uAALUVSAAAn56QAAHza00A== Date: Thu, 17 Dec 2015 19:39:03 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E20AF366BB@szxeml559-mbs.china.huawei.com> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.67] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.56730F68.0023, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.89, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 00848a8b86cf5b6a52bf185d28311680 Archived-At: X-Mailman-Approved-At: Thu, 17 Dec 2015 11:44:54 -0800 Cc: "icnrg@irtf.org" , gaia , "stackevo-discuss@iab.org" , Dirk Kutscher , "marnew@iab.org" , "5gangip@ietf.org" <5gangip@ietf.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 19:39:54 -0000 VGhhdCBpcyBvbmx5IHRydWUgaWYgc3RhdCBtdXggdHJhbnNwb3J0IGlzIG5vdCB1c2VkIGZvciBi YWNraGF1bC9taWRoYXVsLiBJZiBPVE4gb3IgRFdETSBpcyB1c2VkIGZvciBpc29sYXRpb24gb2Yg c2xpY2VzIHRoZW4gb2YgY291cnNlIG5vIGludGVyZmVyZW5jZSBpcyBwb3NzaWJsZSBob3dldmVy IHdpdGggYSBwYWNrZXQgbWl4IHRoZXJlIGlzIHRoZSBwb3NzaWJpbGl0eSBvZiBET1Mgb3IgYXQg dGhlIGxlYXN0IERlbmlhbCBvZiBRT1MgKERPUT8pIGJ1dCBpbiBnZW5lcmFsIHlvdSBhcmUgcmln aHQgdGhhdCBwcm9wZXJseSBzbGljZWQgdGhlcmUgc2hvdWxkIGJlIG1pbmltYWwgc2VjdXJpdHkg aW1wYWN0cyBiZXR3ZWVuIHNsaWNlcy4NCg0KUGV0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IDVnYW5naXAgW21haWx0bzo1Z2FuZ2lwLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBOaXNoYW50aCBTYXN0cnkNClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAxNywg MjAxNSA3OjQzIEFNDQpUbzogSm9uIENyb3djcm9mdA0KQ2M6IGljbnJnQGlydGYub3JnOyBnYWlh OyBzdGFja2V2by1kaXNjdXNzQGlhYi5vcmc7IERpcmsgS3V0c2NoZXI7IG1hcm5ld0BpYWIub3Jn OyA1Z2FuZ2lwQGlldGYub3JnOyBkdG4taW50ZXJlc3RAaXJ0Zi5vcmcNClN1YmplY3Q6IFJlOiBb NWdhbmdpcF0gW2dhaWFdIDVHOiBJdCdzIHRoZSBOZXR3b3JrLCBTdHVwaWQNCg0KRTJFIHNlY3Vy aXR5IGluIDVHIGNhbiBiZSBhZGRyZXNzZWQgdGhyb3VnaCBuZXR3b3JrIHNsaWNpbmcsIGFub3Ro ZXIgY29uY2VwdCB3aGljaCBzZWVtcyB0byBiZSBpbmNsdWRlZCBpbiBtYW55IDVHIHByb3Bvc2Fs cy4gSWYgZWFjaCBhcHBsaWNhdGlvbiBoYXMgaXRzIG93biBzbGljZSwgaXQgY2FuIHNjcmV3IHVw IGJ1dCB3b250IGJlIGFibGUgdG8gYWZmZWN0IG90aGVyIGFwcGxpY2F0aW9ucy4gV2l0aGluIGVh Y2ggc2xpY2UsIEUyRSBzZWN1cml0eSBjYW4gYmUgZW5mb3JjZWQgaW4gYW4gYXBwbGljYXRpb24g c3BlY2lmaWMgbWFubmVyLiBFdmVuIGJldHRlciB3b3VsZCBiZSBpZiB3ZSBjYW4gbWFrZSBlYWNo IGZsb3cgYmUgaXRzIG93biBzbGljZS4gVGhpcyBtYXkgc2VlbSB0byBiZSBvdmVybHkgaGVhdnl3 ZWlnaHQsIGJ1dCBpcyBhbG9uZyB0aGUgbGluZXMgb2Ygd2hhdCBCcm9taXVtICBpcyB0cnlpbmcg dG8gZG8gZm9yIGRlc2t0b3BzLCBpc29sYXRpbmcgcHJvY2Vzc2VzIGFuZCBkYXRhIGZyb20gZWFj aCBvdGhlciB1c2luZw0KIm1pY3Jvdmlzb3JzIjogaHR0cDovL3d3dy5icm9taXVtLmNvbS93aHkt YnJvbWl1bS9ob3ctd2UtZG8taXQuaHRtbCBXZSBqdXN0IG5lZWQgdG8gZG8gaXQgZm9yIG5ldHdv cmtzIDopDQoNCm5pc2hhbnRoDQrigJQNCkNELUdBSU46IGh0dHA6Ly9iaXQubHkvY2QtZ2Fpbg0K UzRTOiBodHRwOi8vd3d3LnNwYWNlNHNoYXJpbmdzdHVkeS5vcmcvDQpSRUFDSDogaHR0cDovL3d3 dy5ldS1pbmRpYS5uZXQNCg0KNUcgTm9ybWE6IGh0dHBzOi8vNWctcHBwLmV1LzVnLW5vcm1hDQpW aXJ0dVdpbmQ6IGh0dHBzOi8vNWctcHBwLmV1L3ZpcnR1d2luZC8NCg0KT24gMTcgRGVjIDIwMTUs IGF0IDc6NTYsIEpvbiBDcm93Y3JvZnQgd3JvdGU6DQoNCj4gR3JlYXQgYXJ0aWNsZS4uLm9uZSB0 aGluZyBhYm91dCB0aGUgNGcuLjVnIGV2b2x1dGlvbiBpcyBpbmNyZWFzaW5nDQo+IGNvb3BlcmF0 aW9uIGluIGZvcndhcmRpbmcgYW5kIHJlbGF5aW5nIHNpZ25hbCwgYml0cywgcGFja2V0cyAoc2hh cmVkIA0KPiBjZWxsDQo+IHRvd2VyL2Jhc2Ugc3RhdGlvbi9hbnRlbm5hZSBhY3Jvc3MgcHJvdmlk ZXIpLiBTbyBkaXJlY3QsbWVzaCxhZGhvYyANCj4gc3RvcA0KPiBqdXN0IGJlaW5nIGVkZ2Ugbm90 aW9ucywgYnV0IGFyZSBhbGwgZmlyc3QgY2xhc3MgcGFydCBvZiB0aGUgDQo+IGFyY2hpdGVjdHVy ZQ0KPiAoImRvbid0IGZlYXIgdGhlIGVkZ2UiKS4gVGhlcmUgaXMgaHVnZSB0ZW5zaW9uIGJldHdl ZW4gdGhpcyB0cmVuZCwgYW5kIA0KPiBlMmUNCj4gc2VjdXJpdHkuLi4uSSBoYXZlIG5vdCBzZWVu IGFueW9uZSBhZGRyZXNzIGhvdyB0byByZXNvbHZlIHRoYXQgDQo+IHRlbnNpb24uLi4NCj4gT24g MTYgRGVjIDIwMTUgNjo0MiBwbSwgIkRpcmsgS3V0c2NoZXIiIDxEaXJrLkt1dHNjaGVyQG5lY2xh Yi5ldT4gDQo+IHdyb3RlOg0KPg0KPj4gW2Fwb2xvZ2llcyBmb3IgY3Jvc3MtcG9zdGluZ10NCj4+ DQo+Pg0KPj4NCj4+IEhpLA0KPj4NCj4+DQo+Pg0KPj4gSSBoYXZlIHdyaXR0ZW4gdXAgYSBmZXcg dGhvdWdodHMgb24gY3VycmVudCBkaXNjdXNzaW9ucyBhcm91bmQgNUcgYW5kDQo+PiBuZXR3b3Jr IGV2b2x1dGlvbi4gSSBtaWdodCBwdWJsaXNoIHRoaXMgYXMgcGFwZXIgbGF0ZXIsIGJ1dCB3YW50 ZWQgdG8gDQo+PiBnZXQNCj4+IGl0IG91dCBlYXJseSBhbmQgYXNrIGZvciBjb21tZW50cyDigJMg c28gd291bGQgYmUgZ3JhdGVmdWwgZm9yIGFueSANCj4+IGZlZWRiYWNrLg0KPj4gSXTigJlzIG5v dCB2ZXJ5IHBvbGlzaGVkIGFuZCBzbGlnaHRseSBsb25nLCBidXQgaG9wZWZ1bGx5IA0KPj4gdW5k ZXJzdGFuZGFibGUNCj4+IGVub3VnaC4gVGFrZSBpdCBhcyBhIOKAnHBvc2l0aW9uIHBhcGVy4oCd IGZvciBub3cuDQo+Pg0KPj4NCj4+DQo+PiBBYnN0cmFjdDoNCj4+DQo+PiBDdXJyZW50IDVHIG5l dHdvcmsgZGlzY3Vzc2lvbiBhcmUgb2Z0ZW4gZm9jdXNpbmcgb24gcHJvdmlkaW5nIG1vcmUNCj4+ IGNvbXByZWhlbnNpdmUgYW5kIGludGVncmF0ZWQgb3JjaGVzdHJhdGlvbiBhbmQgbWFuYWdlbWVu dCBmdW5jdGlvbnMgDQo+PiBpbg0KPj4gb3JkZXIgdG8gaW1wcm92ZSDigJxlbmQtdG8tZW5k4oCd IG1hbmFnZWJpbGl0eSBhbmQgcHJvZ3JhbW1hYmlsaXR5LCANCj4+IGRlcml2ZWQNCj4+IGZyb20g TkdNTiBhbmQgc2ltaWxhciByZXF1aXJlbWVudHMuIFdoaWxlIHRoZXNlIGFyZSBpbXBvcnRhbnQg DQo+PiBjaGFsbGVuZ2VzLA0KPj4gdGhpcyBtZW1vIHRha2VzIHRoZSBwZXJzcGVjdGl2ZSB0aGF0 IGluIG9yZGVyIHRvIGFycml2ZSBhdCBhIG1vcmUgDQo+PiBwb3dlcmZ1bA0KPj4gbmV0d29yaywg aXQgaXMgaW1wb3J0YW50IHRvIHVuZGVyc3RhbmQgdGhlIHBhaW4gcG9pbnRzIGFuZCB0aGUgDQo+ PiByZWFzb25zIGZvcg0KPj4gY2VydGFpbiBkZXNpZ24gY2hvaWNlcyBvZiB0b2RheeKAmXMgbmV0 d29ya3MuIFVuZGVyc3RhbmRpbmcgdGhlIA0KPj4gZHJpdmVycyBmb3INCj4+IHRyYWZmaWMgbWFu YWdlbWVudCBzeXN0ZW1zLCBtaWRkbGVib3hlcywgQ0ROcyBhbmQgb3RoZXIgDQo+PiBhcHBsaWNh dGlvbi1sYXllcg0KPj4gb3ZlcmxheXMgc2hvdWxkIGJlIHRha2VuIGFzIGEgYmFzaXMgZm9yIGFu YWx5emluZyA1RyB1c2VzIGNhc2VzIGFuZCANCj4+IHRoZWlyDQo+PiByZXF1aXJlbWVudHMuIElu IHRoaXMgbWVtbywgSSBhbSBtYWtpbmcgdGhlIHBvaW50IHRoYXQgbWFueSBvZiANCj4+IHRvZGF5 4oCZcw0KPj4gYnVzaW5lc3MgbmVlZHMgYW5kIHRoZSBhbWJpdGlvdXMgNUcgdXNlIGNhc2VzIGRv IGNhbGwgZm9yIGEgbW9yZSANCj4+IHBvd2VyZnVsDQo+PiBkYXRhIGZvcndhcmRpbmcgcGxhbmUs IHRha2luZyBJQ04gYXMgYW4gZXhhbXBsZS4gRmVhdHVyZXMgb2Ygc3VjaCBhDQo+PiBmb3J3YXJk aW5nIHBsYW5lIHdvdWxkIGluY2x1ZGUgYmV0dGVyIHN1cHBvcnQgZm9yIGhldGVyb2dlbmVvdXMg DQo+PiBuZXR3b3Jrcw0KPj4gKGFjY2VzcyBuZXR3b3JrcyBhbmQgd2hvbGUgbmV0d29yayBkZXBs b3ltZW50cyksIG11bHRpLXBhdGggDQo+PiBjb21tdW5pY2F0aW9uLA0KPj4gaW4tbmV0d29yayBz dG9yYWdlIGFuZCBpbXBsZW1lbnRhdGlvbiBvZiBvcGVyYXRvciBwb2xpY2llcy4gVGhpcyANCj4+ IHdvdWxkIGhlbHANCj4+IHRvIGF2b2lkIG92ZXJsYXkgc2lsb3MgYW5kIGZpbmFsbHkgc2ltcGxp ZnkgbmV0d29yayBtYW5hZ2VtZW50Lg0KPj4NCj4+DQo+Pg0KPj4gaHR0cDovL2Rpcmsta3V0c2No ZXIuaW5mby9wb3N0cy81Zy1pdHMtdGhlLW5ldHdvcmstc3R1cGlkLw0KPj4NCj4+DQo+Pg0KPj4g VGhhbmtzLA0KPj4NCj4+IERpcmsNCj4+DQo+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBnYWlhIG1haWxpbmcgbGlzdA0KPj4gZ2Fp YUBpcnRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nYWlh DQo+Pg0KPj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gZ2FpYSBtYWlsaW5nIGxpc3QNCj4gZ2FpYUBpcnRmLm9yZw0KPiBodHRwczovL3d3dy5p cnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dhaWENCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCjVnYW5naXAgbWFpbGluZyBsaXN0DQo1Z2FuZ2lwQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzVnYW5naXANCg== From nobody Thu Dec 17 13:22:04 2015 Return-Path: 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 840491B30BD; Thu, 17 Dec 2015 13:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.191 X-Spam-Level: X-Spam-Status: No, score=-1.191 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, J_CHICKENPOX_64=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_DBL_ABUSE_REDIR=0.001] autolearn=no 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 OoOlSTytWpd1; Thu, 17 Dec 2015 13:22:00 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0729.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5A9E1B30C5; Thu, 17 Dec 2015 13:21:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=emc.kcl.ac.uk; s=selector1-kcl-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+DWgUDalq/dDTjBO9Tgfb7fHLlP1DrPKMrPJyEDro64=; b=Zb4Pg0DZDPnfjeYhcLydFypTboWnBEUazJYLlwf6cfZecwq1BHrmMuV2GOgnzcUROWnDwiIZ35CTbtQckKue3Mpuv0rd3gQ08xMNN30/xv00WlaDANPt+ohqicYZo11ctHzS8OkemDeH+ZQOlf76t9tHJvm3cmoYB7WRQvFf5sE= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=nishanth.sastry@kcl.ac.uk; Received: from [192.168.0.7] (82.1.229.138) by HE1PR03MB1228.eurprd03.prod.outlook.com (10.163.174.154) with Microsoft SMTP Server (TLS) id 15.1.355.16; Thu, 17 Dec 2015 21:21:35 +0000 From: Nishanth Sastry To: Linda Dunbar Date: Thu, 17 Dec 2015 21:21:32 +0000 Message-ID: <87EE2724-55C3-4BC5-8A43-C2BC15569E5C@kcl.ac.uk> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.3r5187) X-Originating-IP: [82.1.229.138] X-ClientProxiedBy: DB5PR03CA0056.eurprd03.prod.outlook.com (25.164.34.24) To HE1PR03MB1228.eurprd03.prod.outlook.com (25.163.174.154) X-Microsoft-Exchange-Diagnostics: 1; HE1PR03MB1228; 2:QfrzSR+RZvViTOMFRrZrQ+wEsUNm22GDEFGP0bRhABd8MDmFYR5SkC9+TDaMLVe0VZD+ON/MuwyD09MEkvh3+NGxoAZVzZd+AW6RmfjvmpuMEfTp1wf9xSWGRFODcomaPXDD3uOkAMMDJ/ctq5SPCQ==; 3:11oC3oaJapw15MNERlK7eH0xEs6g3wrFz076iSDgFBHjbURicCwBETvHCLDmy3l51CcLyDK8qBWeoLaJlnwCwG32aRAco0Cvr1SU5WqaDVfBKULpJCqrmeBIYO+QoD/a; 25:xr1yzwkf4wKEAMYUyZMwy9Jg/jqwA3gBf2WPpMKCOB7u6s6LRlud8SX15voVaa2RXm7PsABW74AzIJJnKKZ3lQTW/0wz4x/sgpQHxW49jHiQNMcohFUeV6/l529iGziuBR+ECAkYLH6UYa2NqKDyMb34ICCngzeQNCuJnATnNlKQMdlNfnVv6IpPGCdiC7/d11XzO/rkkKAbk8t+S8CmyTs6gd+K97QXBWQ24gxTsgPHjJQTFWwcB656n2hkv3c+BEhXBtIX8AqyfsnoVJ9aRQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR03MB1228; X-Microsoft-Exchange-Diagnostics: 1; HE1PR03MB1228; 20:vBd6gWKRRL7XdWh6XvxnX8STDF8urqY8PE1GCOOCHxTfmkfEswKay/oshwv7//hAX8FpaO2eS8RQc39IjGzwFm5zyXJ57zZJBveDLzy7dItK/k9R5+DWLW/FmdAMqJ/ODz3nAOGDpkeApbSI8UkmUUdu0B+oFta07bJ92peLfrXx0vKWa/+J8Xv1RX5I0Q0TZmuyOGMfbrjjLWX76N3vuJfLEYrZRU3FuNatSEgwqRA0fEO0ZAtbpQekRRl7klAa7wtneM1/IgwS7T23QtsjmRYgjZsJ9rGsZMxU2nQE16Fjk4U77oxceIXPHWbikeJstzLnT/icJBbroDawRudR9CppuX8UwlH65+rosmnMmKAAwdIVrWqOdX3d2yZdt6EZm0A1HTJ7Cfgs6ggxWOd6A94nzAT4YBbkUl6rCPFLC9EYok6VYn1X9ad0fYgdC9KnxG2gs3LWVNFWsRG1RPVIJ0/RvSrL7nWBr3KKvkFA/N1YqAHT1jQlPDtv845EZ4oe; 4:j+PnfSst/fI4lmMzVoC2COpdZ5JAItPcByDyIPxJaJqeciQwCqIxq5X7nXSWGjWjIUl2yQearslV6O9rQxCj440zMCUia6PClBxv7Eu5JlGLcHF+xIXPwP3CNYLivG6KBeRMxG1MpQHXj8UEMpApEzANeWEyjWw/1N9G/k4VFL4Q/6TibNo49h1OZNUvDU7dUzMP9k75HjETSuhIeXuzhA6alMvz6yd3I7khZs/H+87E/0aKaSTLS9FYZGRsqVl0Xs8prAEsWZUxLTlAsYqVgjxMHu8XyPoFwUEmeAiWwMP5ZdJtg2s1SF6/ZBmXkGlXhFLZEz5VskFSt16Dm+IE1X0z4dXadoPtUVCzihmF+rXceVoyMrfKrM5chbELYQxt X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:HE1PR03MB1228; BCL:0; PCL:0; RULEID:; SRVR:HE1PR03MB1228; X-Forefront-PRVS: 07935ACF08 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(209900001)(24454002)(13464003)(377454003)(164054003)(199003)(189002)(42186005)(93886004)(117156001)(81156007)(5001960100002)(50466002)(82746002)(74826001)(101416001)(83716003)(50226001)(110136002)(23676002)(97736004)(105586002)(189998001)(106356001)(33656002)(66066001)(86362001)(15975445007)(15395725005)(19580405001)(77096005)(19580395003)(16601075003)(40100003)(5008740100001)(87976001)(36756003)(15198665003)(76176999)(2950100001)(1096002)(122386002)(74482002)(586003)(3846002)(1720100001)(92566002)(47776003)(50986999)(6116002)(5004730100002)(493534005)(104396002)(19477635001)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR03MB1228; H:[192.168.0.7]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: kcl.ac.uk does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjAzTUIxMjI4OzIzOjhtUmRjSW1DR3ZBbzlxOEdybFRWM2V4UHVU?= =?utf-8?B?aE1RbWhqK1BpZm5Rb3RLbEtOMHJtclFZQ0ExZmtRNE1vT09VRVdjNlhjVXM3?= =?utf-8?B?c3RNOW8yMStZMVp6alRtS1YvQktrTHlscXJGclQ4aVpYeVpKL1lkRW56eEd2?= =?utf-8?B?UnpXR2x0alE4TWV3djMrMXB5ekxYVzlIZlR6T3MvbjVqWW8ydThBUmlodU9M?= =?utf-8?B?TVZVVFdiY1p6VnBrK1NDRGg2WFNrSC8wc2xhTGtkcjI3OFFpanBUeXp4ZDJQ?= =?utf-8?B?MUwyUllJeHF4WGMvem9LczRTQjNPS3dZREZZVHdaemZDWmJsb0JlV0NYbDhu?= =?utf-8?B?YVF1Q2RBRnFXUlo5TmlrenlxNW1LS2tjaGljVjVGV0prd3o1NXZsbzVTMnZa?= =?utf-8?B?RFNnYnFpYWFMVzN4RkRzemdFWCs5Tll0U29FQVZqUEhOMW55YmlMd1pnOHBP?= =?utf-8?B?dTBKcjR1SGZackdmNUdsZHVwZk16QVBIeWNweUZQME9uNHFGSzBaMjFkRU1U?= =?utf-8?B?Q0tMQjd5czkyNmJqTUN2Sm5WWDBvWVJyRVNieWM3Zzc2YUsycVlnbE9TOW8r?= =?utf-8?B?T1kvZXVzUmw4a25NbHIveHRoQTVsNHhoUWNDcDFFQnlDZTljMVVDcERTTU5m?= =?utf-8?B?ekJwMUZqUUpUNGdScWtkcGF0VDgxSDR0dG9KL0FhTTJmOGhZckJ1MEUxV2F5?= =?utf-8?B?bXRkKzFTVmtTLzY2NUhyRENYR2ZhY3VOM3h2YWtkY241UVZGRUpCZ3NGa3I4?= =?utf-8?B?cmtmaTcvMzNxR2xIL0hiOW9TcmpnWmZDenFFVndwUHFHRjdTd2ZrM2prSTJ5?= =?utf-8?B?RCtlVHBHNW00bTlZNWV2QUxtekJScGxhV1RuaDVyV3NBWHFwT3doL3NDdGNI?= =?utf-8?B?TUJaZThXdXcrbUMzU25qSmJiUWxxWE9TS1BacGNSeUcvcENvK0VmcDNaOHBV?= =?utf-8?B?SmdtZ0ZNZGcwcnRkQVhGTEw3SkZrS1FkMjdmcVZhbHJxRW5YVm9tR1NGWUlI?= =?utf-8?B?czIxdldWTlMvREdXVVdDOWxLMlNvbmdLMVp1R0N6dEplZkFRR05vVFBCdjNB?= =?utf-8?B?VUV6TE1EckFBS21vbHNjZ09LL1l4ZGdNMUZPeTUraTl6YmVWc01WQWVsZkx6?= =?utf-8?B?M0V1cTQ4NHUwOC9EOHUrN01uL2l5emtzbHF4Y05zUURnN0FYNVdDYTdEdzVI?= =?utf-8?B?Y0hwaGhFemRKdkNQazdmMGlGY01rVk1nQm01UityVmE1VmJ0NGlhQk53aTNu?= =?utf-8?B?MWp3SkxjOW5POEV3WktsODZpRm9XV2wyd1ZnUjh6WUlHWFFTS2VnanJHZmZw?= =?utf-8?B?L0RqcHpWSk5rLzJYd1hucjh2OHpzVG5NbWpqdkdIdHViRUpNK1ZYTVdtR3pl?= =?utf-8?B?TXd1bWZrd0EvNG5oUXFsWExHSGdkaG9zbGUvZEQrQ3Y1dXJXeHFzQjZuWXJJ?= =?utf-8?B?d1Izc2N1dHAzYXE2TjN0dFpOdjJhclVCbHoxWFc1U2RPTXZQMFY4NXVaeG5o?= =?utf-8?B?dGhBL0xNZE1VM2NlVjZUaVZoa005bzFaZWtJeDVqdHlYWHViTFd1L2pUMXND?= =?utf-8?B?ZE5rZWRDZGJtWFVWYm5hOWNPU2U5Y0ZjSWVBdHVTenZ1ek1CeFFPWEpFQXhp?= =?utf-8?B?SndsMG9UeUpqU0NpNzlKQ29jN2FwU0I3VXMxS3ZYYVh6Q1haRWY2NTJNR0xx?= =?utf-8?B?TkJQNktEcnoxZ0xUekNPVTdmVG95cW9JRGlHcEZXZXlRdWZQQUUzWUMzMGVn?= =?utf-8?B?cTNoT3p3NE1xamJTamhxL2VyZDNJTXN3QzhKVmg5UTJnMnI0WWxuMmNDc1hm?= =?utf-8?B?cE0ybE1nNDJkSjFPNHB5RHFkNWE0ZWVrbkNFQzBCU1JSNE5ZQ0owSFkrM1FQ?= =?utf-8?B?ckhSK2RQQkhBb29VbzZWcUEwdjJCbE84QSt3dnpZbmE2N0hsejdqclkyZU1S?= =?utf-8?B?cWsxMFA0ZFlueERIWUc1SFQvcUZpMGhXNm5BclhYVzhlalBNc0VBcWFqZjRI?= =?utf-8?Q?TCd52Y?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR03MB1228; 5:O4FVcYCow5WiUc+M9h+oICCU6qeyQx+V+mn3S/ooWOob8ne26/FDxqVBzG7vSPxqnTMmQHUi4gDbgmCGSLK5AezS7jJPs16i/KE8Xp9TE4RvW0dvvjRf09Chc/ijORGndTp64v5azJGR0Lm3lDGABg==; 24:GoEsbtaPlVXo7fnO1aTlTqTlQJeFLqsbcR7UXGiGa7lX0ieHL30epSj8Jq6nYNy1mNpE8z5sPexKCFCLKPNeQoSLn8JMs1XO/WS2oQ6pd4E= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: kcl.ac.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2015 21:21:35.8857 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR03MB1228 Archived-At: Cc: "icnrg@irtf.org" , gaia , "stackevo-discuss@iab.org" , Dirk Kutscher , Jon Crowcroft , "5gangip@ietf.org" <5gangip@ietf.org>, "marnew@iab.org" , "dtn-interest@irtf.org" Subject: Re: [Stackevo-discuss] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 21:22:02 -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 — 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 17:49, Linda Dunbar wrote: > 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:stackevo-discuss-bounces@iab.org] On > Behalf Of Nishanth Sastry > Sent: Thursday, December 17, 2015 6:43 AM > To: Jon Crowcroft > Cc: icnrg@irtf.org; gaia; stackevo-discuss@iab.org; Dirk Kutscher; > marnew@iab.org; 5gangip@ietf.org; dtn-interest@irtf.org > 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... >> On 16 Dec 2015 6:42 pm, "Dirk Kutscher" >> 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. >>> >>> >>> >>> http://dirk-kutscher.info/posts/5g-its-the-network-stupid/ >>> >>> >>> >>> Thanks, >>> >>> Dirk >>> >>> >>> >>> _______________________________________________ >>> gaia mailing list >>> gaia@irtf.org >>> https://www.irtf.org/mailman/listinfo/gaia >>> >>> >> _______________________________________________ >> gaia mailing list >> gaia@irtf.org >> https://www.irtf.org/mailman/listinfo/gaia > > _______________________________________________ > Stackevo-discuss mailing list > Stackevo-discuss@iab.org > https://www.iab.org/mailman/listinfo/stackevo-discuss From nobody Thu Dec 17 13:42:28 2015 Return-Path: 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 AF3BF1B30CD; Thu, 17 Dec 2015 13:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Fi1NmgRwHFPr; Thu, 17 Dec 2015 13:42:17 -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 77A951B30C5; Thu, 17 Dec 2015 13:42:17 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml705-chm.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLC20787; Thu, 17 Dec 2015 15:42:10 -0600 (CST) Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Thu, 17 Dec 2015 13:42:04 -0800 From: Linda Dunbar To: Dirk Kutscher , Ingemar Johansson S , "icnrg@irtf.org" , "dtn-interest@irtf.org" , gaia , "5gangip@ietf.org" <5gangip@ietf.org>, "marnew@iab.org" , "stackevo-discuss@iab.org" Thread-Topic: [5gangip] 5G: It's the Network, Stupid Thread-Index: AdE4MC4YYpSof3RGRdK/YSjH5J56uAAY4/yAAAYu8OAAGZPx0A== Date: Thu, 17 Dec 2015 21:42:03 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657DB3C14@dfweml701-chm> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <81564C0D7D4D2A4B9A86C8C7404A13DA414EF289@ESESSMB208.ericsson.se> <82AB329A76E2484D934BBCA77E9F5249A683459F@Hydra.office.hd> In-Reply-To: <82AB329A76E2484D934BBCA77E9F5249A683459F@Hydra.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.107] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657DB3C14dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0201.56732C33.0064, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ad1711397763f3adf73d4708320029e6 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2015 21:42:22 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657DB3C14dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kirk, Thanks for the interesting blog. One comment on your writing: you notion of SDN is too narrowly focused. SD= N doesn't have to be OpenFlow. SDN can be Application Controller (such as the CDN controller) using variou= s hooks from the underlay network to achieve more efficient control of thei= r own traffic. The centralized controller will be service oriented. CDN's central controll= er is different from the Real Media central controller. Linda Dunbar From: Stackevo-discuss [mailto:stackevo-discuss-bounces@iab.org] On Behalf = Of Dirk Kutscher Sent: Thursday, December 17, 2015 3:34 AM To: Ingemar Johansson S; icnrg@irtf.org; dtn-interest@irtf.org; gaia; 5gang= ip@ietf.org; marnew@iab.org; stackevo-discuss@iab.org Subject: Re: [Stackevo-discuss] [5gangip] 5G: It's the Network, Stupid Hi Ingemar, thanks for the feedback. Yes, as far as I remember the UPCON work was rather on the traffic manageme= nt 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 accountabili= ty" for various use cases is really more promising than fine-granular traff= ic management. One of the use cases (that Bob came up with) is performance = isolation in virtual networks, which would allow for a more flexible capaci= ty sharing in data centers. My point was if we are thinking about virtual slices, let's not introduce s= tatic 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:ingemar.s.johansson@ericsson.com] Sent: Donnerstag, 17. Dezember 2015 08:26 To: Dirk Kutscher; icnrg@irtf.org; dtn-interest@irtf= .org; gaia; 5gangip@ietf.org; marnew@iab.org; stackevo-discuss@iab.org 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 on= ly 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 RT= T 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:Dirk.Kutscher@neclab.eu] Sent: den 16 december 2015 19:41 To: icnrg@irtf.org; dtn-interest@irtf.org; gaia; 5gangip@ietf.org; marne= w@iab.org; stackevo-discuss@iab.org Subject: [5gangip] 5G: It's the Network, Stupid [apologies for cross-posting] Hi, I have written up a few thoughts on current discussions around 5G and netwo= rk 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 n= ot very polished and slightly long, but hopefully understandable enough. Ta= ke it as a "position paper" for now. Abstract: Current 5G network discussion are often focusing on providing more comprehe= nsive and integrated orchestration and management functions in order to imp= rove "end-to-end" managebility and programmability, derived from NGMN and s= imilar requirements. While these are important challenges, this memo takes = the perspective that in order to arrive at a more powerful network, it is i= mportant to understand the pain points and the reasons for certain design c= hoices of today's networks. Understanding the drivers for traffic managemen= t systems, middleboxes, CDNs and other application-layer overlays should be= taken as a basis for analyzing 5G uses cases and their requirements. In th= is 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, t= aking ICN as an example. Features of such a forwarding plane would include = better support for heterogeneous networks (access networks and whole networ= k deployments), multi-path communication, in-network storage and implementa= tion of operator policies. This would help to avoid overlay silos and final= ly simplify network management. http://dirk-kutscher.info/posts/5g-its-the-network-stupid/ Thanks, Dirk --_000_4A95BA014132FF49AE685FAB4B9F17F657DB3C14dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Kirk,

 

Thanks for the interes= ting blog.

 

One comment on your wr= iting: you notion of SDN is too narrowly focused.  SDN doesn’t h= ave to be OpenFlow.

 

SDN can be Application= Controller (such as the CDN controller) using various hooks from the under= lay network to achieve more efficient control of their own traffic.

The centralized contro= ller will be service oriented. CDN’s central controller is different = from the Real Media central controller.

 

Linda Dunbar

 

 

From: Stackevo= -discuss [mailto:stackevo-discuss-bounces@iab.org] On Behalf Of Dirk Kutscher
Sent: Thursday, December 17, 2015 3:34 AM
To: Ingemar Johansson S; icnrg@irtf.org; dtn-interest@irtf.org; gaia= ; 5gangip@ietf.org; marnew@iab.org; stackevo-discuss@iab.org
Subject: Re: [Stackevo-discuss] [5gangip] 5G: It's the Network, Stup= id

 

Hi Ingemar= ,

 = ;

thanks for= the feedback.

 = ;

Yes, as far as I remem= ber the UPCON work was rather on the traffic management side and may not ha= ve addressed the actual performance aspects (through AQM and ECN) sufficien= tly.

 

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 perfor= mance 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 re= servations etc. for those applications that do not actually need it –= there are other ways to share capacity.

 

Cheers,

Dirk=

 

 

From: Ingemar = Johansson S [mailto:ing= emar.s.johansson@ericsson.com]
Sent: Donnerstag, 17. Dezember 2015 08:26
To: Dirk Kutscher; icnrg@irtf.org<= /a>; dtn-interest@irtf.org; gaia; 5gangi= p@ietf.org; marnew@iab.org; stackevo-discuss@iab.org
Cc: Ingemar Johansson S
Subject: RE: [5gangip] 5G: It's the Network, Stupid

 

Hi

 = ;

Thanks for an interest= ing blog post. Parts of this is above my head so I only comment on the part= s that I know well

AQM and ECN : Agree fu= lly, there seems to be a general tendency to overlook the basic elements in= congestion management in networks. Quite often  one see reports of ro= undtrip times of 1 second or more in LTE networks. High RTT was also part of the problem formulation in the UPCON W= I but as I recall it, the role of (lack of) AQM and ECN  was missed.

ConEx : What is your v= iew of ConEx ?. The work is wrapping up, but as I see it the interest in th= e “end to end” ConEx is quite modest. Do you envision more loca= l deployments like what is outlined in draft-ietf-conex-mobile ?.

 

/Ingemar

 

From: Dirk Kut= scher [mailto:Dirk.Kutscher@necl= ab.eu]
Sent: den 16 december 2015 19:41
To: icnrg@irtf.org; dtn-interest@irtf.org; gaia; 5gangi= p@ietf.org; marnew@iab.org; stackevo-discuss@iab.org
Subject: [5gangip] 5G: It's the Network, Stupid

 

[apologies for cross-posting]

 

Hi,

 

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

 

Abstract:

Current 5G network discussion are often focusing on = providing more comprehensive and integrated orchestration and management fu= nctions in order to improve “end-to-end” managebility and progr= ammability, 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 understa= nd the pain points and the reasons for certain design choices of today̵= 7;s networks. Understanding the drivers for traffic management systems, middleboxes, CDNs and other application-la= yer overlays should be taken as a basis for analyzing 5G uses cases and the= ir requirements. In this memo, I am making the point that many of todayR= 17;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 su= pport for heterogeneous networks (access networks and whole network deploym= ents), multi-path communication, in-network storage and implementation of operator policies. This would hel= p to avoid overlay silos and finally simplify network management.

 

http://dirk-kutscher.info/posts/5g-its-the-network-stupi= d/

 

Thanks,

Dirk

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657DB3C14dfweml701chm_-- From nobody Fri Dec 18 08:14:41 2015 Return-Path: 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 13A091B3650; Fri, 18 Dec 2015 06:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.61 X-Spam-Level: X-Spam-Status: No, score=-3.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_ABUSE_REDIR=0.001] autolearn=unavailable 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 k4AL4LbIGw0z; Fri, 18 Dec 2015 06:16:15 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [58.251.152.64]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 381251B365B; Fri, 18 Dec 2015 06:16:12 -0800 (PST) Received: from 172.24.1.47 (EHLO SZXEML429-HUB.china.huawei.com) ([172.24.1.47]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBD83736; Fri, 18 Dec 2015 22:15:30 +0800 (CST) Received: from szxeml559-mbs.china.huawei.com ([169.254.2.89]) by SZXEML429-HUB.china.huawei.com ([10.82.67.184]) with mapi id 14.03.0235.001; Fri, 18 Dec 2015 22:15:18 +0800 From: AshwoodsmithPeter To: Linda Dunbar , Nishanth Sastry , Jon Crowcroft Thread-Topic: [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid Thread-Index: AQHROW5WZcE4Jya+TkWrglMNHXDB+p7QyYGA Date: Fri, 18 Dec 2015 14:15:17 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E20AF36C89@szxeml559-mbs.china.huawei.com> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.67] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56741504.018C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.89, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 648c0d88d80ad11c6b3aa3548ac1e53e Archived-At: X-Mailman-Approved-At: Fri, 18 Dec 2015 08:14:39 -0800 Cc: "icnrg@irtf.org" , gaia , "stackevo-discuss@iab.org" , Dirk Kutscher , "marnew@iab.org" , "5gangip@ietf.org" <5gangip@ietf.org>, "dtn-interest@irtf.org" Subject: Re: [Stackevo-discuss] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2015 14:16:18 -0000 SSB0ZW5kIHRvIGFncmVlLiBBIHNsaWNlIHBlciB1c2VyLCBleGNlcHQgaW4gZXhjZXB0aW9uYWwg Y2FzZXMgd291bGQgc2VlbSB1bmxpa2VseS4gU2luY2UgYSBzbGljZSByZXF1aXJlcyBtdWx0aXBs ZSByZXNvdXJjZXMgYmUgYWxsb2NhdGVkIGVuZCB0byBlbmQgdGhlIGNvbmNlcHQgbW9zdCBsaWtl bHkgd2lsbCB3b3JrIGJlc3QgZm9yIGEgc2V0IG9mIHVzZXJzIHRoYXQgc2hhcmUgYSBjb21tb24g UU9TL1FPRS9BZG1pbiByZXF1aXJlbWVudC4NCg0KRXNzZW50aWFsbHkgUU9TL1FPRSB3aXRoaW4g YSBzbGljZSB3aWxsIHN0aWxsIGhhdmUgdG8gYmUgYWRkcmVzc2VkIHdpdGggdGhlIHRvb2xzIHdl IGFscmVhZHkgaGF2ZS4NCg0KUGV0ZXINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IDVnYW5naXAgW21haWx0bzo1Z2FuZ2lwLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBMaW5kYSBEdW5iYXINClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAxNywgMjAxNSAxMjo0OSBQ TQ0KVG86IE5pc2hhbnRoIFNhc3RyeTsgSm9uIENyb3djcm9mdA0KQ2M6IGljbnJnQGlydGYub3Jn OyBnYWlhOyBzdGFja2V2by1kaXNjdXNzQGlhYi5vcmc7IERpcmsgS3V0c2NoZXI7IG1hcm5ld0Bp YWIub3JnOyA1Z2FuZ2lwQGlldGYub3JnOyBkdG4taW50ZXJlc3RAaXJ0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbNWdhbmdpcF0gW1N0YWNrZXZvLWRpc2N1c3NdIFtnYWlhXSA1RzogSXQncyB0aGUgTmV0 d29yaywgU3R1cGlkDQoNCkkgc3Ryb25nbHkgc3VwcG9ydCB0aGUgY29uY2VwdCBvZiBuZXR3b3Jr IHNsaWNpbmcgZm9yIEFwcGxpY2F0aW9ucyBvciBJb1QgbmV0d29ya3MuIA0KQnV0IGl0IGlzIG5v dCByZWFsaXN0aWMgdG8gZXhwZWN0IG9wZXJhdG9ycyBuZXR3b3JrcyB0byB0YWtlIGNvbnRyb2wg cmVxdWVzdHMgZnJvbSBpbmRpdmlkdWFsIHVzZXJzL2hhbmRzZXRzLiBUaGVyZSBoYXMgdG8gYmUg YW4gYXV0aGVudGljYXRlZCBhcHBsaWNhdGlvbiBjb250cm9sbGVyIHRoYXQgbWFrZXMgcmVxdWVz dHMvY29tbWFuZHMgdG8gdGhlIHNsaWNlZCBuZXR3b3JrLiANCg0KTXkgdHdvIGNlbnRzLiANCg0K TGluZGEgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGFja2V2by1kaXNj dXNzIFttYWlsdG86c3RhY2tldm8tZGlzY3Vzcy1ib3VuY2VzQGlhYi5vcmddIE9uIEJlaGFsZiBP ZiBOaXNoYW50aCBTYXN0cnkNClNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAxNywgMjAxNSA2OjQz IEFNDQpUbzogSm9uIENyb3djcm9mdA0KQ2M6IGljbnJnQGlydGYub3JnOyBnYWlhOyBzdGFja2V2 by1kaXNjdXNzQGlhYi5vcmc7IERpcmsgS3V0c2NoZXI7IG1hcm5ld0BpYWIub3JnOyA1Z2FuZ2lw QGlldGYub3JnOyBkdG4taW50ZXJlc3RAaXJ0Zi5vcmcNClN1YmplY3Q6IFJlOiBbU3RhY2tldm8t ZGlzY3Vzc10gW2dhaWFdIDVHOiBJdCdzIHRoZSBOZXR3b3JrLCBTdHVwaWQNCg0KRTJFIHNlY3Vy aXR5IGluIDVHIGNhbiBiZSBhZGRyZXNzZWQgdGhyb3VnaCBuZXR3b3JrIHNsaWNpbmcsIGFub3Ro ZXIgY29uY2VwdCB3aGljaCBzZWVtcyB0byBiZSBpbmNsdWRlZCBpbiBtYW55IDVHIHByb3Bvc2Fs cy4gSWYgZWFjaCBhcHBsaWNhdGlvbiBoYXMgaXRzIG93biBzbGljZSwgaXQgY2FuIHNjcmV3IHVw IGJ1dCB3b250IGJlIGFibGUgdG8gYWZmZWN0IG90aGVyIGFwcGxpY2F0aW9ucy4gV2l0aGluIGVh Y2ggc2xpY2UsIEUyRSBzZWN1cml0eSBjYW4gYmUgZW5mb3JjZWQgaW4gYW4gYXBwbGljYXRpb24g c3BlY2lmaWMgbWFubmVyLiBFdmVuIGJldHRlciB3b3VsZCBiZSBpZiB3ZSBjYW4gbWFrZSBlYWNo IGZsb3cgYmUgaXRzIG93biBzbGljZS4gVGhpcyBtYXkgc2VlbSB0byBiZSBvdmVybHkgaGVhdnl3 ZWlnaHQsIGJ1dCBpcyBhbG9uZyB0aGUgbGluZXMgb2Ygd2hhdCBCcm9taXVtICBpcyB0cnlpbmcg dG8gZG8gZm9yIGRlc2t0b3BzLCBpc29sYXRpbmcgcHJvY2Vzc2VzIGFuZCBkYXRhIGZyb20gZWFj aCBvdGhlciB1c2luZw0KIm1pY3Jvdmlzb3JzIjogaHR0cDovL3d3dy5icm9taXVtLmNvbS93aHkt YnJvbWl1bS9ob3ctd2UtZG8taXQuaHRtbCBXZSBqdXN0IG5lZWQgdG8gZG8gaXQgZm9yIG5ldHdv cmtzIDopDQoNCm5pc2hhbnRoDQrigJQNCkNELUdBSU46IGh0dHA6Ly9iaXQubHkvY2QtZ2Fpbg0K UzRTOiBodHRwOi8vd3d3LnNwYWNlNHNoYXJpbmdzdHVkeS5vcmcvDQpSRUFDSDogaHR0cDovL3d3 dy5ldS1pbmRpYS5uZXQNCg0KNUcgTm9ybWE6IGh0dHBzOi8vNWctcHBwLmV1LzVnLW5vcm1hDQpW aXJ0dVdpbmQ6IGh0dHBzOi8vNWctcHBwLmV1L3ZpcnR1d2luZC8NCg0KT24gMTcgRGVjIDIwMTUs IGF0IDc6NTYsIEpvbiBDcm93Y3JvZnQgd3JvdGU6DQoNCj4gR3JlYXQgYXJ0aWNsZS4uLm9uZSB0 aGluZyBhYm91dCB0aGUgNGcuLjVnIGV2b2x1dGlvbiBpcyBpbmNyZWFzaW5nIA0KPiBjb29wZXJh dGlvbiBpbiBmb3J3YXJkaW5nIGFuZCByZWxheWluZyBzaWduYWwsIGJpdHMsIHBhY2tldHMgKHNo YXJlZCANCj4gY2VsbCB0b3dlci9iYXNlIHN0YXRpb24vYW50ZW5uYWUgYWNyb3NzIHByb3ZpZGVy KS4gU28gDQo+IGRpcmVjdCxtZXNoLGFkaG9jIHN0b3AganVzdCBiZWluZyBlZGdlIG5vdGlvbnMs IGJ1dCBhcmUgYWxsIGZpcnN0IA0KPiBjbGFzcyBwYXJ0IG9mIHRoZSBhcmNoaXRlY3R1cmUgKCJk b24ndCBmZWFyIHRoZSBlZGdlIikuIFRoZXJlIGlzIGh1Z2UgDQo+IHRlbnNpb24gYmV0d2VlbiB0 aGlzIHRyZW5kLCBhbmQgZTJlIHNlY3VyaXR5Li4uLkkgaGF2ZSBub3Qgc2VlbiBhbnlvbmUgDQo+ IGFkZHJlc3MgaG93IHRvIHJlc29sdmUgdGhhdCB0ZW5zaW9uLi4uDQo+IE9uIDE2IERlYyAyMDE1 IDY6NDIgcG0sICJEaXJrIEt1dHNjaGVyIiA8RGlyay5LdXRzY2hlckBuZWNsYWIuZXU+DQo+IHdy b3RlOg0KPg0KPj4gW2Fwb2xvZ2llcyBmb3IgY3Jvc3MtcG9zdGluZ10NCj4+DQo+Pg0KPj4NCj4+ IEhpLA0KPj4NCj4+DQo+Pg0KPj4gSSBoYXZlIHdyaXR0ZW4gdXAgYSBmZXcgdGhvdWdodHMgb24g Y3VycmVudCBkaXNjdXNzaW9ucyBhcm91bmQgNUcgYW5kIA0KPj4gbmV0d29yayBldm9sdXRpb24u IEkgbWlnaHQgcHVibGlzaCB0aGlzIGFzIHBhcGVyIGxhdGVyLCBidXQgd2FudGVkIHRvIA0KPj4g Z2V0IGl0IG91dCBlYXJseSBhbmQgYXNrIGZvciBjb21tZW50cyDigJMgc28gd291bGQgYmUgZ3Jh dGVmdWwgZm9yIGFueSANCj4+IGZlZWRiYWNrLg0KPj4gSXTigJlzIG5vdCB2ZXJ5IHBvbGlzaGVk IGFuZCBzbGlnaHRseSBsb25nLCBidXQgaG9wZWZ1bGx5IA0KPj4gdW5kZXJzdGFuZGFibGUgZW5v dWdoLiBUYWtlIGl0IGFzIGEg4oCccG9zaXRpb24gcGFwZXLigJ0gZm9yIG5vdy4NCj4+DQo+Pg0K Pj4NCj4+IEFic3RyYWN0Og0KPj4NCj4+IEN1cnJlbnQgNUcgbmV0d29yayBkaXNjdXNzaW9uIGFy ZSBvZnRlbiBmb2N1c2luZyBvbiBwcm92aWRpbmcgbW9yZSANCj4+IGNvbXByZWhlbnNpdmUgYW5k IGludGVncmF0ZWQgb3JjaGVzdHJhdGlvbiBhbmQgbWFuYWdlbWVudCBmdW5jdGlvbnMgDQo+PiBp biBvcmRlciB0byBpbXByb3ZlIOKAnGVuZC10by1lbmTigJ0gbWFuYWdlYmlsaXR5IGFuZCBwcm9n cmFtbWFiaWxpdHksIA0KPj4gZGVyaXZlZCBmcm9tIE5HTU4gYW5kIHNpbWlsYXIgcmVxdWlyZW1l bnRzLiBXaGlsZSB0aGVzZSBhcmUgaW1wb3J0YW50IA0KPj4gY2hhbGxlbmdlcywgdGhpcyBtZW1v IHRha2VzIHRoZSBwZXJzcGVjdGl2ZSB0aGF0IGluIG9yZGVyIHRvIGFycml2ZSANCj4+IGF0IGEg bW9yZSBwb3dlcmZ1bCBuZXR3b3JrLCBpdCBpcyBpbXBvcnRhbnQgdG8gdW5kZXJzdGFuZCB0aGUg cGFpbiANCj4+IHBvaW50cyBhbmQgdGhlIHJlYXNvbnMgZm9yIGNlcnRhaW4gZGVzaWduIGNob2lj ZXMgb2YgdG9kYXnigJlzIA0KPj4gbmV0d29ya3MuIFVuZGVyc3RhbmRpbmcgdGhlIGRyaXZlcnMg Zm9yIHRyYWZmaWMgbWFuYWdlbWVudCBzeXN0ZW1zLCANCj4+IG1pZGRsZWJveGVzLCBDRE5zIGFu ZCBvdGhlciBhcHBsaWNhdGlvbi1sYXllciBvdmVybGF5cyBzaG91bGQgYmUgDQo+PiB0YWtlbiBh cyBhIGJhc2lzIGZvciBhbmFseXppbmcgNUcgdXNlcyBjYXNlcyBhbmQgdGhlaXIgcmVxdWlyZW1l bnRzLiANCj4+IEluIHRoaXMgbWVtbywgSSBhbSBtYWtpbmcgdGhlIHBvaW50IHRoYXQgbWFueSBv ZiB0b2RheeKAmXMgYnVzaW5lc3MgDQo+PiBuZWVkcyBhbmQgdGhlIGFtYml0aW91cyA1RyB1c2Ug Y2FzZXMgZG8gY2FsbCBmb3IgYSBtb3JlIHBvd2VyZnVsIGRhdGEgDQo+PiBmb3J3YXJkaW5nIHBs YW5lLCB0YWtpbmcgSUNOIGFzIGFuIGV4YW1wbGUuIEZlYXR1cmVzIG9mIHN1Y2ggYSANCj4+IGZv cndhcmRpbmcgcGxhbmUgd291bGQgaW5jbHVkZSBiZXR0ZXIgc3VwcG9ydCBmb3IgaGV0ZXJvZ2Vu ZW91cyANCj4+IG5ldHdvcmtzIChhY2Nlc3MgbmV0d29ya3MgYW5kIHdob2xlIG5ldHdvcmsgZGVw bG95bWVudHMpLCBtdWx0aS1wYXRoIA0KPj4gY29tbXVuaWNhdGlvbiwgaW4tbmV0d29yayBzdG9y YWdlIGFuZCBpbXBsZW1lbnRhdGlvbiBvZiBvcGVyYXRvciANCj4+IHBvbGljaWVzLiBUaGlzIHdv dWxkIGhlbHAgdG8gYXZvaWQgb3ZlcmxheSBzaWxvcyBhbmQgZmluYWxseSBzaW1wbGlmeSANCj4+ IG5ldHdvcmsgbWFuYWdlbWVudC4NCj4+DQo+Pg0KPj4NCj4+IGh0dHA6Ly9kaXJrLWt1dHNjaGVy LmluZm8vcG9zdHMvNWctaXRzLXRoZS1uZXR3b3JrLXN0dXBpZC8NCj4+DQo+Pg0KPj4NCj4+IFRo YW5rcywNCj4+DQo+PiBEaXJrDQo+Pg0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gZ2FpYSBtYWlsaW5nIGxpc3QNCj4+IGdhaWFA aXJ0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2FpYQ0K Pj4NCj4+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IGdhaWEgbWFpbGluZyBsaXN0DQo+IGdhaWFAaXJ0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaXJ0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9nYWlhDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpTdGFja2V2by1kaXNjdXNzIG1haWxpbmcgbGlzdA0KU3Rh Y2tldm8tZGlzY3Vzc0BpYWIub3JnDQpodHRwczovL3d3dy5pYWIub3JnL21haWxtYW4vbGlzdGlu Zm8vc3RhY2tldm8tZGlzY3Vzcw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCjVnYW5naXAgbWFpbGluZyBsaXN0DQo1Z2FuZ2lwQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLzVnYW5naXANCg== From nobody Mon Dec 21 23:49:59 2015 Return-Path: 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 AAEF81ACEA9; Mon, 21 Dec 2015 15:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, 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 4eNepZuE6sj5; Mon, 21 Dec 2015 15:55:38 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDF41ACEA6; Mon, 21 Dec 2015 15:55:38 -0800 (PST) Received: from [128.9.160.81] (nib.isi.edu [128.9.160.81]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id tBLNt3ce021855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 21 Dec 2015 15:55:04 -0800 (PST) To: Linda Dunbar , Nishanth Sastry , Jon Crowcroft References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> From: Joe Touch Message-ID: <56789156.2020704@isi.edu> Date: Mon, 21 Dec 2015 15:55:02 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-Mailman-Approved-At: Mon, 21 Dec 2015 23:49:58 -0800 Cc: "icnrg@irtf.org" , touch@isi.edu, gaia , "stackevo-discuss@iab.org" , Dirk Kutscher , "marnew@iab.org" , "5gangip@ietf.org" <5gangip@ietf.org>, "dtn-interest@irtf.org" Subject: Re: [Stackevo-discuss] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2015 23:55:39 -0000 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 From nobody Tue Dec 22 09:31:01 2015 Return-Path: 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 5587A1A88CE; Tue, 22 Dec 2015 09:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.889 X-Spam-Level: X-Spam-Status: No, score=-5.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, 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 w57wDOu1HexL; Tue, 22 Dec 2015 09:30:55 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 236E51A88CF; Tue, 22 Dec 2015 09:30:55 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id tBMHUT6C024001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 22 Dec 2015 09:30:30 -0800 (PST) References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> <56789156.2020704@isi.edu> From: Joe Touch Message-ID: <567988B4.3090001@isi.edu> Date: Tue, 22 Dec 2015 09:30:28 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Cc: "icnrg@irtf.org" , touch@isi.edu, gaia , "stackevo-discuss@iab.org" , "5gangip@ietf.org" <5gangip@ietf.org>, "dtn-interest@irtf.org" Subject: Re: [Stackevo-discuss] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 17:30:56 -0000 On 12/22/2015 7:48 AM, Theodore V Faber wrote: > On 12/21/15, 15:55, "Stackevo-discuss on behalf of Joe Touch" > 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. > > 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. ... That's true, but a separate issue of deployment feasibility. Whether an overlay/virtual net has service guarantees or not, it's quite different to have a model that ends in network addresses at interfaces (overlay/VN) vs. ending in processes (typical of slice models). When a network ends in a process, cross-network communication (gateways, relays, application transits, or whatever) always become counterexamples to the model rather than a natural part of it. Joe From nobody Tue Dec 22 10:49:38 2015 Return-Path: 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 9329C1A8A7B for ; Tue, 22 Dec 2015 10:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=no 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 JeOUWjrjIT7V for ; Tue, 22 Dec 2015 10:49:36 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 3FFDE1A8A7A for ; Tue, 22 Dec 2015 10:49:36 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id 186so197922204iow.0 for ; Tue, 22 Dec 2015 10:49:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/+rStdITMkKy7Zv+fTe+vokrrtEHv+RnVwjbpQS/ZBk=; b=gRKosuH+M/QjEJGSmWTekhU2O1FuHZxM093WLyzgUs4rBjbRjd6Mmy5ZAbB6A6pLXI U43gorXgJgHAUceHjGkBacWgceo23COTAh4IXiQhLFvVE7QAmJ1udKOb5hOONFrbw7mm g9TUVWvuO8+cfee6GNY1SZny7wbxq/0/9QmZY+yaapUmY1cBPhIwu2wQK6oaXLtZuU56 QixgX0orUB8qoLb3DmOzc2aaW1lFDQ3LwaiVI7Gd17SUPqtZmGpvJCMJIy+XYNZmauXa 2FSUbYvDa5sodk9POQHpnuR5qcuH31BIBfhb0dg+L7svEjkx1G+QAAgkOqSqYE4MV1Kh E9zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/+rStdITMkKy7Zv+fTe+vokrrtEHv+RnVwjbpQS/ZBk=; b=J1g/oNDGnBAVYgTAr7ZWxLu7iL3g013XNYyXzBwlT+qh0x/LTal0UJ4yPiyf7Gra1x YArEKvF6cmd5elnXkjNRm5Tan7sULxPftdtNmXI26r1s7A9oaG3Jxv3seIh/iy4d6/9s ONfGIPbllIT8954HCWOGyQeJjoR57uNUhG7kudXbkNdDExnPg8Q7OOuHcApBrlzKWEbX BTz/vYzge059frElo4im2YG5lff94djvUc2FoLTmT/xxKeSGxiGlfmEPUZds04ubwaew fxwqvkkTOIO6KfgS2s0RGHejGGI9Tx4Tjgua7wvMqmMGsOx4fhmpZy5DDcdJVJqzxOHK IbTQ== X-Gm-Message-State: ALoCoQnUE9icaM+wUWDmQVvustYNHnUKepQ+4UCQOtDj/i+RmqjDcMac9egNU7aIzgIPO8jYC6AkjIOCQhZcVOfZfHvbHumQlA== MIME-Version: 1.0 X-Received: by 10.107.135.23 with SMTP id j23mr3352381iod.50.1450810175576; Tue, 22 Dec 2015 10:49:35 -0800 (PST) Received: by 10.107.140.150 with HTTP; Tue, 22 Dec 2015 10:49:35 -0800 (PST) In-Reply-To: <6689CCA2-CDC4-44AF-BFD4-270EA6E154F4@trammell.ch> References: <6689CCA2-CDC4-44AF-BFD4-270EA6E154F4@trammell.ch> Date: Tue, 22 Dec 2015 10:49:35 -0800 Message-ID: From: Tom Herbert To: Brian Trammell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: stackevo-discuss@iab.org Subject: Re: [Stackevo-discuss] Scope of stackevo and ossification in DC X-BeenThere: stackevo-discuss@iab.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: IP Stack Evolution Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 18:49:37 -0000 >> Similar to the use of protocols on the Internet we are hitting the >> transport protocol ossification problem in the data center. >> Specifically, performance optimizations in networking devices only >> support TCP or UDP, and without these optimizations this negatively >> impacts our use of other protocols. > > Right. But this is a fundamental problem, I think. NIC offloads reach pre= tty deeply into the transport protocol, and as such won't work with new tra= nsports whether they're encrypted or not until those new transports. A ques= tion: for NIC offload, how much of the win comes from segmentation offloadi= ng, and how much comes from other trickery? If the biggest win really is bu= ndling a bunch of packets into a single context switch, then how would the = performance of the current offload architecture compare with a smart librar= y on top of approaches like netmap? > Segmentation offload (RX and TX) is considered win because it reduces the number of packets that need to be processed through various layers of the stack. This becomes really evident in deep layering such as we see with network virtualization. However, most of the benefits can be achieved with software mechanisms and LRO (RX segmentation offload) is pretty controversial since the device is compressing TCP headers and that has had some insidious effects. Checksum offload and RSS are the critical offloads we need. >> One example of this is the need >> for fine grained ECMP which has become driver behind many of the >> foo-over-UDP proposals (e.g. MPLS/UDP, GRE/UDP, ...). > > So this is a separate issue -- ECMP is a (semi-elegant) hack, predicated = on the assumption that things on a five-tuple need to stay together and thi= ngs on separate five-tuples don't. NAT + TCP (any reordering-intolerant tra= nsport, really) makes this assumption more or less hold. Driving it in the = opposite direction -- using knowledge that there's ECMP on path to do cheap= traffic engineering -- leads to the unintended consequences that foo-over-= udp brings with it. > > What you really want architecturally is a way for the network layer (at a= gateway) to explicitly say "keep these packets together" and "it's okay to= split these packets apart". It'd be even better if we had a way to request= /measure/enforce actual path diversity without manually managing tunnels, b= ut this is sadly explicitly a non-feature of our routing protocols. In any = case this seems to have a harder incremental deployment story than simple t= ransport state exposure. > IPv6 flow label for ECMP (RFC6438) solves the problem of ECMP/RSS. With the use of this, devices don't need to parse beyond the IPv6 header to switch packets and we don't need to have the overhead of UDP encapsulation just for the purpose of getting good ECMP. >> This problem is likely a proper subset of the general problem, but >> might be more amenable to some "simpler" solutions. Is this within >> scope of stackevo? > > It very much seems to be, yes. Let's keep this discussion going on this l= ist... > Protocol ossification is also now in the vernacular of Linux networking: https://lwn.net/Articles/667059/ Tom From nobody Wed Dec 30 05:00:48 2015 Return-Path: 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 497691A1A99; Tue, 22 Dec 2015 07:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 7AxwImhIBC7J; Tue, 22 Dec 2015 07:50:05 -0800 (PST) Received: from email3-east.aero.org (email3-east.aero.org [130.221.184.167]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A461A1A97; Tue, 22 Dec 2015 07:50:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=aero.org; i=@aero.org; q=dns/txt; s=mailhub; t=1450799405; x=1482335405; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eszqSwdLnqIaBfsdlAvn/wE8LZU3ngqv4BmOr/iQxDM=; b=xK8RT362MHNIKAtnheK878qnUlg/FGLvf5h/npYfM3w00MHMqq8QVv/N xVBjTrswmdTboJUk9T6GNQSXayPdT5R2Cm7UQrTW7X5kjV6+qqomylswo o3mIVZHsD6STVW/Hs9RNlW8a7BVeAef/jAku70X9h+4twDtHUvhROREDF Q=; x-SBRS: 5.6 x-SenderGroup: Inbound_Office365 X-IronPort-AV: E=McAfee;i="5700,7163,8022"; a="1405488" X-IronPort-AV: E=Sophos;i="5.20,465,1444708800"; d="scan'208";a="1405488" X-IPAS-Result: A2G5AAB+cHlWnPGjLs9bAw4LAQEBAQ8BAQEBBgEBAQGDUm0GjEuzDwkXCoUiSgIcgUwRAQEBAQEBAQMOAQEBAQEGDQkJIS6CYhBVAi4+AQEBAwEBAQ8BEBE6CxACAQgYAgImAgICJQsVEAEBBAENBSKIDQ6efQGBKAEcYQUoAopvAQFwkioBAQEBAQEBAwEBAQEBAQEBAQEBFASBAYVWghaCaoRxCyaCVYFKBZcBjUyBXI0fikSDdDiCU4EfPnIBhB8BgQcBAQE Received: from mail-by2lp0241.outbound.protection.outlook.com (HELO na01-by2-obe.outbound.protection.outlook.com) ([207.46.163.241]) by email3-east.aero.org with ESMTP/TLS/AES256-SHA; 22 Dec 2015 10:48:47 -0500 Received: from DM2PR09MB0336.namprd09.prod.outlook.com (10.160.247.153) by DM2PR09MB0335.namprd09.prod.outlook.com (10.160.247.152) with Microsoft SMTP Server (TLS) id 15.1.361.13; Tue, 22 Dec 2015 15:48:45 +0000 Received: from DM2PR09MB0336.namprd09.prod.outlook.com ([10.160.247.153]) by DM2PR09MB0336.namprd09.prod.outlook.com ([10.160.247.153]) with mapi id 15.01.0361.006; Tue, 22 Dec 2015 15:48:45 +0000 From: Theodore V Faber To: Joe Touch , Linda Dunbar , Nishanth Sastry , Jon Crowcroft Thread-Topic: [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid Thread-Index: AdE4MC4YYpSof3RGRdK/YSjH5J56uAAcFN2AAAn56QAACra1AADV724AABCLD4A= Date: Tue, 22 Dec 2015 15:48:44 +0000 Message-ID: References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> <56789156.2020704@isi.edu> In-Reply-To: <56789156.2020704@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=theodore.v.faber@aero.org; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [130.221.224.7] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0335; 5:kTqH7tiJjYG8k4HvCEzEVVKBeHkpH/nGTyJ031SDEwgaPKp8N0Quq+wh6yiPxBPlPg8cS7yXE66q91vmTdc7xZA8SXlgPaUiScCE71HITri24mOIV9cdyBG26IXn3vVrVCcv2xHVY29Kdh5ofCn/bQ==; 24:qSJfWEUsnpHo7CaqLif0AoQdBFJ1ILP3lMJb8izqb0/QFIZ6ZLlG61Nn/Z3hb2HpF1/lRie2nBt26BjCduaNPdX9WdHvsnj+BnQAI3EK9Wo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0335; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:DM2PR09MB0335; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0335; x-forefront-prvs: 0798146F16 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(24454002)(199003)(479174004)(189002)(86362001)(5002640100001)(2171001)(11100500001)(40100003)(76176999)(66066001)(2900100001)(5008740100001)(101416001)(5001770100001)(122556002)(3846002)(1220700001)(1096002)(87936001)(36756003)(586003)(102836003)(19580395003)(2950100001)(77096005)(6116002)(15975445007)(5001960100002)(50986999)(81156007)(19580405001)(93886004)(5004730100002)(106356001)(10400500002)(54356999)(105586002)(97736004)(189998001)(92566002)(99286002)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR09MB0335; H:DM2PR09MB0336.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <84EFED495B9F32498D592E72F8050DE6@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: aero.org X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2015 15:48:44.9084 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c8294700-c5a4-4ca1-a876-1457d39899fd X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0335 Archived-At: X-Mailman-Approved-At: Wed, 30 Dec 2015 05:00:45 -0800 Cc: "icnrg@irtf.org" , gaia , "stackevo-discuss@iab.org" , Dirk Kutscher , "marnew@iab.org" , "5gangip@ietf.org" <5gangip@ietf.org>, "dtn-interest@irtf.org" Subject: Re: [Stackevo-discuss] [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 15:50:06 -0000 T24gMTIvMjEvMTUsIDE1OjU1LCAiU3RhY2tldm8tZGlzY3VzcyBvbiBiZWhhbGYgb2YgSm9lIFRv dWNoIg0KPHN0YWNrZXZvLWRpc2N1c3MtYm91bmNlc0BpYWIub3JnIG9uIGJlaGFsZiBvZiB0b3Vj aEBpc2kuZWR1PiB3cm90ZToNCg0KPg0KPg0KPk9uIDEyLzE3LzIwMTUgOTo0OSBBTSwgTGluZGEg RHVuYmFyIHdyb3RlOg0KPj4gSSBzdHJvbmdseSBzdXBwb3J0IHRoZSBjb25jZXB0IG9mIG5ldHdv cmsgc2xpY2luZyBmb3IgQXBwbGljYXRpb25zIG9yDQo+PklvVCBuZXR3b3Jrcy4gDQo+DQo+RldJ VywgSSBkbyBub3QgLSBpbiBzcGVjaWZpYywgSSBzdXBwb3J0IHRoZSBub3Rpb24gb2YgcGVyLXNl cnZpY2UNCj5vdmVybGF5cywgYnV0IHdvdWxkIG5vdCBjYWxsIHRoZW0gInNsaWNlcyIuDQo+DQo+ U2xpY2VzIGFyZSBhbiBhcnRpZmFjdCBvZiBhbiBPUy12aWV3IG9mIHRoZSBuZXR3b3JrLiBJdCdz IGEgbmV0d29yaw0KPnBhcnRpdGlvbmluZyBtb2RlbCB0aGF0IGNvbnNpZGVycyBjcm9zcy1vdmVy bGF5IGludGVyYWN0aW9uIG9ubHkgYXMgYQ0KPnZpb2xhdGlvbiBvZiB0aGUgbW9kZWwgaXRzZWxm Lg0KDQpKdXN0IHRvIGRlZmVuZCBteSB0cmliZSBhIGJpdCwgSeKAmWQgc2F5IG1vcmUgb2YgYSB0 ZWxjby12aWV3IG9mIHRoZQ0KbmV0d29yay4gIFByb3ZpZGluZyBpc29sYXRlZCBzdHJpY3RseSBk ZWZpbmVkIHNlcnZpY2VzIC0gZS5nLiAza0h6IHZvaWNlDQpjaGFubmVscyAtIGxldHMgeW91IHJl YXNvbiBhYm91dCBwYXJ0aXRpb25pbmcgYW5kIHNlcnZpY2UgZGV2ZWxvcG1lbnQgYm90aA0KYXQg dGhlIGNvc3Qgb2YgbWFpbnRhaW5pbmcgYSBzdHJhbmdsZWhvbGQgb24gd2hhdCBnZXRzIGRlcGxv eWVkLiAgU2xpY2VzDQpvbmx5IGVuZm9yY2UgdGhlaXIgaXNvbGF0aW9uIGFuZCBndWFyYW50ZWVz IGlmIGFsbCB0aGUgZXF1aXBtZW50IGhhcw0KY2FwYWJpbGl0aWVzIGFuZCBpcyBtYW5hZ2VtZW50 IGFwcHJvcHJpYXRlIHRvIGl0Lg0KDQpZZWFoLCB0aGVyZeKAmXMgYW4gT1MvZGlzdHJpYnV0ZWQg c3lzdGVtcyBmZWVsIHRvIHRoYXQsIGJ1dCBiZWNhdXNlIHRoZQ0KY29uc3RyYWludHMgbm93IGV4 dGVuZCBvdXQgb2YgYSBjaGFzc2lzIGFuZCBiZXlvbmQgYSBMQU4sIHRlbGNvIGFuYWxvZ2llcw0K bWFrZSBtb3JlIHNlbnNlIHRvIG1lLg0KDQpJIGtub3cgeW91IChKb2UpIGtub3cgdGhhdCwgYnV0 IEkgdGhpbmsgaXTigJlzIHdvcnRoIHNheWluZyB0byB0aGUgZ3JvdXANCmJlY2F1c2UgdGhlIG1v cmUgc3RyaWN0bHkgeW91IGFkaGVyZSB0byBhIHNsaWNpbmcgbW9kZWwgdGhlIG1vcmUNCmNvbnN0 cmFpbnRzIHlvdSBwdXQgb24geW91ciBlcXVpcG1lbnQgYW5kIG1hbmFnZW1lbnQuICBJbiBhIHNt YWxsIG5ldHdvcmsNCi0gdGhhdCBtaWdodCBiZSBhcyBiaWcgYXMgYSBtdW5pY2lwYWxpdHkgLSB0 aG9zZSBjb25zdHJhaW50cyBzZWVtIG1vcmUNCnJlYXNvbmFibGUgdG8gbWUgdGhhbiBpbiB0aGUg Y2FwaXRhbC1JIEludGVybmV0LiAgVGhlIGNvc3Qgb2YgZW5mb3JjaW5nIG9yDQpldmVuIGVuY291 cmFnaW5nIHRob3NlIGNvbnN0cmFpbnRzIGFjcm9zcyBtYW55IHByb3ZpZGVycyAob2YgZXF1aXBt ZW50IGFuZA0Kc2VydmljZSkgc3RhcnRzIHRvIGdldCBwcm9oaWJpdGl2ZS4gIEl0IGhhZCBiZXR0 ZXIgYmUgd29ydGggaXQsIGFuZCB0byBtZQ0KdGhlcmUgYXJlIGZldyBjYXNlcyB3aGVyZSBpdCBp cy4NCg0KVGhhdCBsZWF2ZXMgYXNpZGUgYXJndW1lbnRzIHRoYXQgZGl2ZXJzaXR5IG9mIGVxdWlw bWVudCBhbmQgbWFuYWdlbWVudCBtYXkNCmJlIGdvb2QgZm9yIHRoZSBJbnRlcm5ldC4gIElubm92 YXRpb24gb2Z0ZW4gY29tZXMgZnJvbSBsZXR0aW5nIHBlb3BsZQ0KbG9vc2UgaW4gYSBsaWdodGx5 IGNvbnN0cmFpbmVkIHBsYXlncm91bmQuDQoNCj4NCj5XZSBzaG91bGQgYmUgY2FyZWZ1bCB0byBj b25zaWRlciB0aGF0IG5ldHdvcmtzIGVuZCBhdCBuZXR3b3JrIGludGVyZmFjZXMNCj5hbmQgbmV0 d29yayBpbnRlcmZhY2UgbmFtZXMsIG5vdCBPUyBwYXJ0aXRpb25zIC0gYW5kIE9TIHBhcnRpdGlv bnMgYXJlDQo+dGhlIGJhZ2dhZ2UgdGhhdCBjb21lcyB3aXRoIHRoZSB0ZXJtICJzbGljZSIuDQo+ DQo+Sm9lDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj5TdGFja2V2by1kaXNjdXNzIG1haWxpbmcgbGlzdA0KPlN0YWNrZXZvLWRpc2N1c3NAaWFi Lm9yZw0KPmh0dHBzOi8vd3d3LmlhYi5vcmcvbWFpbG1hbi9saXN0aW5mby9zdGFja2V2by1kaXNj dXNzDQo+DQoNCg0KLS0gDQpUZWQgRmFiZXIgPHRoZW9kb3JlLnYuZmFiZXJAYWVyby5vcmc+DQpF bmdpbmVlcmluZyBTcGVjaWFsaXN0DQpDb21wdXRlciBTeXN0ZW1zIFJlc2VhcmNoIERlcGFydG1l bnQNCjMxMC0zMzYtNzM3Mw0KDQoNCg0K From nobody Wed Dec 30 05:00:49 2015 Return-Path: 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 E028F1A88F0; Tue, 22 Dec 2015 08:57:52 -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=unavailable 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 UH1Z064zw0qk; Tue, 22 Dec 2015 08:57:51 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 4E6A41A888A; Tue, 22 Dec 2015 08:57:51 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id u7so62556326pfb.1; Tue, 22 Dec 2015 08:57:51 -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=ZpEKUUR5rc9/Mt/k85pscY5ttN8+XBgB8KQWpg/+Hag=; b=Oi0F9k12HuV1jFle9GPB+xVj4EpA9LB2XCe/Nrut/i4U4VoQsp+6P2mwqnXTx7qUMJ ugOKaB1F/9WgyjpiScAzqnFwf8xLKfytWr41o0VGJfj5bdXrSjcA2+C64WWE1Dqs1oV/ R9adzNjxN8+O7HKAk4PgbOxJoO/+XbBhFGl+gntDENkHiUxJLFVJOosev4lOlqqj6VDd GFXS6KYCNvjjsKbjCLEsslPvS8Y77aqr/XG+0SpkNrL9M99auviz1APX3q688cbxw03d +pJXEu6QfKl/CNWugWascMEwxRl5KDFjbkVXzoxBp3exr6nb9UCGkAv2r2yBAcW1gf57 2Hag== X-Received: by 10.98.44.209 with SMTP id s200mr29035578pfs.2.1450803470919; Tue, 22 Dec 2015 08:57:50 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id h90sm6966060pfj.23.2015.12.22.08.57.46 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Dec 2015 08:57:49 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Dino Farinacci In-Reply-To: <56789156.2020704@isi.edu> Date: Tue, 22 Dec 2015 08:57:46 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <6EE22057-5EB9-4489-A50D-7B92DA2B96AF@gmail.com> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> <56789156.2020704@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.3096.5) Archived-At: X-Mailman-Approved-At: Wed, 30 Dec 2015 05:00:44 -0800 Cc: "icnrg@irtf.org" , gaia , "stackevo-discuss@iab.org" , Linda Dunbar , Jon Crowcroft , "5gangip@ietf.org" <5gangip@ietf.org>, "marnew@iab.org" , Nishanth Sastry , Dirk Kutscher , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 16:57:53 -0000 Why does yet another term need to be defined for what has been = traditionally called a multi-tenant VPN.=20 Dino > On Dec 21, 2015, at 3:55 PM, Joe Touch wrote: >=20 >=20 >=20 > On 12/17/2015 9:49 AM, Linda Dunbar wrote: >> I strongly support the concept of network slicing for Applications or = IoT networks.=20 >=20 > FWIW, I do not - in specific, I support the notion of per-service > overlays, but would not call them "slices". >=20 > 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. >=20 > 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". >=20 > Joe >=20 > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip From nobody Wed Dec 30 05:00:51 2015 Return-Path: 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 781671A889D; Tue, 22 Dec 2015 09:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 JitjyVWTR-4S; Tue, 22 Dec 2015 09:17:45 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04CCF1A21AC; Tue, 22 Dec 2015 09:17:44 -0800 (PST) Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id tBMHGkIe022227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 22 Dec 2015 09:16:51 -0800 (PST) To: Dino Farinacci References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> <56789156.2020704@isi.edu> <6EE22057-5EB9-4489-A50D-7B92DA2B96AF@gmail.com> From: Joe Touch Message-ID: <5679857D.9000602@isi.edu> Date: Tue, 22 Dec 2015 09:16:45 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <6EE22057-5EB9-4489-A50D-7B92DA2B96AF@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: X-Mailman-Approved-At: Wed, 30 Dec 2015 05:00:44 -0800 Cc: "icnrg@irtf.org" , touch@isi.edu, gaia , "stackevo-discuss@iab.org" , Linda Dunbar , Jon Crowcroft , "5gangip@ietf.org" <5gangip@ietf.org>, "marnew@iab.org" , Nishanth Sastry , Dirk Kutscher , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 17:17:46 -0000 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 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 >> >> _______________________________________________ >> 5gangip mailing list >> 5gangip@ietf.org >> https://www.ietf.org/mailman/listinfo/5gangip > From nobody Wed Dec 30 05:00:52 2015 Return-Path: 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 104C81A88DC; Tue, 22 Dec 2015 09:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 cANiEGee17gx; Tue, 22 Dec 2015 09:32:46 -0800 (PST) Received: from mta0.cl.cam.ac.uk (mta0.cl.cam.ac.uk [128.232.25.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66FD81A88CF; Tue, 22 Dec 2015 09:32:46 -0800 (PST) Received: from svr-ssh-1.cl.cam.ac.uk ([128.232.102.11] ident=jac22) by mta0.cl.cam.ac.uk with esmtp (Exim 4.63) (envelope-from ) id 1aBQne-0001st-9g; Tue, 22 Dec 2015 17:32:38 +0000 From: Jon Crowcroft To: Dino Farinacci In-reply-to: <6EE22057-5EB9-4489-A50D-7B92DA2B96AF@gmail.com> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> <56789156.2020704@isi.edu> <6EE22057-5EB9-4489-A50D-7B92DA2B96AF@gmail.com> Comments: In-reply-to Dino Farinacci message dated "Tue, 22 Dec 2015 08:57:46 -0800." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27267.1450805558.1@svr-ssh-1.cl.cam.ac.uk> Date: Tue, 22 Dec 2015 17:32:38 +0000 Message-Id: Archived-At: X-Mailman-Approved-At: Wed, 30 Dec 2015 05:00:45 -0800 Cc: "icnrg@irtf.org" , Joe Touch , gaia , "stackevo-discuss@iab.org" , Linda Dunbar , "marnew@iab.org" , "5gangip@ietf.org" <5gangip@ietf.org>, Nishanth Sastry , Dirk Kutscher , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 17:32:48 -0000 > Why does yet another term need to be defined for what has been > traditionally called a multi-tenant VPN. well, slices came out of planetlab, which is not really a spring chicken (but nor was it a thanksgiving turkey:) > Dino > > > On Dec 21, 2015, at 3:55 PM, Joe Touch 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 > > > > _______________________________________________ > > 5gangip mailing list > > 5gangip@ietf.org > > https://www.ietf.org/mailman/listinfo/5gangip > > From nobody Wed Dec 30 05:00:54 2015 Return-Path: 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 314BF1A8A79; Tue, 22 Dec 2015 10:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable 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 5qCG2MJWqfnh; Tue, 22 Dec 2015 10:47:55 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [58.251.152.64]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2161A8A6D; Tue, 22 Dec 2015 10:47:52 -0800 (PST) Received: from 172.24.1.47 (EHLO szxeml427-hub.china.huawei.com) ([172.24.1.47]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBI46914; Wed, 23 Dec 2015 02:47:30 +0800 (CST) Received: from szxeml559-mbs.china.huawei.com ([169.254.2.89]) by szxeml427-hub.china.huawei.com ([10.82.67.182]) with mapi id 14.03.0235.001; Wed, 23 Dec 2015 02:47:17 +0800 From: AshwoodsmithPeter To: Joe Touch , Dino Farinacci Thread-Topic: [5gangip] [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid Thread-Index: AQHROW5WZcE4Jya+TkWrglMNHXDB+p7VnQoAgAGtUTeAAA3DMA== Date: Tue, 22 Dec 2015 18:47:16 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E20AF3BC87@szxeml559-mbs.china.huawei.com> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <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.100] Content-Type: multipart/alternative; boundary="_000_7AE6A4247B044C4ABE0A5B6BF427F8E20AF3BC87szxeml559mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.56799AC4.0017, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.89, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: dd7428a927495eb80a217c113c229158 Archived-At: X-Mailman-Approved-At: Wed, 30 Dec 2015 05:00:45 -0800 Cc: "icnrg@irtf.org" , gaia , "stackevo-discuss@iab.org" , "marnew@iab.org" , Linda Dunbar , Jon Crowcroft , "5gangip@ietf.org" <5gangip@ietf.org>, Nishanth Sastry , Dirk Kutscher , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 18:47:58 -0000 --_000_7AE6A4247B044C4ABE0A5B6BF427F8E20AF3BC87szxeml559mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. > Why does yet another term need to be defined for what has been traditiona= lly called a multi-tenant VPN. I believe a slice is much more than a VPN however VPN technologies are like= ly 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 en= d devices (1) and the network (2) so: (1) From the perspective of the end devices it's relatively simple. A sli= ce is a way to group end devices that share common QOS/QOE and Administrati= on/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 t= hat makes up the 5G network from Antennas through to core processing. Thus Slice_i =3D 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 fronthau= l to the CRAN fabric, allocate the CRAN fabric, allocate processing resourc= es ( shared or unique in the CRAN), populate those processing resources wit= h the code (Numerology) that implements the RAT, then we need to allocate p= acket backhaul bandwidth in the CRAN or DC fabric, then assign compute reso= urces (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 sub= set 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 sl= ice that are well outside the scope of a VPN. Note also that a slice can be isolated from another slice in time, space, f= requency or statistically in each of those subsets and in particular the fr= onthaul 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. Peter --_000_7AE6A4247B044C4ABE0A5B6BF427F8E20AF3BC87szxeml559mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Couple of comments from my perspective before dis= appearing for Xmas.

 

> Slices have the baggage that a process can b= elong to only one slice at a time.

 

Not always. A process which is implementing an ai= r interface could in fact be implementing several slices in the same proces= s. Or same core.

 

> Why does yet another term need to be defined for what has been tradi= tionally 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: <= /o:p>

 

To define a slice we need to look at it from the = perspective of both the end devices (1) and the network (2) so:<= /p>

 

(1)   From the perspective of the end d= evices 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 netwo= rk a slice is much more complicated. Essentially a slice is a set of subset= s of the all the network equipment that makes up the 5G network from Antenn= as through to core processing. Thus

Slice_i =3D   Subset of(All_Antennas) &= nbsp;      U

        &= nbsp;   subset of(All_Fronthaul)     &nb= sp; U

        &= nbsp;   Subset of(All CRAN fabric)     U=

        &= nbsp;   Subset of(All CRAN processing) U

        &= nbsp;   Subset of(ALL Numerologies)    U

        &= nbsp;   Subset of(All DC fabric)      &n= bsp;U

        &= nbsp;   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 antenn= as, configure the fronthaul to the CRAN fabric, allocate the CRAN fabric, a= llocate processing resources ( shared or unique in the CRAN), populate thos= e processing resources with the code (Numerology) that implements the RAT, then we need to allocate packet back= haul bandwidth in the CRAN or DC fabric, then assign compute resources (sha= red 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 a= ll 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 anoth= er slice in time, space, frequency or statistically in each of those subset= s and in particular the fronthaul and RAT require very hard boundaries betw= een slices while as we get further towards packet processing the boundaries can be less ridgid.

 

Hence the need for a new term.

 

Peter

 

 

 

--_000_7AE6A4247B044C4ABE0A5B6BF427F8E20AF3BC87szxeml559mbschi_-- From nobody Wed Dec 30 05:00:55 2015 Return-Path: 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 ; 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 ; 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 ; 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 To: Joe Touch , Dino Farinacci 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> <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: X-Mailman-Approved-At: Wed, 30 Dec 2015 05:00:44 -0800 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 comb= ined together to meet the requirements of a specific use case or business m= odel. For example, there may be a network slice for video traffic, a slice = for M2M traffic, and a slice for regular web browsing traffic.=20 Each network slice may involve a specific set of (virtual) network function= s 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 essentia= lly a traffic- and service-management tool. So yes, a slice is a form of virtual network but not a VPN per se (in the e= nterprise or multi-tenant sense). A slice may be something that a mobile op= erator uses internally to manage different types of traffic, or it may be s= omething 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 organisation= s 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 >=20 > VPNs often have a lot of baggage, notably that an end system can belong > to only one at a time. >=20 > Slices have the baggage that a process can belong to only one slice at a > time. >=20 > 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. >=20 > Joe >=20 > 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 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 > >> From nobody Wed Dec 30 05:00:57 2015 Return-Path: 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 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: References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <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 X-Mailer: Apple Mail (2.3096.5) Archived-At: X-Mailman-Approved-At: Wed, 30 Dec 2015 05:00:44 -0800 Cc: "icnrg@irtf.org" , Joe Touch , gaia , "stackevo-discuss@iab.org" , "marnew@iab.org" , Linda Dunbar , Jon Crowcroft , "5gangip@ietf.org" <5gangip@ietf.org>, Nishanth Sastry , Dirk Kutscher , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 19:38:06 -0000 > Couple of comments from my perspective before disappearing for Xmas. > =20 > > Slices have the baggage that a process can belong to only one slice = at a time. > =20 > 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). > =20 > > Why does yet another term need to be defined for what has been = traditionally called a multi-tenant VPN. > =20 > I believe a slice is much more than a VPN however VPN technologies are = likely a component part of what a slice 'is'. > =20 > Here is a definition I have found helpful:=20 > =20 > To define a slice we need to look at it from the perspective of both = the end devices (1) and the network (2) so: > =20 > (1) =46rom the perspective of the end devices it=E2=80=99s = relatively simple. A slice is a way to group end devices that share = common QOS/QOE and Administration/Geographic area etc. > =20 > (2) =46rom 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 =3D Subset of(All_Antennas) U=20 > 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)=20 > =20 > Where of course Subset(X) can contain all or none of the elements in = X. > =20 > 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). > =20 > =46rom 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. > =20 > 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. > =20 > Hence the need for a new term. If you use the right network architecture, a VPN can have these = properties. Dino > =20 > Peter From nobody Wed Dec 30 05:00:58 2015 Return-Path: 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 A89E91A8AC1 for ; Tue, 22 Dec 2015 11:41:22 -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 3XxJq5MC0fMG for ; Tue, 22 Dec 2015 11:41:21 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 06D211A8AC0 for ; Tue, 22 Dec 2015 11:41:21 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id q63so4861033pfb.0 for ; Tue, 22 Dec 2015 11:41:21 -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=W6SWE1S5XDhsjmbrN/I+EXL0pt3uTcbgt+YEOOCES3Y=; b=qltbGwlvF+RT19rdCDRHButuwyiJ4WjFPZJcpEppsud4+ax/HFhe6DWV3pEAQtfrTk FscGeBgh88d1c9N4olkOts3WBDMSUto2/hMHeobV1BoQinL+qWF0QMI6a4rI5x3J6J2Y 7vNY6D5vdOW1TwQExY71V5cEzN4yqJZcPRZZro4bL7YCHjS0UTj2pulzFudBHcSKFCoV Jy77fg49BO1o47hnoh8X3m79arIwcI2a4h2X9y+viZR/ySWl5Db7q3xy5xpH02uD0Hkn y5/drANlA8+tehZ/MwjMfDmWifV4I7K3J84PL1xgIHsUTqm/zusjs71hH+vHqz4l5tso HDAg== X-Received: by 10.98.86.195 with SMTP id h64mr38570178pfj.96.1450813280681; Tue, 22 Dec 2015 11:41:20 -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 b26sm42965567pfd.6.2015.12.22.11.41.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Dec 2015 11:41:18 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Dino Farinacci In-Reply-To: <26426B4FF145B449A3D1FAC13C6B297833BBDB31@YYZEML703-CHM.china.huawei.com> Date: Tue, 22 Dec 2015 11:41:20 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <55653654-B03F-400B-B5B4-3A8CFA83BC74@gmail.com> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> <56789156.2020704@isi.edu> <6EE22057-5EB9-4489-A50D-7B92DA2B96AF@gmail.com> <5679857D.9000602@isi.edu> <26426B4FF145B449A3D1FAC13C6B297833BBDB31@YYZEML703-CHM.china.huawei.com> To: Bill Gage X-Mailer: Apple Mail (2.3096.5) Archived-At: X-Mailman-Approved-At: Wed, 30 Dec 2015 05:00:44 -0800 Cc: "stackevo-discuss@iab.org" , "5gangip@ietf.org" <5gangip@ietf.org>, Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 19:41:22 -0000 I think your difference is subtle where in fact you a virtual network = and a VPN is one of the same thing. And you can use VPN technology (an = overlay with segmentation of hosts, routers, and functions) to satisfy = the requirements below. Dino > On Dec 22, 2015, at 11:18 AM, Bill Gage wrote: >=20 > 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.=20 >=20 > 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. >=20 > 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). >=20 > Like it or not, "network slice" seems to the name that various = organisations have given to this concept. >=20 > Cheers ... >=20 > [I tried to trim the receiver list just a little :-] >=20 >=20 >> -----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 >>=20 >> VPNs often have a lot of baggage, notably that an end system can = belong >> to only one at a time. >>=20 >> Slices have the baggage that a process can belong to only one slice = at a >> time. >>=20 >> 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. >>=20 >> Joe >>=20 >> 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. >>>=20 >>> Dino >>>=20 >>>> On Dec 21, 2015, at 3:55 PM, Joe Touch wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On 12/17/2015 9:49 AM, Linda Dunbar wrote: >>>>> I strongly support the concept of network slicing for Applications = or >> IoT networks. >>>>=20 >>>> FWIW, I do not - in specific, I support the notion of per-service >>>> overlays, but would not call them "slices". >>>>=20 >>>> 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. >>>>=20 >>>> 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". >>>>=20 >>>> Joe >>>>=20 >=20 From nobody Wed Dec 30 05:01:00 2015 Return-Path: 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 4F4961A8AE2; Tue, 22 Dec 2015 11:54:05 -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=unavailable 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 VK8_EQrVvARu; Tue, 22 Dec 2015 11:54:04 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [58.251.152.64]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5DF1A8AE1; Tue, 22 Dec 2015 11:54:01 -0800 (PST) Received: from 172.24.1.49 (EHLO szxeml427-hub.china.huawei.com) ([172.24.1.49]) by szxrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBI51285; Wed, 23 Dec 2015 03:53:41 +0800 (CST) Received: from szxeml559-mbs.china.huawei.com ([169.254.2.89]) by szxeml427-hub.china.huawei.com ([10.82.67.182]) with mapi id 14.03.0235.001; Wed, 23 Dec 2015 03:53:26 +0800 From: AshwoodsmithPeter To: Dino Farinacci Thread-Topic: [5gangip] [Stackevo-discuss] [gaia] 5G: It's the Network, Stupid Thread-Index: AQHROW5WZcE4Jya+TkWrglMNHXDB+p7VnQoAgAGtUTeAAA3DMP//j3SAgACIM8A= Date: Tue, 22 Dec 2015 19:53:25 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E20AF3BD35@szxeml559-mbs.china.huawei.com> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> <56789156.2020704@isi.edu> <6EE22057-5EB9-4489-A50D-7B92DA2B96AF@gmail.com> <5679857D.9000602@isi.edu> <7AE6A4247B044C4ABE0A5B6BF427F8E20AF3BC87@szxeml559-mbs.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.60.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.5679AA47.00CA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.2.89, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: dd7428a927495eb80a217c113c229158 Archived-At: X-Mailman-Approved-At: Wed, 30 Dec 2015 05:00:45 -0800 Cc: "icnrg@irtf.org" , Joe Touch , gaia , "stackevo-discuss@iab.org" , "marnew@iab.org" , Linda Dunbar , Jon Crowcroft , "5gangip@ietf.org" <5gangip@ietf.org>, Nishanth Sastry , Dirk Kutscher , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 19:54:05 -0000 Pj4gSGVuY2UgdGhlIG5lZWQgZm9yIGEgbmV3IHRlcm0uDQoNCj4gSWYgeW91IHVzZSB0aGUgcmln aHQgbmV0d29yayBhcmNoaXRlY3R1cmUsIGEgVlBOIGNhbiBoYXZlIHRoZXNlIHByb3BlcnRpZXMu DQoNCk5vIHF1ZXN0aW9uIHRoYXQgVlBOcyBjYW4gcGxheSB0aGUgZGlmZmVyZW50IGludGVyY29u bmVjdCBpc29sYXRpb24gcm9sZXMgd2l0aCBkaWZmZXJlbnQgcHJvcGVydGllcy4NClRoZXJlIHdv dWxkIGJlIGEgVlBOIHRlY2hub2xvZ3kgZG9pbmcgVERNIG9yIERXRE0gb3Igc3BhY2UgaXNvbGF0 aW9uIGluIHRoZSBmcm9udGhhdWwuIFRoZXJlIHdvdWxkIGJlIFZQTiBkb2luZyBwcm9iYWJseSB1 bHRyYSBsb3cgaml0dGVyIHBhY2tldCBpc29sYXRpb24gaW4gdGhlIENSQU4gZmFicmljIGFuZCB0 aGVuIHByZXR0eSBtdWNoIGFueSBwYWNrZXQgVlBOIHRlY2hub2xvZ3kgZG9pbmcgaXNvbGF0aW9u IGluIHRoZSBEQyBmYWJyaWMuIEhvd2V2ZXIgdGhlcmUgYXJlIGFsc28gbWVjaGFuaXNtcyB0byBj b250cm9sIGFudGVubmFzLCBjb250cm9sIGFudGVubmEgbGVuc2VzLCBwaWNrL3N0YXJ0L3N0b3Av cHJvZ3JhbSB0aGUgZGlnaXRhbCBzaWduYWwgcHJvY2Vzc2luZyBzb2Z0d2FyZSAoTnVtZXJvbG9n eSkgZXRjLiBTbyBhIFZQTiBjYW4gaGF2ZSBzb21lIG9mIHRoZSByZXF1aXJlZCBwcm9wZXJ0aWVz IGJ1dCBubyB3YXkgZG9lcyBpdCBjb3ZlciBldmVyeXRoaW5nLCBhbmQgdGhhdCBldmVyeXRoaW5n IGlzIHdoYXQgaXMgYmVpbmcgY2FsbGVkIGEgc2xpY2UuDQoNCkEgc2xpY2luZyBjb250cm9sbGVy IHdvdWxkIHJlYWxseSBiZSBqdXN0IGFuIG9yY2hlc3RyYXRvciB0aGF0IHRlbGxzIHRoZSBkaWZm ZXJlbnQgVlBOJ3Mgd2hhdCBkbyBmb3IgdGhlIGRpZmZlcmVudCBuZXR3b3JrIHNlZ21lbnRzIGFu ZCB0aGVuIHByb2dyYW1zIHRoZSBlbmRzL21pZCBwb2ludHMgd2l0aCB0aGUgYXBwcm9wcmlhdGUg YmVoYXZpb3IuIA0KDQpDaGVlcnMsDQoNClBldGVyDQo= From nobody Wed Dec 30 05:01:01 2015 Return-Path: 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 913321A8F38; Tue, 22 Dec 2015 12:20:58 -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=unavailable 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 sxfetSErBlgK; Tue, 22 Dec 2015 12:20:57 -0800 (PST) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 6A6C41A8F37; Tue, 22 Dec 2015 12:20:56 -0800 (PST) Received: by mail-pa0-x22b.google.com with SMTP id q3so101334231pav.3; Tue, 22 Dec 2015 12:20:56 -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=2/XwuddUyYdDP4kRdLMRjMICcZqZo3XSQBhyBi/BB1c=; b=U0uJx3x75YSPzURJ1/VLGayGG2eBWrW9ThbHvBlmq+7Uiiebqwtn9ExHFdCwvc0ASz p1/HFTEFirUo2DUdSXNUBaIab2ZAuwVmnQP4CSgQhadapJexWFF4BkqrtyjSEsh2yTQD YbYWr/ofsX9YcnZ33kLTP8jmCEKoWhRf5+PCy3KYkKjdi7gA3qvW72TosfaZn+6Yzt8J WEpAbMzN5UDXUdmwx653CqLap3+7swQgL85TSkqMwrVba0eSCbrpbtlUC4qnqlLFB/Iz b4cKivr3Lr/azDRyY4sUTQF61foaOgjQEjkavwgydPCFz9Eau7teW4yTjJIMs8Ng04H4 DZfA== X-Received: by 10.67.3.230 with SMTP id bz6mr38585942pad.118.1450815656069; Tue, 22 Dec 2015 12:20:56 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id l64sm43061008pfb.40.2015.12.22.12.20.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Dec 2015 12:20:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Dino Farinacci In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E20AF3BD35@szxeml559-mbs.china.huawei.com> Date: Tue, 22 Dec 2015 12:20:51 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> <56789156.2020704@isi.edu> <6EE22057-5EB9-4489-A50D-7B92DA2B96AF@gmail.com> <5679857D.9000602@isi.edu> <7AE6A4247B044C4ABE0A5B6BF427F8E20AF3BC87@szxeml559-mbs.china.huawei.com> <7AE6A4247B044C4ABE0A5B6BF427F8E20AF3BD35@szxeml559-mbs.china.huawei.com> To: AshwoodsmithPeter X-Mailer: Apple Mail (2.3096.5) Archived-At: X-Mailman-Approved-At: Wed, 30 Dec 2015 05:00:44 -0800 Cc: "icnrg@irtf.org" , Joe Touch , gaia , "stackevo-discuss@iab.org" , "marnew@iab.org" , Linda Dunbar , Jon Crowcroft , "5gangip@ietf.org" <5gangip@ietf.org>, Nishanth Sastry , Dirk Kutscher , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 20:20:58 -0000 Ack. Makes perfect sense. Dino > On Dec 22, 2015, at 11:53 AM, AshwoodsmithPeter = wrote: >=20 >>> Hence the need for a new term. >=20 >> If you use the right network architecture, a VPN can have these = properties. >=20 > No question that VPNs can play the different interconnect isolation = roles with different properties. > There would be a VPN technology doing TDM or DWDM or space isolation = in the fronthaul. There would be VPN doing probably ultra low jitter = packet isolation in the CRAN fabric and then pretty much any packet VPN = technology doing isolation in the DC fabric. However there are also = mechanisms to control antennas, control antenna lenses, = pick/start/stop/program the digital signal processing software = (Numerology) etc. So a VPN can have some of the required properties but = no way does it cover everything, and that everything is what is being = called a slice. >=20 > A slicing controller would really be just an orchestrator that tells = the different VPN's what do for the different network segments and then = programs the ends/mid points with the appropriate behavior.=20 >=20 > Cheers, >=20 > Peter From nobody Wed Dec 30 05:01:02 2015 Return-Path: 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 401961A8F4A for ; Tue, 22 Dec 2015 12:31:16 -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 58q_5KDGyPEi for ; Tue, 22 Dec 2015 12:31:13 -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 323B71A8F45 for ; Tue, 22 Dec 2015 12:31:13 -0800 (PST) Received: from 172.18.9.243 (EHLO dfweml706-chm.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CUC42087; Tue, 22 Dec 2015 14:31:11 -0600 (CST) Received: from YYZEML702-CHM.china.huawei.com (10.218.33.72) by dfweml706-chm.china.huawei.com (10.193.5.225) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 22 Dec 2015 12:31:10 -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 15:31:06 -0500 From: Bill Gage To: Dino Farinacci Thread-Topic: [5gangip] [Stackevo-discuss] 5G: It's the Network, Stupid Thread-Index: AQHRPPDBZUTsw+FMcUaomDly+qWkA57XdHDw Date: Tue, 22 Dec 2015 20:31:05 +0000 Message-ID: <26426B4FF145B449A3D1FAC13C6B297833BBDB64@YYZEML703-CHM.china.huawei.com> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> <56789156.2020704@isi.edu> <6EE22057-5EB9-4489-A50D-7B92DA2B96AF@gmail.com> <5679857D.9000602@isi.edu> <26426B4FF145B449A3D1FAC13C6B297833BBDB31@YYZEML703-CHM.china.huawei.com> <55653654-B03F-400B-B5B4-3A8CFA83BC74@gmail.com> In-Reply-To: <55653654-B03F-400B-B5B4-3A8CFA83BC74@gmail.com> 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.5679B30F.021D, 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: 0b47501d461d8cb6e3fb471efa6e05dd Archived-At: X-Mailman-Approved-At: Wed, 30 Dec 2015 05:00:44 -0800 Cc: "stackevo-discuss@iab.org" , "5gangip@ietf.org" <5gangip@ietf.org>, Joe Touch 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 20:31:16 -0000 I didn't say that you couldn't use VPN technology to realise a slice, I jus= t said that a slice may encompass more that what one usually associates wit= h the term "VPN". A slice may pull in technologies associated with SFC, NFV= , TE, SDN, and a dozen other TLAs ;-) Cheers ... > -----Original Message----- > From: Dino Farinacci [mailto:farinacci@gmail.com] > Sent: Tuesday, December 22, 2015 2:41 PM > Subject: Re: [5gangip] [Stackevo-discuss] 5G: It's the Network, Stupid >=20 > I think your difference is subtle where in fact you a virtual network and > a VPN is one of the same thing. And you can use VPN technology (an overla= y > with segmentation of hosts, routers, and functions) to satisfy the > requirements below. >=20 > Dino >=20 > > On Dec 22, 2015, at 11:18 AM, Bill Gage wrote: > > > > 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 belon= g > >> 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 al= l > >> 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 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 > >>>> > > From nobody Wed Dec 30 05:01:04 2015 Return-Path: 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 EAEBE1A903F for ; Tue, 22 Dec 2015 13:01:40 -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 gN4hnUI4uT3K for ; Tue, 22 Dec 2015 13:01:39 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 1B6951A903C for ; Tue, 22 Dec 2015 13:01:39 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id o64so111602273pfb.3 for ; Tue, 22 Dec 2015 13:01:39 -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=yvaSOfc8i7O2TNhlnX8GFgkZh2Exa7BPeLZMsXuncck=; b=BXT21OmHuAHQ/t9w2mQ3onYAoKlRX7XR4R2P07pi1rPpkmmP2xLs61/dcOee6v+f/U aQ9KSQ1mRWLLwcaXsCag/CVP0kqQZOwJtPy9RLrj+Ru/oCRy2/nU2BCyXK6vsY1kdoFy fKHsYdFYIO/Sn4Xqwf2nZup8t5Jw3Ej06irZ5kCUsCdg7mBYBYmTpIHauW9EwOyvZMcG C3P/LxLw5C2WAAx6K1UEuK7HcRnggs/MW+xJFApWK4V3i9JnqyENHBjwNcup0owpn45O 69CG7EHQpbZmr0+NUGHg1RvKXKkCnrJe71WE0DFgrj5Y+V89RjVkfhgTus4yBUniMoT2 Rxhg== X-Received: by 10.98.31.153 with SMTP id l25mr13993333pfj.144.1450818098709; Tue, 22 Dec 2015 13:01:38 -0800 (PST) Received: from [10.197.31.157] (173-11-119-245-SFBA.hfc.comcastbusiness.net. [173.11.119.245]) by smtp.gmail.com with ESMTPSA id r90sm43154321pfi.80.2015.12.22.13.01.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Dec 2015 13:01:37 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Dino Farinacci In-Reply-To: <26426B4FF145B449A3D1FAC13C6B297833BBDB64@YYZEML703-CHM.china.huawei.com> Date: Tue, 22 Dec 2015 13:01:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> <56789156.2020704@isi.edu> <6EE22057-5EB9-4489-A50D-7B92DA2B96AF@gmail.com> <5679857D.9000602@isi.edu> <26426B4FF145B449A3D1FAC13C6B297833BBDB31@YYZEML703-CHM.china.huawei.com> <55653654-B03F-400B-B5B4-3A8CFA83BC74@gmail.com> <26426B4FF145B449A3D1FAC13C6B297833BBDB64@YYZEML703-CHM.china.huawei.com> To: Bill Gage X-Mailer: Apple Mail (2.3096.5) Archived-At: X-Mailman-Approved-At: Wed, 30 Dec 2015 05:00:44 -0800 Cc: "stackevo-discuss@iab.org" , Joe Touch , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Dec 2015 21:01:41 -0000 Ack, I certainly agree with that. Dino > On Dec 22, 2015, at 12:31 PM, Bill Gage wrote: >=20 > I didn't say that you couldn't use VPN technology to realise a slice, = I just said that a slice may encompass more that what one usually = associates with the term "VPN". A slice may pull in technologies = associated with SFC, NFV, TE, SDN, and a dozen other TLAs ;-) >=20 > Cheers ... >=20 >=20 >> -----Original Message----- >> From: Dino Farinacci [mailto:farinacci@gmail.com] >> Sent: Tuesday, December 22, 2015 2:41 PM >> Subject: Re: [5gangip] [Stackevo-discuss] 5G: It's the Network, = Stupid >>=20 >> I think your difference is subtle where in fact you a virtual network = and >> a VPN is one of the same thing. And you can use VPN technology (an = overlay >> with segmentation of hosts, routers, and functions) to satisfy the >> requirements below. >>=20 >> Dino >>=20 >>> On Dec 22, 2015, at 11:18 AM, Bill Gage = wrote: >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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). >>>=20 >>> Like it or not, "network slice" seems to the name that various >> organisations have given to this concept. >>>=20 >>> Cheers ... >>>=20 >>> [I tried to trim the receiver list just a little :-] >>>=20 >>>=20 >>>> -----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 >>>>=20 >>>> VPNs often have a lot of baggage, notably that an end system can = belong >>>> to only one at a time. >>>>=20 >>>> Slices have the baggage that a process can belong to only one slice = at >> a >>>> time. >>>>=20 >>>> 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. >>>>=20 >>>> Joe >>>>=20 >>>> 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. >>>>>=20 >>>>> Dino >>>>>=20 >>>>>> On Dec 21, 2015, at 3:55 PM, Joe Touch wrote: >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 12/17/2015 9:49 AM, Linda Dunbar wrote: >>>>>>> I strongly support the concept of network slicing for = Applications >> or >>>> IoT networks. >>>>>>=20 >>>>>> FWIW, I do not - in specific, I support the notion of per-service >>>>>> overlays, but would not call them "slices". >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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". >>>>>>=20 >>>>>> Joe >>>>>>=20 >>>=20 >=20 > _______________________________________________ > 5gangip mailing list > 5gangip@ietf.org > https://www.ietf.org/mailman/listinfo/5gangip From nobody Wed Dec 30 05:01:05 2015 Return-Path: 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 331AD1A874C; Wed, 23 Dec 2015 01:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 dANVvd4gUTuB; Wed, 23 Dec 2015 01:09:50 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 1EC3A1ACDFA; Wed, 23 Dec 2015 01:09:48 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id l133so142739761lfd.2; Wed, 23 Dec 2015 01:09:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=sP3o1WqV7FQQBFWHXbOlP8Ab9ZYoub0rWALvOUKMGIA=; b=qvvY83tM9a7tkWHqXmEafFO1IKdeWIzkAQ+wU1GwktcdBdDCZ5j0FxUELt/MkKfcpQ 7FDaRGvo8YwumS3mem19QmKxu4ewWYPk5LaDX3zlnd3xvMspYKAKtmKaq9JvB1GkJkQK CvyDTbXDTIQgy9WTAN5FhstbxT9JT6SOtgNeU+XJSGPtZ4ha+q0FjfZbZaELXlVRootZ P/pUJGM8EV/+LB6SH4LTFCAxamf4RqyR57EwqtF+hRXOsXmeHiT7FqF6ZqCir4FdGSnk T1N0VJucXN20tAMvcRuMjpiFy3IYtrFh2+2P98AmDFIo/0DSqwIrispjuzWWUBQb5p8Y 3w+Q== MIME-Version: 1.0 X-Received: by 10.25.86.9 with SMTP id k9mr10367527lfb.36.1450861786135; Wed, 23 Dec 2015 01:09:46 -0800 (PST) Sender: crowcroft@gmail.com Received: by 10.25.21.200 with HTTP; Wed, 23 Dec 2015 01:09:45 -0800 (PST) In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E20AF3BC87@szxeml559-mbs.china.huawei.com> References: <82AB329A76E2484D934BBCA77E9F5249A682F744@Hydra.office.hd> <4A95BA014132FF49AE685FAB4B9F17F657DB3A7F@dfweml701-chm> <56789156.2020704@isi.edu> <6EE22057-5EB9-4489-A50D-7B92DA2B96AF@gmail.com> <5679857D.9000602@isi.edu> <7AE6A4247B044C4ABE0A5B6BF427F8E20AF3BC87@szxeml559-mbs.china.huawei.com> Date: Wed, 23 Dec 2015 09:09:45 +0000 X-Google-Sender-Auth: -0za28PDJvinzAjjORt8s7_Yrcw Message-ID: From: Jon Crowcroft To: AshwoodsmithPeter Content-Type: multipart/alternative; boundary=001a1141245c61858a05278d156a Archived-At: X-Mailman-Approved-At: Wed, 30 Dec 2015 05:00:45 -0800 Cc: "icnrg@irtf.org" , Joe Touch , gaia , "stackevo-discuss@iab.org" , Linda Dunbar , "marnew@iab.org" , Dino Farinacci , "5gangip@ietf.org" <5gangip@ietf.org>, Nishanth Sastry , Dirk Kutscher , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 09:09:52 -0000 --001a1141245c61858a05278d156a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable very well said vpns are one (or 2) dimensions of a slice - but slices are cross layer resource pooling with isolation - many new(er) wireless nets need to share resources at antennae and symbol/code and forwarding/relaying levels to maximise capacity, and _then_ isolate pools of resource for given users for QoE/QoS etc reasons - you might subsume the name VPN, but I think that'd be over-reach.. actually designing a cooperative mimo system also has the interesting effect of making you revisit e2e security properly too (at the routing level, sharing resources kind of wreaks havoc with current BGP design/ practice too I believe:) if we assume the future smart city might have about the same number of internet end systems as the whole internet does today, and more providers (every home&autonomous-car/bike is a provider), there's a lot to challenge current architects, and get done before christmas On Tue, Dec 22, 2015 at 6:47 PM, AshwoodsmithPeter < Peter.AshwoodSmith@huawei.com> wrote: > 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 fac= t > be implementing several slices in the same process. Or same core. > > > > > 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=E2=80=99s relatively sim= ple. 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 netwo= rk > equipment that makes up the 5G network from Antennas through to core > processing. Thus > > Slice_i =3D 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 processi= ng > resources ( shared or unique in the CRAN), populate those processing > resources with the code (Numerology) that implements the RAT, then we nee= d > to allocate packet backhaul bandwidth in the CRAN or DC fabric, then assi= gn > 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 implementati= on > 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. > > > > Peter > > > > > > > --001a1141245c61858a05278d156a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
very well said=C2=A0

vpns are one (or 2= ) dimensions of a slice - but slices are cross layer resource pooling with = isolation -=C2=A0
many new(er) wireless nets need to share resour= ces at antennae and symbol/code and forwarding/relaying levels to maximise = capacity, and _then_ isolate pools of resource for given users for QoE/QoS = etc reasons - you might subsume the name VPN, but I think that'd be ove= r-reach..

actually designing a cooperative mimo sy= stem also has the interesting effect of making you revisit e2e security pro= perly too

(at the routing level, sharing resources= kind of wreaks havoc with current BGP design/ practice too I believe:)

if we assume the future smart city might have about t= he same number of internet end systems as the whole internet does today, an= d more providers (every home&autonomous-car/bike is a provider), there&= #39;s a lot to challenge current architects, and get done before christmas<= /div>

On Tue= , Dec 22, 2015 at 6:47 PM, AshwoodsmithPeter <Peter.AshwoodSm= ith@huawei.com> wrote:

Couple of comments from my perspective before disappearing for Xmas.<= /u>

=C2=A0

> Slices have the baggage that a process can belong to only one slice= at a time.

=C2=A0

Not always. A process which is implementing an air interface coul= d in fact be implementing several slices in the same process. Or same core.

=C2=A0

> Why does yet another term need to be defined for what has been tradi= tionally called a multi-tenant VPN.

=C2=A0

I believe a slice is much more than a VPN however VPN technologie= s are likely a component part of what a slice 'is'.

=C2=A0

Here is a definition I have found helpful:

=C2=A0

To define a slice we need to look at it from the perspective of both the= end devices (1) and the network (2) so:

=C2=A0

(1)=C2=A0=C2=A0 From the perspective of the end devices it=E2=80=99s rel= atively simple. A slice is a way to group end devices that share common QOS= /QOE and Administration/Geographic area etc.

=C2=A0

(2)=C2=A0=C2=A0 From the perspective of the network a slice is much more= complicated. Essentially a slice is a set of subsets of the all the networ= k equipment that makes up the 5G network from Antennas through to core proc= essing. Thus

Slice_i =3D=C2=A0=C2=A0 Subset of(All_Antennas) =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0U

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= subset of(All_Fronthaul) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0U

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Subse= t of(All CRAN fabric) =C2=A0=C2=A0=C2=A0=C2=A0U

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Subse= t of(All CRAN processing) U

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Subse= t of(ALL Numerologies) =C2=A0=C2=A0=C2=A0U

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Subse= t of(All DC fabric) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0U

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0Subse= t of(All DC processing)

=C2=A0

Where of course Subset(X) can contain all or none of the elements in X.<= u>

=C2=A0

So to bring up a slice we need to allocate antennas, configure the front= haul to the CRAN fabric, allocate the CRAN fabric, allocate processing reso= urces ( shared or unique in the CRAN), populate those processing resources = with the code (Numerology) that implements the RAT, then we need to allocate packet back= haul bandwidth in the CRAN or DC fabric, then assign compute resources (sha= red or stand alone for the packet core processing).

=C2=A0

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. Howev= er there are a number of other areas of interest to the implementation of a= slice that are well outside the scope of a VPN.

=C2=A0

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

=C2=A0

Hence the need for a new term.

=C2=A0

Peter

=C2=A0

=C2=A0

=C2=A0


--001a1141245c61858a05278d156a--