From nobody Mon Feb 6 04:33:31 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DF9129D32 for ; Mon, 6 Feb 2017 04:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 mE1SP6aAMCGF for ; Mon, 6 Feb 2017 04:33:17 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0114.outbound.protection.outlook.com [104.47.2.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4E6129D31 for ; Mon, 6 Feb 2017 04:33:17 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=a.galis@ucl.ac.uk; Received: from eduroam-int-dhcp-97-56-104.ucl.ac.uk (144.82.8.56) by AM5PR0101MB2337.eurprd01.prod.exchangelabs.com (10.169.240.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Mon, 6 Feb 2017 12:33:14 +0000 From: Alex Galis Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_BC90DEB2-9A01-4294-9323-E6E81692A571" MIME-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 6 Feb 2017 12:33:13 +0000 In-Reply-To: To: "Flinck, Hannu (Nokia - FI/Espoo)" References: X-Mailer: Apple Mail (2.3259) X-Originating-IP: [144.82.8.56] X-ClientProxiedBy: AMSPR01CA014.eurprd01.prod.exchangelabs.com (10.255.167.159) To AM5PR0101MB2337.eurprd01.prod.exchangelabs.com (10.169.240.139) X-MS-Office365-Filtering-Correlation-Id: 808c3b5f-4dd1-434c-55ed-08d44e8c5253 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0101MB2337; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0101MB2337; 3:VZHmV8ziQIhlSCKWbl6vqa2XBsdBj/+GbocW1rbrHlOEIx3X7sPwJrhjT7WOKHN4sdnaZfFWNcR8TBVkU2OKTuPgXHEuE5Mm4WaGD9kY0ceDRl6T5gEzpNvSEDhM9IXj0p6OVHVU1i5Qo+pTg6+zg8qGAXoghaIF0haJrOZ9CkiQJzR2YoNJeRxeI+DqKQJhr8QU6lzmw8isY6bFrX2/NIbNjhPbXl8hJyQ521gJeqXDcTA8d2LCoa7CwSPNnsaG2P3Te6RSSQ0swQnix5jhbw==; 25:McfoZgkeIs0OBQ3/cnYfFDq09ACxF/sxC48Dt/IhEXxgfSZVp/a0rlImtdHfCcBtDXd9DOFPyVATBuq/ULLIpZDhv37X93xF3P7H1F3cxBt/sjMxZqJmuBCqVnD15EtLSHROrD7uk0psMjtiO8CjaHQ/mGIt1d9vCP7f248LYsp15WbCAvgZ/2G5CKqjrpB0B3RUXyMFROWJSBowH3LD79W0Lnh9XIn2nZjHP4FSk0tf8tCG++oJUFnB1m51K4MtbfyN/x9Iid6MfuLJV3Q5xsnx9KUguvjSvlY7mPkFtwCNjC3T1w6SdxIC518JjoQjiuv+51dO7n9gQUU4U06FrhEw3ryfE4wEpOMtc3mwJ1uRuYbNXtE//bNm5qdQlP+JkHDzO95AXhE9dfXB8Vk5qWCL1P9fVNW9AkavAEFO5wCDKzLYEgxDRG7QQWCraoES1W/q1U2OEj9ojItU/ot41Q== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0101MB2337; 31:PzvrKQfhfu1EiBQnKl64RCJsL8puXBeDcboZmoTKFLsSr7EZYN7qvGB5FdEWQf/fW6roMIy7KRpexoUn7lGzy6fa0TkWBNjXfCoEpsR3PnctWfr/ZPXIX03eDaBKq50NVSTBXQ2ncRlD30ZSRuHtPKiJ87dhNEHVIJkpC3tFaVFQ5Y3sTr3C4+dWnJM6IS8sebl0wlvwAPL/roUvSdiy0BS8bMHJGEEmgVpQgEpjFLkCJ7zf4hVX02Lk2wRH1u2DqTgVNiqQOJJf88sVuHRPhFobuXxW3YuYkVCxEKyb96QdwhD4H5Fml34e3skOX+nM; 20:q2wRU5PHAzAGjxATL6mE7EDwruB7UhnjrTM0+Q0fvzNVlg6xqI2o8LM7VTotjHKPIlT/GEOD0bfd/OK6gLriUHpVUSDIb8QGXbXiWxTIQi07FLIexa3lAkbzD+zYpx7kPr3suDTWJQifFDMCteRRr7eMSCVsNNhN/LRSU3iy/xZURsT5/ulhEXQN45iznb/Eh6ngHQwbs/p1FG8PVsFMEKsKwcofFivMqdLYDxp2igHa2sDBnUGnKm0C4uUqHDwrTPwkSe+D4bT1QneGlt8eqdf5fNzx5No/QxUbFNL+gYBVjpTPtZd2Bj8ZKU5KIT2+TdwH2oPkRmGwnm63ikX68om2gm52mahgfh72gQyc4g+cgggPdNsXNmzYZ9he0ufX2tN0avIW17LTxqY3p6Xn7y82jebhFECZO70Jr8ffpdjy/2suEyKP7bRfondij4JZJ/m5ew1lLclu2YOPPcjsWWpy0HKiKrxi+acIg3Xs9oy8JoQBDFz0kjnzIQ4MjyC9 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(20170203043)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123558025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:AM5PR0101MB2337; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0101MB2337; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0101MB2337; 4:rBu6LFlb/sAPRw3M5jwBUYmO3ZUamVfFpU+q7MCCceHGiGbvckMDrXluuaGFJP0G61bLkRZzIwgMqVpLTG5APscOt9/oxSUjAY3KNVAtoK0215RBnkBf0SfmvnZU22RUPsxW5USyukZEN8yLoJHYRCT+EaDe6yJoJUoes3Xww7AMQSwTHZaNfFbeCVSHFxOpTT/YPRTa2EOLdM4dov98RAc9Qy3cIDtoYI2M8JryTCz/tKAQFKMXThiOQxqPGNmAGFPzlX/XNSZKb86Tez+FhPUIuuLpJENtaVCh31LVeylaq3Kcl1Dw5/N3yYk2I+XiDbzJzUT+hQXnrNC6NVFW4h6LZPKokwx0bQ5rHMVanDrDyxcRbQN+4IVLCLodHSh/a8qQaaDvTJ7/OM/C2QIPD6Ophml+EIMj+0cMvxiBilfqJ/GwjwTtMlNFV+1ywUedllrIQ+bipajH8iiBfkvsSrLnqBSwYzW6Iqhl7RhejjtSZKDLrw5R+JoFj3Ux24LNvagKHoBCeG7572Q1MvbTwgM1JAKVbCP6Tf3YTUZSuw+1ojVnIBS92PFGdS19xh5kBOOgP0jGbBhPaifA+fr+K/fevXUdHglm4RqJTDUbz9faDehYl0GXRkIqMmCc9OR/ X-Forefront-PRVS: 0210479ED8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7916002)(39450400003)(189002)(24454002)(199003)(105586002)(81166006)(81156014)(86362001)(42882006)(6916009)(2950100002)(8676002)(6306002)(33656002)(68736007)(53546003)(236005)(106356001)(6246003)(189998001)(50986999)(5660300001)(50226002)(92566002)(97736004)(76176999)(110136003)(74482002)(36756003)(7736002)(7906003)(25786008)(345774005)(53416004)(53936002)(6486002)(42186005)(84326002)(74826001)(512874002)(3846002)(606005)(83716003)(38730400001)(101416001)(229853002)(4326007)(66066001)(82746002)(2906002)(6116002)(57306001)(69556001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0101MB2337; H:eduroam-int-dhcp-97-56-104.ucl.ac.uk; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ucl.ac.uk does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM5PR0101MB2337; 23:JuE+bMqx6qErfeVJiGjF9B4CM69nitd/wQborbh?= =?us-ascii?Q?sTmJb2cQ9PZrDIXUsUejKzI2HwEIluD52VcXZj3NJg4NTf+zL/4KOmoWJ+Qe?= =?us-ascii?Q?k+3CL6piIUPd3MP95EPqIWZdSLoamrN6Q5vVCoS10FltmKHZ6oY8iCNube3r?= =?us-ascii?Q?7owuVfdQ6e1YtpII1EOvBmZkeMGRJwz6SPJmTJBt7qJhjwrOFV3adf3AGH0c?= =?us-ascii?Q?tHnHSWu5qXMiap6mzj1AK4CsBzls/FEFvZuoemlqh8yDZTX72EBV0YRqZKwP?= =?us-ascii?Q?jFD6vc8EtBpoj3XcliUvt35Tz9U9K2PyGaXG17hEGxEwyEAMcjpM4OSntPwx?= =?us-ascii?Q?V39TkR2nY6rLA3mM6DNRl+X0sqlhamC+iaUvUhc3GVYsS+hV0RVHiYgqZuI1?= =?us-ascii?Q?6xIZiqyHw9HaategDfXy6+nBgZEEzc1kiz92kqbqTxZAps/xiPMk2M9G81d7?= =?us-ascii?Q?YvkKakDpJ0nVVNwmcoX2hZ+qFDTMSYPIawAq/pY+TBLo7QldVSi++JLLoecv?= =?us-ascii?Q?o1qknnAln7n7kBa+l7XoCiKSU3Vi8RJlWIDO0MfphmT+5rBsO7BcZr36UM8N?= =?us-ascii?Q?q4TQS+QcAUQ0g9wzNBkRK+q42lyYXNyEIxT8SpgU8U380pAKO/+2AetL0AyU?= =?us-ascii?Q?VfRcjl7AlwjtxS47OnxskQ/9w9t1jdXLqAE4O5yt9oP0zi1Q8AMLjSwbok4x?= =?us-ascii?Q?06yk6ZD+EILL46/QfecxmNocXYOeJROEc2wEEFQI6vPKtrLWz98X7HCnb5gq?= =?us-ascii?Q?jLW4Y2kfFZLfuUzDDm98GKP3uFI7DZgptJVonqiVe11xeKFjcb8Ag1C2E5dE?= =?us-ascii?Q?qLNY2bMRrrscyXzlmcpwZiZgb2dG8fRIF6XlmEq6eqsP9ewVzJ6nDz7OFnDK?= =?us-ascii?Q?wFxhwYZnmaKk2It7pSTFgydYWYgDR3LIfKJj8wNlqDJ1OZz7BlRqoxy/Vthx?= =?us-ascii?Q?0nfU+mHyX23dhT3IU64Grcf9Cw82bQktuwBhf6pbO1wZu10YJzbVP45/L6A8?= =?us-ascii?Q?3KZj7Zpiki57HrnYuGZDHa1ZJ3TvVM/m3VZDVzf6esT3rKsiPEOu/Iab3Nic?= =?us-ascii?Q?r2qBJ7xqoMdefmt+1dB7rHi3hC91P1b7qP7S6KdG+aQYRVPs+QpJlsfai8e2?= =?us-ascii?Q?pd27G95joBwSIBqMVDphnKKafgeyOCAJ67ylthEaNSZPnDeVYd2i6prv95S0?= =?us-ascii?Q?cyUoKfNS1Az4l3BWAJbynqEr925pN/o58dFMXZKLkHlwLVqTJh3S28UQtfoj?= =?us-ascii?Q?Z6diPkEjkddJrt3aLKDFgvY8+eFJ4RVoL/Br7gP82RP08C/S1q/LMnnFb3Tk?= =?us-ascii?Q?6RHPnzAellLtpjQ23pf9gidw=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0101MB2337; 6:eVvL/hMj4wbNo7xQgdaGD6tC0xXWurqx9XlQRbME64pyjN8Boqc6H7J7R+ZEczn3Mak4PpAHmvPEPx3iL111CdV6F21VWqJ2j4zyg2pGlbcdB7SHuwuD9YES0gZ9cc3ghBYWuSb/UUj15oEp8pHxJuZOV6p776ZEjIXznae2KUOrWKAYcq2VKgnu6HOUYtiysyIxfEt2N5ZIpg6S3O1qom9/Iuvc4DcvGiwhKGHWFQq3aJqbi/o1chzIACwOL4JA/mxJ7qpNKOElzA2bLYLOrbooxsb1y7go2lWj32F0iH0LWz0CXBMYP2pwUDJw18+rycvfKpuGsSpa0c1VUgZq3Xa62C/kXV0ZVp9c/z7xLB28O4MinqEvg2+AZhABR5WweFJOqZwIep/hJK3US6yqUA==; 5:zX5487ylVYacwIC0u+VvwDOyuPDMxGvVvVXQCHFuXOI/0moCmA621h38myHcuetbQyHQaZLIt8jReXwT3mf6YBmCnTgWVYhRx26dQmM/QggkzlEfOBfArsaVrGCnoIrF0Yw9GxVgN7gih2fYYTbFXg==; 24:4JAVBw3zOnBTg2XhdF4H7HGd3KqxN6WUuKY5WEufiB1OoW0QJbdqNqD+K4dtW9/k1aYmlgWzs6mN2r0aIhUTgWiLi0U30Q/TT7GVQU/XYtw= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0101MB2337; 7:qeoBanzlM017Mr3GRNkA/2K2s65iZJ+MZEUH33zXXlv6phjykrbqD8oU9uywbyVyquzhCHrCYLBRU1t8a0lxIEhk52NBg90Nvy6MCMgto7oLSp40LgE11YF3CM8rCxUocCTL1sJRMRr2NUmNSY8ac84ZUX3yiPUGBWvf0qAjMXHiLnfMS3Xb+cAccia6BfHZdCOJkwutx7Nvytjfi1Xd9wqeg1Scyl24WkiSMISYblz/DKC+RS7jx7nTNGrzrfaJ/W4+75f2l0U10ut7DqQlbAA2rKzxFrpDUkYqq5bhOSXQrfVmOxf9CMeW1Idz8eE0BgbI1aSKvLOr4GXOYllvyr14ptcAwRyDcW+c59W9i1z7W+NZIm5PE26EDzKRxaEc1ZHn3Ey3FolgZS1VB75FvFhE2EPDf45zPQMq+Vn3ihSfMnDYpbNlzA1a5N4nBhW/oejNVhGYehu1+MdSLfwNRMydE/K2W8QXDJL7Y+QPVDDdFKkxyZ60v+KEY85eXEFHRO2KAj5FTWLLBN5XqdaoWA== X-OriginatorOrg: ucl.ac.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2017 12:33:14.8993 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0101MB2337 Archived-At: Cc: "netslices@ietf.org" Subject: Re: [Netslices] Problem statement comments X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 12:33:23 -0000 --Apple-Mail=_BC90DEB2-9A01-4294-9323-E6E81692A571 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Hannu Thank you for your interest in Network Slicing and for your valuable = comments and suggestions which are already actioned as part of the = update draft-01 - 'Network Slicing - Introductory Document and Revised = Problem Statement' planed for release this week. Best Regards Alex > On 20 Jan 2017, at 11:48, Flinck, Hannu (Nokia - FI/Espoo) = wrote: >=20 > Hello > =20 > Thank you for taking the initiative in consolidating the problem = statement for network slicing. > =20 > Here are my comments and questions to the draft. > =20 > The work area looks very wide even if you try to focus on network = slicing in transport networks. It looks to me that the use cases are = very close if not the same as what is being discussed in the 3GPP. = Should the draft focus only those use cases that are of relevance to = transport? And how much to use cases are then left? It seems that the = slicing is more of a service provisioning and management notion that = transport. =20 > =20 > Regarding the related and relevant IETF WGs you may also consider SFC = WG. One could claim that the SFC protocol defined there has most of what = is needed for slicing as well. > =20 > The bullet item of Slice Templates that ties together connectivity, = compute and storage seems to demonstrate that slicing and service = chaining will go hand-in-hand. Equally, it shows similarly to the use = case section that the scoping to transport slicing is not yet crisp = enough; i.e. what is the scope of the problem? What makes this as = transport issue? Isn=E2=80=99t this more of service problem than = transport resource issue. This would need more motivation. > =20 > What is exactly =E2=80=9Cfour-dimensional isolation=E2=80=9D? What are = the dimensions you are referring to? > =20 > Best regards > Hannu Flinck > =20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices = --Apple-Mail=_BC90DEB2-9A01-4294-9323-E6E81692A571 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Hi Hannu

Thank you for your interest in Network Slicing and for your = valuable comments and suggestions which are already actioned as part of = the update draft-01 - 'Network Slicing - Introductory Document and Revised Problem Statement'  planed = for release this week.

Best Regards
Alex


On = 20 Jan 2017, at 11:48, Flinck, Hannu (Nokia - FI/Espoo) <hannu.flinck@nokia-bell-labs.com> wrote:

Hello
 
Thank = you for taking the initiative in consolidating the problem statement for = network slicing.
 
Here = are my comments and questions to the draft.
 
The work area looks very wide = even if you try to focus on network slicing in transport networks. It = looks to me that the use cases are very close if not the same as what is = being discussed in the 3GPP. Should the draft focus only those use cases = that are of relevance to transport? And how much to use cases are then = left? It seems that the slicing is more of a service provisioning and = management notion that transport.  
 
Regarding the related and = relevant IETF WGs you may also consider SFC WG. One could claim that the = SFC protocol defined there has most of what is needed for slicing as = well.
 
The bullet item = of Slice Templates that ties together connectivity, compute and storage = seems to demonstrate that slicing and service chaining will go = hand-in-hand. Equally, it shows similarly to the use case section that = the scoping to transport slicing is not yet crisp enough; i.e. what is = the scope of the problem? What makes this as transport issue? Isn=E2=80=99= t this more of service problem than transport resource issue. This would = need more motivation.
 
What is exactly =E2=80=9Cfour-dimensional isolation=E2=80=9D? = What are the dimensions you are referring to?
 
Best regards
Hannu Flinck
 
_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

= --Apple-Mail=_BC90DEB2-9A01-4294-9323-E6E81692A571-- From nobody Mon Feb 6 04:44:28 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6C0129D3A for ; Mon, 6 Feb 2017 04:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 IejzccI2bN74 for ; Mon, 6 Feb 2017 04:44:24 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40123.outbound.protection.outlook.com [40.107.4.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32F3F129CE5 for ; Mon, 6 Feb 2017 04:44:24 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=a.galis@ucl.ac.uk; Received: from eduroam-int-dhcp-97-56-104.ucl.ac.uk (144.82.8.56) by AM5PR0101MB2339.eurprd01.prod.exchangelabs.com (10.169.240.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Mon, 6 Feb 2017 12:44:21 +0000 From: Alex Galis Message-ID: <13275D2C-6EEA-4186-BF3C-30DAE9588D22@ucl.ac.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_CBF8329D-E7F1-448C-83EE-7D8879246F7F" MIME-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 6 Feb 2017 12:44:20 +0000 In-Reply-To: To: "Smith, Kevin, (R&D) Vodafone Group" References: X-Mailer: Apple Mail (2.3259) X-Originating-IP: [144.82.8.56] X-ClientProxiedBy: AMXPR01CA002.eurprd01.prod.exchangelabs.com (10.255.173.147) To AM5PR0101MB2339.eurprd01.prod.exchangelabs.com (10.169.240.141) X-MS-Office365-Filtering-Correlation-Id: 43c140c8-4e8c-4c61-474d-08d44e8ddfc2 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:AM5PR0101MB2339; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0101MB2339; 3:SEpeqigZEpVc7PPQwPOcreRg1Yb0uid4cnDN0lzmMLkFxKd5V2LosWv2Wk0/hqixPHtgXzvpgxs0wF1OF/4VBsy/NEVt24UmoX6BJjg571dd1tgrIt3Fk3JjplodOvqtaD/6O9yQqqN9/w/P8BA48IBdxHk2PX9r/tJdqIDWYeSvFlBKCu924+RZ1vncm+wiyVWUNF73Okv1E2lVbnYjggAtGbnfImFfejME2MLafgCsTyzXxRC/e+7gxCsz/ah5B0QlBgqSNEHkZqdeOfPW7w==; 25:8lAOHpJaaWiTMxGOa90Fd15MNpSskP9HuwJbxaUqOB+bv1I0atqdLXqxdJYc0LHkKPhudJ79/8g7f7stxmXDCCr3ueyO8cexh+9Tkte2lIA7YvM03unsSNuNL6s104WPK4fxy4T/qiQGSsg5zQOXgCq2jpLeUdAKAfuPplUq1wTyk2g0lpgRT4PDCYAFhrIN4YnHYMOom7vMxY89fYP7h6/Ppppy8ghq11TCrWX5O+Rnwm+PSPc14q0ZVgNMXQ4GqLYFbmsQwk/i5OovcsI4A94wxrWTauM4q/VCXBzLZwLfMAxUVGhAE25jeFSG2cNB+gVUNFYE3CLtmNF9PAl1427r0fVZ/j+yWiOiQLMNBwZjZ2ex9zBpbGsCSjtCeCIJlS8KYq3gaqy1pQzy8mpqPULFBb8A5UjDlYtRD6RVMELhxQ6kEDoxT2K8hKtyZngkCJ1lG7nNOT1nLafAgO479w== X-Microsoft-Exchange-Diagnostics: 1; AM5PR0101MB2339; 31:mfWix0MzIEJhFrfeSfTB5bzCWCXYfQTX3Mubi5Cc0sv+rwITc1bC/77VsXuTg2GyqMLHvDay6cxQQMV0EdpqF7pli1BGR6dpZmxUCAyj92kSYsUntNQa9tiQHULOMEq5+YrwyjpBVZQFkrKsgZbJwIYNb4pLC0vtDzpe2zXSDdF1kgs42OEX8aOgxxf3vjSPEN8+uCwR2sqGfw/8a07ShfgGlz7u4Ae3MxzXp6gzXm09yeLCYp5sniwFLVgKjVQeQ68wfpppK4VSMSBUf2bpJg==; 20:eSDjetD19007BY9mVVT8aAXLEmWiqyI/UzIVc8+EhlmKTglqRzxq+aVtg++ncYVDJkxjhyNstMUiPLMESGfNax4HB6y/YeaS8DhWEVLBYS7wi4ruKk9syIn2Ui/shTkHht99VdG/RL5TaWfuJHmTJATdNiYPHzzZd03Y2XjGqgdlOhGkj28yGqrNI1cFPmNCZavpkuFjeqFk+RPfldzjxsYlMWaEcFsG2/a1dj5IUiuiU8Udsfma3+nFnRmGQf/P/7KdUnu+vKQr7aoGR0svqOWilUqlJj+L28z67j6BsLycFyI/HTAA3w3JO4uXE5jr/alDyItDFQQEnRIGGLOUSs22p6GUPKoRD9TZmwdjz71dtPdpSAZkyKLshLao4xwxrxFk5wigzHSCF+gypGI54EKaPHKNZJxePn384IWB63yJBThH24zNJxcHDonkaZa4vb3/CYkmrI0kZZZCvfYTxBk5thDigBHu2j5+tmS/Qax0Ed6eD5IeSP7aDA8pxpe8 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(67444318432085); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(20170203043)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6072148); SRVR:AM5PR0101MB2339; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0101MB2339; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0101MB2339; 4:k1OMohrzzx1qRXa6pzQVzDMf/jbedkQDswB/wwBqzKwJMYD3obPTkCMUwboICiCVm+/fAZArKRVIQtsHuBX5dOrRqxtXcqkophZLSayDVGW1XNh4vqCQkKKKkZ3eL8j8uHZSAffnUgB0Rj2SpF7nYURmFMyuAeCpCNb92VNcaOz5rAUB8FiLLR9WXvrpn/sN/puMLSQKyB4run/Tb36TSPBo065eskHRDmuKFyhZq6aSc8eWNdRLAQKNvTT8uVYI0PMpq+uGp1udyByXR4J2NpyE4waa3Q9Svxcirxgnj5zEag4NUIBdLyrsDZUjV5se7TPfwLHJpDtxTgvniY2UVK5w1klMyQIAHtSJN5x8dxVxGAZZSEwCFvxds3l3l8Z1RpcCRn1Mrhub0eiQatM0HYXfWtrnV2FvRZqf6QLJ/eHLj0r7esDXEaX5f9LH/n31W2bsSruoe37AHbTnDcRgAgSzgnsHbWFBIpV3UbTsuDIKCi0uQhsD07iOCHVQVqAeTlsq+Zi04+rPyMty1KdiEqdh9SBKbpp0qhMIvBkB8Y4k2jCkxWKh0t6x7S3B0xaJcpQTbDp1MlE9odsG9DxJQ61YfMY1d8YgvR1x9/RQhJlPqJ1Ok9EDAAeITAHXuWCxKO/ReGsc7A/Yqp7L2Ng1A3aAZrn9a8KzlMAg6y1uGqEBpx4QVsFW2Nm/hpR+Fukb X-Forefront-PRVS: 0210479ED8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7916002)(39450400003)(24454002)(189002)(199003)(38730400001)(83716003)(229853002)(57306001)(7736002)(7906003)(8656002)(6306002)(512874002)(236005)(6486002)(2950100002)(5660300001)(42882006)(6916009)(110136003)(86362001)(50986999)(84326002)(76176999)(82746002)(66066001)(25786008)(606005)(74826001)(69556001)(189998001)(97736004)(50226002)(106356001)(105586002)(81166006)(81156014)(3846002)(8676002)(6116002)(53546003)(2906002)(53936002)(92566002)(74482002)(36756003)(6246003)(345774005)(33656002)(101416001)(53416004)(42186005)(68736007)(4326007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0101MB2339; H:eduroam-int-dhcp-97-56-104.ucl.ac.uk; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ucl.ac.uk does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; AM5PR0101MB2339; 23:DiGZIdp+gfWnbO22ew//Jnw6vxYZviidYcZ+Z/p?= =?us-ascii?Q?dOh3rKT2r+6HAxKGp8k9vH2ATp4K5r4MxdInOoeMUo6qX+sqJC+cLBc7JdPw?= =?us-ascii?Q?hA6TOjOpI+UCNUX/T6ZeEu+ZR/CAo6+ugWmfCrQOfa53WOLWkHeE0XXXZIUm?= =?us-ascii?Q?wVMLPBXUIOQN/AIhg8l5H9J+DGLkyGqDKBnrAA9VNsufsNkGqN6SY5VBlzTF?= =?us-ascii?Q?gmRJysiKI1za+MhbO7/wSXb0wB6+nRhQEy9N/xWBb79K5tHQjFd+6cEeG+B5?= =?us-ascii?Q?NEMDRYQYNvqHqM/wb/dT+bFQMWCKUlbycoaaLESs1zllG7lIcsMdSbid6qDB?= =?us-ascii?Q?VsoQXTQTRFdAzYWC+nD2RIIy7NMdCr56f8SHukjUPFWteqGfFBUATv6lXXHl?= =?us-ascii?Q?pB3vUvgw0zsjCUJsdY7Rph4orJVSKEB9KuqInBJiuAZQ0XK/3d9U/F6sLEDT?= =?us-ascii?Q?x3/nVAJsPiKSBUnBoS1X/rwLmyOg9Y4C5caHScaNEgRdC7MKm4R9YA1ksh0H?= =?us-ascii?Q?m5Ah3lBrNEhalulE41j+/jbSh4t3h5G/S0CSpXOiQgdFjGqP6r+dxl7Z2hl1?= =?us-ascii?Q?oXgpu30Pc51dYb1VdrRH11J8bh+SJfmZGccP2BCr8oFfL1cXbMWz0augI491?= =?us-ascii?Q?y4feyEkmxk0d4+Vwi0OcL4AlD3CI1zDLCf5ri0LhfqcWzfxD5UosdqIL6K71?= =?us-ascii?Q?fUOLNpFU2Fk/1xXAuW7ytd/U405mfeqkTYl9/aezmT1Ub2GC+j8WqfSZQ2So?= =?us-ascii?Q?5LSt8KjMg371KrfEECAAxuYve4LVEQo+rfp5yu6MvOSGEMhnT5eVhxcFK5S5?= =?us-ascii?Q?xqi/kwOAeLMpE9Eo0r8AgakadTqOcJkn6c1iN5sDv2mLJLaUqNpUya1h9Rj2?= =?us-ascii?Q?ddhsDW12TAZhZITlWqQ2cYNRxeItPc3Ak3qxu/ID64GikUepXLMZtfhfK/J2?= =?us-ascii?Q?UIzV7HJLwg0T8I5VR8NUeaCJ5dI14HwyOHJIrjGkb15wv9pcqtnS4ve3XSF6?= =?us-ascii?Q?2Us7Z0bdghHZLBYde8TO4C9DKxfvGInZuD62L5C5F6p36sD/lijM37mh80MV?= =?us-ascii?Q?BVfmYwcjQfr8Xxs+tQ8kezlINccoXLU2I2G4lhJoxz4B5bO6BJVqH63K+y9a?= =?us-ascii?Q?fq00pRxpWFZ61VGGyD4omO59WkIltv2LgNHVjlOOWoseWS3vobxoDScbUfBC?= =?us-ascii?Q?fxr11+xdShgIcZJYeYuVBLTiulcbKhwDrn5lEpmMIh/QmDZFdyC5jzMcFUKl?= =?us-ascii?Q?CMkEMKP7yGUCoiKm5wDTtBH5t95q+yPvCGMCMGwpKCXUYErCmeLpT60FiIj2?= =?us-ascii?Q?eBlzXVZGw/KLq5hLtGpbTd7C+/AWdjw4ZExn9+CG6qyDX?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0101MB2339; 6:/jtDuSbQWqYz1D8hjCl2ERtqqGTxxbvlXArjnoXLeWoHsruW29aSh0RdPhNVTC4RFLWrcQIkkK9w/AZWBmo9mr2qcB9uX/bxucWESiGfG4eElzFy+GhFL0TlHSit0t0kn/A7g6PAUzIiVT7y4fiHojwAEtv+S8TygzQOf02RwvZ8CGagqNQ1bvjD5LxdqK4hniGlUUF8UYM2uaoytrv7h/Xd+ixh2edm7QE5UDnh368S+fRLd0qM/B3oncXDHiEYVvFMGnUYIfmF/RSYUnALhLrk8xWJglltOB0rvYgs6/C9QC9QRCrLYx+gu2FkNHHCkNl9rWB93eb/QZS7hwAI3lHbRA91V/Gv6trQ+2rCosd/d2c6onb/nrzSgjPlU28789gajfu+I55IrVr/xmogdA==; 5:+FVIzkwdMOyBX/JXBniFq9z/onUQO/NbX/txdS1F+dFducY3nxvmp5Rp67t/7nKMzUDvp+U8xtq0LIw6dYA6gQIPwrhFTo9AmdySe+96lgWMoqQTTHIQEoZ5KgE6Azd7VMiC5h+/aYul8wyBTNAZRQ==; 24:Y9RcmlccpiTJJK7NMKI4/+bB0PGyBHvGjurQ9wlhCNcGEpkVs7MjHtbxCjxZ1+eXMjqpWEWJcif1hZyTa7DRGhNTOcIh2buq6Gq4W1uMUPc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; AM5PR0101MB2339; 7:ITd0FvjJPCBSOm9Be2fs9nhjomJ+Y01IzRzZ1K0BIA59s85Q+B+N62NUEBZJqIi91W0TyzohT6w8EJJYhs6njLDK1/vA0znYj676Kvf1JSh0G7BaXX36+2rgvyQ5NkfEmqXqarRpZJlt9Hew7JUup0Rqi5jpb50IXoT/quphPcNzziRwZI0J5x293dImARJrumrlhkwm1vS0sYEmsZRf1rg7o507bgAL4wfbDFhqf9neNRkj4E1PUbi7/rQHLPSwHAzt9wy/UXZu7cxGxa25Tj3YfjE4TW+pwiOt0BgmjR0Oj1Wh37VseHT/x4TOG29oCD04VgYqCneBDvfvJ+2VqOZ0iyCgEc8gFGhB0mObfDtZ/1+ck1ysSK1NmznTEJwEwzVCxme7/3gtAX4TxMGqPn30OWlHPd+M8Nq9dLrkIzd7S+w0gotklD3JwntiduuJBIp4yQr2kI/QR71BdVhVnp11eBcq0PoboiIcI0JVXg3TpQZnuhAxsk0XrlZrHaJba/f5NFqlYiLGPtVrV24Kow== X-OriginatorOrg: ucl.ac.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2017 12:44:21.5547 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0101MB2339 Archived-At: Cc: "netslices@ietf.org" Subject: Re: [Netslices] Problem statement comments/ Kevin X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 12:44:26 -0000 --Apple-Mail=_CBF8329D-E7F1-448C-83EE-7D8879246F7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Kevin Thank you for your interest in Network Slicing and for your valuable = comments and suggestions which are already actioned as part of the = update draft-01 - 'Network Slicing - Introductory Document and Revised = Problem Statement' planed for release this week. Best Regards Alex =20 > On 17 Jan 2017, at 11:40, Smith, Kevin, (R&D) Vodafone Group = > wrote: >=20 > Hello Jie and Stewart, > =20 > Thanks for drafting the problem statement, it=E2=80=99s good to see = interest in network slicing outside of mobile standards. In fact, I = think here is an opportunity to think of slicing as a network model, = rather than purely a mobile model. > =20 > Network slicing should be considered a network technology, allowing = for the allocation and release of network resources according to the = context and contention policy. Since many operators operate PLMN, fixed = fibre broadband, WiFi, Narrow Band IoT etc. networks then the benefits = of slicing can include handoff between access networks according to = resource contention or other factors (such as mobility). So IMO the = problem scope is broader than just 3GPP mobile access and core. I=E2=80=99= m not familiar with network slicing discussions in non-mobile fora, so = the problem statement may in fact stimulate those discussions. > =20 > Another comment is that the various service characteristics are = mentioned throughout the draft - and you make the point that different = services require different treatment - but I suggest that needs calling = out in the introduction as it=E2=80=99s so important. I have heard the = misconception that 5G can simply be realised by building out capacity, = to meet all service requirements in a =E2=80=98one (bigger) size fits = all=E2=80=99 approach. So strengthening the point that requirements for = latency, guaranteed delivery and pacing, durability (e.g. waking up an = IoT node twice a year), mobility, coverage, throughput all differ across = service types and industries, is crucial upfront. > =20 > 2.5. Management considerations: without opening a Net Neutrality = can-o=E2=80=99-worms, it may be worth noting that the intention of = slicing is to tailor treatment towards the service type and delivery = context, not tailoring towards a particular customer or content = provider. > =20 > And a couple of nits ;) > The goal of 5G -> A goal of 5G > s/bares further consideration/bears further consideration > =20 > All best, > Kevin > Vodafone R&D > =20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices = --Apple-Mail=_CBF8329D-E7F1-448C-83EE-7D8879246F7F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi Kevin

Thank you for your interest in Network = Slicing and for your valuable comments and suggestions which are already = actioned as part of the update draft-01 - 'Network Slicing - = Introductory Document and Revised Problem Statement'  planed = for release this week.

Best Regards
Alex  


On 17 = Jan 2017, at 11:40, Smith, Kevin, (R&D) Vodafone Group <Kevin.Smith@vodafone.com> wrote:

Hello Jie and Stewart,
 
Thanks = for drafting the problem statement, it=E2=80=99s good to see interest in = network slicing outside of mobile standards. In fact, I think here is an = opportunity to think of slicing as a network model, rather than purely a = mobile model.
 
Network slicing should be considered a network technology, = allowing for the allocation and release of network resources according = to the context and contention policy. Since many operators operate PLMN, = fixed fibre broadband, WiFi, Narrow Band IoT etc. networks then the = benefits of slicing can include handoff between access networks = according to resource contention or other factors (such as mobility). So = IMO the problem scope is broader than just 3GPP mobile access and core. = I=E2=80=99m not familiar with network slicing discussions in non-mobile = fora, so the problem statement may in fact stimulate those = discussions.
 
Another comment is that the various service characteristics = are mentioned throughout the draft - and you make the point that = different services require different treatment - but I suggest that = needs calling out in the introduction as it=E2=80=99s so important. I = have heard the misconception that 5G can simply be realised by building = out capacity, to meet all service requirements in a  =E2=80=98one = (bigger) size fits all=E2=80=99 approach. So strengthening the point = that requirements for latency, guaranteed delivery and pacing, = durability (e.g. waking up an IoT node twice a year), mobility, = coverage, throughput all differ across service types and industries, is = crucial upfront.
 
2.5. Management considerations: without opening a Net = Neutrality can-o=E2=80=99-worms, it may be worth noting that the = intention of slicing is to tailor treatment towards the service type and = delivery context, not tailoring towards a particular customer or content = provider.
 
And a couple of nits ;)
The goal of 5G -> A goal of 5G
s/bares = further consideration/bears further consideration
 
All = best,
Kevin
Vodafone = R&D
 
_______________________________________________
Netslices mailing = list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

= --Apple-Mail=_CBF8329D-E7F1-448C-83EE-7D8879246F7F-- From nobody Mon Feb 6 05:25:31 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C989129D4E for ; Mon, 6 Feb 2017 05:25:31 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.onmicrosoft.com 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 NMMjltbk3vSQ for ; Mon, 6 Feb 2017 05:25:29 -0800 (PST) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id 52D5C120724 for ; Mon, 6 Feb 2017 05:25:29 -0800 (PST) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5AC466FC015; Mon, 6 Feb 2017 08:25:28 -0500 (EST) Received: from imshyb02.MITRE.ORG (imshyb02.mitre.org [129.83.29.3]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 472B56FC011; Mon, 6 Feb 2017 08:25:28 -0500 (EST) Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 6 Feb 2017 08:25:27 -0500 Received: from gcc01-dm2-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Mon, 6 Feb 2017 08:25:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.onmicrosoft.com; s=selector1-mitre-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HXqgDqPmig53KTMywqwJ94jixzQmpwvBgR8wK3ryJok=; b=hCtWNpi2hy/uGn0RBp5y5LSe7ZTqkkFgMmrPTuMVsbg0HF62Nzy7T9FoaqR5uu3B0wf1yPijDO2yWXmdwXtKgHFPYlh7w5jqRzXodfC8pkPT00u/cPoOvs9PhrYufLQzl6rYjsc9IHBILpEeduZK+pF+3Xlh1QTa/lk/Aq/d4Y0= Received: from CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) by CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Mon, 6 Feb 2017 13:25:26 +0000 Received: from CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) by CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) with mapi id 15.01.0888.025; Mon, 6 Feb 2017 13:25:25 +0000 From: "Natale, Bob" To: Alex Galis , Network Slices Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvrXaDeoOCGArUagAhaMsA6e+KFcERXw Date: Mon, 6 Feb 2017 13:25:25 +0000 Message-ID: References: In-Reply-To: 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=RNATALE@mitre.org; x-originating-ip: [128.29.43.2] x-ms-office365-filtering-correlation-id: 2e50b8e6-b8aa-44c9-8cce-08d44e939c90 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR09MB0922; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0922; 7:msX9umoqsF9SG0gAuyHj1xuO48g8Owww0i1L5wBIrvP2smGDaCOqHrwpxT+a3cf5L9LSUK+d+kqYJVgcndB65XUuamzJeGmX6PJZZkj0cwVYK+x+7A6+QlXBr/4kel292JoiIVNXm5OPjaghHqoFyMxdhhPQpGLgBfLJ0vvjgJFteYuhmlKrieEnbp6ArVMMlHPFUrCYbF2JlNKW+oAJLWY+d49R4IafjxJIXsOyybDgr5XDA4rXCpsWkID1a7LNOqZvb9WAxXGmooRht78zeNxtYwjD4PTNH0kR5RD1kPDi7d6cJbF0YttdebTwIIbE+ajRTI8bN0wXQpe0IoY8p8pCdOTFouLFjYN2w2BEkDrSWHrp4skqoxtyht4Z1jtXsINImCx1Tr0wgfU+QS2iuSDY3F7MD5+kAuBpwHYG51cscGBxI4+6/Ob9eCE0PeY4Z5gxm9nbCFskhoUlPyO/k0bSz7allvIc0tLyh4+Pn4tVoP2ne+4YXgNHOodcqs1CWS5SP8B64zi1sSPxxweVlQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513)(57025502571588)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(20170203043)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123558025)(20161123564025)(20161123555025)(6072148); SRVR:CY1PR09MB0922; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0922; x-forefront-prvs: 0210479ED8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39850400002)(39450400003)(39840400002)(39410400002)(377454003)(189002)(504964003)(199003)(101416001)(8676002)(2900100001)(99286003)(106116001)(66066001)(92566002)(229853002)(6246003)(3280700002)(8936002)(33656002)(76176999)(9686003)(2906002)(81166006)(81156014)(55016002)(77096006)(31430400001)(236005)(53936002)(4326007)(6506006)(50986999)(54906002)(105586002)(3660700001)(606005)(6436002)(106356001)(25786008)(345774005)(5660300001)(86362001)(68736007)(189998001)(7906003)(74316002)(7736002)(19609705001)(39060400001)(2950100002)(5001770100001)(122556002)(54356999)(38730400001)(9326002)(6306002)(790700001)(97736004)(3846002)(7696004)(6116002)(102836003)(54896002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR09MB0922; H:CY1PR09MB0922.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0922B9B2C7037C6AB43DA808A8400CY1PR09MB0922namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2017 13:25:25.8639 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0922 X-OriginatorOrg: mitre.org Archived-At: Cc: "Dongjie \(Jimmy\)" , "Kiran.Makhijani" , Stewart Bryant Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 13:25:31 -0000 --_000_CY1PR09MB0922B9B2C7037C6AB43DA808A8400CY1PR09MB0922namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alex, I just have two basic questions - more like "requests" - for now: - How does a network "slice" differ from all established forms of network v= irtualization (VLANs, VPNs, SDPs, etc.? - Do we really need the term "softwarization" (and its various derivatives)= ... isn't that just a confounding way of saying "virtualization" ... as in= "softwarizing and separating logical network components from the underlying physical network resource= s" ... isn't that latter part what we commonly call virtualization and, if = so, how does "softwarization" differ from it? >From a lurker, BobN From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Alex Galis Sent: Friday, January 20, 2017 3:54 AM To: Network Slices Cc: Dongjie (Jimmy) ; Stewart Bryant ; Alex Galis ; Kiran.Makhijani Subject: Re: [Netslices] Network Slicing - Introductory Document and Revise= d Problem Statement 20th January 2017 Dear All Re: Network Slicing - Introductory Document and Revised Problem Statement https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-an= d-ps-00.txt Thank you for your expressed interest in the Network Slicing. One of the action from the Network Slicing side meeting at IETF 97 of 15th = Nov 2016 was to consolidate all suggestions and comments received into an u= nified initial revised problem statement and work plan which would be the b= asis of a BoF at IETF 98 or IETF99. Such an introductory document is ready = for your review and it is enclosed as a draft. Would you be so kind as to provide your feedback, comments, contributions a= nd work interest with the view of further progressing this draft for un upd= ate and presentation at IETF 98. Thank you in advance, Best Regards Alex, Jie, Kiran and Stewart Network Slicing - Introductory Document and Revised Problem Statement Abstract: This document represents an introduction to the motivation and Network Slicing problems and work ares. It represents an initial revision of Network Slicing problem statement derived from the analysis of the technical gaps in IETF protocols ecosystem. It complements and it bring together the isolated efforts being carried out in several IETF working groups to achieve certain aspects of network slice functions and operations. _______________________________________________ Netslices mailing list Netslices@ietf.org https://www.ietf.org/mailman/listinfo/netslices --_000_CY1PR09MB0922B9B2C7037C6AB43DA808A8400CY1PR09MB0922namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alex,

 

I just have two basic questions – more like R= 20;requests” – for now:

 

- How does a network “slice” differ from a= ll established forms of network virtualization (VLANs, VPNs, SDPs, etc.?

 

- Do we really need the term “softwarizationR= 21; (and its various derivatives) … isn’t that just a confoundi= ng way of saying “virtualization” … as in “softwari= zing and separating

   logical network components from the under= lying physical network resources” … isn’t that latter par= t what we commonly call virtualization and, if so, how does “softwari= zation” differ from it?

 

From a lurker,

BobN

 

From: Netslices [mailto:netslices-bo= unces@ietf.org] On Behalf Of Alex Galis
Sent: Friday, January 20, 2017 3:54 AM
To: Network Slices <netslices@ietf.org>
Cc: Dongjie (Jimmy) <jie.dong@huawei.com>; Stewart Bryant <= stewart.bryant@gmail.com>; Alex Galis <a.galis@ucl.ac.uk>; Kiran.M= akhijani <Kiran.Makhijani@huawei.com>
Subject: Re: [Netslices] Network Slicing - Introductory Document and= Revised Problem Statement

 

 



20th January 2017


Dear All

 
Re:  Network Slicing - Introductory Document and Revised Problem State= ment

         https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-and-ps-00.t= xt

 

Thank you for your expressed interest in the Network Slicing.

One of the action from the Network Slicing side meeting at IETF 97 of 15th = Nov 2016 was to consolidate all suggestions and comments received into an u= nified initial revised problem statement and work plan which would be the b= asis of a BoF at IETF 98 or IETF99. Such an introductory document is ready for your review and it is enclosed = as a draft.
 
Would you be so kind as to provide your feedback, comments, contributions a= nd work interest with the view of further progressing this draft for un upd= ate and presentation at IETF 98.
 
Thank you in advance,
Best Regards
Alex, Jie, Kiran and Stewart
 
 
 
Network Slicing - Introductory Document and Revised Problem Statement
 
Abstract:
  This document represents an introduction to the motivation and
  Network Slicing problems and work ares. It represents an initial
  revision of Network Slicing problem statement derived from the
  analysis of the technical gaps in IETF protocols ecosystem. It
  complements and it bring together the isolated efforts being carried=
  out in several IETF working groups to achieve certain aspects of
  network slice functions and operations.

___________________= ____________________________
Netslices mailing list
Netslices@ietf.org
https://www.iet= f.org/mailman/listinfo/netslices

--_000_CY1PR09MB0922B9B2C7037C6AB43DA808A8400CY1PR09MB0922namp_-- From nobody Mon Feb 6 05:52:30 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4D5129570 for ; Mon, 6 Feb 2017 05:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 JQRFvUWnybBK for ; Mon, 6 Feb 2017 05:52:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12F72129526 for ; Mon, 6 Feb 2017 05:52:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFX69082; Mon, 06 Feb 2017 13:52:23 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 6 Feb 2017 13:51:55 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 6 Feb 2017 21:51:52 +0800 From: "Dongjie (Jimmy)" To: "netslices@ietf.org" Thread-Topic: Discussion about network slicing in IETF Thread-Index: AQHSgF/eQQU/hdFeu02poLyUO2CZPw== Date: Mon, 6 Feb 2017 13:53:04 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9279357A0F2@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.109.41] 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.0A090203.58987F99.003A, 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: d747000a33dc5ae2c1a576e9490c62ee Archived-At: Subject: [Netslices] Discussion about network slicing in IETF X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 13:52:29 -0000 Dear all,=20 According to some early investigations, the topic network slicing would cro= ss several WGs, even multiple Areas in IETF, and there are some existing an= d ongoing works in IETF related to network slicing, such as the various VPN= technologies, the ongoing ACTN work in TEAS WG, the work on deterministic = network in DETNET WG, the work on autonomic management in ANIMA WG, etc. Th= rough the discussion on this mailing list, we'd like to understand if there= are gaps in meeting the network slicing requirements, and if needed, to co= mbine the existing and ongoing works, together with potential protocol enha= ncements or new protocols to achieve network slicing of the mobile transpor= t network.=20 In order to have better understanding of the gaps in transport network slic= ing, we may start with a few questions:=20 1. To what extent can the requirements of network slicing in data plane be = addressed by existing IETF technologies such as VPNs (and VPN like technolo= gies)? We note in asking this that in some cases VPNs may need to be enhanc= ed by some deterministic technology such as that being investigated in the = DETNET WG. And to what extent do the control planes of existing technologies satisfy t= he needs of network slicing? Note that in some 5G use cases the customized = or dedicated control plane may be needed for some of the network slices, wh= ile in some other cases the control plane may be shared between slices. 2. Does ACTN completely satisfy the abstraction of Network Slices (NS) to t= he operators or the customers who instantiate, monitor and manage an NS thr= ough its lifecycle, including dynamically changing a slice to account for t= he varying needs during its lifecycle from creation to disposal, is there a= ny additional mechanism also required? 3. How do we characterize the determinism requirement of NS? To what extent= is the determinism hard and to what extent is it soft, i.e. what are the a= bsolute requirements, and what requirements can be met by some form of prob= ability mask? Does the design being proposed by the DETNET design team (whi= ch is still in stealth mode) address all of this? 4. To what extent does the network need to open the control and management = of the network slices to the third parties? And to what extent can this be = addressed by existing technologies, such as PCE, Segment Routing, SFC and N= etconf? Your insightful thoughts are much appreciated. Best regards, Jie From nobody Mon Feb 6 13:58:58 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7D7129530 for ; Mon, 6 Feb 2017 13:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 dyuIoljuETD8 for ; Mon, 6 Feb 2017 13:58:55 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1DED129528 for ; Mon, 6 Feb 2017 13:58:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFY24829; Mon, 06 Feb 2017 21:58:51 +0000 (GMT) Received: from YYZEML702-CHM.china.huawei.com (10.218.33.72) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 6 Feb 2017 21:58:50 +0000 Received: from YYZEML701-CHM.china.huawei.com ([169.254.4.116]) by YYZEML702-CHM.china.huawei.com ([169.254.6.152]) with mapi id 14.03.0301.000; Mon, 6 Feb 2017 16:57:17 -0500 From: AshwoodsmithPeter To: "Natale, Bob" , Alex Galis , Network Slices Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvrXaDeoOCGArUagAhaMsA6e+KFcERXwgACKloA= Date: Mon, 6 Feb 2017 21:57:17 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.61.40] Content-Type: multipart/alternative; boundary="_000_7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304YYZEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5898F19C.0093, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.116, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f6548cccac4325e6ded5c70cc1387d4d Archived-At: Cc: "Dongjie \(Jimmy\)" , Stewart Bryant , "Kiran.Makhijani" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 21:58:57 -0000 --_000_7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304YYZEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Bob, Here are a few points that I find useful to understand Slicing and VPN's. 1. A "slice" in the context of 5G is essentially an end to end set of = resources which make up a fully functional wireless network drawn from larg= er pool of end to end resources. 2. A slice is therefore a superset of the capabilities of an L0,L1,L3 = or L3 VPN. 3. An L2VPN or L3VPN is likely a useful connectivity model for the con= trol and user plane data paths for the obvious reasons and DETNET type capa= bilities are of interest for stricter QOS guarantees. For even stricter gua= rantees ACTN etc. and L0/L1 control is required. 4. I hate the term "softwarization" also, but essentially it's being u= sed to describe a programmatic interface to each of the end to end sets of = resources to allow them to be allocated/linked/deallocated/grown/shrunk etc= . and is therefore more than just virtualization but of course covers virtu= alization. I gave a short presentation on this at 5gandIp meeting last year which you = may find useful, I'll be happy to send it to you directly or I suspect it's= on an IETF server somewhere. Cheers, Peter From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Natale, Bo= b Sent: Monday, February 06, 2017 8:25 AM To: Alex Galis ; Network Slices Cc: Dongjie (Jimmy) ; Kiran.Makhijani ; Stewart Bryant Subject: Re: [Netslices] Network Slicing - Introductory Document and Revise= d Problem Statement Hi Alex, I just have two basic questions - more like "requests" - for now: - How does a network "slice" differ from all established forms of network v= irtualization (VLANs, VPNs, SDPs, etc.? - Do we really need the term "softwarization" (and its various derivatives)= ... isn't that just a confounding way of saying "virtualization" ... as in= "softwarizing and separating logical network components from the underlying physical network resource= s" ... isn't that latter part what we commonly call virtualization and, if = so, how does "softwarization" differ from it? >From a lurker, BobN From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Alex Galis Sent: Friday, January 20, 2017 3:54 AM To: Network Slices > Cc: Dongjie (Jimmy) >; Stew= art Bryant >; Ale= x Galis >; Kiran.Makhijani > Subject: Re: [Netslices] Network Slicing - Introductory Document and Revise= d Problem Statement 20th January 2017 Dear All Re: Network Slicing - Introductory Document and Revised Problem Statement https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-an= d-ps-00.txt Thank you for your expressed interest in the Network Slicing. One of the action from the Network Slicing side meeting at IETF 97 of 15th = Nov 2016 was to consolidate all suggestions and comments received into an u= nified initial revised problem statement and work plan which would be the b= asis of a BoF at IETF 98 or IETF99. Such an introductory document is ready = for your review and it is enclosed as a draft. Would you be so kind as to provide your feedback, comments, contributions a= nd work interest with the view of further progressing this draft for un upd= ate and presentation at IETF 98. Thank you in advance, Best Regards Alex, Jie, Kiran and Stewart Network Slicing - Introductory Document and Revised Problem Statement Abstract: This document represents an introduction to the motivation and Network Slicing problems and work ares. It represents an initial revision of Network Slicing problem statement derived from the analysis of the technical gaps in IETF protocols ecosystem. It complements and it bring together the isolated efforts being carried out in several IETF working groups to achieve certain aspects of network slice functions and operations. _______________________________________________ Netslices mailing list Netslices@ietf.org https://www.ietf.org/mailman/listinfo/netslices --_000_7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304YYZEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey Bob,

 

Here are a few points that I find use= ful to understand Slicing and VPN’s.

 

1.   = ;   A “slice” in the = context of 5G is essentially an end to end set of resources which make up a= fully functional wireless network drawn from larger pool of end to end resources.

 

2.   = ;   A slice is therefore a superset of the capabilities of an L0,L1,L3 or L3 VPN.

 

3.   = ;   An L2VPN or L3VPN is likely a= useful connectivity model for the control and user plane data paths for th= e obvious reasons and DETNET type capabilities are of interest for stricter QOS guarantees. For even stricter guarantees = ACTN etc. and L0/L1 control is required.

 

4.   = ;   I hate the term “softwa= rization” also, but essentially it’s being used to describe a p= rogrammatic interface to each of the end to end sets of resources to allow them to be allocated/linked/deallocated/grown/shrunk etc. and is = therefore more than just virtualization but of course covers virtualization= .

 

I gave a short presentation on this a= t 5gandIp meeting last year which you may find useful, I’ll be happy = to send it to you directly or I suspect it’s on an IETF server somewhere.

 

Cheers,

 

Peter

 

 

From: Netslices [mailto:netslices-bo= unces@ietf.org] On Behalf Of Natale, Bob
Sent: Monday, February 06, 2017 8:25 AM
To: Alex Galis <a.galis@ucl.ac.uk>; Network Slices <netslic= es@ietf.org>
Cc: Dongjie (Jimmy) <jie.dong@huawei.com>; Kiran.Makhijani <= ;Kiran.Makhijani@huawei.com>; Stewart Bryant <stewart.bryant@gmail.co= m>
Subject: Re: [Netslices] Network Slicing - Introductory Document and= Revised Problem Statement

 

Hi Alex,

 

I just have two basic questions – more like R= 20;requests” – for now:

 

- How does a network “slice” differ from a= ll established forms of network virtualization (VLANs, VPNs, SDPs, etc.?

 

- Do we really need the term “softwarizationR= 21; (and its various derivatives) … isn’t that just a confoundi= ng way of saying “virtualization” … as in “softwari= zing and separating

   logical network components from the under= lying physical network resources” … isn’t that latter par= t what we commonly call virtualization and, if so, how does “softwari= zation” differ from it?

 

From a lurker,

BobN

 

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Alex Galis
Sent: Friday, January 20, 2017 3:54 AM
To: Network Slices <netslic= es@ietf.org>
Cc: Dongjie (Jimmy) <jie.d= ong@huawei.com>; Stewart Bryant <stewart.bryant@gmail.com>; Alex Galis <a.galis@ucl.ac.uk>; Kiran.Makhijani <Kiran.Makhijani@huawei.c= om>
Subject: Re: [Netslices] Network Slicing - Introductory Document and= Revised Problem Statement

 

 



20th January 2017


Dear All

 
Re:  Network Slicing - Introductory Document and Revised Problem State= ment

         https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-and-ps-00.t= xt

 

Thank you for your expressed interest in the Network Slicing.

One of the action from the Network Slicing side meeting at IETF 97 of 15th = Nov 2016 was to consolidate all suggestions and comments received into an u= nified initial revised problem statement and work plan which would be the b= asis of a BoF at IETF 98 or IETF99. Such an introductory document is ready for your review and it is enclosed = as a draft.
 
Would you be so kind as to provide your feedback, comments, contributions a= nd work interest with the view of further progressing this draft for un upd= ate and presentation at IETF 98.
 
Thank you in advance,
Best Regards
Alex, Jie, Kiran and Stewart
 
 
 
Network Slicing - Introductory Document and Revised Problem Statement
 
Abstract:
  This document represents an introduction to the motivation and
  Network Slicing problems and work ares. It represents an initial
  revision of Network Slicing problem statement derived from the
  analysis of the technical gaps in IETF protocols ecosystem. It
  complements and it bring together the isolated efforts being carried=
  out in several IETF working groups to achieve certain aspects of
  network slice functions and operations.

___________________= ____________________________
Netslices mailing list
Netslices@ietf.org
https://www.iet= f.org/mailman/listinfo/netslices

--_000_7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304YYZEML701CHMchi_-- From nobody Mon Feb 6 15:13:49 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21FBE129692 for ; Mon, 6 Feb 2017 15:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.222 X-Spam-Level: X-Spam-Status: No, score=-3.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 29XcJC2qr0Ji for ; Mon, 6 Feb 2017 15:13:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E98129699 for ; Mon, 6 Feb 2017 15:13:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAD08150; Mon, 06 Feb 2017 23:13:39 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 6 Feb 2017 23:13:38 +0000 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.133]) by SJCEML701-CHM.china.huawei.com ([169.254.3.132]) with mapi id 14.03.0235.001; Mon, 6 Feb 2017 15:11:58 -0800 From: Leeyoung To: "Dongjie (Jimmy)" , "netslices@ietf.org" Thread-Topic: Discussion about network slicing in IETF Thread-Index: AQHSgF/eQQU/hdFeu02poLyUO2CZP6Fcmbug Date: Mon, 6 Feb 2017 23:11:55 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172B295440@SJCEML702-CHM.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9279357A0F2@NKGEML515-MBX.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C9279357A0F2@NKGEML515-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.165] 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.0A020203.58990324.00A3, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.133, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0a4ee341736e61d72576a2cf8218006e Archived-At: Subject: Re: [Netslices] Discussion about network slicing in IETF X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 23:13:46 -0000 Hi Jim, I can speak for ACTN. Please see inline for my comment. Thanks. Young -----Original Message----- From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Dongjie (J= immy) Sent: Monday, February 06, 2017 7:53 AM To: netslices@ietf.org Subject: [Netslices] Discussion about network slicing in IETF Dear all,=20 According to some early investigations, the topic network slicing would cro= ss several WGs, even multiple Areas in IETF, and there are some existing an= d ongoing works in IETF related to network slicing, such as the various VPN= technologies, the ongoing ACTN work in TEAS WG, the work on deterministic = network in DETNET WG, the work on autonomic management in ANIMA WG, etc. Th= rough the discussion on this mailing list, we'd like to understand if there= are gaps in meeting the network slicing requirements, and if needed, to co= mbine the existing and ongoing works, together with potential protocol enha= ncements or new protocols to achieve network slicing of the mobile transpor= t network.=20 In order to have better understanding of the gaps in transport network slic= ing, we may start with a few questions:=20 1. To what extent can the requirements of network slicing in data plane be = addressed by existing IETF technologies such as VPNs (and VPN like technolo= gies)? We note in asking this that in some cases VPNs may need to be enhanc= ed by some deterministic technology such as that being investigated in the = DETNET WG. And to what extent do the control planes of existing technologies satisfy t= he needs of network slicing? Note that in some 5G use cases the customized = or dedicated control plane may be needed for some of the network slices, wh= ile in some other cases the control plane may be shared between slices. 2. Does ACTN completely satisfy the abstraction of Network Slices (NS) to t= he operators or the customers who instantiate, monitor and manage an NS thr= ough its lifecycle, including dynamically changing a slice to account for t= he varying needs during its lifecycle from creation to disposal, is there a= ny additional mechanism also required? YOUNG>> I think so. ACTN allows VN slice to be created/monitored/modified/d= eleted dynamically supporting CRUD operations. I just want to make a point = that the abstraction of network slices in ACTN is only for network resource= s but not for compute or storage. CSO (Cross-Stratum Optimzation) work addr= ess how to combine compute and storage slices with ACTN's network slices. M= y understanding for the scope of network slicing is primarily network resou= rce slicing, correct?=20 3. How do we characterize the determinism requirement of NS? To what extent= is the determinism hard and to what extent is it soft, i.e. what are the a= bsolute requirements, and what requirements can be met by some form of prob= ability mask? Does the design being proposed by the DETNET design team (whi= ch is still in stealth mode) address all of this? 4. To what extent does the network need to open the control and management = of the network slices to the third parties? And to what extent can this be = addressed by existing technologies, such as PCE, Segment Routing, SFC and N= etconf? Your insightful thoughts are much appreciated. Best regards, Jie _______________________________________________ Netslices mailing list Netslices@ietf.org https://www.ietf.org/mailman/listinfo/netslices From nobody Mon Feb 6 15:52:59 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFC4F12952D for ; Mon, 6 Feb 2017 15:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=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 v8Z-2qjafuhw for ; Mon, 6 Feb 2017 15:52:56 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 473F31293F5 for ; Mon, 6 Feb 2017 15:52:56 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.124.247.135; From: "Susan Hares" To: "'Dongjie \(Jimmy\)'" , References: <76CD132C3ADEF848BD84D028D243C9279357A0F2@NKGEML515-MBX.china.huawei.com> In-Reply-To: <76CD132C3ADEF848BD84D028D243C9279357A0F2@NKGEML515-MBX.china.huawei.com> Date: Mon, 6 Feb 2017 18:48:29 -0500 Message-ID: <013401d280d3$85138730$8f3a9590$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQM7zWXVz8sV9bdk/QJMOg1zMF7y+56KCoGQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Netslices] Discussion about network slicing in IETF X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 23:52:57 -0000 Jie: The opening of the control plane to 3rd party reporting on deterministic information with the NETCONF/NETMOD improved notification, pub/sub, ephemeral state (from I2RS), and revised data stores. The pub/sub and improved NETCONF notification has a number of knobs that can allow increasing or decreasing the level at which events are monitored. One of the questions about network slicing is whether network slicing needs to define additional BGP, PCE, RIB, and filter-base RIBS yang data models or augmentation to existing data models. Sue Hares -----Original Message----- From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Dongjie (Jimmy) Sent: Monday, February 6, 2017 8:53 AM To: netslices@ietf.org Subject: [Netslices] Discussion about network slicing in IETF Dear all, According to some early investigations, the topic network slicing would cross several WGs, even multiple Areas in IETF, and there are some existing and ongoing works in IETF related to network slicing, such as the various VPN technologies, the ongoing ACTN work in TEAS WG, the work on deterministic network in DETNET WG, the work on autonomic management in ANIMA WG, etc. Through the discussion on this mailing list, we'd like to understand if there are gaps in meeting the network slicing requirements, and if needed, to combine the existing and ongoing works, together with potential protocol enhancements or new protocols to achieve network slicing of the mobile transport network. In order to have better understanding of the gaps in transport network slicing, we may start with a few questions: 1. To what extent can the requirements of network slicing in data plane be addressed by existing IETF technologies such as VPNs (and VPN like technologies)? We note in asking this that in some cases VPNs may need to be enhanced by some deterministic technology such as that being investigated in the DETNET WG. And to what extent do the control planes of existing technologies satisfy the needs of network slicing? Note that in some 5G use cases the customized or dedicated control plane may be needed for some of the network slices, while in some other cases the control plane may be shared between slices. 2. Does ACTN completely satisfy the abstraction of Network Slices (NS) to the operators or the customers who instantiate, monitor and manage an NS through its lifecycle, including dynamically changing a slice to account for the varying needs during its lifecycle from creation to disposal, is there any additional mechanism also required? 3. How do we characterize the determinism requirement of NS? To what extent is the determinism hard and to what extent is it soft, i.e. what are the absolute requirements, and what requirements can be met by some form of probability mask? Does the design being proposed by the DETNET design team (which is still in stealth mode) address all of this? 4. To what extent does the network need to open the control and management of the network slices to the third parties? And to what extent can this be addressed by existing technologies, such as PCE, Segment Routing, SFC and Netconf? Your insightful thoughts are much appreciated. Best regards, Jie _______________________________________________ Netslices mailing list Netslices@ietf.org https://www.ietf.org/mailman/listinfo/netslices From nobody Mon Feb 6 15:56:28 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930A11294E6 for ; Mon, 6 Feb 2017 15:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=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 YdbRjk6Hpv8U for ; Mon, 6 Feb 2017 15:56:26 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 D12981293F5 for ; Mon, 6 Feb 2017 15:56:25 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=50.124.247.135; From: "Susan Hares" To: "'AshwoodsmithPeter'" , "'Natale, Bob'" , "'Alex Galis'" , "'Network Slices'" References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> Date: Mon, 6 Feb 2017 18:51:50 -0500 Message-ID: <013901d280d3$fcf6c050$f6e440f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013A_01D280AA.14235060" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDRcT5+JTP9KmmueWKg00wrBgSOBwIe2CqdAeW45emjPqAsYA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: "'Dongjie \(Jimmy\)'" , "'Kiran.Makhijani'" , 'Stewart Bryant' Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 23:56:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_013A_01D280AA.14235060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Peter: On #3 on your list - do you believe all the L2VPN and L3VPN features are needed? Or can you suggest a smalls subset of these features that will be needed to support network slicing. On #4 - how is this programmatic interface to the control plane different than the work we are doing in I2RS. I would appreciate a copy of your short presentation on this matter. Sue Hares From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of AshwoodsmithPeter Sent: Monday, February 6, 2017 4:57 PM To: Natale, Bob; Alex Galis; Network Slices Cc: Dongjie (Jimmy); Stewart Bryant; Kiran.Makhijani Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Hey Bob, Here are a few points that I find useful to understand Slicing and VPN's. 1. A "slice" in the context of 5G is essentially an end to end set of resources which make up a fully functional wireless network drawn from larger pool of end to end resources. 2. A slice is therefore a superset of the capabilities of an L0,L1,L3 or L3 VPN. 3. An L2VPN or L3VPN is likely a useful connectivity model for the control and user plane data paths for the obvious reasons and DETNET type capabilities are of interest for stricter QOS guarantees. For even stricter guarantees ACTN etc. and L0/L1 control is required. 4. I hate the term "softwarization" also, but essentially it's being used to describe a programmatic interface to each of the end to end sets of resources to allow them to be allocated/linked/deallocated/grown/shrunk etc. and is therefore more than just virtualization but of course covers virtualization. I gave a short presentation on this at 5gandIp meeting last year which you may find useful, I'll be happy to send it to you directly or I suspect it's on an IETF server somewhere. Cheers, Peter From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Natale, Bob Sent: Monday, February 06, 2017 8:25 AM To: Alex Galis ; Network Slices Cc: Dongjie (Jimmy) ; Kiran.Makhijani ; Stewart Bryant Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Hi Alex, I just have two basic questions - more like "requests" - for now: - How does a network "slice" differ from all established forms of network virtualization (VLANs, VPNs, SDPs, etc.? - Do we really need the term "softwarization" (and its various derivatives) . isn't that just a confounding way of saying "virtualization" . as in "softwarizing and separating logical network components from the underlying physical network resources" . isn't that latter part what we commonly call virtualization and, if so, how does "softwarization" differ from it? >From a lurker, BobN From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Alex Galis Sent: Friday, January 20, 2017 3:54 AM To: Network Slices Cc: Dongjie (Jimmy) ; Stewart Bryant ; Alex Galis ; Kiran.Makhijani Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement 20th January 2017 Dear All Re: Network Slicing - Introductory Document and Revised Problem Statement https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-and-ps-00.tx t Thank you for your expressed interest in the Network Slicing. One of the action from the Network Slicing side meeting at IETF 97 of 15th Nov 2016 was to consolidate all suggestions and comments received into an unified initial revised problem statement and work plan which would be the basis of a BoF at IETF 98 or IETF99. Such an introductory document is ready for your review and it is enclosed as a draft. Would you be so kind as to provide your feedback, comments, contributions and work interest with the view of further progressing this draft for un update and presentation at IETF 98. Thank you in advance, Best Regards Alex, Jie, Kiran and Stewart Network Slicing - Introductory Document and Revised Problem Statement Abstract: This document represents an introduction to the motivation and Network Slicing problems and work ares. It represents an initial revision of Network Slicing problem statement derived from the analysis of the technical gaps in IETF protocols ecosystem. It complements and it bring together the isolated efforts being carried out in several IETF working groups to achieve certain aspects of network slice functions and operations. _______________________________________________ Netslices mailing list Netslices@ietf.org https://www.ietf.org/mailman/listinfo/netslices ------=_NextPart_000_013A_01D280AA.14235060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Peter:

 

On #3 on your list – do you believe all the L2VPN and L3VPN = features are needed?  Or can you suggest a smalls subset of these = features that will be needed to support network slicing. =

 

On #4 – how is this programmatic interface to the control plane = different than the work we are doing in I2RS.  =

 

I would appreciate a copy of your short presentation on this matter. =

 

Sue Hares

 

From:= = Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of = AshwoodsmithPeter
Sent: Monday, February 6, 2017 4:57 = PM
To: Natale, Bob; Alex Galis; Network Slices
Cc: = Dongjie (Jimmy); Stewart Bryant; Kiran.Makhijani
Subject: Re: = [Netslices] Network Slicing - Introductory Document and Revised Problem = Statement

 

Hey Bob,

 

Here are a few points that I find useful to understand Slicing and = VPN’s.

 

1.      = A “slice” in the context of 5G is essentially an end to = end set of resources which make up a fully functional wireless network = drawn from larger pool of end to end resources.

 

2.      = A slice is therefore a superset of the capabilities of an = L0,L1,L3 or L3 VPN.

 

3.      = An L2VPN or L3VPN is likely a useful connectivity model for the = control and user plane data paths for the obvious reasons and DETNET = type capabilities are of interest for stricter QOS guarantees. For even = stricter guarantees ACTN etc. and L0/L1 control is = required.

 

4.      = I hate the term “softwarization” also, but essentially = it’s being used to describe a programmatic interface to each of = the end to end sets of resources to allow them to be = allocated/linked/deallocated/grown/shrunk etc. and is therefore more = than just virtualization but of course covers = virtualization.

 

I gave a short presentation on this at 5gandIp meeting last year = which you may find useful, I’ll be happy to send it to you = directly or I suspect it’s on an IETF server = somewhere.

 

Cheers,

 

Peter

 

 

From: Netslices = [mailto:netslices-bounces@ietf.= org] On Behalf Of Natale, Bob
Sent: Monday, = February 06, 2017 8:25 AM
To: Alex Galis <a.galis@ucl.ac.uk>; Network = Slices <netslices@ietf.org>
Cc: Dongjie (Jimmy) <jie.dong@huawei.com>; = Kiran.Makhijani <Kiran.Makhijani@huawei.com= >; Stewart Bryant <stewart.bryant@gmail.com>=
Subject: Re: [Netslices] Network Slicing - Introductory = Document and Revised Problem = Statement

 

Hi = Alex,

 

I just have = two basic questions – more like “requests” – for = now:

 

- How does a = network “slice” differ from all established forms of network = virtualization (VLANs, VPNs, SDPs, etc.?

 

- Do we = really need the term “softwarization” (and its various = derivatives) … isn’t that just a confounding way of saying = “virtualization” … as in “softwarizing and = separating

   = logical network components from the underlying physical network = resources” … isn’t that latter part what we commonly = call virtualization and, if so, how does “softwarization” = differ from it?

 

From a = lurker,

BobN

 

From: Netslices = [mailto:netslices-bounces@ietf.= org] On Behalf Of Alex Galis
Sent: Friday, January = 20, 2017 3:54 AM
To: Network Slices <netslices@ietf.org>
Cc: Dongjie (Jimmy) <jie.dong@huawei.com>; Stewart = Bryant <stewart.bryant@gmail.com>= ; Alex Galis <a.galis@ucl.ac.uk>; = Kiran.Makhijani <Kiran.Makhijani@huawei.com= >
Subject: Re: [Netslices] Network Slicing - Introductory = Document and Revised Problem = Statement

 

 

<= div>



20th = January 2017


Dear All

 
Re:  Network = Slicing - Introductory Document and Revised Problem = Statement

         https://www.ietf.org/internet-drafts/draft-gdmb-netslices-i= ntro-and-ps-00.txt

 

Thank you for your expressed = interest in the Network Slicing.

One of the action from the = Network Slicing side meeting at IETF 97 of 15th Nov 2016 was to = consolidate all suggestions and comments received into an unified = initial revised problem statement and work plan which would be the basis = of a BoF at IETF 98 or IETF99. Such an introductory document is ready = for your review and it is enclosed as a draft.
 
Would you be = so kind as to provide your feedback, comments, contributions and work = interest with the view of further progressing this draft for un update = and presentation at IETF 98.
 
Thank you in advance,
Best = Regards
Alex, Jie, Kiran and = Stewart
 
 
 
Network Slicing - Introductory = Document and Revised Problem Statement
 
Abstract:
  = This document represents an introduction to the motivation and
  = Network Slicing problems and work ares. It represents an = initial
  revision of Network Slicing problem statement derived = from the
  analysis of the technical gaps in IETF protocols = ecosystem. It
  complements and it bring together the isolated = efforts being carried
  out in several IETF working groups to = achieve certain aspects of
  network slice functions and = operations.

______________________________________________= _
Netslices mailing list
Netslices@ietf.org
https://www.ietf= .org/mailman/listinfo/netslices

------=_NextPart_000_013A_01D280AA.14235060-- From nobody Mon Feb 6 16:32:00 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF4412956E for ; Mon, 6 Feb 2017 16:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 2zYrPJPQX3P4 for ; Mon, 6 Feb 2017 16:31:58 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id D621712947A for ; Mon, 6 Feb 2017 16:31:57 -0800 (PST) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id v170Vjqd047536; Tue, 7 Feb 2017 09:31:45 +0900 (JST) Received: from mail2.nict.go.jp (mail2.nict.go.jp [133.243.18.15]) by gw1.nict.go.jp with ESMTP id v170Vi0K047523; Tue, 7 Feb 2017 09:31:44 +0900 (JST) Received: from spectre (unknown [133.243.115.68]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.nict.go.jp (NICT Mail Spool Server2) with ESMTPS id AE0529A51; Tue, 7 Feb 2017 09:31:44 +0900 (JST) Date: Tue, 7 Feb 2017 09:31:45 +0900 From: Pedro Martinez-Julia To: AshwoodsmithPeter Message-ID: <20170207003145.GN12800@spectre> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Virus-Scanned: clamav-milter 0.98.7 at zenith1 X-Virus-Status: Clean Archived-At: Cc: "Dongjie \(Jimmy\)" , Network Slices , "Kiran.Makhijani" , "Natale, Bob" , Stewart Bryant , Alex Galis Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 00:31:59 -0000 Dear al, Regarding the relation between current virtualization, network slicing, and softwarization, I insist what I had already mentioned it in our F2F meeting @ IETF 97, that we have some clashes. For instance: - A slice is, by definition, "a portion" of something. There is no E2E implied on it, but there can be specifications including it (e.g. E2E slices). - I identify two different but complementary points of view in relation to "network slices": 1) The result of partitioning a set of (physical/virtual) resources to get the aforementioned "portions". This is the operator/owner point of view and is intrinsically related to the embedding and management. 2) The set of resource portions assigned to a singe entity. As it is being currently used, for instance, by PlanetLab, a "slice" means a portion of the whole infrastructure and not just a portion of a single resource. - The relation between virtualiation and slicing is that the latter can be implemented by the former. However, slices could be instantiated by other means, so the separate definitions are not superfluous. Also, it is not fair to link VPN capabilities and slices. A VPN can be embedded on a slice, but it is not the only purpose of the latter, so such link of capabilities could end up in some misunderstandings. - Softwarization is "the act of converting hard-ware to soft-ware". It is not an interface or a mechanism but a method and process. As with slicing, virtualization can be used to implement such "process", but it is not limited to it. In fact, it could be the other way around, so using softwarized systems to implement virtual systems. For instance, an OpenFlow Switch is "a sofwarized switch" and its main relation to virtualization is that the flexibility provided by such softwarization process can be used to "slice" a physical switch and provide isolated virtual switches (using some tool like FlowVisor). This shows a way of link the three terms (slicing, softwarization, and virtualization). Contrasting these and previous explanations, and considering all of them as valid from different perspectives, I conclude that there are still many nuances that need to be clarified and maybe some misconceptions on current concepts that should be eradicated. Therefore, I insist in the need to make some collaborative document (wiki, Google Doc, etc.) to try to reach a common and agreed set of definitions. Regards, Pedro -- Pedro Martinez-Julia Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: pedro@nict.go.jp --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** From nobody Mon Feb 6 17:10:02 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58FE129558 for ; Mon, 6 Feb 2017 17:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 G4H1UXFGLDL5 for ; Mon, 6 Feb 2017 17:09:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DED83129503 for ; Mon, 6 Feb 2017 17:09:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFY39861; Tue, 07 Feb 2017 01:09:55 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Feb 2017 01:09:54 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML703-CHM.china.huawei.com ([169.254.5.69]) with mapi id 14.03.0235.001; Mon, 6 Feb 2017 17:09:23 -0800 From: "Kiran.Makhijani" To: Leeyoung , "Dongjie (Jimmy)" , "netslices@ietf.org" Thread-Topic: [Netslices] Discussion about network slicing in IETF Thread-Index: AQHSgN7QQQU/hdFeu02poLyUO2CZPw== Date: Tue, 7 Feb 2017 01:09:22 +0000 Message-ID: <143B3310-E8F2-4FF0-A481-89188C800B9F@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.36] Content-Type: text/plain; charset="utf-8" Content-ID: <0E64B78BAA2AB34B81D1E858C5181B6D@huawei.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58991E64.0013, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1ee52cd0859fc99459b040cea595bb89 Archived-At: Subject: Re: [Netslices] Discussion about network slicing in IETF X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 01:10:01 -0000 SGVsbG8gWW91bmcsIA0KVG8gbWUsIGl0IGhhcyBhIGJyb2FkZXIgc2NvcGU7IHRvIGxvb2sgYXQg b3ZlcmFsbCByZXNvdXJjZSBlZmZpY2llbmN5LCBhZ2lsaXR5IGFuZCBpbmRlcGVuZGVudCAzcmQg cGFydHkgc2xpY2UgY29udHJvbCBvdmVyIGRpZmZlcmVudCBuZXR3b3JrIHNlZ21lbnRzIGFuZCBu ZXR3b3JrIGZ1bmN0aW9ucy4gV2l0aCBsaW1pdGVkIGtub3dsZWRnZSBvbiBBQ1ROLCBteSBhc3N1 bXB0aW9uIGlzIHRoYXQgaXQgaXMgYSBjZW50cmFsaXplZCBjb250cm9sbGVyIHNvbHV0aW9uIHdp dGggbWFpbiBnb2FsIHRvIGNvbXB1dGUgY29uc3RyYWludHMgYmFzZWQgcGF0aHMgb3ZlciB3aGF0 J3MgYWJzdHJhY3RlZCBmcm9tIHZhcmlvdXMgY29udHJvbGxlcnMuIE5ldFNsaWNlcyBzaG91bGRu 4oCZdCBiaW5kIHRvIGNlbnRyYWwsIGhpZXJhcmNoaWNhbCBvciBkaXN0cmlidXRlZCBhcHByb2Fj aCAoYXQgbGVhc3QgYXQgdGhlIGJlZ2lubmluZykuICBJbiB0aGF0IHNlbnNlLCBsZXTigJlzIGxv b2sgYXQgc2xpY2VzIGZyb20gYWxsIGFzcGVjdHMgZGF0YSwgY29udHJvbCwgbWFuYWdlbWVudCBh bmQgc2VydmljZXMgaW4gYSBnZW5lcmljIGZhc2hpb24uDQoNCkkgYWdyZWUgd2l0aCBQZWRyb+KA mXMgZW1haWwgc3VnZ2VzdGlvbiB0aGF0IGEgY291cGxlIG9mIGNvbGxhYm9yYXRpdmUgbGl2ZSBk b2N1bWVudHMgd2lsbCBiZSBnb29kIHN0YXJ0aW5nIHBvaW50Lg0KDQpSZWdhcmRzDQpLaXJhbiAN Cg0KT24gMi82LzE3LCAzOjExIFBNLCAiTmV0c2xpY2VzIG9uIGJlaGFsZiBvZiBMZWV5b3VuZyIg PG5ldHNsaWNlcy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsZWV5b3VuZ0BodWF3ZWku Y29tPiB3cm90ZToNCg0KICAgIEhpIEppbSwNCiAgICANCiAgICBJIGNhbiBzcGVhayBmb3IgQUNU Ti4gUGxlYXNlIHNlZSBpbmxpbmUgZm9yIG15IGNvbW1lbnQuDQogICAgDQogICAgVGhhbmtzLg0K ICAgIFlvdW5nDQogICAgDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9t OiBOZXRzbGljZXMgW21haWx0bzpuZXRzbGljZXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIERvbmdqaWUgKEppbW15KQ0KICAgIFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMDYsIDIwMTcg Nzo1MyBBTQ0KICAgIFRvOiBuZXRzbGljZXNAaWV0Zi5vcmcNCiAgICBTdWJqZWN0OiBbTmV0c2xp Y2VzXSBEaXNjdXNzaW9uIGFib3V0IG5ldHdvcmsgc2xpY2luZyBpbiBJRVRGDQogICAgDQogICAg RGVhciBhbGwsIA0KICAgIA0KICAgIEFjY29yZGluZyB0byBzb21lIGVhcmx5IGludmVzdGlnYXRp b25zLCB0aGUgdG9waWMgbmV0d29yayBzbGljaW5nIHdvdWxkIGNyb3NzIHNldmVyYWwgV0dzLCBl dmVuIG11bHRpcGxlIEFyZWFzIGluIElFVEYsIGFuZCB0aGVyZSBhcmUgc29tZSBleGlzdGluZyBh bmQgb25nb2luZyB3b3JrcyBpbiBJRVRGIHJlbGF0ZWQgdG8gbmV0d29yayBzbGljaW5nLCBzdWNo IGFzIHRoZSB2YXJpb3VzIFZQTiB0ZWNobm9sb2dpZXMsIHRoZSBvbmdvaW5nIEFDVE4gd29yayBp biBURUFTIFdHLCB0aGUgd29yayBvbiBkZXRlcm1pbmlzdGljIG5ldHdvcmsgaW4gREVUTkVUIFdH LCB0aGUgd29yayBvbiBhdXRvbm9taWMgbWFuYWdlbWVudCBpbiBBTklNQSBXRywgZXRjLiBUaHJv dWdoIHRoZSBkaXNjdXNzaW9uIG9uIHRoaXMgbWFpbGluZyBsaXN0LCB3ZSdkIGxpa2UgdG8gdW5k ZXJzdGFuZCBpZiB0aGVyZSBhcmUgZ2FwcyBpbiBtZWV0aW5nIHRoZSBuZXR3b3JrIHNsaWNpbmcg cmVxdWlyZW1lbnRzLCBhbmQgaWYgbmVlZGVkLCB0byBjb21iaW5lIHRoZSBleGlzdGluZyBhbmQg b25nb2luZyB3b3JrcywgdG9nZXRoZXIgd2l0aCBwb3RlbnRpYWwgcHJvdG9jb2wgZW5oYW5jZW1l bnRzIG9yIG5ldyBwcm90b2NvbHMgdG8gYWNoaWV2ZSBuZXR3b3JrIHNsaWNpbmcgb2YgdGhlIG1v YmlsZSB0cmFuc3BvcnQgbmV0d29yay4gDQogICAgDQogICAgSW4gb3JkZXIgdG8gaGF2ZSBiZXR0 ZXIgdW5kZXJzdGFuZGluZyBvZiB0aGUgZ2FwcyBpbiB0cmFuc3BvcnQgbmV0d29yayBzbGljaW5n LCB3ZSBtYXkgc3RhcnQgd2l0aCBhIGZldyBxdWVzdGlvbnM6IA0KICAgIA0KICAgIDEuIFRvIHdo YXQgZXh0ZW50IGNhbiB0aGUgcmVxdWlyZW1lbnRzIG9mIG5ldHdvcmsgc2xpY2luZyBpbiBkYXRh IHBsYW5lIGJlIGFkZHJlc3NlZCBieSBleGlzdGluZyBJRVRGIHRlY2hub2xvZ2llcyBzdWNoIGFz IFZQTnMgKGFuZCBWUE4gbGlrZSB0ZWNobm9sb2dpZXMpPyBXZSBub3RlIGluIGFza2luZyB0aGlz IHRoYXQgaW4gc29tZSBjYXNlcyBWUE5zIG1heSBuZWVkIHRvIGJlIGVuaGFuY2VkIGJ5IHNvbWUg ZGV0ZXJtaW5pc3RpYyB0ZWNobm9sb2d5IHN1Y2ggYXMgdGhhdCBiZWluZyBpbnZlc3RpZ2F0ZWQg aW4gdGhlIERFVE5FVCBXRy4NCiAgICANCiAgICBBbmQgdG8gd2hhdCBleHRlbnQgZG8gdGhlIGNv bnRyb2wgcGxhbmVzIG9mIGV4aXN0aW5nIHRlY2hub2xvZ2llcyBzYXRpc2Z5IHRoZSBuZWVkcyBv ZiBuZXR3b3JrIHNsaWNpbmc/IE5vdGUgdGhhdCBpbiBzb21lIDVHIHVzZSBjYXNlcyB0aGUgY3Vz dG9taXplZCBvciBkZWRpY2F0ZWQgY29udHJvbCBwbGFuZSBtYXkgYmUgbmVlZGVkIGZvciBzb21l IG9mIHRoZSBuZXR3b3JrIHNsaWNlcywgd2hpbGUgaW4gc29tZSBvdGhlciBjYXNlcyB0aGUgY29u dHJvbCBwbGFuZSBtYXkgYmUgc2hhcmVkIGJldHdlZW4gc2xpY2VzLg0KICAgIA0KICAgIDIuIERv ZXMgQUNUTiBjb21wbGV0ZWx5IHNhdGlzZnkgdGhlIGFic3RyYWN0aW9uIG9mIE5ldHdvcmsgU2xp Y2VzIChOUykgdG8gdGhlIG9wZXJhdG9ycyBvciB0aGUgY3VzdG9tZXJzIHdobyBpbnN0YW50aWF0 ZSwgbW9uaXRvciBhbmQgbWFuYWdlIGFuIE5TIHRocm91Z2ggaXRzIGxpZmVjeWNsZSwgaW5jbHVk aW5nIGR5bmFtaWNhbGx5IGNoYW5naW5nIGEgc2xpY2UgdG8gYWNjb3VudCBmb3IgdGhlIHZhcnlp bmcgbmVlZHMgZHVyaW5nIGl0cyBsaWZlY3ljbGUgZnJvbSBjcmVhdGlvbiB0byBkaXNwb3NhbCwg aXMgdGhlcmUgYW55IGFkZGl0aW9uYWwgbWVjaGFuaXNtIGFsc28gcmVxdWlyZWQ/DQogICAgDQog ICAgWU9VTkc+PiBJIHRoaW5rIHNvLiBBQ1ROIGFsbG93cyBWTiBzbGljZSB0byBiZSBjcmVhdGVk L21vbml0b3JlZC9tb2RpZmllZC9kZWxldGVkIGR5bmFtaWNhbGx5IHN1cHBvcnRpbmcgQ1JVRCBv cGVyYXRpb25zLiBJIGp1c3Qgd2FudCB0byBtYWtlIGEgcG9pbnQgdGhhdCB0aGUgYWJzdHJhY3Rp b24gb2YgbmV0d29yayBzbGljZXMgaW4gQUNUTiBpcyBvbmx5IGZvciBuZXR3b3JrIHJlc291cmNl cyBidXQgbm90IGZvciBjb21wdXRlIG9yIHN0b3JhZ2UuIENTTyAoQ3Jvc3MtU3RyYXR1bSBPcHRp bXphdGlvbikgd29yayBhZGRyZXNzIGhvdyB0byBjb21iaW5lIGNvbXB1dGUgYW5kIHN0b3JhZ2Ug c2xpY2VzIHdpdGggQUNUTidzIG5ldHdvcmsgc2xpY2VzLiBNeSB1bmRlcnN0YW5kaW5nIGZvciB0 aGUgc2NvcGUgb2YgbmV0d29yayBzbGljaW5nIGlzIHByaW1hcmlseSBuZXR3b3JrIHJlc291cmNl IHNsaWNpbmcsIGNvcnJlY3Q/IA0KICAgIA0KICAgIDMuIEhvdyBkbyB3ZSBjaGFyYWN0ZXJpemUg dGhlIGRldGVybWluaXNtIHJlcXVpcmVtZW50IG9mIE5TPyBUbyB3aGF0IGV4dGVudCBpcyB0aGUg ZGV0ZXJtaW5pc20gaGFyZCBhbmQgdG8gd2hhdCBleHRlbnQgaXMgaXQgc29mdCwgaS5lLiB3aGF0 IGFyZSB0aGUgYWJzb2x1dGUgcmVxdWlyZW1lbnRzLCBhbmQgd2hhdCByZXF1aXJlbWVudHMgY2Fu IGJlIG1ldCBieSBzb21lIGZvcm0gb2YgcHJvYmFiaWxpdHkgbWFzaz8gRG9lcyB0aGUgZGVzaWdu IGJlaW5nIHByb3Bvc2VkIGJ5IHRoZSBERVRORVQgZGVzaWduIHRlYW0gKHdoaWNoIGlzIHN0aWxs IGluIHN0ZWFsdGggbW9kZSkgYWRkcmVzcyBhbGwgb2YgdGhpcz8NCiAgICANCiAgICA0LiBUbyB3 aGF0IGV4dGVudCBkb2VzIHRoZSBuZXR3b3JrIG5lZWQgdG8gb3BlbiB0aGUgY29udHJvbCBhbmQg bWFuYWdlbWVudCBvZiB0aGUgbmV0d29yayBzbGljZXMgdG8gdGhlIHRoaXJkIHBhcnRpZXM/IEFu ZCB0byB3aGF0IGV4dGVudCBjYW4gdGhpcyBiZSBhZGRyZXNzZWQgYnkgZXhpc3RpbmcgdGVjaG5v bG9naWVzLCBzdWNoIGFzIFBDRSwgU2VnbWVudCBSb3V0aW5nLCBTRkMgYW5kIE5ldGNvbmY/DQog ICAgDQogICAgWW91ciBpbnNpZ2h0ZnVsIHRob3VnaHRzIGFyZSBtdWNoIGFwcHJlY2lhdGVkLg0K ICAgIA0KICAgIEJlc3QgcmVnYXJkcywNCiAgICBKaWUNCiAgICANCiAgICANCiAgICBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIE5ldHNsaWNlcyBt YWlsaW5nIGxpc3QNCiAgICBOZXRzbGljZXNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldHNsaWNlcw0KICAgIA0KICAgIF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgTmV0c2xpY2VzIG1haWxpbmcg bGlzdA0KICAgIE5ldHNsaWNlc0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbmV0c2xpY2VzDQogICAgDQoNCg== From nobody Mon Feb 6 17:50:31 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7A0129446 for ; Mon, 6 Feb 2017 17:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Urzb1oKaOqSC for ; Mon, 6 Feb 2017 17:50:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639F112943E for ; Mon, 6 Feb 2017 17:50:20 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFY43509; Tue, 07 Feb 2017 01:50:18 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Feb 2017 01:50:16 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 7 Feb 2017 09:50:06 +0800 From: Yudelei To: Susan Hares , AshwoodsmithPeter , "'Natale, Bob'" , "'Alex Galis'" , "'Network Slices'" Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvrBvwW0JTXRw0ii0QJ7j3vUhqFbjOGAgACPA4CAACACAIAAnmQg Date: Tue, 7 Feb 2017 01:51:18 +0000 Message-ID: <397489E39F2A984AB838214767A532AD919DCA62@NKGEML515-MBX.china.huawei.com> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <013901d280d3$fcf6c050$f6e440f0$@ndzh.com> In-Reply-To: <013901d280d3$fcf6c050$f6e440f0$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.153.185] Content-Type: multipart/alternative; boundary="_000_397489E39F2A984AB838214767A532AD919DCA62NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.589927DA.0146, 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: 10b7b78e3c97adfaecead25cebc384ae Archived-At: Cc: "Dongjie \(Jimmy\)" , 'Stewart Bryant' , "Kiran.Makhijani" Subject: [Netslices] =?gb2312?b?tPC4tDogIE5ldHdvcmsgU2xpY2luZyAtIEludHJv?= =?gb2312?b?ZHVjdG9yeSBEb2N1bWVudCBhbmQgUmV2aXNlZCBQcm9ibGVtIFN0YXRlbWVu?= =?gb2312?b?dA==?= X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 01:50:25 -0000 --_000_397489E39F2A984AB838214767A532AD919DCA62NKGEML515MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIGFsbA0KSSByZXBseSBvbiB0aGlzIHRocmVhZCwgYnV0IEmhr3ZlIHJlYWQgYW5vdGhlciB0 aHJlYWQgSmltIHN0YXJ0Lg0KQmVmb3JlIGFyZ3VlIG9uIHRoZSB0ZXJtaW5vbG9neSBkZWZpbml0 aW9uIGFuZCBzY29wZSwgaXQgbmVlZCB0byBjb21lIHRvIHRoZSByZXF1aXJlbWVudCBhZ2Fpbi4N CkkgY29uY2x1ZGUgdGhlIHR3byBpbXBvcnRhbnQgcmVxdWlyZW1lbnQgYXM6DQoNCjEuICAgICAg IERlZGljYXRlZCBuZXR3b3JrIHJlc291cmNlIGZvciBhIG5ldHdvcmsgc2xpY2UuDQoNCjIuICAg ICAgIEluZGVwZW5kZW50IG9wZXJhdGlvbiBvbiBhIG5ldHdvcmsgc2xpY2UNClRoZXJlIGFyZSBu byBhYnNvbHV0ZSBkZWRpY2F0ZWQgcmVzb3VyY2UsIGUuZy4sIGV2ZW4gdXNlIHR3byBmaWJlciBl YWNoIGZvciBvbmUgbmV0d29yayBzbGljZSwgdGhleSBtYXkgc3RpbGwgc2hhcmUgdGhlIHNhbWUg cGxhc3RpYyBwaXBlLiBCdXQgaWYgdXNlIE1QTFMgbGFiZWwsIGl0IHdpbGwgYmUgc2hhcmVkIG9u IFZQTiB0dW5uZWwgbGV2ZWwsIHRoZSB0aGluZyBtYXkganVzdCBrZWVwIGluIFZQTiBzY29wZSwg dGhlcmUgYWN0dWFsbHkgbm8gbmV0d29yayBzbGljZSBjb25jZXB0LCB3aGF0IHdlIGRvIGlzIGp1 c3QgY2FsbCB0aGUgVlBOIHRvIGFub3RoZXIgbmFtZS4gU28gSSBzdWdnZXN0IHdlIGRlZmluZSB0 aGUgbmV0d29yayBzbGljZSBtb3JlIG9uIGRlZGljYXRlZCByZXNvdXJjZSwgc3VwcG9zZSB0byBw cm92aWRlIHRoZSBkZWRpY2F0ZWQgZW5vdWdoIGxvZ2ljYWwgcGF0aC9wb3J0L2xpbmsvbm9kZSB0 byB0aGUgbmV0d29yayBzbGljZSB0ZW5hbnQuIEkgdW5kZXJzdGFuZCBpdCBpcyBhIHVuLWVmZmlj aWVudCB3YXkgdG8gZG8gdGhpcywgYWdhaW5zdCB0aGUgc2hhcmluZyBzcGlyaXQgb2YgTVBMUy9J UCBuZXR3b3JrLiBUaGlzIHdpbGwgYmUgY29tcGVuc2F0ZSBieSBuZXR3b3JrIHNsaWNlIG1hbmFn ZW1lbnQgZHluYW1pY2FsbHkuDQpUaGUgbmV0d29yayBzbGljZSBpcyB0byBiZSBwcm92aWRlZCB0 byBhIHBhcnRpY3VsYXIgZS5nLiA1RyBzZXJ2aWNlIG9yIGEgNUcgdGVuYW50LiBTbyBpdCBpcyBh bGxvd2VkIHRoZSBuZXR3b3JrIHNsaWNlIHRlbmFudCB0byBvcGVyYXRlIG9uIGl0IGluZGVwZW5k ZW50bHksIHRoZSBuZXR3b3JrIHNsaWNlIGxvb2tzIGxpa2UgYSBkZWRpY2F0ZWQgbmV0d29yayBm b3IgdGhlIHRlbmFudCwgaXQgaGFzIGEgbG9naWNhbCB0b3BvbG9neSwgd2l0aCBleHBlY3RlZCBR b1MgcHJvcGVydHksIHRoZSB0ZW5hbnQgY2FuIGRlcGxveSB0aGUgc2VydmljZSBvbiBpdCwgZS5n LiwgYnkgcHJvZ3JhbW1pbmcgaW50ZXJmYWNlLCBhbmQgY2FuIGhhdmUgc3RhdGUgcmVwb3J0IGZy b20gaXQuIEl0IGlzIGNsZWFyIGRpZmZlcmVudCB3aXRoIFZQTiwgd2hpY2ggY2Fubm90IGJlIG9w ZXJhdGVkIG9uIGl0IGJ5IHRoZSB0ZW5hbnQuDQoNCg0KRGVsZWkNCg0Kt6K8/sjLOiBOZXRzbGlj ZXMgW21haWx0bzpuZXRzbGljZXMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBTdXNhbiBIYXJlcw0K t6LLzcqxvOQ6IDIwMTfE6jLUwjfI1SA3OjUyDQrK1bz+yMs6IEFzaHdvb2RzbWl0aFBldGVyOyAn TmF0YWxlLCBCb2InOyAnQWxleCBHYWxpcyc7ICdOZXR3b3JrIFNsaWNlcycNCrOty806IERvbmdq aWUgKEppbW15KTsgS2lyYW4uTWFraGlqYW5pOyAnU3Rld2FydCBCcnlhbnQnDQrW98ziOiBSZTog W05ldHNsaWNlc10gTmV0d29yayBTbGljaW5nIC0gSW50cm9kdWN0b3J5IERvY3VtZW50IGFuZCBS ZXZpc2VkIFByb2JsZW0gU3RhdGVtZW50DQoNClBldGVyOg0KDQpPbiAjMyBvbiB5b3VyIGxpc3Qg qEMgZG8geW91IGJlbGlldmUgYWxsIHRoZSBMMlZQTiBhbmQgTDNWUE4gZmVhdHVyZXMgYXJlIG5l ZWRlZD8gIE9yIGNhbiB5b3Ugc3VnZ2VzdCBhIHNtYWxscyBzdWJzZXQgb2YgdGhlc2UgZmVhdHVy ZXMgdGhhdCB3aWxsIGJlIG5lZWRlZCB0byBzdXBwb3J0IG5ldHdvcmsgc2xpY2luZy4NCg0KT24g IzQgqEMgaG93IGlzIHRoaXMgcHJvZ3JhbW1hdGljIGludGVyZmFjZSB0byB0aGUgY29udHJvbCBw bGFuZSBkaWZmZXJlbnQgdGhhbiB0aGUgd29yayB3ZSBhcmUgZG9pbmcgaW4gSTJSUy4NCg0KSSB3 b3VsZCBhcHByZWNpYXRlIGEgY29weSBvZiB5b3VyIHNob3J0IHByZXNlbnRhdGlvbiBvbiB0aGlz IG1hdHRlci4NCg0KU3VlIEhhcmVzDQoNCkZyb206IE5ldHNsaWNlcyBbbWFpbHRvOm5ldHNsaWNl cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQXNod29vZHNtaXRoUGV0ZXINClNlbnQ6 IE1vbmRheSwgRmVicnVhcnkgNiwgMjAxNyA0OjU3IFBNDQpUbzogTmF0YWxlLCBCb2I7IEFsZXgg R2FsaXM7IE5ldHdvcmsgU2xpY2VzDQpDYzogRG9uZ2ppZSAoSmltbXkpOyBTdGV3YXJ0IEJyeWFu dDsgS2lyYW4uTWFraGlqYW5pDQpTdWJqZWN0OiBSZTogW05ldHNsaWNlc10gTmV0d29yayBTbGlj aW5nIC0gSW50cm9kdWN0b3J5IERvY3VtZW50IGFuZCBSZXZpc2VkIFByb2JsZW0gU3RhdGVtZW50 DQoNCkhleSBCb2IsDQoNCkhlcmUgYXJlIGEgZmV3IHBvaW50cyB0aGF0IEkgZmluZCB1c2VmdWwg dG8gdW5kZXJzdGFuZCBTbGljaW5nIGFuZCBWUE6hr3MuDQoNCg0KMS4gICAgICBBIKGwc2xpY2Wh sSBpbiB0aGUgY29udGV4dCBvZiA1RyBpcyBlc3NlbnRpYWxseSBhbiBlbmQgdG8gZW5kIHNldCBv ZiByZXNvdXJjZXMgd2hpY2ggbWFrZSB1cCBhIGZ1bGx5IGZ1bmN0aW9uYWwgd2lyZWxlc3MgbmV0 d29yayBkcmF3biBmcm9tIGxhcmdlciBwb29sIG9mIGVuZCB0byBlbmQgcmVzb3VyY2VzLg0KDQoN CjIuICAgICAgQSBzbGljZSBpcyB0aGVyZWZvcmUgYSBzdXBlcnNldCBvZiB0aGUgY2FwYWJpbGl0 aWVzIG9mIGFuIEwwLEwxLEwzIG9yIEwzIFZQTi4NCg0KDQoNCjMuICAgICAgQW4gTDJWUE4gb3Ig TDNWUE4gaXMgbGlrZWx5IGEgdXNlZnVsIGNvbm5lY3Rpdml0eSBtb2RlbCBmb3IgdGhlIGNvbnRy b2wgYW5kIHVzZXIgcGxhbmUgZGF0YSBwYXRocyBmb3IgdGhlIG9idmlvdXMgcmVhc29ucyBhbmQg REVUTkVUIHR5cGUgY2FwYWJpbGl0aWVzIGFyZSBvZiBpbnRlcmVzdCBmb3Igc3RyaWN0ZXIgUU9T IGd1YXJhbnRlZXMuIEZvciBldmVuIHN0cmljdGVyIGd1YXJhbnRlZXMgQUNUTiBldGMuIGFuZCBM MC9MMSBjb250cm9sIGlzIHJlcXVpcmVkLg0KDQoNCg0KNC4gICAgICBJIGhhdGUgdGhlIHRlcm0g obBzb2Z0d2FyaXphdGlvbqGxIGFsc28sIGJ1dCBlc3NlbnRpYWxseSBpdKGvcyBiZWluZyB1c2Vk IHRvIGRlc2NyaWJlIGEgcHJvZ3JhbW1hdGljIGludGVyZmFjZSB0byBlYWNoIG9mIHRoZSBlbmQg dG8gZW5kIHNldHMgb2YgcmVzb3VyY2VzIHRvIGFsbG93IHRoZW0gdG8gYmUgYWxsb2NhdGVkL2xp bmtlZC9kZWFsbG9jYXRlZC9ncm93bi9zaHJ1bmsgZXRjLiBhbmQgaXMgdGhlcmVmb3JlIG1vcmUg dGhhbiBqdXN0IHZpcnR1YWxpemF0aW9uIGJ1dCBvZiBjb3Vyc2UgY292ZXJzIHZpcnR1YWxpemF0 aW9uLg0KDQpJIGdhdmUgYSBzaG9ydCBwcmVzZW50YXRpb24gb24gdGhpcyBhdCA1Z2FuZElwIG1l ZXRpbmcgbGFzdCB5ZWFyIHdoaWNoIHlvdSBtYXkgZmluZCB1c2VmdWwsIEmhr2xsIGJlIGhhcHB5 IHRvIHNlbmQgaXQgdG8geW91IGRpcmVjdGx5IG9yIEkgc3VzcGVjdCBpdKGvcyBvbiBhbiBJRVRG IHNlcnZlciBzb21ld2hlcmUuDQoNCkNoZWVycywNCg0KUGV0ZXINCg0KDQpGcm9tOiBOZXRzbGlj ZXMgW21haWx0bzpuZXRzbGljZXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5hdGFs ZSwgQm9iDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDA2LCAyMDE3IDg6MjUgQU0NClRvOiBBbGV4 IEdhbGlzIDxhLmdhbGlzQHVjbC5hYy51azxtYWlsdG86YS5nYWxpc0B1Y2wuYWMudWs+PjsgTmV0 d29yayBTbGljZXMgPG5ldHNsaWNlc0BpZXRmLm9yZzxtYWlsdG86bmV0c2xpY2VzQGlldGYub3Jn Pj4NCkNjOiBEb25namllIChKaW1teSkgPGppZS5kb25nQGh1YXdlaS5jb208bWFpbHRvOmppZS5k b25nQGh1YXdlaS5jb20+PjsgS2lyYW4uTWFraGlqYW5pIDxLaXJhbi5NYWtoaWphbmlAaHVhd2Vp LmNvbTxtYWlsdG86S2lyYW4uTWFraGlqYW5pQGh1YXdlaS5jb20+PjsgU3Rld2FydCBCcnlhbnQg PHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbTxtYWlsdG86c3Rld2FydC5icnlhbnRAZ21haWwuY29t Pj4NClN1YmplY3Q6IFJlOiBbTmV0c2xpY2VzXSBOZXR3b3JrIFNsaWNpbmcgLSBJbnRyb2R1Y3Rv cnkgRG9jdW1lbnQgYW5kIFJldmlzZWQgUHJvYmxlbSBTdGF0ZW1lbnQNCg0KSGkgQWxleCwNCg0K SSBqdXN0IGhhdmUgdHdvIGJhc2ljIHF1ZXN0aW9ucyCoQyBtb3JlIGxpa2UgobByZXF1ZXN0c6Gx IKhDIGZvciBub3c6DQoNCi0gSG93IGRvZXMgYSBuZXR3b3JrIKGwc2xpY2WhsSBkaWZmZXIgZnJv bSBhbGwgZXN0YWJsaXNoZWQgZm9ybXMgb2YgbmV0d29yayB2aXJ0dWFsaXphdGlvbiAoVkxBTnMs IFZQTnMsIFNEUHMsIGV0Yy4/DQoNCi0gRG8gd2UgcmVhbGx5IG5lZWQgdGhlIHRlcm0gobBzb2Z0 d2FyaXphdGlvbqGxIChhbmQgaXRzIHZhcmlvdXMgZGVyaXZhdGl2ZXMpIKGtIGlzbqGvdCB0aGF0 IGp1c3QgYSBjb25mb3VuZGluZyB3YXkgb2Ygc2F5aW5nIKGwdmlydHVhbGl6YXRpb26hsSChrSBh cyBpbiChsHNvZnR3YXJpemluZyBhbmQgc2VwYXJhdGluZw0KICAgbG9naWNhbCBuZXR3b3JrIGNv bXBvbmVudHMgZnJvbSB0aGUgdW5kZXJseWluZyBwaHlzaWNhbCBuZXR3b3JrIHJlc291cmNlc6Gx IKGtIGlzbqGvdCB0aGF0IGxhdHRlciBwYXJ0IHdoYXQgd2UgY29tbW9ubHkgY2FsbCB2aXJ0dWFs aXphdGlvbiBhbmQsIGlmIHNvLCBob3cgZG9lcyChsHNvZnR3YXJpemF0aW9uobEgZGlmZmVyIGZy b20gaXQ/DQoNCkZyb20gYSBsdXJrZXIsDQpCb2JODQoNCkZyb206IE5ldHNsaWNlcyBbbWFpbHRv Om5ldHNsaWNlcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWxleCBHYWxpcw0KU2Vu dDogRnJpZGF5LCBKYW51YXJ5IDIwLCAyMDE3IDM6NTQgQU0NClRvOiBOZXR3b3JrIFNsaWNlcyA8 bmV0c2xpY2VzQGlldGYub3JnPG1haWx0bzpuZXRzbGljZXNAaWV0Zi5vcmc+Pg0KQ2M6IERvbmdq aWUgKEppbW15KSA8amllLmRvbmdAaHVhd2VpLmNvbTxtYWlsdG86amllLmRvbmdAaHVhd2VpLmNv bT4+OyBTdGV3YXJ0IEJyeWFudCA8c3Rld2FydC5icnlhbnRAZ21haWwuY29tPG1haWx0bzpzdGV3 YXJ0LmJyeWFudEBnbWFpbC5jb20+PjsgQWxleCBHYWxpcyA8YS5nYWxpc0B1Y2wuYWMudWs8bWFp bHRvOmEuZ2FsaXNAdWNsLmFjLnVrPj47IEtpcmFuLk1ha2hpamFuaSA8S2lyYW4uTWFraGlqYW5p QGh1YXdlaS5jb208bWFpbHRvOktpcmFuLk1ha2hpamFuaUBodWF3ZWkuY29tPj4NClN1YmplY3Q6 IFJlOiBbTmV0c2xpY2VzXSBOZXR3b3JrIFNsaWNpbmcgLSBJbnRyb2R1Y3RvcnkgRG9jdW1lbnQg YW5kIFJldmlzZWQgUHJvYmxlbSBTdGF0ZW1lbnQNCg0KDQoNCg0KMjB0aCBKYW51YXJ5IDIwMTcN Cg0KDQpEZWFyIEFsbA0KDQoNClJlOiAgTmV0d29yayBTbGljaW5nIC0gSW50cm9kdWN0b3J5IERv Y3VtZW50IGFuZCBSZXZpc2VkIFByb2JsZW0gU3RhdGVtZW50DQoNCiAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1nZG1iLW5ldHNsaWNlcy1pbnRyby1h bmQtcHMtMDAudHh0DQoNCg0KDQpUaGFuayB5b3UgZm9yIHlvdXIgZXhwcmVzc2VkIGludGVyZXN0 IGluIHRoZSBOZXR3b3JrIFNsaWNpbmcuDQoNCk9uZSBvZiB0aGUgYWN0aW9uIGZyb20gdGhlIE5l dHdvcmsgU2xpY2luZyBzaWRlIG1lZXRpbmcgYXQgSUVURiA5NyBvZiAxNXRoIE5vdiAyMDE2IHdh cyB0byBjb25zb2xpZGF0ZSBhbGwgc3VnZ2VzdGlvbnMgYW5kIGNvbW1lbnRzIHJlY2VpdmVkIGlu dG8gYW4gdW5pZmllZCBpbml0aWFsIHJldmlzZWQgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHdvcmsg cGxhbiB3aGljaCB3b3VsZCBiZSB0aGUgYmFzaXMgb2YgYSBCb0YgYXQgSUVURiA5OCBvciBJRVRG OTkuIFN1Y2ggYW4gaW50cm9kdWN0b3J5IGRvY3VtZW50IGlzIHJlYWR5IGZvciB5b3VyIHJldmll dyBhbmQgaXQgaXMgZW5jbG9zZWQgYXMgYSBkcmFmdC4NCg0KV291bGQgeW91IGJlIHNvIGtpbmQg YXMgdG8gcHJvdmlkZSB5b3VyIGZlZWRiYWNrLCBjb21tZW50cywgY29udHJpYnV0aW9ucyBhbmQg d29yayBpbnRlcmVzdCB3aXRoIHRoZSB2aWV3IG9mIGZ1cnRoZXIgcHJvZ3Jlc3NpbmcgdGhpcyBk cmFmdCBmb3IgdW4gdXBkYXRlIGFuZCBwcmVzZW50YXRpb24gYXQgSUVURiA5OC4NCg0KVGhhbmsg eW91IGluIGFkdmFuY2UsDQpCZXN0IFJlZ2FyZHMNCkFsZXgsIEppZSwgS2lyYW4gYW5kIFN0ZXdh cnQNCg0KDQoNCk5ldHdvcmsgU2xpY2luZyAtIEludHJvZHVjdG9yeSBEb2N1bWVudCBhbmQgUmV2 aXNlZCBQcm9ibGVtIFN0YXRlbWVudA0KDQpBYnN0cmFjdDoNCiAgVGhpcyBkb2N1bWVudCByZXBy ZXNlbnRzIGFuIGludHJvZHVjdGlvbiB0byB0aGUgbW90aXZhdGlvbiBhbmQNCiAgTmV0d29yayBT bGljaW5nIHByb2JsZW1zIGFuZCB3b3JrIGFyZXMuIEl0IHJlcHJlc2VudHMgYW4gaW5pdGlhbA0K ICByZXZpc2lvbiBvZiBOZXR3b3JrIFNsaWNpbmcgcHJvYmxlbSBzdGF0ZW1lbnQgZGVyaXZlZCBm cm9tIHRoZQ0KICBhbmFseXNpcyBvZiB0aGUgdGVjaG5pY2FsIGdhcHMgaW4gSUVURiBwcm90b2Nv bHMgZWNvc3lzdGVtLiBJdA0KICBjb21wbGVtZW50cyBhbmQgaXQgYnJpbmcgdG9nZXRoZXIgdGhl IGlzb2xhdGVkIGVmZm9ydHMgYmVpbmcgY2FycmllZA0KICBvdXQgaW4gc2V2ZXJhbCBJRVRGIHdv cmtpbmcgZ3JvdXBzIHRvIGFjaGlldmUgY2VydGFpbiBhc3BlY3RzIG9mDQogIG5ldHdvcmsgc2xp Y2UgZnVuY3Rpb25zIGFuZCBvcGVyYXRpb25zLg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCk5ldHNsaWNlcyBtYWlsaW5nIGxpc3QNCk5ldHNsaWNlc0Bp ZXRmLm9yZzxtYWlsdG86TmV0c2xpY2VzQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRzbGljZXMNCg== --_000_397489E39F2A984AB838214767A532AD919DCA62NKGEML515MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, all

I reply on= this thread, but I=A1=AFve read another thread Jim start.

Before arg= ue on the terminology definition and scope, it need to come to the requirem= ent again.

I conclude= the two important requirement as:

1.       De= dicated network resource for a network slice.

2.       In= dependent operation on a network slice

There are = no absolute dedicated resource, e.g., even use two fiber each for one netwo= rk slice, they may still share the same plastic pipe. But if use MPLS label, it will be shared on VPN tunnel level, the thing may ju= st keep in VPN scope, there actually no network slice concept, what we do i= s just call the VPN to another name. So I suggest we define the network sli= ce more on dedicated resource, suppose to provide the dedicated enough logical path/port/link/node to the network= slice tenant. I understand it is a un-efficient way to do this, against th= e sharing spirit of MPLS/IP network. This will be compensate by network sli= ce management dynamically.

The networ= k slice is to be provided to a particular e.g. 5G service or a 5G tenant. S= o it is allowed the network slice tenant to operate on it independently, the network slice looks like a dedicated network for the te= nant, it has a logical topology, with expected QoS property, the tenant can= deploy the service on it, e.g., by programming interface, and can have sta= te report from it. It is clear different with VPN, which cannot be operated on it by the tenant.<= /p>

 = ;

 = ;

Delei=

 = ;

=B7=A2=BC=FE=C8=CB: Netslic= es [mailto:netslices-bounces@ietf.org] =B4=FA= =B1=ED Susan Hares
=B7=A2= =CB=CD=CA=B1=BC=E4: 2017=C4=EA2=D4=C27=C8=D5 7:52
=CA=D5=BC=FE=C8=CB: AshwoodsmithPeter; 'Natale, Bob'; 'Alex Galis'; 'Network Slices' =B3=AD=CB=CD: Dongjie (Jimmy); Kiran.Makhijani; 'Stewart Bryant'
=D6=F7=CC=E2: Re: [Netslices] Network Slicing - Introductory Document and Revised Probl= em Statement

 

Peter:

 = ;

On #3 on y= our list =A8C do you believe all the L2VPN and L3VPN features are needed?&n= bsp; Or can you suggest a smalls subset of these features that will be needed to support network slicing.

 = ;

On #4 =A8C= how is this programmatic interface to the control plane different than the= work we are doing in I2RS. 

 = ;

I would ap= preciate a copy of your short presentation on this matter.

 = ;

Sue Hares

 = ;

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of AshwoodsmithPeter
Sent: Monday, February 6, 2017 4:57 PM
To: Natale, Bob; Alex Galis; Network Slices
Cc: Dongjie (Jimmy); Stewart Bryant; Kiran.Makhijani
Subject: Re: [Netslices] Network Slicing - Introductory Document and= Revised Problem Statement

 

Hey Bob,

 = ;

Here are a= few points that I find useful to understand Slicing and VPN=A1=AFs.

 = ;

1.      A =A1=B0slice=A1=B1 in the= context of 5G is essentially an end to end set of resources which make up = a fully functional wireless network drawn from larger pool of end to end resources.

 = ;

2.      A slice is therefore a superset of the capabilities of an L0,L1,L3 or L3 VPN.

 

3.      An L2VPN or L3VPN is likel= y a useful connectivity model for the control and user plane data paths for= the obvious reasons and DETNET type capabilities are of interest for stricter QOS guarantees. For even stricter guarantees ACTN et= c. and L0/L1 control is required.

 

4.      I hate the term =A1=B0soft= warization=A1=B1 also, but essentially it=A1=AFs being used to describe a p= rogrammatic interface to each of the end to end sets of resources to allow them to be allocated/linked/deallocated/grown/shrunk etc. and is therefore= more than just virtualization but of course covers virtualization.

 = ;

I gave a s= hort presentation on this at 5gandIp meeting last year which you may find u= seful, I=A1=AFll be happy to send it to you directly or I suspect it=A1=AFs on an IETF server somewhere.

 = ;

Cheers,

 = ;

Peter=

 = ;

 = ;

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Natale, Bob
Sent: Monday, February 06, 2017 8:25 AM
To: Alex Galis <a.galis@ucl.= ac.uk>; Network Slices <net= slices@ietf.org>
Cc: Dongjie (Jimmy) <jie.d= ong@huawei.com>; Kiran.Makhijani <Kiran.Makhijani@huawei.com>; Stewart Bryant <stewart.bryant@gmail.com>
Subject: Re: [Netslices] Network Slicing - Introductory Document and= Revised Problem Statement

 

Hi Alex,<= /p>

 

I just have two basic quest= ions =A8C more like =A1=B0requests=A1=B1 =A8C for now:

 

- How does a network =A1=B0= slice=A1=B1 differ from all established forms of network virtualization (VL= ANs, VPNs, SDPs, etc.?

 

- Do we really need the ter= m =A1=B0softwarization=A1=B1 (and its various derivatives) =A1=AD isn=A1=AF= t that just a confounding way of saying =A1=B0virtualization=A1=B1 =A1=AD a= s in =A1=B0softwarizing and separating

   logical networ= k components from the underlying physical network resources=A1=B1 =A1=AD is= n=A1=AFt that latter part what we commonly call virtualization and, if so, = how does =A1=B0softwarization=A1=B1 differ from it?

 

From a lurker,

BobN

 

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Alex Galis
Sent: Friday, January 20, 2017 3:54 AM
To: Network Slices <netslic= es@ietf.org>
Cc: Dongjie (Jimmy) <jie.d= ong@huawei.com>; Stewart Bryant <stewart.bryant@gmail.com>; Alex Galis <a.galis@ucl.ac.uk>; Kiran.Makhijani <Kiran.Makhijani@huawei.c= om>
Subject: Re: [Netslices] Network Slicing - Introductory Document and= Revised Problem Statement

 

 



20th January 2017


Dear All

 
Re:  Network Slicing - Introductory Document and Revised Problem State= ment

         https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-and-ps-00.t= xt

 

Thank you for your expressed interest in the Network Slicing.

One of the action from the Network Slicing side meeting at IETF 97 of 15th = Nov 2016 was to consolidate all suggestions and comments received into an u= nified initial revised problem statement and work plan which would be the b= asis of a BoF at IETF 98 or IETF99. Such an introductory document is ready for your review and it is enclosed = as a draft.
 
Would you be so kind as to provide your feedback, comments, contributions a= nd work interest with the view of further progressing this draft for un upd= ate and presentation at IETF 98.
 
Thank you in advance,
Best Regards
Alex, Jie, Kiran and Stewart
 
 
 
Network Slicing - Introductory Document and Revised Problem Statement
 
Abstract:
  This document represents an introduction to the motivation and
  Network Slicing problems and work ares. It represents an initial
  revision of Network Slicing problem statement derived from the
  analysis of the technical gaps in IETF protocols ecosystem. It
  complements and it bring together the isolated efforts being carried=
  out in several IETF working groups to achieve certain aspects of
  network slice functions and operations.

____= ___________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.iet= f.org/mailman/listinfo/netslices

--_000_397489E39F2A984AB838214767A532AD919DCA62NKGEML515MBXchi_-- From nobody Mon Feb 6 19:12:50 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAB2120727 for ; Mon, 6 Feb 2017 19:12:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 TDnpIdayt9Ww for ; Mon, 6 Feb 2017 19:12:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E49D81297EC for ; Mon, 6 Feb 2017 19:12:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAD27224; Tue, 07 Feb 2017 03:12:43 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Feb 2017 03:09:32 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Tue, 7 Feb 2017 11:09:28 +0800 From: "Dongjie (Jimmy)" To: Susan Hares , "netslices@ietf.org" Thread-Topic: [Netslices] Discussion about network slicing in IETF Thread-Index: AQHSgF/eQQU/hdFeu02poLyUO2CZP6FcICyAgACwBAA= Date: Tue, 7 Feb 2017 03:10:40 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9279357A4DD@NKGEML515-MBX.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9279357A0F2@NKGEML515-MBX.china.huawei.com> <013401d280d3$85138730$8f3a9590$@ndzh.com> In-Reply-To: <013401d280d3$85138730$8f3a9590$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] 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.0A020205.58993B2B.021A, 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: 8e22a9ab9e8759fb3bb8f1513c9dd287 Archived-At: Subject: Re: [Netslices] Discussion about network slicing in IETF X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 03:12:49 -0000 Hi Sue, Thanks a lot for the information about the latest Netconf/Netmod features. = They may become valuable tools for the management of network slices.=20 As for your question about additional data models, so far it is not quite c= lear to me what new models or augmentations are needed, we need to first un= derstand the required interactions between the third parties and their netw= ork slices. It would be great if the operators or the third party users of 5G could pro= vide some input on the use cases and requirements in this respect. Best regards, Jie > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Tuesday, February 07, 2017 7:48 AM > To: Dongjie (Jimmy) ; netslices@ietf.org > Subject: RE: [Netslices] Discussion about network slicing in IETF >=20 > Jie: >=20 > The opening of the control plane to 3rd party reporting on deterministic > information with the NETCONF/NETMOD improved notification, pub/sub, > ephemeral state (from I2RS), and revised data stores. The pub/sub and > improved NETCONF notification has a number of knobs that can allow increa= sing > or decreasing the level at which events are monitored. One of the questi= ons > about network slicing is whether network slicing needs to define addition= al BGP, > PCE, RIB, and filter-base RIBS yang data models or > augmentation to existing data models. >=20 > Sue Hares >=20 > -----Original Message----- > From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Dongjie > (Jimmy) > Sent: Monday, February 6, 2017 8:53 AM > To: netslices@ietf.org > Subject: [Netslices] Discussion about network slicing in IETF >=20 > Dear all, >=20 > According to some early investigations, the topic network slicing would c= ross > several WGs, even multiple Areas in IETF, and there are some existing and > ongoing works in IETF related to network slicing, such as the various VPN > technologies, the ongoing ACTN work in TEAS WG, the work on deterministic > network in DETNET WG, the work on autonomic management in ANIMA WG, etc. > Through the discussion on this mailing list, we'd like to understand if t= here are > gaps in meeting the network slicing requirements, and if needed, to combi= ne the > existing and ongoing works, together with potential protocol enhancements= or > new protocols to achieve network slicing of the mobile transport network. >=20 > In order to have better understanding of the gaps in transport network sl= icing, > we may start with a few questions: >=20 > 1. To what extent can the requirements of network slicing in data plane b= e > addressed by existing IETF technologies such as VPNs (and VPN like techno= logies)? > We note in asking this that in some cases VPNs may need to be enhanced by > some deterministic technology such as that being investigated in the DETN= ET > WG. >=20 > And to what extent do the control planes of existing technologies satisfy= the > needs of network slicing? Note that in some 5G use cases the customized o= r > dedicated control plane may be needed for some of the network slices, whi= le in > some other cases the control plane may be shared between slices. >=20 > 2. Does ACTN completely satisfy the abstraction of Network Slices (NS) to= the > operators or the customers who instantiate, monitor and manage an NS thro= ugh > its lifecycle, including dynamically changing a slice to account for the = varying > needs during its lifecycle from creation to disposal, is there any additi= onal > mechanism also required? >=20 > 3. How do we characterize the determinism requirement of NS? To what exte= nt > is the determinism hard and to what extent is it soft, i.e. what are the = absolute > requirements, and what requirements can be met by some form of probabilit= y > mask? Does the design being proposed by the DETNET design team (which is = still > in stealth mode) address all of this? >=20 > 4. To what extent does the network need to open the control and managemen= t > of the network slices to the third parties? And to what extent can this b= e > addressed by existing technologies, such as PCE, Segment Routing, SFC and > Netconf? >=20 > Your insightful thoughts are much appreciated. >=20 > Best regards, > Jie >=20 >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices From nobody Mon Feb 6 20:53:41 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E1C1299CC for ; Mon, 6 Feb 2017 20:53:40 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.onmicrosoft.com 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 IazwYzChKvU5 for ; Mon, 6 Feb 2017 20:53:39 -0800 (PST) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id D46311299CF for ; Mon, 6 Feb 2017 20:53:38 -0800 (PST) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6E2CBABD6F3; Mon, 6 Feb 2017 23:53:38 -0500 (EST) Received: from imshyb02.MITRE.ORG (imshyb02.mitre.org [129.83.29.3]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 5C96FABD6DF; Mon, 6 Feb 2017 23:53:38 -0500 (EST) Received: from imshyb02.MITRE.ORG (129.83.29.3) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 6 Feb 2017 23:53:38 -0500 Received: from gcc01-CY1-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Mon, 6 Feb 2017 23:53:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.onmicrosoft.com; s=selector1-mitre-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qnpHawUpKprXcGiQu0zdBFoMpdC7Q623nm+JQ+hu6i0=; b=qSAxKTm4OmHZ6F9wRwp/qwrNYtSmxnimPo2e8VphFqgy8YZT+C9rr/TfPl5qg0cGJeUG4GhvoslCcEHkcdabY+nwpd9kt1Hv0SuzgQTo0mKQzcdNsurTsS0taZncJbsLFJY47dcftxgICv6+TC4G7DtY/1OUlnyu5dxSDTQTUJE= Received: from CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) by CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 7 Feb 2017 04:53:34 +0000 Received: from CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) by CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) with mapi id 15.01.0888.026; Tue, 7 Feb 2017 04:53:34 +0000 From: "Natale, Bob" To: Pedro Martinez-Julia , AshwoodsmithPeter Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvrXaDeoOCGArUagAhaMsA6e+KFcERXwgACKloCAADF+gIAASNqg Date: Tue, 7 Feb 2017 04:53:34 +0000 Message-ID: References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> In-Reply-To: <20170207003145.GN12800@spectre> 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=RNATALE@mitre.org; x-originating-ip: [192.80.55.87] x-ms-office365-filtering-correlation-id: 3a949001-9123-4f28-7f2d-08d44f1545c8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR09MB0922; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0922; 7:rNoBIsBdmOEsG8mmZ3Ty1rLdcCtq6yVaiBA3c0sEk/IGl53w6FQAAyxJ4TEfGroatGVeJVHf3IbG0fyZgsyVUnBzCXGJ6RKAL36zsueC7xiTC96n84YwLzHO42SAewgLCITIFtmuGAK7/MbS5H0aqbBno6RT4KV9nsc5dijigAwbt00YPjiIhOHTfZqs0FTfDtJeEpKPBJ43UJLqNkuZM83pDdqT182jEzDgwtGflk8RXX3AYCI/Tk5CP+8cCsK1nCdWALKNEV7GjW4ojtMk7OInfr4BOinG2NKa33CPeafr3xvhnbzr6NU+DNNZFBxSLiZ+AJIdxVvXVK+YImMxEHVBwctwJ/Fe12gujwZ8Y3Q14I/ehMGc3E3eRa7AwCjROPcvd7/g/R2oAfNKDtmBx4Gx8+UiRPtznJurDizDxEi17nr2rrvaqaPtTvZe/rN9YTv7sF8So6N0PWI7HPnLN7FgX5aGTMRnBkCuQGkiUVydzIWWqc+OLyi6H1Acf0+hFV1Iy04igWiOhxTOg/J2eg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513)(57025502571588); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(20170203043)(5005006)(2017020601046)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(20161123558025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:CY1PR09MB0922; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0922; x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39860400002)(39840400002)(39450400003)(39850400002)(39410400002)(377424004)(252514010)(189002)(199003)(13464003)(377454003)(305945005)(6246003)(7736002)(92566002)(33656002)(3280700002)(3660700001)(53936002)(86362001)(106116001)(106356001)(105586002)(68736007)(93886004)(8936002)(2900100001)(189998001)(81166006)(81156014)(97736004)(8676002)(122556002)(5660300001)(2906002)(54356999)(50986999)(76176999)(4326007)(2950100002)(102836003)(3846002)(6116002)(101416001)(7696004)(229853002)(25786008)(55016002)(54906002)(74316002)(99286003)(66066001)(77096006)(6436002)(38730400002)(6506006)(9686003)(39060400001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR09MB0922; H:CY1PR09MB0922.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2017 04:53:34.8867 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0922 X-OriginatorOrg: mitre.org Archived-At: Cc: "Dongjie \(Jimmy\)" , "Kiran.Makhijani" , Network Slices , Alex Galis , Stewart Bryant Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 04:53:40 -0000 SGkgUGVkcm8sDQoNCkNvbmNlcm5pbmcgeW91ciBleHBsYW5hdGlvbiB0aGF0ICdTb2Z0d2FyaXph dGlvbiBpcyAidGhlIGFjdCBvZiBjb252ZXJ0aW5nIGhhcmQtd2FyZSB0byBzb2Z0LXdhcmUiJywg aXNuJ3QgdGhhdCBqdXN0ICJmdW5jdGlvbiB2aXJ0dWFsaXphdGlvbiIgYXMgaW4sIGZvciBleGFt cGxlLCBORlY/DQoNCkF2YW50aSwNCkJvYk4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IFBlZHJvIE1hcnRpbmV6LUp1bGlhIFttYWlsdG86cGVkcm9AbmljdC5nby5qcF0gDQpT ZW50OiBNb25kYXksIEZlYnJ1YXJ5IDA2LCAyMDE3IDc6MzIgUE0NClRvOiBBc2h3b29kc21pdGhQ ZXRlciA8UGV0ZXIuQXNod29vZFNtaXRoQGh1YXdlaS5jb20+DQpDYzogTmF0YWxlLCBCb2IgPFJO QVRBTEVAbWl0cmUub3JnPjsgQWxleCBHYWxpcyA8YS5nYWxpc0B1Y2wuYWMudWs+OyBOZXR3b3Jr IFNsaWNlcyA8bmV0c2xpY2VzQGlldGYub3JnPjsgRG9uZ2ppZSAoSmltbXkpIDxqaWUuZG9uZ0Bo dWF3ZWkuY29tPjsgU3Rld2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT47IEtp cmFuLk1ha2hpamFuaSA8S2lyYW4uTWFraGlqYW5pQGh1YXdlaS5jb20+DQpTdWJqZWN0OiBSZTog W05ldHNsaWNlc10gTmV0d29yayBTbGljaW5nIC0gSW50cm9kdWN0b3J5IERvY3VtZW50IGFuZCBS ZXZpc2VkIFByb2JsZW0gU3RhdGVtZW50DQoNCkRlYXIgYWwsDQoNClJlZ2FyZGluZyB0aGUgcmVs YXRpb24gYmV0d2VlbiBjdXJyZW50IHZpcnR1YWxpemF0aW9uLCBuZXR3b3JrIHNsaWNpbmcsIGFu ZCBzb2Z0d2FyaXphdGlvbiwgSSBpbnNpc3Qgd2hhdCBJIGhhZCBhbHJlYWR5IG1lbnRpb25lZCBp dCBpbiBvdXIgRjJGIG1lZXRpbmcgQCBJRVRGIDk3LCB0aGF0IHdlIGhhdmUgc29tZSBjbGFzaGVz LiBGb3IgaW5zdGFuY2U6DQoNCi0gQSBzbGljZSBpcywgYnkgZGVmaW5pdGlvbiwgImEgcG9ydGlv biIgb2Ygc29tZXRoaW5nLiBUaGVyZSBpcyBubyBFMkUNCiAgaW1wbGllZCBvbiBpdCwgYnV0IHRo ZXJlIGNhbiBiZSBzcGVjaWZpY2F0aW9ucyBpbmNsdWRpbmcgaXQgKGUuZy4gRTJFDQogIHNsaWNl cykuDQoNCi0gSSBpZGVudGlmeSB0d28gZGlmZmVyZW50IGJ1dCBjb21wbGVtZW50YXJ5IHBvaW50 cyBvZiB2aWV3IGluIHJlbGF0aW9uDQogIHRvICJuZXR3b3JrIHNsaWNlcyI6DQogIA0KICAxKSBU aGUgcmVzdWx0IG9mIHBhcnRpdGlvbmluZyBhIHNldCBvZiAocGh5c2ljYWwvdmlydHVhbCkgcmVz b3VyY2VzIHRvDQogIGdldCB0aGUgYWZvcmVtZW50aW9uZWQgInBvcnRpb25zIi4gVGhpcyBpcyB0 aGUgb3BlcmF0b3Ivb3duZXIgcG9pbnQgb2YNCiAgdmlldyBhbmQgaXMgaW50cmluc2ljYWxseSBy ZWxhdGVkIHRvIHRoZSBlbWJlZGRpbmcgYW5kIG1hbmFnZW1lbnQuDQoNCiAgMikgVGhlIHNldCBv ZiByZXNvdXJjZSBwb3J0aW9ucyBhc3NpZ25lZCB0byBhIHNpbmdlIGVudGl0eS4gQXMgaXQgaXMN CiAgYmVpbmcgY3VycmVudGx5IHVzZWQsIGZvciBpbnN0YW5jZSwgYnkgUGxhbmV0TGFiLCBhICJz bGljZSIgbWVhbnMgYQ0KICBwb3J0aW9uIG9mIHRoZSB3aG9sZSBpbmZyYXN0cnVjdHVyZSBhbmQg bm90IGp1c3QgYSBwb3J0aW9uIG9mIGEgc2luZ2xlDQogIHJlc291cmNlLg0KDQotIFRoZSByZWxh dGlvbiBiZXR3ZWVuIHZpcnR1YWxpYXRpb24gYW5kIHNsaWNpbmcgaXMgdGhhdCB0aGUgbGF0dGVy IGNhbg0KICBiZSBpbXBsZW1lbnRlZCBieSB0aGUgZm9ybWVyLiBIb3dldmVyLCBzbGljZXMgY291 bGQgYmUgaW5zdGFudGlhdGVkIGJ5DQogIG90aGVyIG1lYW5zLCBzbyB0aGUgc2VwYXJhdGUgZGVm aW5pdGlvbnMgYXJlIG5vdCBzdXBlcmZsdW91cy4gQWxzbywgaXQNCiAgaXMgbm90IGZhaXIgdG8g bGluayBWUE4gY2FwYWJpbGl0aWVzIGFuZCBzbGljZXMuIEEgVlBOIGNhbiBiZSBlbWJlZGRlZA0K ICBvbiBhIHNsaWNlLCBidXQgaXQgaXMgbm90IHRoZSBvbmx5IHB1cnBvc2Ugb2YgdGhlIGxhdHRl ciwgc28gc3VjaCBsaW5rDQogIG9mIGNhcGFiaWxpdGllcyBjb3VsZCBlbmQgdXAgaW4gc29tZSBt aXN1bmRlcnN0YW5kaW5ncy4NCg0KLSBTb2Z0d2FyaXphdGlvbiBpcyAidGhlIGFjdCBvZiBjb252 ZXJ0aW5nIGhhcmQtd2FyZSB0byBzb2Z0LXdhcmUiLiBJdA0KICBpcyBub3QgYW4gaW50ZXJmYWNl IG9yIGEgbWVjaGFuaXNtIGJ1dCBhIG1ldGhvZCBhbmQgcHJvY2Vzcy4gQXMgd2l0aA0KICBzbGlj aW5nLCB2aXJ0dWFsaXphdGlvbiBjYW4gYmUgdXNlZCB0byBpbXBsZW1lbnQgc3VjaCAicHJvY2Vz cyIsIGJ1dA0KICBpdCBpcyBub3QgbGltaXRlZCB0byBpdC4gSW4gZmFjdCwgaXQgY291bGQgYmUg dGhlIG90aGVyIHdheSBhcm91bmQsIHNvDQogIHVzaW5nIHNvZnR3YXJpemVkIHN5c3RlbXMgdG8g aW1wbGVtZW50IHZpcnR1YWwgc3lzdGVtcy4gRm9yIGluc3RhbmNlLA0KICBhbiBPcGVuRmxvdyBT d2l0Y2ggaXMgImEgc29md2FyaXplZCBzd2l0Y2giIGFuZCBpdHMgbWFpbiByZWxhdGlvbiB0bw0K ICB2aXJ0dWFsaXphdGlvbiBpcyB0aGF0IHRoZSBmbGV4aWJpbGl0eSBwcm92aWRlZCBieSBzdWNo IHNvZnR3YXJpemF0aW9uDQogIHByb2Nlc3MgY2FuIGJlIHVzZWQgdG8gInNsaWNlIiBhIHBoeXNp Y2FsIHN3aXRjaCBhbmQgcHJvdmlkZSBpc29sYXRlZA0KICB2aXJ0dWFsIHN3aXRjaGVzICh1c2lu ZyBzb21lIHRvb2wgbGlrZSBGbG93Vmlzb3IpLiBUaGlzIHNob3dzIGEgd2F5IG9mDQogIGxpbmsg dGhlIHRocmVlIHRlcm1zIChzbGljaW5nLCBzb2Z0d2FyaXphdGlvbiwgYW5kIHZpcnR1YWxpemF0 aW9uKS4NCg0KQ29udHJhc3RpbmcgdGhlc2UgYW5kIHByZXZpb3VzIGV4cGxhbmF0aW9ucywgYW5k IGNvbnNpZGVyaW5nIGFsbCBvZiB0aGVtIGFzIHZhbGlkIGZyb20gZGlmZmVyZW50IHBlcnNwZWN0 aXZlcywgSSBjb25jbHVkZSB0aGF0IHRoZXJlIGFyZSBzdGlsbCBtYW55IG51YW5jZXMgdGhhdCBu ZWVkIHRvIGJlIGNsYXJpZmllZCBhbmQgbWF5YmUgc29tZSBtaXNjb25jZXB0aW9ucyBvbiBjdXJy ZW50IGNvbmNlcHRzIHRoYXQgc2hvdWxkIGJlIGVyYWRpY2F0ZWQuIFRoZXJlZm9yZSwgSSBpbnNp c3QgaW4gdGhlIG5lZWQgdG8gbWFrZSBzb21lIGNvbGxhYm9yYXRpdmUgZG9jdW1lbnQgKHdpa2ks IEdvb2dsZSBEb2MsIGV0Yy4pIHRvIHRyeSB0byByZWFjaCBhIGNvbW1vbiBhbmQgYWdyZWVkIHNl dCBvZiBkZWZpbml0aW9ucy4NCg0KUmVnYXJkcywNClBlZHJvDQoNCi0tDQpQZWRybyBNYXJ0aW5l ei1KdWxpYQ0KTmV0d29yayBTY2llbmNlIGFuZCBDb252ZXJnZW5jZSBEZXZpY2UgVGVjaG5vbG9n eSBMYWJvcmF0b3J5IE5ldHdvcmsgU3lzdGVtIFJlc2VhcmNoIEluc3RpdHV0ZSBOYXRpb25hbCBJ bnN0aXR1dGUgb2YgSW5mb3JtYXRpb24gYW5kIENvbW11bmljYXRpb25zIFRlY2hub2xvZ3kgKE5J Q1QpIDQtMi0xLCBOdWt1aS1LaXRhbWFjaGksIEtvZ2FuZWksIFRva3lvIDE4NC04Nzk1LCBKYXBh bg0KRW1haWw6IHBlZHJvQG5pY3QuZ28uanANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KKioqIEVudGlhIG5vbiBzdW50IG11bHRpcGxp Y2FuZGEgcHJhZXRlciBuZWNlc3NpdGF0ZW0gKioqDQoNCg== From nobody Mon Feb 6 20:57:30 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114C31299E3 for ; Mon, 6 Feb 2017 20:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.onmicrosoft.com 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 2iXQUMuDsQZo for ; Mon, 6 Feb 2017 20:57:17 -0800 (PST) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0C51299E2 for ; Mon, 6 Feb 2017 20:57:17 -0800 (PST) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3A839ABD719; Mon, 6 Feb 2017 23:57:17 -0500 (EST) Received: from imshyb02.MITRE.ORG (imshyb02.mitre.org [129.83.29.3]) by smtpvmsrv1.mitre.org (Postfix) with ESMTP id 24051ABD6DF; Mon, 6 Feb 2017 23:57:17 -0500 (EST) Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 6 Feb 2017 23:57:16 -0500 Received: from gcc01-CY1-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Mon, 6 Feb 2017 23:57:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.onmicrosoft.com; s=selector1-mitre-org; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9vdi4eexmRetEwatCeEQOslGqMAGoDBEGuP0AP+drJ4=; b=Itusu7YvrPIrzdie0I+HiOg8EOFNgylrikST20k50M+v3rI2YMzekmOw7d9hZxHWC9Wzn+GbG9pU2dtMcP0pjE1F94NUIIaH5WDFbEhUAipSwGo04/55Nlwh9l3aQo2XC3whR3dyvXeIYoG+GRe2PCqxUtmsM8KVTQxddD8ftUw= Received: from CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) by CY1PR09MB0922.namprd09.prod.outlook.com (10.163.89.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 7 Feb 2017 04:57:09 +0000 Received: from CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) by CY1PR09MB0922.namprd09.prod.outlook.com ([10.163.89.140]) with mapi id 15.01.0888.026; Tue, 7 Feb 2017 04:57:09 +0000 From: "Natale, Bob" To: AshwoodsmithPeter , Alex Galis , Network Slices Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvrXaDeoOCGArUagAhaMsA6e+KFcERXwgACKloCAAHqwIA== Date: Tue, 7 Feb 2017 04:57:09 +0000 Message-ID: References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> In-Reply-To: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> 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=RNATALE@mitre.org; x-originating-ip: [192.80.55.87] x-ms-office365-filtering-correlation-id: c06e1873-d09b-439e-c22b-08d44f15c5a7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR09MB0922; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0922; 7:cvKvFrP+c5EgYlR5cgJKj/UqbasBoVvu5MbrnDPrpoqJ4sOlvSAtWWJw/tbQeYhDlPfNF8AE7TljDSmDroiDE02C12di00zTtMUtJNnXYv+9MyTMgYcYjHEpqLC7L+VY+sAhEBvGNj0m399dOayW33tUOuVK7WbufZY8A3tyJZ0j9iZMY+ayRD1TSfnY20BF02Fjpb2vRWuRmNPySBxcmgAQH68PSjQVEljwFtH110YGF5It58uHGCRGdq5mQ1eEvzGCIzIzVi/lBh77gS3ZLIxX4hx4rIw1rjj80RW2q+cjH67AcP4RNkTpm1s1eSKXkXcqidze8h0KyJBn0bv15WtBuiaOb8jqitTgAyaNpRjPiWZ6HD0+gYPtJ9V7Da/dXrXaRYT1QlUL3KABmNzL9VFwXA4ijcI7Td6jKvckCx26aGy9W84uyE3WLmtjInE1wtazz6OJmn/2CWwk0MsREsx8bGOR4UTmjQzD5T0iQ/FOqccxtDcBZhxodSgXdMzRZEUD25T1FgcgOLKrio5FrA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(50582790962513)(57025502571588)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(2017020601047)(8121501046)(20170203043)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123558025)(20161123562025)(6072148); SRVR:CY1PR09MB0922; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0922; x-forefront-prvs: 0211965D06 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39860400002)(39840400002)(39450400003)(39850400002)(39410400002)(189002)(51914003)(199003)(504964003)(377454003)(6246003)(7736002)(92566002)(33656002)(3280700002)(3660700001)(53936002)(345774005)(86362001)(106116001)(106356001)(105586002)(68736007)(8936002)(2900100001)(189998001)(81166006)(81156014)(97736004)(8676002)(122556002)(5660300001)(2906002)(54356999)(50986999)(76176999)(4326007)(2950100002)(790700001)(102836003)(3846002)(6116002)(101416001)(31430400001)(7696004)(229853002)(6306002)(54896002)(19609705001)(25786008)(7906003)(55016002)(54906002)(74316002)(99286003)(66066001)(77096006)(6436002)(606005)(38730400002)(6506006)(9686003)(236005)(39060400001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR09MB0922; H:CY1PR09MB0922.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB09221F84DD41812AF0D1C3BEA8430CY1PR09MB0922namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2017 04:57:09.0251 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0922 X-OriginatorOrg: mitre.org Archived-At: Cc: "Dongjie \(Jimmy\)" , Stewart Bryant , "Kiran.Makhijani" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 04:57:20 -0000 --_000_CY1PR09MB09221F84DD41812AF0D1C3BEA8430CY1PR09MB0922namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the responses, Peter ... I'll stay in "learning mode" on these t= opics (with the aim of overcoming my skepticism :)). (I would appreciate a copy of your presentation to help me in that endeavor= .) Avanti, BobN From: AshwoodsmithPeter [mailto:Peter.AshwoodSmith@huawei.com] Sent: Monday, February 06, 2017 4:57 PM To: Natale, Bob ; Alex Galis ; Networ= k Slices Cc: Dongjie (Jimmy) ; Kiran.Makhijani ; Stewart Bryant Subject: RE: [Netslices] Network Slicing - Introductory Document and Revise= d Problem Statement Hey Bob, Here are a few points that I find useful to understand Slicing and VPN's. 1. A "slice" in the context of 5G is essentially an end to end set of= resources which make up a fully functional wireless network drawn from lar= ger pool of end to end resources. 2. A slice is therefore a superset of the capabilities of an L0,L1,L3= or L3 VPN. 3. An L2VPN or L3VPN is likely a useful connectivity model for the co= ntrol and user plane data paths for the obvious reasons and DETNET type cap= abilities are of interest for stricter QOS guarantees. For even stricter gu= arantees ACTN etc. and L0/L1 control is required. 4. I hate the term "softwarization" also, but essentially it's being = used to describe a programmatic interface to each of the end to end sets of= resources to allow them to be allocated/linked/deallocated/grown/shrunk et= c. and is therefore more than just virtualization but of course covers virt= ualization. I gave a short presentation on this at 5gandIp meeting last year which you = may find useful, I'll be happy to send it to you directly or I suspect it's= on an IETF server somewhere. Cheers, Peter From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Natale, Bo= b Sent: Monday, February 06, 2017 8:25 AM To: Alex Galis >; Network Slice= s > Cc: Dongjie (Jimmy) >; Kira= n.Makhijani >= ; Stewart Bryant = > Subject: Re: [Netslices] Network Slicing - Introductory Document and Revise= d Problem Statement Hi Alex, I just have two basic questions - more like "requests" - for now: - How does a network "slice" differ from all established forms of network v= irtualization (VLANs, VPNs, SDPs, etc.? - Do we really need the term "softwarization" (and its various derivatives)= ... isn't that just a confounding way of saying "virtualization" ... as in= "softwarizing and separating logical network components from the underlying physical network resource= s" ... isn't that latter part what we commonly call virtualization and, if = so, how does "softwarization" differ from it? >From a lurker, BobN From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Alex Galis Sent: Friday, January 20, 2017 3:54 AM To: Network Slices > Cc: Dongjie (Jimmy) >; Stew= art Bryant >; Ale= x Galis >; Kiran.Makhijani > Subject: Re: [Netslices] Network Slicing - Introductory Document and Revise= d Problem Statement 20th January 2017 Dear All Re: Network Slicing - Introductory Document and Revised Problem Statement https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-an= d-ps-00.txt Thank you for your expressed interest in the Network Slicing. One of the action from the Network Slicing side meeting at IETF 97 of 15th = Nov 2016 was to consolidate all suggestions and comments received into an u= nified initial revised problem statement and work plan which would be the b= asis of a BoF at IETF 98 or IETF99. Such an introductory document is ready = for your review and it is enclosed as a draft. Would you be so kind as to provide your feedback, comments, contributions a= nd work interest with the view of further progressing this draft for un upd= ate and presentation at IETF 98. Thank you in advance, Best Regards Alex, Jie, Kiran and Stewart Network Slicing - Introductory Document and Revised Problem Statement Abstract: This document represents an introduction to the motivation and Network Slicing problems and work ares. It represents an initial revision of Network Slicing problem statement derived from the analysis of the technical gaps in IETF protocols ecosystem. It complements and it bring together the isolated efforts being carried out in several IETF working groups to achieve certain aspects of network slice functions and operations. _______________________________________________ Netslices mailing list Netslices@ietf.org https://www.ietf.org/mailman/listinfo/netslices --_000_CY1PR09MB09221F84DD41812AF0D1C3BEA8430CY1PR09MB0922namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the responses, Peter … I’ll sta= y in “learning mode” on these topics (with the aim of overcomin= g my skepticism J).

 

(I would appreciate a copy of your presentation to hel= p me in that endeavor.)

 

Avanti,

BobN

 

From: AshwoodsmithPeter [mailto:Pete= r.AshwoodSmith@huawei.com]
Sent: Monday, February 06, 2017 4:57 PM
To: Natale, Bob <RNATALE@mitre.org>; Alex Galis <a.galis@uc= l.ac.uk>; Network Slices <netslices@ietf.org>
Cc: Dongjie (Jimmy) <jie.dong@huawei.com>; Kiran.Makhijani <= ;Kiran.Makhijani@huawei.com>; Stewart Bryant <stewart.bryant@gmail.co= m>
Subject: RE: [Netslices] Network Slicing - Introductory Document and= Revised Problem Statement

 

Hey Bob,

 

Here are a few points that I find use= ful to understand Slicing and VPN’s.

 

1.   = ;    A “slice” in the = context of 5G is essentially an end to end set of resources which make up a= fully functional wireless network drawn from larger pool of end to end resources.

 

2.   = ;    A slice is therefore a superset of the capabilities of an L0,L1,L3 or L3 VPN.

 

3.   = ;    An L2VPN or L3VPN is likely a= useful connectivity model for the control and user plane data paths for th= e obvious reasons and DETNET type capabilities are of interest for stricter QOS guarantees. For even stricter guarantees = ACTN etc. and L0/L1 control is required.

 

4.   = ;    I hate the term “softwa= rization” also, but essentially it’s being used to describe a p= rogrammatic interface to each of the end to end sets of resources to allow them to be allocated/linked/deallocated/grown/shrunk etc. and is = therefore more than just virtualization but of course covers virtualization= .

 

I gave a short presentation on this a= t 5gandIp meeting last year which you may find useful, I’ll be happy = to send it to you directly or I suspect it’s on an IETF server somewhere.

 

Cheers,

 

Peter

 

 

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Natale, Bob
Sent: Monday, February 06, 2017 8:25 AM
To: Alex Galis <a.galis@ucl.= ac.uk>; Network Slices <net= slices@ietf.org>
Cc: Dongjie (Jimmy) <jie.d= ong@huawei.com>; Kiran.Makhijani <Kiran.Makhijani@huawei.com>; Stewart Bryant <stewart.bryant@gmail.com>
Subject: Re: [Netslices] Network Slicing - Introductory Document and= Revised Problem Statement

 

Hi Alex,

 

I just have two basic questions – more like R= 20;requests” – for now:

 

- How does a network “slice” differ from a= ll established forms of network virtualization (VLANs, VPNs, SDPs, etc.?

 

- Do we really need the term “softwarizationR= 21; (and its various derivatives) … isn’t that just a confoundi= ng way of saying “virtualization” … as in “softwari= zing and separating

   logical network components from the under= lying physical network resources” … isn’t that latter par= t what we commonly call virtualization and, if so, how does “softwari= zation” differ from it?

 

From a lurker,

BobN

 

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Alex Galis
Sent: Friday, January 20, 2017 3:54 AM
To: Network Slices <netslic= es@ietf.org>
Cc: Dongjie (Jimmy) <jie.d= ong@huawei.com>; Stewart Bryant <stewart.bryant@gmail.com>; Alex Galis <a.galis@ucl.ac.uk>; Kiran.Makhijani <Kiran.Makhijani@huawei.c= om>
Subject: Re: [Netslices] Network Slicing - Introductory Document and= Revised Problem Statement

 

 



20th January 2017


Dear All

 
Re:  Network Slicing - Introductory Document and Revised Problem State= ment

         https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-and-ps-00.t= xt

 

Thank you for your expressed interest in the Network Slicing.

One of the action from the Network Slicing side meeting at IETF 97 of 15th = Nov 2016 was to consolidate all suggestions and comments received into an u= nified initial revised problem statement and work plan which would be the b= asis of a BoF at IETF 98 or IETF99. Such an introductory document is ready for your review and it is enclosed = as a draft.
 
Would you be so kind as to provide your feedback, comments, contributions a= nd work interest with the view of further progressing this draft for un upd= ate and presentation at IETF 98.
 
Thank you in advance,
Best Regards
Alex, Jie, Kiran and Stewart
 
 
 
Network Slicing - Introductory Document and Revised Problem Statement
 
Abstract:
  This document represents an introduction to the motivation and
  Network Slicing problems and work ares. It represents an initial
  revision of Network Slicing problem statement derived from the
  analysis of the technical gaps in IETF protocols ecosystem. It
  complements and it bring together the isolated efforts being carried=
  out in several IETF working groups to achieve certain aspects of
  network slice functions and operations.

___________________= ____________________________
Netslices mailing list
Netslices@ietf.org
https://www.iet= f.org/mailman/listinfo/netslices

--_000_CY1PR09MB09221F84DD41812AF0D1C3BEA8430CY1PR09MB0922namp_-- From nobody Mon Feb 6 21:26:26 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B12B129A0E for ; Mon, 6 Feb 2017 21:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 47RDvQekL1Vg for ; Mon, 6 Feb 2017 21:26:22 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD89129A0C for ; Mon, 6 Feb 2017 21:26:22 -0800 (PST) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id v175Q93m089571; Tue, 7 Feb 2017 14:26:09 +0900 (JST) Received: from mail2.nict.go.jp (mail2.nict.go.jp [133.243.18.15]) by gw1.nict.go.jp with ESMTP id v175Q9Sk089506; Tue, 7 Feb 2017 14:26:09 +0900 (JST) Received: from spectre (unknown [133.243.115.68]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.nict.go.jp (NICT Mail Spool Server2) with ESMTPS id 2EAA79417; Tue, 7 Feb 2017 14:26:09 +0900 (JST) Date: Tue, 7 Feb 2017 14:26:10 +0900 From: Pedro Martinez-Julia To: "Natale, Bob" Message-ID: <20170207052610.GT12800@spectre> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Virus-Scanned: clamav-milter 0.98.7 at zenith1 X-Virus-Status: Clean Archived-At: Cc: "Dongjie \(Jimmy\)" , Network Slices , AshwoodsmithPeter , "Kiran.Makhijani" , Stewart Bryant , Alex Galis Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 05:26:24 -0000 On Tue, Feb 07, 2017 at 04:53:34AM +0000, Natale, Bob wrote: > Hi Pedro, > > Concerning your explanation that 'Softwarization is "the act of > converting hard-ware to soft-ware"', isn't that just "function > virtualization" as in, for example, NFV? They can be somehow related but it is not the same concept. Using NFV to illustrate the difference, it defines a set of fixed functions that are virtualized, but the resulting functions are not 100% soft-ware because they resemble the corresponding "hardware", which is quite fixed. Taking this into account I would say that NFV is a mechanism for softwarizing a network infrastructure (making it more flexible, programmable, etc.) but it is only limited to the infrastructure boundary because the functions themselves are "hard-fixed" unless they are also softwarized. I hope this adds some useful concepts about the relations and diferences between virtualization and softwarization... > Avanti, > BobN Regards, Pedro -- Pedro Martinez-Julia Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: pedro@nict.go.jp --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** From nobody Mon Feb 6 22:01:52 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7BE129A64 for ; Mon, 6 Feb 2017 22:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4ae_Ou4lTJaY for ; Mon, 6 Feb 2017 22:01:49 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 86226129A63 for ; Mon, 6 Feb 2017 22:01:49 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id v184so35560483pgv.3 for ; Mon, 06 Feb 2017 22:01:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:date:subject:to:message-id :mime-version; bh=IpRAyf7IERLVao7rX4vj38RKSZWHEbgpwZFRyLLx7Hg=; b=dBmJkz2hO7UzAf/Ug47Gg8tVz/fmz2224jYgK/2i1gw/Q526ZhR60YeSRB9CoOwUSI eyfmfnSWOVKv9G+QXZyrPUuGK/UtY23ykYsWJR7686eBRA65mJlC4HQcJWFHZNyykNiO L7ceqATpd1ej6g8lGkKC5JN6PtiHq6Ogn2lGAFfs7Jh16UsFIWJSt1iM4BuaQiFskZsO 28r1dCcL2NxUHjjq9AV/mYhrbsgg6EMDWpbHQuHeoNytlD2flHlmt/p10anHa7QVNIM/ PH+zrVjBy7zSa4gX0hrUBkNE2XJdKEaTLXSuU7Rjv+6/LDydjySGJG/ZEGI2bI5U7QGw muCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:date:subject:to :message-id:mime-version; bh=IpRAyf7IERLVao7rX4vj38RKSZWHEbgpwZFRyLLx7Hg=; b=d0finepT6yDC4Pr1N7rrxZSLUK2fI8Gvs/bbMjL0gotznio5UAFMYihJVNnf4iRZ3M iJ8/6CalGbtKgOeJEFAhsXtZkaVwEOXUBuDTL+Hv6/q44aQabdsp9Csvux/vjI8aiHFe xyRil+O/KqOCMLeZ2Mo+e2kL2wrTxNmANusRDHomU8n2D0Q+AxjPfoCf61KZweSwM25c QuHg/jxCTzirV7K2Z2Xjx7TVt80WhO6hWFhUODPwITU0lQor8Ja9DsxL8/ixvXQg2dZD j0P7tT4ZRhjq5hYNNaYTpg9Tojl3yt+iBpTal9rE6ZjpLtfAyKvvkn45vAwpqMBkCTi3 W5jg== X-Gm-Message-State: AIkVDXIo10Lumr+nYdxgE+y2YMAxdGPJYuehrXOg/gCXvHcoslhbEDZgaGvG3oxsBFOvZA== X-Received: by 10.99.133.65 with SMTP id u62mr18248495pgd.70.1486447308891; Mon, 06 Feb 2017 22:01:48 -0800 (PST) Received: from [10.207.114.161] ([202.45.12.164]) by smtp.gmail.com with ESMTPSA id t185sm7200750pgb.32.2017.02.06.22.01.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 06 Feb 2017 22:01:48 -0800 (PST) From: Satoru Matsushima Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Feb 2017 15:01:46 +0900 To: netslices@ietf.org Message-Id: <503A1908-2068-47A2-B8E0-5D7E3BF88444@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Netslices] Data-plane work in DMM WG with slicing concept X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 06:01:51 -0000 All, IETF DMM (Distributed Mobility Management) working group has been = chartered=20 to make separation of data-plane from mobile control-plane, which = defines=20 data-plane obstruction models with network slicing concept. Through the discussion on the Netslices list, I=E2=80=99ve noticed what = the draft calls =E2=80=9CDomain=E2=80=9D would almost close to =E2=80=9CNetwork = Slicing=E2=80=9D.=20 Data-plane model of FPC provides information and data model by YANG for = mobile network which IMO would be helpful to figure slicing model out.=20 FPC-topology tree is one for that. FPC-policy would be requirements to = the slice. https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/ Protocol for Forwarding Policy Configuration (FPC) in DMM draft-ietf-dmm-fpc-cpdp-05.txt Abstract This document describes the solution of data-plane separation from control-plane which enables a flexible mobility management system using agent and client functions. To configure data-plane nodes and functions, the data-plane is abstracted by an agent interface to the client. The data-plane abstraction model is extensible in order to support many different type of mobility management systems and data- plane functions. Best regards, --satoru= From nobody Mon Feb 6 23:04:42 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B915129A9A for ; Mon, 6 Feb 2017 23:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 YHSRMQEA4vgQ for ; Mon, 6 Feb 2017 23:04:39 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 A84FB12009C for ; Mon, 6 Feb 2017 23:04:39 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id 14so36185782pgg.1 for ; Mon, 06 Feb 2017 23:04:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=+BF/OvKo2RQ0dZ/x1cnNpXIIXr+pfQLZQf/HpuYhyJk=; b=SB6swIch6gDT26Yk+xF+Euady0FChXaRKw+SAFYfR9e0ARTa60qj+rzanPIZgMmFPV crCPmxWyelLwXTS6KNnEtZDvYvJDVWs8fKnaCom4Q1pf7KDLZV4jwWnMbIpvuZQUvxSG I/g8Vzr5cuoyZzCA/K1g9QYZNqJKemlM+mEghcqq2RSgS6nmp/GzwPCEFEM+QiuT2gJ7 pynTnIggrOLfqs9A3PE1Zt4r0l4o64e4Sf3JIapEZa7u9ZGEspsttgKz6Kr1kIcDA4aq 28BKJgUOp5Z2VHn4eaxWoO5Kfn/9dDYXrTowho196WCAYs8+mofrFZ088t+NECKythI1 Jp2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=+BF/OvKo2RQ0dZ/x1cnNpXIIXr+pfQLZQf/HpuYhyJk=; b=pDq+tRrMGDAn1OfTxVxO0zoxNHqMF87yBdYOc0/oAR6uT2S4aQQQhlbYWpen6vUjUH hXDKl2Egtz0Z0v1NEy61Pb/TX3hh20l/Xx5jpe4vJo25MK146t0hIx85EgbNgfeyeqLf yOq6N1YubCKPyGB6bdta9563Eis3mobDYKXZ0kgk/rt7tIxxdBfhRgrmMjb4ldJYoq/4 AmPWYM/VQlnK71pqGCJFa2g0UlV3bG36N+Oh4ymksWI26dT4c0Tj3e5rGrhDKr5D8Omo Z6xvdDfjboBN+Tr2hyXUVyo/X+6nWZ9tHrsBITuFwCxKSVxYyaBZX9ttKPzH+pPUhHER hpJQ== X-Gm-Message-State: AIkVDXKInSXDOAeqbyr3dACFoSsXnFcLAlVYnUc/h8QeAgah5gVfvxIE5EzwATPSKtwyXQ== X-Received: by 10.99.64.4 with SMTP id n4mr18363063pga.71.1486451079207; Mon, 06 Feb 2017 23:04:39 -0800 (PST) Received: from [10.207.114.161] ([202.45.12.164]) by smtp.gmail.com with ESMTPSA id i10sm7870732pgd.37.2017.02.06.23.04.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 06 Feb 2017 23:04:38 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Satoru Matsushima In-Reply-To: <503A1908-2068-47A2-B8E0-5D7E3BF88444@gmail.com> Date: Tue, 7 Feb 2017 16:04:36 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <503A1908-2068-47A2-B8E0-5D7E3BF88444@gmail.com> To: netslices@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Netslices] Data-plane work in DMM WG with slicing concept X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 07:04:41 -0000 oops, s/obstruction/abstraction/; --satoru > 2017/02/07 15:01=E3=80=81Satoru Matsushima = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A= >=20 > All, >=20 > IETF DMM (Distributed Mobility Management) working group has been = chartered=20 > to make separation of data-plane from mobile control-plane, which = defines=20 > data-plane obstruction models with network slicing concept. >=20 > Through the discussion on the Netslices list, I=E2=80=99ve noticed = what the draft calls > =E2=80=9CDomain=E2=80=9D would almost close to =E2=80=9CNetwork = Slicing=E2=80=9D.=20 >=20 > Data-plane model of FPC provides information and data model by YANG = for mobile network > which IMO would be helpful to figure slicing model out.=20 >=20 > FPC-topology tree is one for that. FPC-policy would be requirements to = the slice. >=20 >=20 > https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/ >=20 >=20 > Protocol for Forwarding Policy Configuration (FPC) in DMM > draft-ietf-dmm-fpc-cpdp-05.txt >=20 >=20 > Abstract >=20 >=20 > This document describes the solution of data-plane separation from > control-plane which enables a flexible mobility management system > using agent and client functions. To configure data-plane nodes and > functions, the data-plane is abstracted by an agent interface to the > client. The data-plane abstraction model is extensible in order to > support many different type of mobility management systems and data- > plane functions. >=20 > Best regards, > --satoru From nobody Mon Feb 6 23:19:49 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34288129A9B for ; Mon, 6 Feb 2017 23:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 fGnCrrQHA-VG for ; Mon, 6 Feb 2017 23:19:46 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31CD712009C for ; Mon, 6 Feb 2017 23:19:46 -0800 (PST) Received: from [192.168.1.11] (unknown [112.204.169.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 968B518013BE for ; Tue, 7 Feb 2017 08:19:43 +0100 (CET) To: netslices@ietf.org References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> From: Loa Andersson Message-ID: <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> Date: Tue, 7 Feb 2017 15:19:39 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170207052610.GT12800@spectre> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 07:19:48 -0000 Folks, I may be kicking in open doors, or alternatively showing that I misunderstood thing fundamentally. I thought that "network slicing" meant that a network provider can give a network user, a slice of the network (with all functions needed), to satisfy the network users requirements. So E2E if E2E is needed. /Loa On 2017-02-07 13:26, Pedro Martinez-Julia wrote: > On Tue, Feb 07, 2017 at 04:53:34AM +0000, Natale, Bob wrote: >> Hi Pedro, >> >> Concerning your explanation that 'Softwarization is "the act of >> converting hard-ware to soft-ware"', isn't that just "function >> virtualization" as in, for example, NFV? > > They can be somehow related but it is not the same concept. Using NFV to > illustrate the difference, it defines a set of fixed functions that are > virtualized, but the resulting functions are not 100% soft-ware because > they resemble the corresponding "hardware", which is quite fixed. Taking > this into account I would say that NFV is a mechanism for softwarizing a > network infrastructure (making it more flexible, programmable, etc.) but > it is only limited to the infrastructure boundary because the functions > themselves are "hard-fixed" unless they are also softwarized. > > I hope this adds some useful concepts about the relations and diferences > between virtualization and softwarization... > >> Avanti, >> BobN > > Regards, > Pedro > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Feb 7 01:20:42 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B608129504 for ; Tue, 7 Feb 2017 01:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.785 X-Spam-Level: X-Spam-Status: No, score=-3.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 GXRVXDQUpbBN for ; Tue, 7 Feb 2017 01:20:35 -0800 (PST) Received: from mail1.bemta6.messagelabs.com (mail1.bemta6.messagelabs.com [193.109.254.106]) (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 DFF111294E8 for ; Tue, 7 Feb 2017 01:20:34 -0800 (PST) Received: from [193.109.255.99] by server-2.bemta-6.messagelabs.com id 4D/A2-22326-06199985; Tue, 07 Feb 2017 09:20:32 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleJIrShJLcpLzFFi42LR98zp1o2dODP CYMJ1YYt/c+cwWzT2L2F0YPJYsuQnk8es6W1sAUxRrJl5SfkVCawZGw/0MRf8EKvouzaJvYHx j1AXIxeHkMA2Romz87cxQjiHGCX2v/8F5RxmlPjRtJoJwtnMKPHy9w72LkZODjYBV4mju+6A2 SICHhIrOhezgtjCAvESrcf3skHEEyQO3NrADGFHSSxbuhssziKgIvH//RkmEJtXIFTiVOMOFo gFc5glFmzpB0twClhKzLr8BayBUUBW4kvjarBBzALiEreezAerkRAQkFiy5zwzhC0q8fLxP1a IGh2JBbs/sUHY2hLLFr5mhlgmKHFy5hMWEFtIQFXixKE5bBMYRWchGTsLSfssJO2zkLQvYGRZ xahRnFpUllqka2iml1SUmZ5RkpuYmaNraGCml5taXJyYnpqTmFSsl5yfu4kRGEsMQLCD8f7Gg EOMkhxMSqK8hV4zI4T4kvJTKjMSizPii0pzUosPMcpwcChJ8CpPAMoJFqWmp1akZeYAoxomLc HBoyTCKwKS5i0uSMwtzkyHSJ1iVJQS5xUHSQiAJDJK8+DaYInkEqOslDAvI9AhQjwFqUW5mSW o8q8YxTkYlYR5U0Gm8GTmlcBNfwW0mAlo8bYr00AWlyQipKQaGFOLVHtjlnNUfjE4U5si1Fm7 fMZNIan6uSs3TVUqL2Nf8477gqjDxaO2uuzyjptuRc3ZGSTalnDq+0bDM2cz2r66u2ety2df/ so65viJ9HMflrxxCZ4b/4zjxF+1fK+L4nx/Wb8lZW0K041eqVAZ0tg+JUld7lOsyY4FLyZc63 2udp/77j+PGiWW4oxEQy3mouJEAEMAOxofAwAA X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-8.tower-48.messagelabs.com!1486459229!84163444!1 X-Originating-IP: [47.73.108.139] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25981 invoked from network); 7 Feb 2017 09:20:29 -0000 Received: from vgdpm13vr.vodafone.com (HELO voxe03hw.internal.vodafone.com) (47.73.108.139) by server-8.tower-48.messagelabs.com with AES256-SHA256 encrypted SMTP; 7 Feb 2017 09:20:29 -0000 Received: from VOEXH11W.internal.vodafone.com (47.73.211.215) by edge1.vodafone.com (195.232.244.48) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 7 Feb 2017 10:20:27 +0100 Received: from VOEXC04W.internal.vodafone.com (145.230.101.24) by VOEXH11W.internal.vodafone.com (47.73.211.209) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 7 Feb 2017 10:20:26 +0100 Received: from AVOEXH03W.internal.vodafone.com (145.230.15.141) by VOEXC04W.internal.vodafone.com (145.230.101.24) with Microsoft SMTP Server (TLS) id 14.3.294.0; Tue, 7 Feb 2017 10:20:26 +0100 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.118]) by AVOEXH03W.internal.vodafone.com ([145.230.15.141]) with mapi id 14.03.0294.000; Tue, 7 Feb 2017 10:20:26 +0100 From: "Smith, Kevin, (R&D) Vodafone Group" To: Loa Andersson , "netslices@ietf.org" Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvq6cbf2LwP39U2AqU8b9Ij7AaFcAjqAgACPA4CAACsogIAASScAgAAJHACAAB+1gIAAMClg Date: Tue, 7 Feb 2017 09:20:25 +0000 Message-ID: References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> In-Reply-To: <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 09:20:39 -0000 Hi Loa, > I thought that "network slicing" meant that a network provider can give a= network user, a slice of the network (with all functions needed), to satis= fy the network users requirements. So E2E if E2E is needed. Yes, although that may not be fully E2E if the origin server is hosted out= side of the providers' network. Network slicing should allow the network pr= ovider to rapidly allocate/deallocate network resources towards flows, base= d on the characteristics of each flow. So each flow will demand a certain b= lend of latency, mobility, capacity, resilience, pacing, durability etc. - = it doesn't necessarily need to be a function as such, although those can be= added a la service chaining if required. In a cellular network this can al= so include radio resources, so terminal-to-external-edge-of-operator-networ= k (maybe 'operator domain' is snappier :)). All best, Kevin Kevin Smith, Vodafone -----Original Message----- From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Loa Anders= son Sent: 07 February 2017 07:20 To: netslices@ietf.org Subject: Re: [Netslices] Network Slicing - Introductory Document and Revise= d Problem Statement Folks, I may be kicking in open doors, or alternatively showing that I misundersto= od thing fundamentally. I thought that "network slicing" meant that a network provider can give a n= etwork user, a slice of the network (with all functions needed), to satisfy= the network users requirements. So E2E if E2E is needed. /Loa On 2017-02-07 13:26, Pedro Martinez-Julia wrote: > On Tue, Feb 07, 2017 at 04:53:34AM +0000, Natale, Bob wrote: >> Hi Pedro, >> >> Concerning your explanation that 'Softwarization is "the act of=20 >> converting hard-ware to soft-ware"', isn't that just "function=20 >> virtualization" as in, for example, NFV? > > They can be somehow related but it is not the same concept. Using NFV=20 > to illustrate the difference, it defines a set of fixed functions that=20 > are virtualized, but the resulting functions are not 100% soft-ware=20 > because they resemble the corresponding "hardware", which is quite=20 > fixed. Taking this into account I would say that NFV is a mechanism=20 > for softwarizing a network infrastructure (making it more flexible,=20 > programmable, etc.) but it is only limited to the infrastructure=20 > boundary because the functions themselves are "hard-fixed" unless they ar= e also softwarized. > > I hope this adds some useful concepts about the relations and=20 > diferences between virtualization and softwarization... > >> Avanti, >> BobN > > Regards, > Pedro > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ Netslices mailing list Netslices@ietf.org https://www.ietf.org/mailman/listinfo/netslices From nobody Tue Feb 7 09:16:10 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4BF1293D9 for ; Tue, 7 Feb 2017 09:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.221 X-Spam-Level: X-Spam-Status: No, score=-3.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 GOldXZahdDC3 for ; Tue, 7 Feb 2017 09:16:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4ACE12944F for ; Tue, 7 Feb 2017 09:16:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAE43810; Tue, 07 Feb 2017 17:16:03 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Feb 2017 17:16:02 +0000 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.133]) by SJCEML701-CHM.china.huawei.com ([169.254.3.132]) with mapi id 14.03.0235.001; Tue, 7 Feb 2017 09:15:54 -0800 From: Leeyoung To: "Kiran.Makhijani" , "Dongjie (Jimmy)" , "netslices@ietf.org" Thread-Topic: [Netslices] Discussion about network slicing in IETF Thread-Index: AQHSgN7QQQU/hdFeu02poLyUO2CZP6Fdx3qA Date: Tue, 7 Feb 2017 17:15:54 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172B29564C@SJCEML702-CHM.china.huawei.com> References: <143B3310-E8F2-4FF0-A481-89188C800B9F@huawei.com> In-Reply-To: <143B3310-E8F2-4FF0-A481-89188C800B9F@huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.218.137.165] 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.0A020204.589A00D3.036E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.133, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8e22a9ab9e8759fb3bb8f1513c9dd287 Archived-At: Subject: Re: [Netslices] Discussion about network slicing in IETF X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 17:16:08 -0000 SGkgS2lyYW4sDQoNCkhlcmUncyB0aGUgbGF0ZXN0IEFDVE4gZnJhbWV3b3JrIGFuZCBSZXF1aXJl bWVudHMgZm9yIHlvdXIgcmVmZXJlbmNlIGlmIHlvdSB3YW50IHRvIGtub3cgbW9yZSBhYm91dCBB Q1ROLiBBQ1ROIGlzIG5vdCBqdXN0IGEgY29udHJvbGxlciBzb2x1dGlvbi4gSXQgYWxsb3dzIHRo ZSB0aGlyZCBwYXJ0eSBjdXN0b21lcnMvY2xpZW50cyB0byBpbnN0YW50aWF0ZSBWaXJ0dWFsIE5l dHdvcmtzIHRvIHRoZSBvcGVyYXRvciBuZXR3b3JrcyB0byBiZSBhYmxlIHRvIG93biBhbmQgY29u dHJvbCBWTiBzbGljaW5nIGFzIHRoZXkgd2lsbC4gQnV0IGFzIHlvdSBzYWlkLCB0aGVyZSBtYXkg YmUgb3RoZXIgbmV0d29yayByZXNvdXJjZXMgdGhhdCB5b3UgaGF2ZSBpbiBtaW5kIGluIGEgbGFy Z2VyIGNvbnRleHQgYmV5b25kIHdoYXQgQUNUTiBpcyBjb3ZlcmluZy4gSSB3b3VsZCBiZSBpbnRl cmVzdGVkIGluIGhlYXJpbmcgd2hhdCB3b3VsZCBiZSB0aGVzZSAib3RoZXIiIHJlc291Y2VzIHlv dSB3b3VsZCBsaWtlIHRvIGluY2x1ZGUgaW4gdGhlICBuZXcgd29yayAoTmV0U2xpY2VzKS4gDQoN Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRlYXMtYWN0bi1mcmFtZXdv cmstMDMgDQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRlYXMt YWN0bi1yZXF1aXJlbWVudHMvIA0KDQpUaGFua3MuDQpZb3VuZw0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogS2lyYW4uTWFraGlqYW5pIA0KU2VudDogTW9uZGF5LCBGZWJydWFy eSAwNiwgMjAxNyA3OjA5IFBNDQpUbzogTGVleW91bmcgPGxlZXlvdW5nQGh1YXdlaS5jb20+OyBE b25namllIChKaW1teSkgPGppZS5kb25nQGh1YXdlaS5jb20+OyBuZXRzbGljZXNAaWV0Zi5vcmcN ClN1YmplY3Q6IFJlOiBbTmV0c2xpY2VzXSBEaXNjdXNzaW9uIGFib3V0IG5ldHdvcmsgc2xpY2lu ZyBpbiBJRVRGDQoNCkhlbGxvIFlvdW5nLCANClRvIG1lLCBpdCBoYXMgYSBicm9hZGVyIHNjb3Bl OyB0byBsb29rIGF0IG92ZXJhbGwgcmVzb3VyY2UgZWZmaWNpZW5jeSwgYWdpbGl0eSBhbmQgaW5k ZXBlbmRlbnQgM3JkIHBhcnR5IHNsaWNlIGNvbnRyb2wgb3ZlciBkaWZmZXJlbnQgbmV0d29yayBz ZWdtZW50cyBhbmQgbmV0d29yayBmdW5jdGlvbnMuIFdpdGggbGltaXRlZCBrbm93bGVkZ2Ugb24g QUNUTiwgbXkgYXNzdW1wdGlvbiBpcyB0aGF0IGl0IGlzIGEgY2VudHJhbGl6ZWQgY29udHJvbGxl ciBzb2x1dGlvbiB3aXRoIG1haW4gZ29hbCB0byBjb21wdXRlIGNvbnN0cmFpbnRzIGJhc2VkIHBh dGhzIG92ZXIgd2hhdCdzIGFic3RyYWN0ZWQgZnJvbSB2YXJpb3VzIGNvbnRyb2xsZXJzLiBOZXRT bGljZXMgc2hvdWxkbuKAmXQgYmluZCB0byBjZW50cmFsLCBoaWVyYXJjaGljYWwgb3IgZGlzdHJp YnV0ZWQgYXBwcm9hY2ggKGF0IGxlYXN0IGF0IHRoZSBiZWdpbm5pbmcpLiAgSW4gdGhhdCBzZW5z ZSwgbGV04oCZcyBsb29rIGF0IHNsaWNlcyBmcm9tIGFsbCBhc3BlY3RzIGRhdGEsIGNvbnRyb2ws IG1hbmFnZW1lbnQgYW5kIHNlcnZpY2VzIGluIGEgZ2VuZXJpYyBmYXNoaW9uLg0KDQpJIGFncmVl IHdpdGggUGVkcm/igJlzIGVtYWlsIHN1Z2dlc3Rpb24gdGhhdCBhIGNvdXBsZSBvZiBjb2xsYWJv cmF0aXZlIGxpdmUgZG9jdW1lbnRzIHdpbGwgYmUgZ29vZCBzdGFydGluZyBwb2ludC4NCg0KUmVn YXJkcw0KS2lyYW4gDQoNCk9uIDIvNi8xNywgMzoxMSBQTSwgIk5ldHNsaWNlcyBvbiBiZWhhbGYg b2YgTGVleW91bmciIDxuZXRzbGljZXMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbGVl eW91bmdAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCiAgICBIaSBKaW0sDQogICAgDQogICAgSSBjYW4g c3BlYWsgZm9yIEFDVE4uIFBsZWFzZSBzZWUgaW5saW5lIGZvciBteSBjb21tZW50Lg0KICAgIA0K ICAgIFRoYW5rcy4NCiAgICBZb3VuZw0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQogICAgRnJvbTogTmV0c2xpY2VzIFttYWlsdG86bmV0c2xpY2VzLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBEb25namllIChKaW1teSkNCiAgICBTZW50OiBNb25kYXksIEZlYnJ1 YXJ5IDA2LCAyMDE3IDc6NTMgQU0NCiAgICBUbzogbmV0c2xpY2VzQGlldGYub3JnDQogICAgU3Vi amVjdDogW05ldHNsaWNlc10gRGlzY3Vzc2lvbiBhYm91dCBuZXR3b3JrIHNsaWNpbmcgaW4gSUVU Rg0KICAgIA0KICAgIERlYXIgYWxsLCANCiAgICANCiAgICBBY2NvcmRpbmcgdG8gc29tZSBlYXJs eSBpbnZlc3RpZ2F0aW9ucywgdGhlIHRvcGljIG5ldHdvcmsgc2xpY2luZyB3b3VsZCBjcm9zcyBz ZXZlcmFsIFdHcywgZXZlbiBtdWx0aXBsZSBBcmVhcyBpbiBJRVRGLCBhbmQgdGhlcmUgYXJlIHNv bWUgZXhpc3RpbmcgYW5kIG9uZ29pbmcgd29ya3MgaW4gSUVURiByZWxhdGVkIHRvIG5ldHdvcmsg c2xpY2luZywgc3VjaCBhcyB0aGUgdmFyaW91cyBWUE4gdGVjaG5vbG9naWVzLCB0aGUgb25nb2lu ZyBBQ1ROIHdvcmsgaW4gVEVBUyBXRywgdGhlIHdvcmsgb24gZGV0ZXJtaW5pc3RpYyBuZXR3b3Jr IGluIERFVE5FVCBXRywgdGhlIHdvcmsgb24gYXV0b25vbWljIG1hbmFnZW1lbnQgaW4gQU5JTUEg V0csIGV0Yy4gVGhyb3VnaCB0aGUgZGlzY3Vzc2lvbiBvbiB0aGlzIG1haWxpbmcgbGlzdCwgd2Un ZCBsaWtlIHRvIHVuZGVyc3RhbmQgaWYgdGhlcmUgYXJlIGdhcHMgaW4gbWVldGluZyB0aGUgbmV0 d29yayBzbGljaW5nIHJlcXVpcmVtZW50cywgYW5kIGlmIG5lZWRlZCwgdG8gY29tYmluZSB0aGUg ZXhpc3RpbmcgYW5kIG9uZ29pbmcgd29ya3MsIHRvZ2V0aGVyIHdpdGggcG90ZW50aWFsIHByb3Rv Y29sIGVuaGFuY2VtZW50cyBvciBuZXcgcHJvdG9jb2xzIHRvIGFjaGlldmUgbmV0d29yayBzbGlj aW5nIG9mIHRoZSBtb2JpbGUgdHJhbnNwb3J0IG5ldHdvcmsuIA0KICAgIA0KICAgIEluIG9yZGVy IHRvIGhhdmUgYmV0dGVyIHVuZGVyc3RhbmRpbmcgb2YgdGhlIGdhcHMgaW4gdHJhbnNwb3J0IG5l dHdvcmsgc2xpY2luZywgd2UgbWF5IHN0YXJ0IHdpdGggYSBmZXcgcXVlc3Rpb25zOiANCiAgICAN CiAgICAxLiBUbyB3aGF0IGV4dGVudCBjYW4gdGhlIHJlcXVpcmVtZW50cyBvZiBuZXR3b3JrIHNs aWNpbmcgaW4gZGF0YSBwbGFuZSBiZSBhZGRyZXNzZWQgYnkgZXhpc3RpbmcgSUVURiB0ZWNobm9s b2dpZXMgc3VjaCBhcyBWUE5zIChhbmQgVlBOIGxpa2UgdGVjaG5vbG9naWVzKT8gV2Ugbm90ZSBp biBhc2tpbmcgdGhpcyB0aGF0IGluIHNvbWUgY2FzZXMgVlBOcyBtYXkgbmVlZCB0byBiZSBlbmhh bmNlZCBieSBzb21lIGRldGVybWluaXN0aWMgdGVjaG5vbG9neSBzdWNoIGFzIHRoYXQgYmVpbmcg aW52ZXN0aWdhdGVkIGluIHRoZSBERVRORVQgV0cuDQogICAgDQogICAgQW5kIHRvIHdoYXQgZXh0 ZW50IGRvIHRoZSBjb250cm9sIHBsYW5lcyBvZiBleGlzdGluZyB0ZWNobm9sb2dpZXMgc2F0aXNm eSB0aGUgbmVlZHMgb2YgbmV0d29yayBzbGljaW5nPyBOb3RlIHRoYXQgaW4gc29tZSA1RyB1c2Ug Y2FzZXMgdGhlIGN1c3RvbWl6ZWQgb3IgZGVkaWNhdGVkIGNvbnRyb2wgcGxhbmUgbWF5IGJlIG5l ZWRlZCBmb3Igc29tZSBvZiB0aGUgbmV0d29yayBzbGljZXMsIHdoaWxlIGluIHNvbWUgb3RoZXIg Y2FzZXMgdGhlIGNvbnRyb2wgcGxhbmUgbWF5IGJlIHNoYXJlZCBiZXR3ZWVuIHNsaWNlcy4NCiAg ICANCiAgICAyLiBEb2VzIEFDVE4gY29tcGxldGVseSBzYXRpc2Z5IHRoZSBhYnN0cmFjdGlvbiBv ZiBOZXR3b3JrIFNsaWNlcyAoTlMpIHRvIHRoZSBvcGVyYXRvcnMgb3IgdGhlIGN1c3RvbWVycyB3 aG8gaW5zdGFudGlhdGUsIG1vbml0b3IgYW5kIG1hbmFnZSBhbiBOUyB0aHJvdWdoIGl0cyBsaWZl Y3ljbGUsIGluY2x1ZGluZyBkeW5hbWljYWxseSBjaGFuZ2luZyBhIHNsaWNlIHRvIGFjY291bnQg Zm9yIHRoZSB2YXJ5aW5nIG5lZWRzIGR1cmluZyBpdHMgbGlmZWN5Y2xlIGZyb20gY3JlYXRpb24g dG8gZGlzcG9zYWwsIGlzIHRoZXJlIGFueSBhZGRpdGlvbmFsIG1lY2hhbmlzbSBhbHNvIHJlcXVp cmVkPw0KICAgIA0KICAgIFlPVU5HPj4gSSB0aGluayBzby4gQUNUTiBhbGxvd3MgVk4gc2xpY2Ug dG8gYmUgY3JlYXRlZC9tb25pdG9yZWQvbW9kaWZpZWQvZGVsZXRlZCBkeW5hbWljYWxseSBzdXBw b3J0aW5nIENSVUQgb3BlcmF0aW9ucy4gSSBqdXN0IHdhbnQgdG8gbWFrZSBhIHBvaW50IHRoYXQg dGhlIGFic3RyYWN0aW9uIG9mIG5ldHdvcmsgc2xpY2VzIGluIEFDVE4gaXMgb25seSBmb3IgbmV0 d29yayByZXNvdXJjZXMgYnV0IG5vdCBmb3IgY29tcHV0ZSBvciBzdG9yYWdlLiBDU08gKENyb3Nz LVN0cmF0dW0gT3B0aW16YXRpb24pIHdvcmsgYWRkcmVzcyBob3cgdG8gY29tYmluZSBjb21wdXRl IGFuZCBzdG9yYWdlIHNsaWNlcyB3aXRoIEFDVE4ncyBuZXR3b3JrIHNsaWNlcy4gTXkgdW5kZXJz dGFuZGluZyBmb3IgdGhlIHNjb3BlIG9mIG5ldHdvcmsgc2xpY2luZyBpcyBwcmltYXJpbHkgbmV0 d29yayByZXNvdXJjZSBzbGljaW5nLCBjb3JyZWN0PyANCiAgICANCiAgICAzLiBIb3cgZG8gd2Ug Y2hhcmFjdGVyaXplIHRoZSBkZXRlcm1pbmlzbSByZXF1aXJlbWVudCBvZiBOUz8gVG8gd2hhdCBl eHRlbnQgaXMgdGhlIGRldGVybWluaXNtIGhhcmQgYW5kIHRvIHdoYXQgZXh0ZW50IGlzIGl0IHNv ZnQsIGkuZS4gd2hhdCBhcmUgdGhlIGFic29sdXRlIHJlcXVpcmVtZW50cywgYW5kIHdoYXQgcmVx dWlyZW1lbnRzIGNhbiBiZSBtZXQgYnkgc29tZSBmb3JtIG9mIHByb2JhYmlsaXR5IG1hc2s/IERv ZXMgdGhlIGRlc2lnbiBiZWluZyBwcm9wb3NlZCBieSB0aGUgREVUTkVUIGRlc2lnbiB0ZWFtICh3 aGljaCBpcyBzdGlsbCBpbiBzdGVhbHRoIG1vZGUpIGFkZHJlc3MgYWxsIG9mIHRoaXM/DQogICAg DQogICAgNC4gVG8gd2hhdCBleHRlbnQgZG9lcyB0aGUgbmV0d29yayBuZWVkIHRvIG9wZW4gdGhl IGNvbnRyb2wgYW5kIG1hbmFnZW1lbnQgb2YgdGhlIG5ldHdvcmsgc2xpY2VzIHRvIHRoZSB0aGly ZCBwYXJ0aWVzPyBBbmQgdG8gd2hhdCBleHRlbnQgY2FuIHRoaXMgYmUgYWRkcmVzc2VkIGJ5IGV4 aXN0aW5nIHRlY2hub2xvZ2llcywgc3VjaCBhcyBQQ0UsIFNlZ21lbnQgUm91dGluZywgU0ZDIGFu ZCBOZXRjb25mPw0KICAgIA0KICAgIFlvdXIgaW5zaWdodGZ1bCB0aG91Z2h0cyBhcmUgbXVjaCBh cHByZWNpYXRlZC4NCiAgICANCiAgICBCZXN0IHJlZ2FyZHMsDQogICAgSmllDQogICAgDQogICAg DQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg ICBOZXRzbGljZXMgbWFpbGluZyBsaXN0DQogICAgTmV0c2xpY2VzQGlldGYub3JnDQogICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRzbGljZXMNCiAgICANCiAgICBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIE5ldHNs aWNlcyBtYWlsaW5nIGxpc3QNCiAgICBOZXRzbGljZXNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldHNsaWNlcw0KICAgIA0KDQo= From nobody Tue Feb 7 09:56:11 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF35129450 for ; Tue, 7 Feb 2017 09:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 mMvZjrc-uQ_X for ; Tue, 7 Feb 2017 09:56:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EED5129413 for ; Tue, 7 Feb 2017 09:56:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAE48101; Tue, 07 Feb 2017 17:56:03 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Feb 2017 17:56:01 +0000 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML701-CHM.china.huawei.com ([169.254.3.132]) with mapi id 14.03.0235.001; Tue, 7 Feb 2017 09:55:55 -0800 From: Uma Chunduri To: "Smith, Kevin, (R&D) Vodafone Group" , "Loa Andersson" , "netslices@ietf.org" Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvrD6j58iX4VgEaRLQtBcJ4q06FcmRmAgACPBICAACsogIAASScAgAAJGwCAAB+1gIAAIb6AgAAIBUA= Date: Tue, 7 Feb 2017 17:55:53 +0000 Message-ID: <25B4902B1192E84696414485F572685401880308@SJCEML703-CHM.china.huawei.com> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.100] 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.0A090201.589A0A33.0120, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4a463013224896b063d859c77b66bc81 Archived-At: Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 17:56:09 -0000 Hi Loa, > I thought that "network slicing" meant that a network provider can give a= network user Agree with Kevin below and he put it more eloquently. I see and agree it'= s mostly per user (well it could be) but primarily for a flow in mobile n= etworks with also different QoE requirements. > In a cellular network this can also include radio resources, so terminal-= to-external-edge-of-operator-network (maybe 'operator domain' is snappier := )). Just to add a bit more, I see slice as a combination of radio resource, tra= nsport network resource and the packet core resource .. Best Regards, -- Uma C. -----Original Message----- From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Smith, Kev= in, (R&D) Vodafone Group Sent: Tuesday, February 07, 2017 1:20 AM To: Loa Andersson ; netslices@ietf.org Subject: Re: [Netslices] Network Slicing - Introductory Document and Revise= d Problem Statement Hi Loa, > I thought that "network slicing" meant that a network provider can give a= network user, a slice of the network (with all functions needed), to satis= fy the network users requirements. So E2E if E2E is needed. Yes, although that may not be fully E2E if the origin server is hosted out= side of the providers' network. Network slicing should allow the network pr= ovider to rapidly allocate/deallocate network resources towards flows, base= d on the characteristics of each flow. So each flow will demand a certain b= lend of latency, mobility, capacity, resilience, pacing, durability etc. - = it doesn't necessarily need to be a function as such, although those can be= added a la service chaining if required. In a cellular network this can al= so include radio resources, so terminal-to-external-edge-of-operator-networ= k (maybe 'operator domain' is snappier :)). All best, Kevin Kevin Smith, Vodafone -----Original Message----- From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Loa Anders= son Sent: 07 February 2017 07:20 To: netslices@ietf.org Subject: Re: [Netslices] Network Slicing - Introductory Document and Revise= d Problem Statement Folks, I may be kicking in open doors, or alternatively showing that I misundersto= od thing fundamentally. I thought that "network slicing" meant that a network provider can give a n= etwork user, a slice of the network (with all functions needed), to satisfy= the network users requirements. So E2E if E2E is needed. /Loa On 2017-02-07 13:26, Pedro Martinez-Julia wrote: > On Tue, Feb 07, 2017 at 04:53:34AM +0000, Natale, Bob wrote: >> Hi Pedro, >> >> Concerning your explanation that 'Softwarization is "the act of=20 >> converting hard-ware to soft-ware"', isn't that just "function=20 >> virtualization" as in, for example, NFV? > > They can be somehow related but it is not the same concept. Using NFV=20 > to illustrate the difference, it defines a set of fixed functions that=20 > are virtualized, but the resulting functions are not 100% soft-ware=20 > because they resemble the corresponding "hardware", which is quite=20 > fixed. Taking this into account I would say that NFV is a mechanism=20 > for softwarizing a network infrastructure (making it more flexible,=20 > programmable, etc.) but it is only limited to the infrastructure=20 > boundary because the functions themselves are "hard-fixed" unless they ar= e also softwarized. > > I hope this adds some useful concepts about the relations and=20 > diferences between virtualization and softwarization... > >> Avanti, >> BobN > > Regards, > Pedro > --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ Netslices mailing list Netslices@ietf.org https://www.ietf.org/mailman/listinfo/netslices _______________________________________________ Netslices mailing list Netslices@ietf.org https://www.ietf.org/mailman/listinfo/netslices From nobody Tue Feb 7 10:16:08 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC6F12952F for ; Tue, 7 Feb 2017 10:16:07 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 31RaoACUKr_2 for ; Tue, 7 Feb 2017 10:16:06 -0800 (PST) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 D516112943A for ; Tue, 7 Feb 2017 10:16:05 -0800 (PST) Received: by mail-wr0-x22d.google.com with SMTP id k90so43085059wrc.3 for ; Tue, 07 Feb 2017 10:16:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=9aPWesk1wNFsnXfVcGYQLoJhIE3lq3BlB1maIWkJ8RA=; b=q1J3q953NE55oBDQP6xg6VJLKYkqMTKSfRK2DeC1s0DuOQV7YRchdHh6SJqIrr+9xe D8qDPq6ou+uJ5Q011FwuIqDk8Lz9trW+DOI+XE6S3L/+v7LPXO75lWmDEM7XY3O9mUQ9 GD+m84NwDRyr91v+IHhJGyJc5Fq1okZQsoy6C+N6GU3NCMNn6DEbxppgEfxHvPg3DAu9 avH/xsGKdsftDHNQkLb8QUrnCaWu8hAXrg3bDslQp5XhujBDvEvG2bglZM4CWvPdSWzK agWYk/lA6mGZW2yyEy6LrXh/WgMUoh7s4nDB3m8Nky0j5CU+UzTXLMWftmIVUCbhPlNe rvDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=9aPWesk1wNFsnXfVcGYQLoJhIE3lq3BlB1maIWkJ8RA=; b=E9vuXAyinaECnnUThwYtpP1aKJ/tYE25e6e+cWIB8Rt72OFtHZmREVzNQ+ePreh5C1 R05oJo9U6W+XwQGyUd8OpHfa0shKRzP27lY8GympnBYyoxLG47TYJR6rcbk7O5uqeZk4 9l316ATT4URItqltVZtCNCPF7RfDt8tYngwQer9FcDORICATq+tOE1NHx5739bP/HYAp 3clmuBzpAzsFAH3Xp2Pa2r6EExcD4VCMhh55rr5HXDNRMYLpfbfe0m5dCxd0WWBpzX9w m+C7LLa9Xwsiaok/fcnCKZIUgCDSbQtNjf8Eh40cXAFMK+kOEOC1Ki17B2lh+yClYtXt 6n0Q== X-Gm-Message-State: AIkVDXKR2DUKVzlXJ+hqsbYtJzBwvukUvSwuY2rTzaZrAZLKiZlYIq34BFfOh2gHBNu21A== X-Received: by 10.223.145.227 with SMTP id 90mr15820174wri.156.1486491364314; Tue, 07 Feb 2017 10:16:04 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id x135sm20097264wme.23.2017.02.07.10.16.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 10:16:03 -0800 (PST) To: Pedro Martinez-Julia , "Natale, Bob" References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> From: Stewart Bryant Message-ID: Date: Tue, 7 Feb 2017 18:16:02 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170207052610.GT12800@spectre> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Dongjie \(Jimmy\)" , "Kiran.Makhijani" , Network Slices , Alex Galis , AshwoodsmithPeter Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:16:07 -0000 On 07/02/2017 05:26, Pedro Martinez-Julia wrote: > On Tue, Feb 07, 2017 at 04:53:34AM +0000, Natale, Bob wrote: >> Hi Pedro, >> >> Concerning your explanation that 'Softwarization is "the act of >> converting hard-ware to soft-ware"', isn't that just "function >> virtualization" as in, for example, NFV? > They can be somehow related but it is not the same concept. Using NFV to > illustrate the difference, it defines a set of fixed functions that are > virtualized, but the resulting functions are not 100% soft-ware because > they resemble the corresponding "hardware", which is quite fixed. I don't agree with that. I can instantiate any function I wish as an NFV function, be it a well known function such as a load balancer, or it can be some relatively unknown function such as a homomorphic packet timestamper, or it could be some function only known to the customer but hosted in the network as an opaque function. I can dynamically provision such functions on CPU and add or remove them from a path. Thus I see no difference between a softwarized system and a system of NFV components stitched together with SFC, at least with the definition provided above. > Taking > this into account I would say that NFV is a mechanism for softwarizing a > network infrastructure (making it more flexible, programmable, etc.) but > it is only limited to the infrastructure boundary because the functions > themselves are "hard-fixed" unless they are also softwarized. Obviously I don't agree with that. What constrains them to be hard-fixed? - Stewart > > I hope this adds some useful concepts about the relations and diferences > between virtualization and softwarization... > >> Avanti, >> BobN > Regards, > Pedro > From nobody Tue Feb 7 10:21:12 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005E012959F for ; Tue, 7 Feb 2017 10:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=realsdn.org 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 eBSNzBjE1KRz for ; Tue, 7 Feb 2017 10:21:09 -0800 (PST) Received: from ajmclachlan.com (pigmail.ajmclachlan.com [78.31.107.96]) (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 B1F0A1293D8 for ; Tue, 7 Feb 2017 10:21:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=realsdn.org; s=default; t=1486491668; bh=XhMPP4N+Wlt9IxBmV9UeQUalT0oCZzOs9GNkqWg+WBM=; h=Subject:From:In-Reply-To:Date:References:To; b=Uktu5PAkBlZfKcyl9f72mNk+iuEUtOIonTQgIqlW/gxigOACvxtGIiBHSGIAuwC62 e+K5ZAwEw0Be1jsr9SwzivWyGH6jsjS4YDk1tPE0FTUIL2V/z+4K5yekQhHFap33kZ bQNy8HksrnXEH8U3CLiWTn929YLmgBdlAeB82N2Y= X-Default-Received-SPF: pass (skip=forwardok (res=PASS)); Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Andrew McLachlan In-Reply-To: <25B4902B1192E84696414485F572685401880308@SJCEML703-CHM.china.huawei.com> Date: Tue, 7 Feb 2017 18:21:03 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7886983F-3939-4D18-AECC-20A9094C8185@realsdn.org> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> <25B4902B1192E84696414485F572685401880308@SJCEML703-CHM.china.huawei.com> To: "netslices@ietf.org" X-Mailer: Apple Mail (2.3124) X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted Archived-At: Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:21:11 -0000 Agree that it will be combinations of infrastructure to achieve = something E2E in most cases, and I hope this does not drive us to put = more complexity into the various control planes / infras, but rather we = take an approach to expose the capabilities through high-functioning = brokers, controllers and functions such as PCE. Essentially this could be an NNI / UNI exercise out of band of the = network.=20 > On 7 Feb 2017, at 17:55, Uma Chunduri wrote: >=20 > Hi Loa, >=20 >> I thought that "network slicing" meant that a network provider can = give a network user >=20 > Agree with Kevin below and he put it more eloquently. I see and = agree it's mostly per user (well it could be) but primarily for a flow = in mobile networks with also different QoE requirements. >=20 >=20 >> In a cellular network this can also include radio resources, so = terminal-to-external-edge-of-operator-network (maybe 'operator domain' = is snappier :)). >=20 > Just to add a bit more, I see slice as a combination of radio = resource, transport network resource and the packet core resource .. >=20 > Best Regards, > -- > Uma C. >=20 >=20 > -----Original Message----- > From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of = Smith, Kevin, (R&D) Vodafone Group > Sent: Tuesday, February 07, 2017 1:20 AM > To: Loa Andersson ; netslices@ietf.org > Subject: Re: [Netslices] Network Slicing - Introductory Document and = Revised Problem Statement >=20 > Hi Loa, >=20 >> I thought that "network slicing" meant that a network provider can = give a network user, a slice of the network (with all functions needed), = to satisfy the network users requirements. So E2E if E2E is needed. >=20 > Yes, although that may not be fully E2E if the origin server is = hosted outside of the providers' network. Network slicing should allow = the network provider to rapidly allocate/deallocate network resources = towards flows, based on the characteristics of each flow. So each flow = will demand a certain blend of latency, mobility, capacity, resilience, = pacing, durability etc. - it doesn't necessarily need to be a function = as such, although those can be added a la service chaining if required. = In a cellular network this can also include radio resources, so = terminal-to-external-edge-of-operator-network (maybe 'operator domain' = is snappier :)). >=20 > All best, > Kevin >=20 > Kevin Smith, Vodafone >=20 > -----Original Message----- > From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Loa = Andersson > Sent: 07 February 2017 07:20 > To: netslices@ietf.org > Subject: Re: [Netslices] Network Slicing - Introductory Document and = Revised Problem Statement >=20 > Folks, >=20 > I may be kicking in open doors, or alternatively showing that I = misunderstood thing fundamentally. >=20 > I thought that "network slicing" meant that a network provider can = give a network user, a slice of the network (with all functions needed), = to satisfy the network users requirements. >=20 > So E2E if E2E is needed. >=20 > /Loa >=20 >=20 > On 2017-02-07 13:26, Pedro Martinez-Julia wrote: >> On Tue, Feb 07, 2017 at 04:53:34AM +0000, Natale, Bob wrote: >>> Hi Pedro, >>>=20 >>> Concerning your explanation that 'Softwarization is "the act of=20 >>> converting hard-ware to soft-ware"', isn't that just "function=20 >>> virtualization" as in, for example, NFV? >>=20 >> They can be somehow related but it is not the same concept. Using NFV=20= >> to illustrate the difference, it defines a set of fixed functions = that=20 >> are virtualized, but the resulting functions are not 100% soft-ware=20= >> because they resemble the corresponding "hardware", which is quite=20 >> fixed. Taking this into account I would say that NFV is a mechanism=20= >> for softwarizing a network infrastructure (making it more flexible,=20= >> programmable, etc.) but it is only limited to the infrastructure=20 >> boundary because the functions themselves are "hard-fixed" unless = they are also softwarized. >>=20 >> I hope this adds some useful concepts about the relations and=20 >> diferences between virtualization and softwarization... >>=20 >>> Avanti, >>> BobN >>=20 >> Regards, >> Pedro >>=20 >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices From nobody Tue Feb 7 10:24:28 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF06129E09 for ; Tue, 7 Feb 2017 10:24:28 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 SZLciCDJmnR5 for ; Tue, 7 Feb 2017 10:24:27 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 DF5FE1293D8 for ; Tue, 7 Feb 2017 10:24:26 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id i10so43329853wrb.0 for ; Tue, 07 Feb 2017 10:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=DT4sB4hLWA6OcHnlvfdtFBDVhMm7Az5sbLp4IbUc17c=; b=XkmUzPKc9yLZkJKLY5dB2pgIoINr3WsUwKg+aSflrokR/vzqK1pbZ+SQwLi9NIIyIb 9HNSELkt8IVb1tzwq5rzB9OPXGYJ+uOUOIAcyvQgTXLq27KzxvD+mw7irtw29IYAvUMk UzQEybhb+duppxTch+ChZV6t8+dRFeLZD8wGf1iE6HJRievwiN4mHwCCwpqq/mNwbkfD /qmXGJCEtu2B3Wsiy/9P+2rn7bi+IJKuONwoZACdSI24q/TheqCPrREo0hx+f6wB4ruN v+dxb/bfcKZWK5evBnV0J+3qKQO2u51qnmN6iK9SK6oPOQXgpekOoqlf2o5zeepigwFP hWXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DT4sB4hLWA6OcHnlvfdtFBDVhMm7Az5sbLp4IbUc17c=; b=OO/DfG35h9TGVg1huxNnBCEXxnzr2xSkZD0C+vBeMP16n4Gtq6lJwRHglOGpqbebaC neYLZVFi6WS+9m35+2IpCHMdcQzN5bCHIlyndkW0UwAezDWmOGCW/xS5aOhvcgrNx2cH HtGTcg53++5nPGTHm7xxypz6anQDpOQH+P1LqLkw5VAD4NqoWXj0CO9RQjNuWjriFWJW 3XhEhnDdACDsBDot59HoTWVfGuyX5XFZRmAAMa1OHS5baiQucZ3BFiWy+/yV18NTUPBj DTB/n3uhiLyHis98hofapnw4xySCmd8ZP2T06Np/1NJzkcE9YcsBxtW+Hvy3L1mKMhJs 3oDg== X-Gm-Message-State: AMke39kH5jBPa5VLyZRFLW+A+oKXgveeU9Xei23OdoQoWPe3Qnn20GPIsV0it++f4STtCA== X-Received: by 10.223.171.65 with SMTP id r1mr15005741wrc.38.1486491865316; Tue, 07 Feb 2017 10:24:25 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id y1sm20098191wme.15.2017.02.07.10.24.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2017 10:24:24 -0800 (PST) To: Uma Chunduri , "Smith, Kevin, (R&D) Vodafone Group" , Loa Andersson , "netslices@ietf.org" References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> <25B4902B1192E84696414485F572685401880308@SJCEML703-CHM.china.huawei.com> From: Stewart Bryant Message-ID: <2306d711-2445-71e3-eff3-baa86ac36422@gmail.com> Date: Tue, 7 Feb 2017 18:24:23 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <25B4902B1192E84696414485F572685401880308@SJCEML703-CHM.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:24:28 -0000 On 07/02/2017 17:55, Uma Chunduri wrote: > Hi Loa, > >> I thought that "network slicing" meant that a network provider can give a network user > Agree with Kevin below and he put it more eloquently. I see and agree it's mostly per user (well it could be) but primarily for a flow in mobile networks with also different QoE requirements. > > >> In a cellular network this can also include radio resources, so terminal-to-external-edge-of-operator-network (maybe 'operator domain' is snappier :)). > Just to add a bit more, I see slice as a combination of radio resource, transport network resource and the packet core resource .. Are those the position of the resources or the resources themselves? In other words do you include or exclude functions inline with the path, and even functions at the terminal of the path? So where does NFV and the compute resources to run it fit in? Now people have talked about dedicated resources. Are the end customers prepared to pay for the consequences of dedicated resources? If a resource is dedicated they have to pay the full overhead cost of every nut and bolt along the path including a real proportion of some very expensive linecards, which contrasts with mainstream networking where these costs are shared much more widely. - Stewart From nobody Tue Feb 7 10:33:07 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751DA129E15 for ; Tue, 7 Feb 2017 10:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 U_7SyzA0Zm3j for ; Tue, 7 Feb 2017 10:33:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C736129E09 for ; Tue, 7 Feb 2017 10:33:04 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAE51427; Tue, 07 Feb 2017 18:33:02 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Feb 2017 18:33:01 +0000 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML701-CHM.china.huawei.com ([169.254.3.132]) with mapi id 14.03.0235.001; Tue, 7 Feb 2017 10:32:58 -0800 From: Uma Chunduri To: Stewart Bryant , "Smith, Kevin, (R&D) Vodafone Group" , Loa Andersson , "netslices@ietf.org" Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvrD6j58iX4VgEaRLQtBcJ4q06FcmRmAgACPBICAACsogIAASScAgAAJGwCAAB+1gIAAIb6AgAAIBUCAAI/3gP//emhg Date: Tue, 7 Feb 2017 18:32:57 +0000 Message-ID: <25B4902B1192E84696414485F572685401880360@SJCEML703-CHM.china.huawei.com> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> <25B4902B1192E84696414485F572685401880308@SJCEML703-CHM.china.huawei.com> <2306d711-2445-71e3-eff3-baa86ac36422@gmail.com> In-Reply-To: <2306d711-2445-71e3-eff3-baa86ac36422@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.100] 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.0A0B0206.589A12DE.0147, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4a463013224896b063d859c77b66bc81 Archived-At: Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 18:33:06 -0000 Hi Stewart, First let me correct I intend to say "not" per user mostly (well it could b= e)... In-line [Uma]: -- Uma C. -----Original Message----- From: Stewart Bryant [mailto:stewart.bryant@gmail.com]=20 Sent: Tuesday, February 07, 2017 10:24 AM To: Uma Chunduri ; Smith, Kevin, (R&D) Vodafone Gr= oup ; Loa Andersson ; netslices@ietf.o= rg Subject: Re: [Netslices] Network Slicing - Introductory Document and Revise= d Problem Statement On 07/02/2017 17:55, Uma Chunduri wrote: > Hi Loa, > >> I thought that "network slicing" meant that a network provider can=20 >> give a network user > Agree with Kevin below and he put it more eloquently. I see and agree i= t's mostly per user (well it could be) but primarily for a flow in mobile= networks with also different QoE requirements. > > >> In a cellular network this can also include radio resources, so terminal= -to-external-edge-of-operator-network (maybe 'operator domain' is snappier = :)). > Just to add a bit more, I see slice as a combination of radio resource, t= ransport network resource and the packet core resource .. Are those the position of the resources or the resources themselves? [Uma]: Position is merely how the mobile network is architected today and b= eing evolved, but I see it's about combination of E2E resources. In other words do you include or exclude functions inline with the path, an= d even functions at the terminal of the path? So where does NFV and the compute resources to run it fit in? Now people have talked about dedicated resources. Are the end customers pre= pared to pay for the consequences of dedicated resources? If a resource is = dedicated they have to pay the full overhead cost of every nut and bolt alo= ng the path including a real proportion of some very expensive linecards, w= hich contrasts with mainstream networking where these costs are shared muc= h more widely. [Uma]: I see this mostly shared flows (even considering where 5G is going)= with defined QCI values (with certain E2E promises on jitter, latency, Qos= etc..). I don't think it's per user at all (but in future it may be .. I a= m not sure on that part!) - Stewart From nobody Tue Feb 7 13:54:50 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE411293E1 for ; Tue, 7 Feb 2017 13:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 AX8VdVNyNCQ5 for ; Tue, 7 Feb 2017 13:54:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8ECE1294EA for ; Tue, 7 Feb 2017 13:54:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGA05462; Tue, 07 Feb 2017 21:54:42 +0000 (GMT) Received: from YYZEML703-CHM.china.huawei.com (10.218.33.73) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Feb 2017 21:54:42 +0000 Received: from YYZEML701-CHM.china.huawei.com ([169.254.4.116]) by YYZEML703-CHM.china.huawei.com ([169.254.5.250]) with mapi id 14.03.0301.000; Tue, 7 Feb 2017 16:54:31 -0500 From: AshwoodsmithPeter To: Susan Hares , "'Natale, Bob'" , "'Alex Galis'" , "'Network Slices'" Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvrXaDeoOCGArUagAhaMsA6e+KFcERXwgACKloCAAHooAIABGqow Date: Tue, 7 Feb 2017 21:54:30 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5CDE1@YYZEML701-CHM.china.huawei.com> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <013901d280d3$fcf6c050$f6e440f0$@ndzh.com> In-Reply-To: <013901d280d3$fcf6c050$f6e440f0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.146] Content-Type: multipart/alternative; boundary="_000_7AE6A4247B044C4ABE0A5B6BF427F8E230A5CDE1YYZEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.589A4223.0220, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.116, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f6548cccac4325e6ded5c70cc1387d4d Archived-At: Cc: "Dongjie \(Jimmy\)" , "Kiran.Makhijani" , 'Stewart Bryant' Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 21:54:48 -0000 --_000_7AE6A4247B044C4ABE0A5B6BF427F8E230A5CDE1YYZEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, comments in-line. Peter: On #3 on your list - do you believe all the L2VPN and L3VPN features are ne= eded? Or can you suggest a smalls subset of these features that will be ne= eded to support network slicing. [PETER] - It's possible that the control planes may not be required in all = their glory and that much of the functionality can be done via logically ce= ntral control under an orchestrator of the different VPN data planes. This = is because much of the VPN encapsulation happens in the DC's/C-RANs where m= ore centralized control is the norm as opposed to fully distributed stuff t= hat may be the case. In our proof of concepts we use fairly simple overlapp= ing IP addresses spaces within a given slice with the same subnet actually = in each slice to make it simpler to debug. Kind of like a template that you= instantiate over and over again. Makes it simpler to understand. On #4 - how is this programmatic interface to the control plane different t= han the work we are doing in I2RS. [PETER] Well you are doing an interface to a routing system but slicing req= uires and interface to lots of different things including a routing system.= It needs an interface to antennas, an interface to fronthaul, an interface= to the cran DSPs, an interface to the cran fabric and eventually we get to= interfaces to transport/routing/NFV etc. All that to say that softwarizati= on is being used as a term to mean all the hardware and software end to end= has programmable interfaces that meet an orchestration system. The softwar= ization may or may not end up in something virtual being created it can jus= t as easily be something physical and as Loa alluded to in a later message = the slices do not have to be end to end separate they can and will share ma= ny resources as long as there are other means to provide guarantees them wh= ere they overlap. I would appreciate a copy of your short presentation on this matter [PETER] will do In a direct email. Sue Hares From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Ashwoodsmi= thPeter Sent: Monday, February 6, 2017 4:57 PM To: Natale, Bob; Alex Galis; Network Slices Cc: Dongjie (Jimmy); Stewart Bryant; Kiran.Makhijani Subject: Re: [Netslices] Network Slicing - Introductory Document and Revise= d Problem Statement Hey Bob, Here are a few points that I find useful to understand Slicing and VPN's. 1. A "slice" in the context of 5G is essentially an end to end set of = resources which make up a fully functional wireless network drawn from larg= er pool of end to end resources. 2. A slice is therefore a superset of the capabilities of an L0,L1,L3 = or L3 VPN. 3. An L2VPN or L3VPN is likely a useful connectivity model for the con= trol and user plane data paths for the obvious reasons and DETNET type capa= bilities are of interest for stricter QOS guarantees. For even stricter gua= rantees ACTN etc. and L0/L1 control is required. 4. I hate the term "softwarization" also, but essentially it's being u= sed to describe a programmatic interface to each of the end to end sets of = resources to allow them to be allocated/linked/deallocated/grown/shrunk etc= . and is therefore more than just virtualization but of course covers virtu= alization. I gave a short presentation on this at 5gandIp meeting last year which you = may find useful, I'll be happy to send it to you directly or I suspect it's= on an IETF server somewhere. Cheers, Peter From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Natale, Bo= b Sent: Monday, February 06, 2017 8:25 AM To: Alex Galis >; Network Slice= s > Cc: Dongjie (Jimmy) >; Kira= n.Makhijani >= ; Stewart Bryant = > Subject: Re: [Netslices] Network Slicing - Introductory Document and Revise= d Problem Statement Hi Alex, I just have two basic questions - more like "requests" - for now: - How does a network "slice" differ from all established forms of network v= irtualization (VLANs, VPNs, SDPs, etc.? - Do we really need the term "softwarization" (and its various derivatives)= ... isn't that just a confounding way of saying "virtualization" ... as in= "softwarizing and separating logical network components from the underlying physical network resource= s" ... isn't that latter part what we commonly call virtualization and, if = so, how does "softwarization" differ from it? >From a lurker, BobN From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Alex Galis Sent: Friday, January 20, 2017 3:54 AM To: Network Slices > Cc: Dongjie (Jimmy) >; Stew= art Bryant >; Ale= x Galis >; Kiran.Makhijani > Subject: Re: [Netslices] Network Slicing - Introductory Document and Revise= d Problem Statement 20th January 2017 Dear All Re: Network Slicing - Introductory Document and Revised Problem Statement https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-an= d-ps-00.txt Thank you for your expressed interest in the Network Slicing. One of the action from the Network Slicing side meeting at IETF 97 of 15th = Nov 2016 was to consolidate all suggestions and comments received into an u= nified initial revised problem statement and work plan which would be the b= asis of a BoF at IETF 98 or IETF99. Such an introductory document is ready = for your review and it is enclosed as a draft. Would you be so kind as to provide your feedback, comments, contributions a= nd work interest with the view of further progressing this draft for un upd= ate and presentation at IETF 98. Thank you in advance, Best Regards Alex, Jie, Kiran and Stewart Network Slicing - Introductory Document and Revised Problem Statement Abstract: This document represents an introduction to the motivation and Network Slicing problems and work ares. It represents an initial revision of Network Slicing problem statement derived from the analysis of the technical gaps in IETF protocols ecosystem. It complements and it bring together the isolated efforts being carried out in several IETF working groups to achieve certain aspects of network slice functions and operations. _______________________________________________ Netslices mailing list Netslices@ietf.org https://www.ietf.org/mailman/listinfo/netslices --_000_7AE6A4247B044C4ABE0A5B6BF427F8E230A5CDE1YYZEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sue, comments in-line.<= /span>

 

Peter:

 

On #3 on your list – do you bel= ieve all the L2VPN and L3VPN features are needed?  Or can you suggest = a smalls subset of these features that will be needed to support network slicing.

 

[PETER] – It’s possible t= hat the control planes may not be required in all their glory and that much= of the functionality can be done via logically central control under an orchestrator of the different VPN data planes. This is because mu= ch of the VPN encapsulation happens in the DC’s/C-RANs where more cen= tralized control is the norm as opposed to fully distributed stuff that may= be the case. In our proof of concepts we use fairly simple overlapping IP addresses spaces within a given slice = with the same subnet actually in each slice to make it simpler to debug. Ki= nd of like a template that you instantiate over and over again. Makes it si= mpler to understand.

 

On #4 – how is this programmati= c interface to the control plane different than the work we are doing in I2= RS. 

 

[PETER] Well you are doing an interfa= ce to a routing system but slicing requires and interface to lots of differ= ent things including a routing system. It needs an interface to antennas, an interface to fronthaul, an interface to the c= ran DSPs, an interface to the cran fabric and eventually we get to interfac= es to transport/routing/NFV etc. All that to say that softwarization is bei= ng used as a term to mean all the hardware and software end to end has programmable interfaces that meet an = orchestration system. The softwarization may or may not end up in something= virtual being created it can just as easily be something physical and as L= oa alluded to in a later message the slices do not have to be end to end separate they can and will share m= any resources as long as there are other means to provide guarantees them w= here they overlap.

 

I would appreciate a copy of your sho= rt presentation on this matter

 

[PETER] will do In a direct email.

 

 

Sue Hares

 

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of AshwoodsmithPeter
Sent: Monday, February 6, 2017 4:57 PM
To: Natale, Bob; Alex Galis; Network Slices
Cc: Dongjie (Jimmy); Stewart Bryant; Kiran.Makhijani
Subject: Re: [Netslices] Network Slicing - Introductory Document and= Revised Problem Statement

 

Hey Bob,

 

Here are a few points that I find use= ful to understand Slicing and VPN’s.

 

1= .   &nb= sp;  A “slice” in the context of 5G is essenti= ally an end to end set of resources which make up a fully functional wirele= ss network drawn from larger pool of end to end resources.

 

2= .   &nb= sp;  A slice is therefore a superset of the capabilities of an L0,L1,L3 or L3 VPN.

 

3= .   &nb= sp;  An L2VPN or L3VPN is likely a useful connectivity mod= el for the control and user plane data paths for the obvious reasons and DE= TNET type capabilities are of interest for stricter QOS guarantees. For even stricter guarantees ACTN etc. and L0/L1 control i= s required.

 

4= .   &nb= sp;  I hate the term “softwarization” also, bu= t essentially it’s being used to describe a programmatic interface to= each of the end to end sets of resources to allow them to be allocated/linked/deallocated/grown/shrunk etc. and is therefore more than = just virtualization but of course covers virtualization.<= /p>

 

I gave a short presentation on this a= t 5gandIp meeting last year which you may find useful, I’ll be happy = to send it to you directly or I suspect it’s on an IETF server somewhere.

 

Cheers,

 

Peter

 

 

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Natale, Bob
Sent: Monday, February 06, 2017 8:25 AM
To: Alex Galis <a.galis@ucl.= ac.uk>; Network Slices <net= slices@ietf.org>
Cc: Dongjie (Jimmy) <jie.d= ong@huawei.com>; Kiran.Makhijani <Kiran.Makhijani@huawei.com>; Stewart Bryant <stewart.bryant@gmail.com>
Subject: Re: [Netslices] Network Slicing - Introductory Document and= Revised Problem Statement

 

Hi Alex,

 

I just have two basic questions – more like R= 20;requests” – for now:

 

- How does a network “slice” differ from a= ll established forms of network virtualization (VLANs, VPNs, SDPs, etc.?

 

- Do we really need the term “softwarizationR= 21; (and its various derivatives) … isn’t that just a confoundi= ng way of saying “virtualization” … as in “softwari= zing and separating

   logical network components from the under= lying physical network resources” … isn’t that latter par= t what we commonly call virtualization and, if so, how does “softwari= zation” differ from it?

 

From a lurker,

BobN

 

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Alex Galis
Sent: Friday, January 20, 2017 3:54 AM
To: Network Slices <netslic= es@ietf.org>
Cc: Dongjie (Jimmy) <jie.d= ong@huawei.com>; Stewart Bryant <stewart.bryant@gmail.com>; Alex Galis <a.galis@ucl.ac.uk>; Kiran.Makhijani <Kiran.Makhijani@huawei.c= om>
Subject: Re: [Netslices] Network Slicing - Introductory Document and= Revised Problem Statement

 

 



20th January 2017


Dear All

 
Re:  Network Slicing - Introductory Document and Revised Problem State= ment

         https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-and-ps-00.t= xt

 

Thank you for your expressed interest in the Network Slicing.

One of the action from the Network Slicing side meeting at IETF 97 of 15th = Nov 2016 was to consolidate all suggestions and comments received into an u= nified initial revised problem statement and work plan which would be the b= asis of a BoF at IETF 98 or IETF99. Such an introductory document is ready for your review and it is enclosed = as a draft.
 
Would you be so kind as to provide your feedback, comments, contributions a= nd work interest with the view of further progressing this draft for un upd= ate and presentation at IETF 98.
 
Thank you in advance,
Best Regards
Alex, Jie, Kiran and Stewart
 
 
 
Network Slicing - Introductory Document and Revised Problem Statement
 
Abstract:
  This document represents an introduction to the motivation and
  Network Slicing problems and work ares. It represents an initial
  revision of Network Slicing problem statement derived from the
  analysis of the technical gaps in IETF protocols ecosystem. It
  complements and it bring together the isolated efforts being carried=
  out in several IETF working groups to achieve certain aspects of
  network slice functions and operations.

___________________= ____________________________
Netslices mailing list
Netslices@ietf.org
https://www.iet= f.org/mailman/listinfo/netslices

--_000_7AE6A4247B044C4ABE0A5B6BF427F8E230A5CDE1YYZEML701CHMchi_-- From nobody Tue Feb 7 14:05:27 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2FB12949E for ; Tue, 7 Feb 2017 14:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 hEloE_viXD8X for ; Tue, 7 Feb 2017 14:05:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C1B129482 for ; Tue, 7 Feb 2017 14:05:22 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGA06262; Tue, 07 Feb 2017 22:05:20 +0000 (GMT) Received: from YYZEML703-CHM.china.huawei.com (10.218.33.73) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 7 Feb 2017 22:05:19 +0000 Received: from YYZEML701-CHM.china.huawei.com ([169.254.4.116]) by YYZEML703-CHM.china.huawei.com ([169.254.5.250]) with mapi id 14.03.0301.000; Tue, 7 Feb 2017 17:05:12 -0500 From: AshwoodsmithPeter To: "Natale, Bob" , Pedro Martinez-Julia Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvrXaDeoOCGArUagAhaMsA6e+KFcERXwgACKloCAAIVPgIAASScAgADKcsA= Date: Tue, 7 Feb 2017 22:05:11 +0000 Message-ID: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5CE3A@YYZEML701-CHM.china.huawei.com> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.146] 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.0A0B0201.589A44A0.00C2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.116, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f6548cccac4325e6ded5c70cc1387d4d Archived-At: Cc: "Dongjie \(Jimmy\)" , "Kiran.Makhijani" , Network Slices , Alex Galis , Stewart Bryant Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 22:05:26 -0000 DQpPbmUgb2YgdGhlIHJlYXNvbnMgSSBkb24ndCByZWFsbHkgbGlrZSB0aGUgdGVybSBzb2Z0d2Fy aXphdGlvbiBpcyBiZWNhdXNlIGl0cyBiZWluZyB1c2VkIGluIGEgZmV3IGRpZmZlcmVudCB3YXlz Lg0KDQpTb2Z0d2FyaXphdGlvbiBhcyBJIGhlYXIgaXQgaW4gdGhlIGNvbnRleHQgb2YgNUcgaXMg YmVpbmcgdXNlZCB0byBkZXNjcmliZSBob3cgYWxsIHRoZSBiaXRzIGFuZCBwaWVjZXMgdGhhdCBn byB0b2dldGhlciBjYW4gYmUgYXNzZW1ibGVkIGFuZCBwcm9ncmFtbWVkIGJ5IGhpZ2hlciBsYXll ciBzb2Z0d2FyZS4gDQoNCk5GViBpcyBhcyB5b3Ugc2F5IGJlaW5nIHVzZWQgdG8gZGVzY3JpYmUg dGhlIHVzZSBvZiBzb2Z0d2FyZSB0byByZXBsYWNlIGhhcmR3YXJlIGFuZCB0aGVyZWJ5IHZpcnR1 YWxpemUgaXQuIEhlbmNlIHNvZnR3YXJpemF0aW9uIGRvZXMgbm90IGltcGx5IHZpcnR1YWxpemF0 aW9uLg0KDQpTbzoNCg0KTkZWIGNhbiBiZSBzb2Z0d2FyaXplZCBieSBwdXR0aW5nIGEgcHJvcGVy IGxheWVyIGFib3ZlIGl0IHRvIGFsbG93IGl0IHRvIGJlIHByb2dyYW1tZWQuDQpBbnRlbm5hcyBj YW4gYmUgc29mdHdhcml6ZWQgYnkgcHV0dGluZyBhIHByb3BlciBsYXllciBhYm92ZSB0aGVtIHRv IGFsbG93IHRoZW0gdG8gYmUgcHJvZ3JhbW1lZC4NClRoZSBodXQgdGhhdCBzdG9yZXMgZU5CcyBj YW4gYmUgc29mdHdhcml6ZWQgYnkgbWFraW5nIGFjY2VzcyB0byBpdHMgaGVhdC9jb29saW5nL3Nl Y3VyaXR5IGV0Yy4NCg0KTWFueSBvZiB0aGUgY29tcG9uZW50cyB0aGF0IHRoZSBJRVRGIGRvZXMg YXJlIG9mIGNvdXJzZSBhbHJlYWR5ICdzb2Z0d2FyaXplZCcgYnV0IHRoZSB3aXJlbGVzcyB3b3Js ZCBpcyBzbG93bHkgY2F0Y2hpbmcgdXAgd2l0aCB0aGVzZSBjb25jZXB0cyBhbmQgaGVuY2UgeW91 IGdldCBzb21lIG5ldyB0ZXJtaW5vbG9neSBsaWtlIHNvZnR3YXJpemUvc2xpY2luZyBldGMuIA0K DQpQZXRlcg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE5hdGFsZSwg Qm9iIFttYWlsdG86Uk5BVEFMRUBtaXRyZS5vcmddIA0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAw NiwgMjAxNyAxMTo1NCBQTQ0KVG86IFBlZHJvIE1hcnRpbmV6LUp1bGlhIDxwZWRyb0BuaWN0Lmdv LmpwPjsgQXNod29vZHNtaXRoUGV0ZXIgPFBldGVyLkFzaHdvb2RTbWl0aEBodWF3ZWkuY29tPg0K Q2M6IEFsZXggR2FsaXMgPGEuZ2FsaXNAdWNsLmFjLnVrPjsgTmV0d29yayBTbGljZXMgPG5ldHNs aWNlc0BpZXRmLm9yZz47IERvbmdqaWUgKEppbW15KSA8amllLmRvbmdAaHVhd2VpLmNvbT47IFN0 ZXdhcnQgQnJ5YW50IDxzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb20+OyBLaXJhbi5NYWtoaWphbmkg PEtpcmFuLk1ha2hpamFuaUBodWF3ZWkuY29tPg0KU3ViamVjdDogUkU6IFtOZXRzbGljZXNdIE5l dHdvcmsgU2xpY2luZyAtIEludHJvZHVjdG9yeSBEb2N1bWVudCBhbmQgUmV2aXNlZCBQcm9ibGVt IFN0YXRlbWVudA0KDQpIaSBQZWRybywNCg0KQ29uY2VybmluZyB5b3VyIGV4cGxhbmF0aW9uIHRo YXQgJ1NvZnR3YXJpemF0aW9uIGlzICJ0aGUgYWN0IG9mIGNvbnZlcnRpbmcgaGFyZC13YXJlIHRv IHNvZnQtd2FyZSInLCBpc24ndCB0aGF0IGp1c3QgImZ1bmN0aW9uIHZpcnR1YWxpemF0aW9uIiBh cyBpbiwgZm9yIGV4YW1wbGUsIE5GVj8NCg0KQXZhbnRpLA0KQm9iTg0KDQotLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGVkcm8gTWFydGluZXotSnVsaWEgW21haWx0bzpwZWRyb0Bu aWN0LmdvLmpwXSANClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMDYsIDIwMTcgNzozMiBQTQ0KVG86 IEFzaHdvb2RzbWl0aFBldGVyIDxQZXRlci5Bc2h3b29kU21pdGhAaHVhd2VpLmNvbT4NCkNjOiBO YXRhbGUsIEJvYiA8Uk5BVEFMRUBtaXRyZS5vcmc+OyBBbGV4IEdhbGlzIDxhLmdhbGlzQHVjbC5h Yy51az47IE5ldHdvcmsgU2xpY2VzIDxuZXRzbGljZXNAaWV0Zi5vcmc+OyBEb25namllIChKaW1t eSkgPGppZS5kb25nQGh1YXdlaS5jb20+OyBTdGV3YXJ0IEJyeWFudCA8c3Rld2FydC5icnlhbnRA Z21haWwuY29tPjsgS2lyYW4uTWFraGlqYW5pIDxLaXJhbi5NYWtoaWphbmlAaHVhd2VpLmNvbT4N ClN1YmplY3Q6IFJlOiBbTmV0c2xpY2VzXSBOZXR3b3JrIFNsaWNpbmcgLSBJbnRyb2R1Y3Rvcnkg RG9jdW1lbnQgYW5kIFJldmlzZWQgUHJvYmxlbSBTdGF0ZW1lbnQNCg0KRGVhciBhbCwNCg0KUmVn YXJkaW5nIHRoZSByZWxhdGlvbiBiZXR3ZWVuIGN1cnJlbnQgdmlydHVhbGl6YXRpb24sIG5ldHdv cmsgc2xpY2luZywgYW5kIHNvZnR3YXJpemF0aW9uLCBJIGluc2lzdCB3aGF0IEkgaGFkIGFscmVh ZHkgbWVudGlvbmVkIGl0IGluIG91ciBGMkYgbWVldGluZyBAIElFVEYgOTcsIHRoYXQgd2UgaGF2 ZSBzb21lIGNsYXNoZXMuIEZvciBpbnN0YW5jZToNCg0KLSBBIHNsaWNlIGlzLCBieSBkZWZpbml0 aW9uLCAiYSBwb3J0aW9uIiBvZiBzb21ldGhpbmcuIFRoZXJlIGlzIG5vIEUyRQ0KICBpbXBsaWVk IG9uIGl0LCBidXQgdGhlcmUgY2FuIGJlIHNwZWNpZmljYXRpb25zIGluY2x1ZGluZyBpdCAoZS5n LiBFMkUNCiAgc2xpY2VzKS4NCg0KLSBJIGlkZW50aWZ5IHR3byBkaWZmZXJlbnQgYnV0IGNvbXBs ZW1lbnRhcnkgcG9pbnRzIG9mIHZpZXcgaW4gcmVsYXRpb24NCiAgdG8gIm5ldHdvcmsgc2xpY2Vz IjoNCiAgDQogIDEpIFRoZSByZXN1bHQgb2YgcGFydGl0aW9uaW5nIGEgc2V0IG9mIChwaHlzaWNh bC92aXJ0dWFsKSByZXNvdXJjZXMgdG8NCiAgZ2V0IHRoZSBhZm9yZW1lbnRpb25lZCAicG9ydGlv bnMiLiBUaGlzIGlzIHRoZSBvcGVyYXRvci9vd25lciBwb2ludCBvZg0KICB2aWV3IGFuZCBpcyBp bnRyaW5zaWNhbGx5IHJlbGF0ZWQgdG8gdGhlIGVtYmVkZGluZyBhbmQgbWFuYWdlbWVudC4NCg0K ICAyKSBUaGUgc2V0IG9mIHJlc291cmNlIHBvcnRpb25zIGFzc2lnbmVkIHRvIGEgc2luZ2UgZW50 aXR5LiBBcyBpdCBpcw0KICBiZWluZyBjdXJyZW50bHkgdXNlZCwgZm9yIGluc3RhbmNlLCBieSBQ bGFuZXRMYWIsIGEgInNsaWNlIiBtZWFucyBhDQogIHBvcnRpb24gb2YgdGhlIHdob2xlIGluZnJh c3RydWN0dXJlIGFuZCBub3QganVzdCBhIHBvcnRpb24gb2YgYSBzaW5nbGUNCiAgcmVzb3VyY2Uu DQoNCi0gVGhlIHJlbGF0aW9uIGJldHdlZW4gdmlydHVhbGlhdGlvbiBhbmQgc2xpY2luZyBpcyB0 aGF0IHRoZSBsYXR0ZXIgY2FuDQogIGJlIGltcGxlbWVudGVkIGJ5IHRoZSBmb3JtZXIuIEhvd2V2 ZXIsIHNsaWNlcyBjb3VsZCBiZSBpbnN0YW50aWF0ZWQgYnkNCiAgb3RoZXIgbWVhbnMsIHNvIHRo ZSBzZXBhcmF0ZSBkZWZpbml0aW9ucyBhcmUgbm90IHN1cGVyZmx1b3VzLiBBbHNvLCBpdA0KICBp cyBub3QgZmFpciB0byBsaW5rIFZQTiBjYXBhYmlsaXRpZXMgYW5kIHNsaWNlcy4gQSBWUE4gY2Fu IGJlIGVtYmVkZGVkDQogIG9uIGEgc2xpY2UsIGJ1dCBpdCBpcyBub3QgdGhlIG9ubHkgcHVycG9z ZSBvZiB0aGUgbGF0dGVyLCBzbyBzdWNoIGxpbmsNCiAgb2YgY2FwYWJpbGl0aWVzIGNvdWxkIGVu ZCB1cCBpbiBzb21lIG1pc3VuZGVyc3RhbmRpbmdzLg0KDQotIFNvZnR3YXJpemF0aW9uIGlzICJ0 aGUgYWN0IG9mIGNvbnZlcnRpbmcgaGFyZC13YXJlIHRvIHNvZnQtd2FyZSIuIEl0DQogIGlzIG5v dCBhbiBpbnRlcmZhY2Ugb3IgYSBtZWNoYW5pc20gYnV0IGEgbWV0aG9kIGFuZCBwcm9jZXNzLiBB cyB3aXRoDQogIHNsaWNpbmcsIHZpcnR1YWxpemF0aW9uIGNhbiBiZSB1c2VkIHRvIGltcGxlbWVu dCBzdWNoICJwcm9jZXNzIiwgYnV0DQogIGl0IGlzIG5vdCBsaW1pdGVkIHRvIGl0LiBJbiBmYWN0 LCBpdCBjb3VsZCBiZSB0aGUgb3RoZXIgd2F5IGFyb3VuZCwgc28NCiAgdXNpbmcgc29mdHdhcml6 ZWQgc3lzdGVtcyB0byBpbXBsZW1lbnQgdmlydHVhbCBzeXN0ZW1zLiBGb3IgaW5zdGFuY2UsDQog IGFuIE9wZW5GbG93IFN3aXRjaCBpcyAiYSBzb2Z3YXJpemVkIHN3aXRjaCIgYW5kIGl0cyBtYWlu IHJlbGF0aW9uIHRvDQogIHZpcnR1YWxpemF0aW9uIGlzIHRoYXQgdGhlIGZsZXhpYmlsaXR5IHBy b3ZpZGVkIGJ5IHN1Y2ggc29mdHdhcml6YXRpb24NCiAgcHJvY2VzcyBjYW4gYmUgdXNlZCB0byAi c2xpY2UiIGEgcGh5c2ljYWwgc3dpdGNoIGFuZCBwcm92aWRlIGlzb2xhdGVkDQogIHZpcnR1YWwg c3dpdGNoZXMgKHVzaW5nIHNvbWUgdG9vbCBsaWtlIEZsb3dWaXNvcikuIFRoaXMgc2hvd3MgYSB3 YXkgb2YNCiAgbGluayB0aGUgdGhyZWUgdGVybXMgKHNsaWNpbmcsIHNvZnR3YXJpemF0aW9uLCBh bmQgdmlydHVhbGl6YXRpb24pLg0KDQpDb250cmFzdGluZyB0aGVzZSBhbmQgcHJldmlvdXMgZXhw bGFuYXRpb25zLCBhbmQgY29uc2lkZXJpbmcgYWxsIG9mIHRoZW0gYXMgdmFsaWQgZnJvbSBkaWZm ZXJlbnQgcGVyc3BlY3RpdmVzLCBJIGNvbmNsdWRlIHRoYXQgdGhlcmUgYXJlIHN0aWxsIG1hbnkg bnVhbmNlcyB0aGF0IG5lZWQgdG8gYmUgY2xhcmlmaWVkIGFuZCBtYXliZSBzb21lIG1pc2NvbmNl cHRpb25zIG9uIGN1cnJlbnQgY29uY2VwdHMgdGhhdCBzaG91bGQgYmUgZXJhZGljYXRlZC4gVGhl cmVmb3JlLCBJIGluc2lzdCBpbiB0aGUgbmVlZCB0byBtYWtlIHNvbWUgY29sbGFib3JhdGl2ZSBk b2N1bWVudCAod2lraSwgR29vZ2xlIERvYywgZXRjLikgdG8gdHJ5IHRvIHJlYWNoIGEgY29tbW9u IGFuZCBhZ3JlZWQgc2V0IG9mIGRlZmluaXRpb25zLg0KDQpSZWdhcmRzLA0KUGVkcm8NCg0KLS0N ClBlZHJvIE1hcnRpbmV6LUp1bGlhDQpOZXR3b3JrIFNjaWVuY2UgYW5kIENvbnZlcmdlbmNlIERl dmljZSBUZWNobm9sb2d5IExhYm9yYXRvcnkgTmV0d29yayBTeXN0ZW0gUmVzZWFyY2ggSW5zdGl0 dXRlIE5hdGlvbmFsIEluc3RpdHV0ZSBvZiBJbmZvcm1hdGlvbiBhbmQgQ29tbXVuaWNhdGlvbnMg VGVjaG5vbG9neSAoTklDVCkgNC0yLTEsIE51a3VpLUtpdGFtYWNoaSwgS29nYW5laSwgVG9reW8g MTg0LTg3OTUsIEphcGFuDQpFbWFpbDogcGVkcm9AbmljdC5nby5qcA0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoqKiogRW50aWEgbm9u IHN1bnQgbXVsdGlwbGljYW5kYSBwcmFldGVyIG5lY2Vzc2l0YXRlbSAqKioNCg0K From nobody Tue Feb 7 15:50:40 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14F2129697 for ; Tue, 7 Feb 2017 15:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 wXboxMISPDzn for ; Tue, 7 Feb 2017 15:50:36 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 93AF9129685 for ; Tue, 7 Feb 2017 15:50:36 -0800 (PST) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id v17NoUSQ078109; Wed, 8 Feb 2017 08:50:30 +0900 (JST) Received: from mail2.nict.go.jp (mail2.nict.go.jp [133.243.18.15]) by gw1.nict.go.jp with ESMTP id v17NoU2V078006; Wed, 8 Feb 2017 08:50:30 +0900 (JST) Received: from spectre (unknown [133.243.115.68]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.nict.go.jp (NICT Mail Spool Server2) with ESMTPS id 29B4595BB; Wed, 8 Feb 2017 08:50:30 +0900 (JST) Date: Wed, 8 Feb 2017 08:50:31 +0900 From: Pedro Martinez-Julia To: Stewart Bryant Message-ID: <20170207235031.GV12800@spectre> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Virus-Scanned: clamav-milter 0.98.7 at zenith1 X-Virus-Status: Clean Archived-At: Cc: "Dongjie \(Jimmy\)" , Network Slices , AshwoodsmithPeter , "Kiran.Makhijani" , "Natale, Bob" , Alex Galis Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 23:50:38 -0000 Dear Stewart, Find my comments in-line. On Tue, Feb 07, 2017 at 06:16:02PM +0000, Stewart Bryant wrote: > > They can be somehow related but it is not the same concept. Using > > NFV to illustrate the difference, it defines a set of fixed > > functions that are virtualized, but the resulting functions are not > > 100% soft-ware because they resemble the corresponding "hardware", > > which is quite fixed. > > I don't agree with that. > > I can instantiate any function I wish as an NFV function, be it a well > known function such as a load balancer, or it can be some relatively > unknown function such as a homomorphic packet timestamper, or it could > be some function only known to the customer but hosted in the network > as an opaque function. > > I can dynamically provision such functions on CPU and add or remove > them from a path. > > Thus I see no difference between a softwarized system and a system of > NFV components stitched together with SFC, at least with the > definition provided above. As I mentioned in my following paragraph, what you are describing is a softwarized "infrastructure" composed of non-softwarized functions. Thus you are true that they are related, I am not saying the opposite, but it is not the same. We can say that "NFV is a mechanism to sofwarize the infrastructure aspects of a network system" but it does not mean that "softwarization is virtualization" or that "NFV is a subset of softarization". They are different mechanisms/techniques for purposes that overlap, but only to some extent. > > Taking this into account I would say that NFV is a mechanism for > > softwarizing a network infrastructure (making it more flexible, > > programmable, etc.) but it is only limited to the infrastructure > > boundary because the functions themselves are "hard-fixed" unless > > they are also softwarized. > > Obviously I don't agree with that. What constrains them to be > hard-fixed? I think that Pete's message in this thread gives a better illustration of the meaning of such "hard-fixed" concept. In summary is that although the infrastructure, as I mentioned above, can be programmable (flexible, soft-ware), the individual mechanisms that compose do not usually expose such degree of programmability. As you mentioned, a homomorphic packet time stamper or a load balancer, for instance, usually have pre-defined behaviours which are configurable but not programmable. To sum up, I am not arguing that NFV "is not softwarization", just that softwarization is not virtualization, at least "not just". They can have some common goals but the former emphasizes the migration from pre-fixed to dynamic *behaviors* while the latter lies in the migration from fixed to dynamic *elements* (services, devices, infrastructures). > - Stewart Regards, Pedro -- Pedro Martinez-Julia Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: pedro@nict.go.jp --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** From nobody Tue Feb 7 18:40:49 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC10B1294E2 for ; Tue, 7 Feb 2017 18:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RJF-3EHd8FEq for ; Tue, 7 Feb 2017 18:40:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C674129446 for ; Tue, 7 Feb 2017 18:40:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAE89255; Wed, 08 Feb 2017 02:40:44 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 8 Feb 2017 02:40:43 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 8 Feb 2017 10:40:35 +0800 From: "Dongjie (Jimmy)" To: Leeyoung , "netslices@ietf.org" Thread-Topic: Discussion about network slicing in IETF Thread-Index: AQHSgF/eQQU/hdFeu02poLyUO2CZP6FcmbuggAHIVfA= Date: Wed, 8 Feb 2017 02:41:45 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9279357B497@NKGEML515-MBX.china.huawei.com> References: <76CD132C3ADEF848BD84D028D243C9279357A0F2@NKGEML515-MBX.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E172B295440@SJCEML702-CHM.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E172B295440@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] 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.0A090206.589A852D.000B, 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: 0a4ee341736e61d72576a2cf8218006e Archived-At: Subject: Re: [Netslices] Discussion about network slicing in IETF X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 02:40:49 -0000 Hi Young,=20 Thanks a lot for your feedbacks about ACTN.=20 As E2E network slicing is required in 5G, it would cover the slicing of end= to end resources including the network, compute and storage. While IMO the= scope of network slicing in IETF would be mainly related to the network pa= rt, the coordination/interaction between network and other parts (network o= r service functions) of the E2E slicing may also need to be considered. Best regards, Jie > -----Original Message----- > From: Leeyoung > Sent: Tuesday, February 07, 2017 7:12 AM > To: Dongjie (Jimmy) ; netslices@ietf.org > Subject: RE: Discussion about network slicing in IETF >=20 > Hi Jim, >=20 > I can speak for ACTN. Please see inline for my comment. >=20 > Thanks. > Young >=20 > -----Original Message----- > From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Dongjie > (Jimmy) > Sent: Monday, February 06, 2017 7:53 AM > To: netslices@ietf.org > Subject: [Netslices] Discussion about network slicing in IETF >=20 > Dear all, >=20 > According to some early investigations, the topic network slicing would c= ross > several WGs, even multiple Areas in IETF, and there are some existing and > ongoing works in IETF related to network slicing, such as the various VPN > technologies, the ongoing ACTN work in TEAS WG, the work on deterministic > network in DETNET WG, the work on autonomic management in ANIMA WG, etc. > Through the discussion on this mailing list, we'd like to understand if t= here are > gaps in meeting the network slicing requirements, and if needed, to combi= ne the > existing and ongoing works, together with potential protocol enhancements= or > new protocols to achieve network slicing of the mobile transport network. >=20 > In order to have better understanding of the gaps in transport network sl= icing, > we may start with a few questions: >=20 > 1. To what extent can the requirements of network slicing in data plane b= e > addressed by existing IETF technologies such as VPNs (and VPN like techno= logies)? > We note in asking this that in some cases VPNs may need to be enhanced by > some deterministic technology such as that being investigated in the DETN= ET > WG. >=20 > And to what extent do the control planes of existing technologies satisfy= the > needs of network slicing? Note that in some 5G use cases the customized o= r > dedicated control plane may be needed for some of the network slices, whi= le in > some other cases the control plane may be shared between slices. >=20 > 2. Does ACTN completely satisfy the abstraction of Network Slices (NS) to= the > operators or the customers who instantiate, monitor and manage an NS thro= ugh > its lifecycle, including dynamically changing a slice to account for the = varying > needs during its lifecycle from creation to disposal, is there any additi= onal > mechanism also required? >=20 > YOUNG>> I think so. ACTN allows VN slice to be > created/monitored/modified/deleted dynamically supporting CRUD operations= . I > just want to make a point that the abstraction of network slices in ACTN = is only > for network resources but not for compute or storage. CSO (Cross-Stratum > Optimzation) work address how to combine compute and storage slices with > ACTN's network slices. My understanding for the scope of network slicing = is > primarily network resource slicing, correct? >=20 > 3. How do we characterize the determinism requirement of NS? To what exte= nt > is the determinism hard and to what extent is it soft, i.e. what are the = absolute > requirements, and what requirements can be met by some form of probabilit= y > mask? Does the design being proposed by the DETNET design team (which is = still > in stealth mode) address all of this? >=20 > 4. To what extent does the network need to open the control and managemen= t > of the network slices to the third parties? And to what extent can this b= e > addressed by existing technologies, such as PCE, Segment Routing, SFC and > Netconf? >=20 > Your insightful thoughts are much appreciated. >=20 > Best regards, > Jie >=20 >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices From nobody Tue Feb 7 19:17:34 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0E1129EFB for ; Tue, 7 Feb 2017 19:17:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 1Q9ybB9kw7GF for ; Tue, 7 Feb 2017 19:17:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 808AD129EF4 for ; Tue, 7 Feb 2017 19:17:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAE92983; Wed, 08 Feb 2017 03:17:28 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 8 Feb 2017 03:17:08 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 8 Feb 2017 11:16:44 +0800 From: "Dongjie (Jimmy)" To: Satoru Matsushima , "netslices@ietf.org" Thread-Topic: [Netslices] Data-plane work in DMM WG with slicing concept Thread-Index: AQHSgQe2CvJm0ANxj0ieKTIcony6vaFeagFA Date: Wed, 8 Feb 2017 03:17:55 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9279357B4CB@NKGEML515-MBX.china.huawei.com> References: <503A1908-2068-47A2-B8E0-5D7E3BF88444@gmail.com> In-Reply-To: <503A1908-2068-47A2-B8E0-5D7E3BF88444@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] 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.0A090202.589A8DC8.00D0, 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: 047617b17877e7d3d3434efd2840db09 Archived-At: Subject: Re: [Netslices] Data-plane work in DMM WG with slicing concept X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 03:17:33 -0000 SGkgU2F0b3J1LCANCg0KVGhhbmtzIGZvciBpbnRyb2R1Y2luZyB0aGUgbmV0d29yayBzbGljaW5n IHJlbGF0ZWQgd29yayBpbiBETU0uIA0KDQpXaGlsZSBJIGRvbid0IGhhdmUgbXVjaCBleHBlcnRp c2UgaW4gRE1NLCBteSByb3VnaCB1bmRlcnN0YW5kaW5nIGlzIHRoZSBzZXBhcmF0aW9uIG9mIGRh dGEgcGxhbmUgYW5kIGNvbnRyb2wgcGxhbmUgaW4gbW9iaWxlIG5ldHdvcmsgbWF5IGhhdmUgc29t ZSByZXF1aXJlbWVudCBvbiBuZXR3b3JrIHNsaWNpbmcsIGFuZCBmb3IgRTJFIG5ldHdvcmsgc2xp Y2luZyBpdCBtYXkgYmUgbmVlZGVkIHRvIGpvaW50bHkgY29uc2lkZXIgdGhlIHNsaWNpbmcgaW4g bW9iaWxlIG5ldHdvcmsgYW5kIHRyYW5zcG9ydCBuZXR3b3JrLiBJdCB3b3VsZCBiZSBncmVhdCBp ZiB5b3UgY291bGQgaGVscCB0byBkZXNjcmliZSB0aGUgc2xpY2luZyByZXF1aXJlbWVudHMgZnJv bSBETU0gcGVyc3BlY3RpdmUuIA0KDQpCZXN0IHJlZ2FyZHMsDQpKaWUNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBOZXRzbGljZXMgW21haWx0bzpuZXRzbGljZXMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNhdG9ydQ0KPiBNYXRzdXNoaW1hDQo+IFNlbnQ6 IFR1ZXNkYXksIEZlYnJ1YXJ5IDA3LCAyMDE3IDI6MDIgUE0NCj4gVG86IG5ldHNsaWNlc0BpZXRm Lm9yZw0KPiBTdWJqZWN0OiBbTmV0c2xpY2VzXSBEYXRhLXBsYW5lIHdvcmsgaW4gRE1NIFdHIHdp dGggc2xpY2luZyBjb25jZXB0DQo+IA0KPiBBbGwsDQo+IA0KPiBJRVRGIERNTSAoRGlzdHJpYnV0 ZWQgTW9iaWxpdHkgTWFuYWdlbWVudCkgd29ya2luZyBncm91cCBoYXMgYmVlbg0KPiBjaGFydGVy ZWQgdG8gbWFrZSBzZXBhcmF0aW9uIG9mIGRhdGEtcGxhbmUgZnJvbSBtb2JpbGUgY29udHJvbC1w bGFuZSwgd2hpY2gNCj4gZGVmaW5lcyBkYXRhLXBsYW5lIG9ic3RydWN0aW9uIG1vZGVscyB3aXRo IG5ldHdvcmsgc2xpY2luZyBjb25jZXB0Lg0KPiANCj4gVGhyb3VnaCB0aGUgZGlzY3Vzc2lvbiBv biB0aGUgTmV0c2xpY2VzIGxpc3QsIEnigJl2ZSBub3RpY2VkIHdoYXQgdGhlIGRyYWZ0IGNhbGxz DQo+IOKAnERvbWFpbuKAnSB3b3VsZCBhbG1vc3QgY2xvc2UgdG8g4oCcTmV0d29yayBTbGljaW5n 4oCdLg0KPiANCj4gRGF0YS1wbGFuZSBtb2RlbCBvZiBGUEMgcHJvdmlkZXMgaW5mb3JtYXRpb24g YW5kIGRhdGEgbW9kZWwgYnkgWUFORyBmb3INCj4gbW9iaWxlIG5ldHdvcmsgd2hpY2ggSU1PIHdv dWxkIGJlIGhlbHBmdWwgdG8gZmlndXJlIHNsaWNpbmcgbW9kZWwgb3V0Lg0KPiANCj4gRlBDLXRv cG9sb2d5IHRyZWUgaXMgb25lIGZvciB0aGF0LiBGUEMtcG9saWN5IHdvdWxkIGJlIHJlcXVpcmVt ZW50cyB0byB0aGUgc2xpY2UuDQo+IA0KPiANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1kbW0tZnBjLWNwZHAvDQo+IA0KPiANCj4gUHJvdG9jb2wgZm9yIEZv cndhcmRpbmcgUG9saWN5IENvbmZpZ3VyYXRpb24gKEZQQykgaW4gRE1NDQo+ICAgICAgICAgICAg ICBkcmFmdC1pZXRmLWRtbS1mcGMtY3BkcC0wNS50eHQNCj4gDQo+IA0KPiBBYnN0cmFjdA0KPiAN Cj4gDQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBzb2x1dGlvbiBvZiBkYXRhLXBs YW5lIHNlcGFyYXRpb24gZnJvbQ0KPiAgICBjb250cm9sLXBsYW5lIHdoaWNoIGVuYWJsZXMgYSBm bGV4aWJsZSBtb2JpbGl0eSBtYW5hZ2VtZW50IHN5c3RlbQ0KPiAgICB1c2luZyBhZ2VudCBhbmQg Y2xpZW50IGZ1bmN0aW9ucy4gIFRvIGNvbmZpZ3VyZSBkYXRhLXBsYW5lIG5vZGVzIGFuZA0KPiAg ICBmdW5jdGlvbnMsIHRoZSBkYXRhLXBsYW5lIGlzIGFic3RyYWN0ZWQgYnkgYW4gYWdlbnQgaW50 ZXJmYWNlIHRvIHRoZQ0KPiAgICBjbGllbnQuICBUaGUgZGF0YS1wbGFuZSBhYnN0cmFjdGlvbiBt b2RlbCBpcyBleHRlbnNpYmxlIGluIG9yZGVyIHRvDQo+ICAgIHN1cHBvcnQgbWFueSBkaWZmZXJl bnQgdHlwZSBvZiBtb2JpbGl0eSBtYW5hZ2VtZW50IHN5c3RlbXMgYW5kIGRhdGEtDQo+ICAgIHBs YW5lIGZ1bmN0aW9ucy4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gLS1zYXRvcnUNCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTmV0c2xpY2VzIG1h aWxpbmcgbGlzdA0KPiBOZXRzbGljZXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRzbGljZXMNCg== From nobody Tue Feb 7 19:51:28 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9439312983F for ; Tue, 7 Feb 2017 19:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 YR15l58QscW5 for ; Tue, 7 Feb 2017 19:51:24 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7BD1297ED for ; Tue, 7 Feb 2017 19:51:24 -0800 (PST) Received: from [192.168.1.11] (unknown [112.204.169.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id A0AB118013D1; Wed, 8 Feb 2017 04:51:21 +0100 (CET) To: "Smith, Kevin, (R&D) Vodafone Group" , "netslices@ietf.org" References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> From: Loa Andersson Message-ID: Date: Wed, 8 Feb 2017 11:51:16 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 03:51:26 -0000 Kevin, On 2017-02-07 17:20, Smith, Kevin, (R&D) Vodafone Group wrote: > Hi Loa, > >> I thought that "network slicing" meant that a network provider can give a network user, a slice of the network (with all functions needed), to satisfy the network users requirements. So E2E if E2E is needed. > > Yes, although that may not be fully E2E I - think we agree. You ysay "may not be fully E2"", which I take to be more or less the same as "E2E if E2E is needed". So we have a BIG and resourceful network, from which we can cut slices in such a way that a particular slice may serve a particular network user exactly as a purpose built network woud? /Loa if the origin server is hosted outside of the providers' network. Network slicing should allow the network provider to rapidly allocate/deallocate network resources towards flows, based on the characteristics of each flow. So each flow will demand a certain blend of latency, mobility, capacity, resilience, pacing, durability etc. - it doesn't necessarily need to be a function as such, although those can be added a la service chaining if required. In a cellular network this can also include radio resources, so terminal-to-external-edge-of-operator-network (maybe 'operator domain' is snappier :)). > > All best, > Kevin > > Kevin Smith, Vodafone > > -----Original Message----- > From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: 07 February 2017 07:20 > To: netslices@ietf.org > Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement > > Folks, > > I may be kicking in open doors, or alternatively showing that I misunderstood thing fundamentally. > > I thought that "network slicing" meant that a network provider can give a network user, a slice of the network (with all functions needed), to satisfy the network users requirements. > > So E2E if E2E is needed. > > /Loa > > > On 2017-02-07 13:26, Pedro Martinez-Julia wrote: >> On Tue, Feb 07, 2017 at 04:53:34AM +0000, Natale, Bob wrote: >>> Hi Pedro, >>> >>> Concerning your explanation that 'Softwarization is "the act of >>> converting hard-ware to soft-ware"', isn't that just "function >>> virtualization" as in, for example, NFV? >> >> They can be somehow related but it is not the same concept. Using NFV >> to illustrate the difference, it defines a set of fixed functions that >> are virtualized, but the resulting functions are not 100% soft-ware >> because they resemble the corresponding "hardware", which is quite >> fixed. Taking this into account I would say that NFV is a mechanism >> for softwarizing a network infrastructure (making it more flexible, >> programmable, etc.) but it is only limited to the infrastructure >> boundary because the functions themselves are "hard-fixed" unless they are also softwarized. >> >> I hope this adds some useful concepts about the relations and >> diferences between virtualization and softwarization... >> >>> Avanti, >>> BobN >> >> Regards, >> Pedro >> > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Tue Feb 7 20:17:07 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B831112987C for ; Tue, 7 Feb 2017 20:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 BO0UlK1aXaB5 for ; Tue, 7 Feb 2017 20:17:04 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id F03C7129875 for ; Tue, 7 Feb 2017 20:17:03 -0800 (PST) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id v184H0sA039525; Wed, 8 Feb 2017 13:17:00 +0900 (JST) Received: from mail1.nict.go.jp (mail1.nict.go.jp [133.243.18.14]) by gw1.nict.go.jp with ESMTP id v184Gx0L039522; Wed, 8 Feb 2017 13:17:00 +0900 (JST) Received: from spectre (unknown [133.243.28.222]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.nict.go.jp (NICT Mail Spool Server1) with ESMTPS id DFB759FFF; Wed, 8 Feb 2017 13:16:59 +0900 (JST) Date: Wed, 8 Feb 2017 13:16:59 +0900 From: Pedro Martinez-Julia To: Loa Andersson Message-ID: <20170208041658.GW12800@spectre> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Virus-Scanned: clamav-milter 0.98.7 at zenith1 X-Virus-Status: Clean Archived-At: Cc: "Smith, Kevin, \(R&D\) Vodafone Group" , "netslices@ietf.org" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 04:17:05 -0000 On Wed, Feb 08, 2017 at 11:51:16AM +0800, Loa Andersson wrote: > So we have a BIG and resourceful network, from which we can cut slices > in such a way that a particular slice may serve a particular network > user exactly as a purpose built network woud? This is a key definition for network slicing. However, we have also to consider two different manners to provision such slices: - That the slice is provided "as a set of resources" (which would be most probably virtual) without being pre-configured. This way, the user is responsible of the management of such resources to form and control/manage its infrastructure. - That the slice is provided as an infrastructure for a specific purpose requested by the user. The provider is responsible of the management of both the underlying and overlaying infrastructures and the user is limited to consume it and make any management-related request to the provider. As we are trying to get a proper definition of slice and its scope, I think we have to clarify those two alternatives or, at least, be sure that the definition we finally push forward is not tied to just one of them. Regards, Pedro -- Pedro Martinez-Julia Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: pedro@nict.go.jp --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** From nobody Tue Feb 7 21:09:47 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DF9129954 for ; Tue, 7 Feb 2017 21:09:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fm75FGZHqQSG for ; Tue, 7 Feb 2017 21:09:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7910E129964 for ; Tue, 7 Feb 2017 21:09:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAF02878; Wed, 08 Feb 2017 05:09:41 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 8 Feb 2017 05:09:40 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML703-CHM.china.huawei.com ([169.254.5.69]) with mapi id 14.03.0235.001; Tue, 7 Feb 2017 21:09:34 -0800 From: "Kiran.Makhijani" To: "loa@pi.nu" , "pedro@nict.go.jp" Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHSgcmJNCA/VgOI1EK435kCjbl9Pw== Date: Wed, 8 Feb 2017 05:09:34 +0000 Message-ID: References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> , <20170208041658.GW12800@spectre> In-Reply-To: <20170208041658.GW12800@spectre> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_etPan589aa80e50fa7ffc137cKiransiPhone_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.589AA815.02BA, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4b4087b739c9a583b19a823722c57024 Archived-At: Cc: "Smith, Kevin" , "netslices@ietf.org" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 05:09:46 -0000 --_000_etPan589aa80e50fa7ffc137cKiransiPhone_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The provider is responsible of the management of both the underlying and overlaying infrastructures. ^^^^^^** I like the way you explain it, but disagree with the above; the overlaying = infrastructures should be managed by different set of operators who'd own t= hose logical infrastructures. Isn't it? Regards Kiran From: Pedro Martinez-Julia To: Loa Andersson; Cc: Smith, Kevin; netslices@ietf.org; Subject: Re: [Netslices] Network Slicing - Introductory Document and Revise= d Problem Statement Time: 2017-02-07 20:17:34 On Wed, Feb 08, 2017 at 11:51:16AM +0800, Loa Andersson wrote: > So we have a BIG and resourceful network, from which we can cut slices > in such a way that a particular slice may serve a particular network > user exactly as a purpose built network woud? This is a key definition for network slicing. However, we have also to consider two different manners to provision such slices: - That the slice is provided "as a set of resources" (which would be most probably virtual) without being pre-configured. This way, the user is responsible of the management of such resources to form and control/manage its infrastructure. - That the slice is provided as an infrastructure for a specific purpose requested by the user. The provider is responsible of the management of both the underlying and overlaying infrastructures and the user is limited to consume it and make any management-related request to the provider. As we are trying to get a proper definition of slice and its scope, I think we have to clarify those two alternatives or, at least, be sure that the definition we finally push forward is not tied to just one of them. Regards, Pedro -- Pedro Martinez-Julia Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: pedro@nict.go.jp --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** _______________________________________________ Netslices mailing list Netslices@ietf.org https://www.ietf.org/mailman/listinfo/netslices --_000_etPan589aa80e50fa7ffc137cKiransiPhone_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The provider is responsible of the manag= ement
  of both the underlying and overlaying&= nbsp;infrastructures.
^^^^^^**
I like the way you explain it, but = disagree with the above; the overlaying infra= structures should be managed by different set=  of operators who'd own those logical in= frastructures. Isn't it?

Regards
Kiran
From: Pedro Martinez-Julia
To: Loa Andersson;
Cc: Smith, Kevin; netslices@ietf.org;
Subject: Re: [Netslices] Network Slicing - Introductory Documen= t and Revised Problem Statement
Time: 2017-02-07 20:17:34


On Wed, Feb 08, 2017 at 11:51:16AM +0800, Loa = Andersson wrote:
> So we have a BIG and resourceful network, from which we can cut slices=
> in such a way that a particular slice may serve a particular network > user exactly as a purpose built network woud?

This is a key definition for network slicing. However, we have also to
consider two different manners to provision such slices:

- That the slice is provided "as a set of resources" (which would= be
  most probably virtual) without being pre-configured. This way, the   user is responsible of the management of such resources to form and<= br>   control/manage its infrastructure.

- That the slice is provided as an infrastructure for a specific purpose   requested by the user. The provider is responsible of the management=
  of both the underlying and overlaying infrastructures and the user i= s
  limited to consume it and make any management-related request to the=
  provider.

As we are trying to get a proper definition of slice and its scope, I
think we have to clarify those two alternatives or, at least, be sure
that the definition we finally push forward is not tied to just one of
them.

Regards,
Pedro

--
Pedro Martinez-Julia
Network Science and Convergence Device Technology Laboratory
Network System Research Institute
National Institute of Information and Communications Technology (NICT)
4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan
Email: pedro@nict.go.jp
---------------------------------------------------------
*** Entia non sunt multiplicanda praeter necessitatem ***

_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.iet= f.org/mailman/listinfo/netslices
 --_000_etPan589aa80e50fa7ffc137cKiransiPhone_-- From nobody Tue Feb 7 21:29:05 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0C0129980 for ; Tue, 7 Feb 2017 21:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UloypQ_XWtd4 for ; Tue, 7 Feb 2017 21:29:02 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7925312997F for ; Tue, 7 Feb 2017 21:29:02 -0800 (PST) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id v185SxXV077221; Wed, 8 Feb 2017 14:28:59 +0900 (JST) Received: from mail1.nict.go.jp (mail1.nict.go.jp [133.243.18.14]) by gw1.nict.go.jp with ESMTP id v185SxkN077217; Wed, 8 Feb 2017 14:28:59 +0900 (JST) Received: from spectre (unknown [133.243.28.222]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail1.nict.go.jp (NICT Mail Spool Server1) with ESMTPS id 38BBE9BDC; Wed, 8 Feb 2017 14:28:59 +0900 (JST) Date: Wed, 8 Feb 2017 14:28:58 +0900 From: Pedro Martinez-Julia To: "Kiran.Makhijani" Message-ID: <20170208052858.GX12800@spectre> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> <20170208041658.GW12800@spectre> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Virus-Scanned: clamav-milter 0.98.7 at zenith1 X-Virus-Status: Clean Archived-At: Cc: "Smith, Kevin" , "netslices@ietf.org" , "loa@pi.nu" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 05:29:04 -0000 On Wed, Feb 08, 2017 at 05:09:34AM +0000, Kiran.Makhijani wrote: > The provider is responsible of the management > of both the underlying and overlaying infrastructures. > ^^^^^^** > I like the way you explain it, but disagree with the above; the overlaying infrastructures should be managed by different set of operators who'd own those logical infrastructures. Isn't it? Hence such operators are "the provider". However, they do not need to be different, so: Some role definitions: - Infrastructure Provider (InP): Owner and manager of the underlying physical infrastructure (*). - Virtual Network Operator (VNO): Gets one or more slices of resources from the InP and offers a network service them to users. - User: Exploits the network service, such as connectivity (**). Possible scenarios: - The three roles (InP, VNO, User) are played by different entities. - The same entity plays the InP and VNO roles, the user role is played by a different entity. This is one of the cases I mentioned. - An entity plays the InP role and other entity plays the VNO and User roles. This is the other case I mentioned and reflects a user that needs (or wants) to self-manage their slices. (*) On purpose of simplicity I do not mention the scenario where the underlying infrastructure is virtual. However, this scheme can be made recursive, so we have a single InP, multiple VNOs, and a final User. (**) Here the "user" can be a final user or a service provider. I also avoid delving on it to keep the example simple. This view is quite extended but, please, give your comments so we can refine it together. Thank you. > Regards > Kiran Regards, Pedro -- Pedro Martinez-Julia Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: pedro@nict.go.jp --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** From nobody Tue Feb 7 22:21:56 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE071298B9 for ; Tue, 7 Feb 2017 22:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bT3wDNxzoyrn for ; Tue, 7 Feb 2017 22:21:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06DE5129440 for ; Tue, 7 Feb 2017 22:21:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGA52154; Wed, 08 Feb 2017 06:21:50 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 8 Feb 2017 06:21:49 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Wed, 8 Feb 2017 14:21:47 +0800 From: "Dongjie (Jimmy)" To: "Smith, Kevin, (R&D) Vodafone Group" , "Loa Andersson" , "netslices@ietf.org" Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvq7wX2ECP+/oEWl791jc0LWbKFbjOGAgACPA4CAACspgIAASSYAgAAJHACAAB+1gIAAIb6AgAG9wSA= Date: Wed, 8 Feb 2017 06:22:56 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9279357B562@NKGEML515-MBX.china.huawei.com> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] 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.0A090202.589AB8FE.0048, 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: f6548cccac4325e6ded5c70cc1387d4d Archived-At: Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 06:21:54 -0000 Hi Kevin,=20 > -----Original Message----- > From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Smith, K= evin, > (R&D) Vodafone Group > Sent: Tuesday, February 07, 2017 5:20 PM > To: Loa Andersson ; netslices@ietf.org > Subject: Re: [Netslices] Network Slicing - Introductory Document and Revi= sed > Problem Statement >=20 > Hi Loa, >=20 > > I thought that "network slicing" meant that a network provider can give= a > network user, a slice of the network (with all functions needed), to sati= sfy the > network users requirements. So E2E if E2E is needed. >=20 > Yes, although that may not be fully E2E if the origin server is hosted o= utside of > the providers' network. Network slicing should allow the network provider= to > rapidly allocate/deallocate network resources towards flows, based on the > characteristics of each flow. So each flow will demand a certain blend of= latency, > mobility, capacity, resilience, pacing, durability etc. - it doesn't nece= ssarily need to > be a function as such, although those can be added a la service chaining = if > required. In a cellular network this can also include radio resources, so > terminal-to-external-edge-of-operator-network (maybe 'operator domain' is > snappier :)). Thanks for the description about the requirements on network slicing. May I= summarize it as "on demand network resource allocation to meet the charact= eristics required by particular service"? And I agree that a network slice may simply provide the connectivity with r= equired characteristics, or together with some network or service functions= , this all depends on the requirements of the slice user.=20 Best regards, Jie >=20 > All best, > Kevin >=20 > Kevin Smith, Vodafone >=20 > -----Original Message----- > From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Loa Ande= rsson > Sent: 07 February 2017 07:20 > To: netslices@ietf.org > Subject: Re: [Netslices] Network Slicing - Introductory Document and Revi= sed > Problem Statement >=20 > Folks, >=20 > I may be kicking in open doors, or alternatively showing that I misunders= tood > thing fundamentally. >=20 > I thought that "network slicing" meant that a network provider can give a > network user, a slice of the network (with all functions needed), to sati= sfy the > network users requirements. >=20 > So E2E if E2E is needed. >=20 > /Loa >=20 >=20 > On 2017-02-07 13:26, Pedro Martinez-Julia wrote: > > On Tue, Feb 07, 2017 at 04:53:34AM +0000, Natale, Bob wrote: > >> Hi Pedro, > >> > >> Concerning your explanation that 'Softwarization is "the act of > >> converting hard-ware to soft-ware"', isn't that just "function > >> virtualization" as in, for example, NFV? > > > > They can be somehow related but it is not the same concept. Using NFV > > to illustrate the difference, it defines a set of fixed functions that > > are virtualized, but the resulting functions are not 100% soft-ware > > because they resemble the corresponding "hardware", which is quite > > fixed. Taking this into account I would say that NFV is a mechanism > > for softwarizing a network infrastructure (making it more flexible, > > programmable, etc.) but it is only limited to the infrastructure > > boundary because the functions themselves are "hard-fixed" unless they = are > also softwarized. > > > > I hope this adds some useful concepts about the relations and > > diferences between virtualization and softwarization... > > > >> Avanti, > >> BobN > > > > Regards, > > Pedro > > >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices From nobody Tue Feb 7 22:35:53 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B946A127A90 for ; Tue, 7 Feb 2017 22:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CQQ1NEFnZYb5 for ; Tue, 7 Feb 2017 22:35:48 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7353912948F for ; Tue, 7 Feb 2017 22:35:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAF12264; Wed, 08 Feb 2017 06:35:46 +0000 (GMT) Received: from SZXEMA415-HUB.china.huawei.com (10.82.72.33) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 8 Feb 2017 06:35:45 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.116]) by SZXEMA415-HUB.china.huawei.com ([10.82.72.33]) with mapi id 14.03.0235.001; Wed, 8 Feb 2017 14:35:16 +0800 From: Mach Chen To: Pedro Martinez-Julia , "Kiran.Makhijani" Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvrBi4GMWY6lKkuz9Pzx/U+ReKFbjOGAgACPA4CAACspgIAASSYAgAAJHACAAB+1gIAAIb6AgAE2XgCAAAcvgIAADrEAgAAFbACAAJd1YA== Date: Wed, 8 Feb 2017 06:35:17 +0000 Message-ID: References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> <20170208041658.GW12800@spectre> <20170208052858.GX12800@spectre> In-Reply-To: <20170208052858.GX12800@spectre> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.194.201] 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.0A020206.589ABC43.0003, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.116, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4a463013224896b063d859c77b66bc81 Archived-At: Cc: "Smith, Kevin" , "netslices@ietf.org" , "loa@pi.nu" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 06:35:53 -0000 Hi Pedro, I like your explanation below and the two categories of network slice. I th= ink we are approaching to give a definition of network slice. Best regards, Mach > -----Original Message----- > From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Pedro > Martinez-Julia > Sent: Wednesday, February 08, 2017 1:29 PM > To: Kiran.Makhijani > Cc: Smith, Kevin; netslices@ietf.org; loa@pi.nu > Subject: Re: [Netslices] Network Slicing - Introductory Document and Revi= sed > Problem Statement >=20 > On Wed, Feb 08, 2017 at 05:09:34AM +0000, Kiran.Makhijani wrote: > > The provider is responsible of the management > > of both the underlying and overlaying infrastructures. > > ^^^^^^** > > I like the way you explain it, but disagree with the above; the overlay= ing > infrastructures should be managed by different set of operators who'd own > those logical infrastructures. Isn't it? >=20 > Hence such operators are "the provider". However, they do not need to be > different, so: >=20 > Some role definitions: >=20 > - Infrastructure Provider (InP): Owner and manager of the underlying > physical infrastructure (*). >=20 > - Virtual Network Operator (VNO): Gets one or more slices of resources > from the InP and offers a network service them to users. >=20 > - User: Exploits the network service, such as connectivity (**). >=20 > Possible scenarios: >=20 > - The three roles (InP, VNO, User) are played by different entities. >=20 > - The same entity plays the InP and VNO roles, the user role is played > by a different entity. This is one of the cases I mentioned. >=20 > - An entity plays the InP role and other entity plays the VNO and User > roles. This is the other case I mentioned and reflects a user that > needs (or wants) to self-manage their slices. >=20 > (*) On purpose of simplicity I do not mention the scenario where the unde= rlying > infrastructure is virtual. However, this scheme can be made recursive, so= we > have a single InP, multiple VNOs, and a final User. >=20 > (**) Here the "user" can be a final user or a service provider. I also av= oid > delving on it to keep the example simple. >=20 > This view is quite extended but, please, give your comments so we can ref= ine it > together. Thank you. >=20 > > Regards > > Kiran >=20 > Regards, > Pedro >=20 > -- > Pedro Martinez-Julia > Network Science and Convergence Device Technology Laboratory Network > System Research Institute National Institute of Information and > Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo > 184-8795, Japan > Email: pedro@nict.go.jp > --------------------------------------------------------- > *** Entia non sunt multiplicanda praeter necessitatem *** >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices From nobody Wed Feb 8 00:39:05 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCD9129762 for ; Wed, 8 Feb 2017 00:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 pL29Rgklek5k for ; Wed, 8 Feb 2017 00:39:01 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE137129706 for ; Wed, 8 Feb 2017 00:39:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAF30417; Wed, 08 Feb 2017 08:38:58 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 8 Feb 2017 08:38:54 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 8 Feb 2017 16:38:45 +0800 From: "Dongjie (Jimmy)" To: Pedro Martinez-Julia , "Kiran.Makhijani" Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvq7wX2ECP+/oEWl791jc0LWbKFbjOGAgACPA4CAACspgIAASSYAgAAJHACAAB+1gIAAIb6AgAE2XgCAAAcvgIAADrEAgAAFbACAAKpG8A== Date: Wed, 8 Feb 2017 08:39:55 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9279357B679@NKGEML515-MBX.china.huawei.com> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> <20170208041658.GW12800@spectre> <20170208052858.GX12800@spectre> In-Reply-To: <20170208052858.GX12800@spectre> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] 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.0A020201.589AD923.0002, 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: 4a463013224896b063d859c77b66bc81 Archived-At: Cc: "Smith, Kevin" , "netslices@ietf.org" , "loa@pi.nu" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 08:39:03 -0000 Hi Pedro,=20 Thanks for the analysis of the roles and possible scenarios. IMO all the th= ree scenarios can be possible, while in the first case the VNO may be seen = as the user of the InP, so it is kind of recursion here. According to recent discussions, maybe we could list the key properties of = network slicing, such as: 1. On-demand creation and adjustment of a logical network according to the = user requirements 2. Allocation of appropriate network resources to guarantee the characteris= tics of the network slice 3. Management and operation of the network slice can be done by either the = network operator or the network slice user. And there could be others... Hope this helps to build the definition of network slice.=20 Best regards, Jie > -----Original Message----- > From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Pedro > Martinez-Julia > Sent: Wednesday, February 08, 2017 1:29 PM > To: Kiran.Makhijani > Cc: Smith, Kevin ; netslices@ietf.org; > loa@pi.nu > Subject: Re: [Netslices] Network Slicing - Introductory Document and Revi= sed > Problem Statement >=20 > On Wed, Feb 08, 2017 at 05:09:34AM +0000, Kiran.Makhijani wrote: > > The provider is responsible of the management > > of both the underlying and overlaying infrastructures. > > ^^^^^^** > > I like the way you explain it, but disagree with the above; the overlay= ing > infrastructures should be managed by different set of operators who'd own > those logical infrastructures. Isn't it? >=20 > Hence such operators are "the provider". However, they do not need to be > different, so: >=20 > Some role definitions: >=20 > - Infrastructure Provider (InP): Owner and manager of the underlying > physical infrastructure (*). >=20 > - Virtual Network Operator (VNO): Gets one or more slices of resources > from the InP and offers a network service them to users. >=20 > - User: Exploits the network service, such as connectivity (**). >=20 > Possible scenarios: >=20 > - The three roles (InP, VNO, User) are played by different entities. >=20 > - The same entity plays the InP and VNO roles, the user role is played > by a different entity. This is one of the cases I mentioned. >=20 > - An entity plays the InP role and other entity plays the VNO and User > roles. This is the other case I mentioned and reflects a user that > needs (or wants) to self-manage their slices. >=20 > (*) On purpose of simplicity I do not mention the scenario where the > underlying infrastructure is virtual. However, this scheme can be made > recursive, so we have a single InP, multiple VNOs, and a final User. >=20 > (**) Here the "user" can be a final user or a service provider. I also av= oid > delving on it to keep the example simple. >=20 > This view is quite extended but, please, give your comments so we can ref= ine > it together. Thank you. >=20 > > Regards > > Kiran >=20 > Regards, > Pedro >=20 > -- > Pedro Martinez-Julia > Network Science and Convergence Device Technology Laboratory Network > System Research Institute National Institute of Information and > Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo > 184-8795, Japan > Email: pedro@nict.go.jp > --------------------------------------------------------- > *** Entia non sunt multiplicanda praeter necessitatem *** >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices From nobody Wed Feb 8 00:44:24 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7101299DC for ; Wed, 8 Feb 2017 00:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ggF1bFb41-VE for ; Wed, 8 Feb 2017 00:44:20 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id A43851299A3 for ; Wed, 8 Feb 2017 00:44:20 -0800 (PST) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id v188iDc2003222; Wed, 8 Feb 2017 17:44:13 +0900 (JST) Received: from mail2.nict.go.jp (mail2.nict.go.jp [133.243.18.15]) by gw1.nict.go.jp with ESMTP id v188iDJv003218; Wed, 8 Feb 2017 17:44:13 +0900 (JST) Received: from spectre (unknown [133.243.115.68]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.nict.go.jp (NICT Mail Spool Server2) with ESMTPS id 237279D7A; Wed, 8 Feb 2017 17:44:13 +0900 (JST) Date: Wed, 8 Feb 2017 17:44:12 +0900 From: Pedro Martinez-Julia To: "Dongjie (Jimmy)" Message-ID: <20170208084412.GY12800@spectre> References: <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> <20170208041658.GW12800@spectre> <20170208052858.GX12800@spectre> <76CD132C3ADEF848BD84D028D243C9279357B679@NKGEML515-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <76CD132C3ADEF848BD84D028D243C9279357B679@NKGEML515-MBX.china.huawei.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Virus-Scanned: clamav-milter 0.98.7 at zenith1 X-Virus-Status: Clean Archived-At: Cc: "loa@pi.nu" , "Smith, Kevin" , "netslices@ietf.org" , "Kiran.Makhijani" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 08:44:23 -0000 On Wed, Feb 08, 2017 at 08:39:55AM +0000, Dongjie (Jimmy) wrote: > Hi Pedro, > > Thanks for the analysis of the roles and possible scenarios. IMO all > the three scenarios can be possible, while in the first case the VNO > may be seen as the user of the InP, so it is kind of recursion here. Yes, it can. However, without additional levels, the functions used by the InP and VNO are different. The former "slices" its resources while the latter "services" the infrastructure to the users. If you add more levels, you actually have that the middle would have a VNO interface to their "parent" InP and an InP interface to their "child" VNO... > According to recent discussions, maybe we could list the key > properties of network slicing, such as: > > 1. On-demand creation and adjustment of a logical network according to > the user requirements > > 2. Allocation of appropriate network resources to guarantee the > characteristics of the network slice > > 3. Management and operation of the network slice can be done by either > the network operator or the network slice user. > > And there could be others... > > Hope this helps to build the definition of network slice. I agree with this line of definition, although there could be nuances to add to each aspect. I insist to proceed with the collection of all this information in some wiki... > Best regards, > Jie Regards, Pedro -- Pedro Martinez-Julia Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: pedro@nict.go.jp --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** From nobody Wed Feb 8 02:13:33 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D415F129504 for ; Wed, 8 Feb 2017 02:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 nI_RdSr480ZI for ; Wed, 8 Feb 2017 02:13:30 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 0DA351294E8 for ; Wed, 8 Feb 2017 02:13:30 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id r141so180967308wmg.1 for ; Wed, 08 Feb 2017 02:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=hOxgZ2mLM/jOa69snRnvmkZaYip20n4UXs03ANOvW4Q=; b=tM6aLXi5FBXkfy3Y3ypMynJAMV8JTkEtCRXshtS2BP5Myt0AfC1BpXg/bJXRcbijlL i9y4ZCcUt5AuT2t69Zi0S/kkIRTPQBAVzrblni2KIALH6qW2mFf5Z4kompbb2Z1tRu2H VlB4SfeOlm5rEHI2uDthYi6IdGXjH3VtztkrVf6AhA4GUGEm659XBK3ysDKy6Wxu8sxp 8CXLJNwGkbw1bmMcLx8UbUuB5z1bqYINvdf89aCLuSOvrIkxLUlBCtQBTlCudfSHrSuA q0M3byIhbElc9nUW5EfgiDCJO/SzD5qBjbIVL/a08KPTNx7+KT8BMZBLAJOrYaYpNtKK qhZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=hOxgZ2mLM/jOa69snRnvmkZaYip20n4UXs03ANOvW4Q=; b=KoHfVwD+Mpnz0+47N2mFKGzUzzM/idgeklPQdqcLm60frKTZLvBGWXOXblXUWQkFRC XGRHVSgB/drIKTm60rUHlmkOzn2w4v/Ia5XrHVjKE/g6HIuU1uQv3zEuGns0uXTv/aDD qGlSkYS7Knu/j5X6wCu510GIgo/pK7GfsF680Aam+BIg0OJ0DSSMwz0cjUTzWQqhISwK +aIABNNzWd9jUCnE933w/8Fi+S+UDEh/ouKhTvAhbQfrnVi5+ULIUhblEk9VhnFeoinR lHJIDbF7riUaurdqYeHIqwNtHbmc8ohR15GVPthbpeVg8iqcsjGPQC4sssi+xBRKFzrC DFsQ== X-Gm-Message-State: AMke39lU2Ah9bj8cT/DZMUaFXVY3qNR6B4dbCvzTGLCAMwe4XIkED0W7bK+j1/V8LbJYzA== X-Received: by 10.28.98.194 with SMTP id w185mr18634294wmb.84.1486548808446; Wed, 08 Feb 2017 02:13:28 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id 186sm2452654wmw.24.2017.02.08.02.13.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 02:13:27 -0800 (PST) To: Pedro Martinez-Julia References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> From: Stewart Bryant Message-ID: <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> Date: Wed, 8 Feb 2017 10:13:26 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170207235031.GV12800@spectre> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Dongjie \(Jimmy\)" , Network Slices , AshwoodsmithPeter , "Kiran.Makhijani" , "Natale, Bob" , Alex Galis Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 10:13:32 -0000 Pedro Maybe we start from different positions. My assumption is that I can create at will a new virtual function, and instantiate it at will and configure it at will, and create and modify the SFC chain at will. My further assumption is that we are building programmatic systems whereby the controls to do the above can be assessed by someone creating a service and that they can do so in a programming environment of their choice. If your fundamental assumption is that NFV functionality is created on the basis of the current hardware catalogue, and is forever fixed, then we have radically different views of what NFV will be. At the end of the day a virtual NF is a computer program running on a device that provides it with a network interface, CPU cycles and storage, an operator can spin up any program they wish on the device that hosts the NF. I think that what you are saying is that softwarization a step forward that allow the dynamic instantiation of general functions to create services, whereas I had assumed that this was always the end-game in NFV and SFC. - Stewart On 07/02/2017 23:50, Pedro Martinez-Julia wrote: > Dear Stewart, > > Find my comments in-line. > > On Tue, Feb 07, 2017 at 06:16:02PM +0000, Stewart Bryant wrote: >>> They can be somehow related but it is not the same concept. Using >>> NFV to illustrate the difference, it defines a set of fixed >>> functions that are virtualized, but the resulting functions are not >>> 100% soft-ware because they resemble the corresponding "hardware", >>> which is quite fixed. >> I don't agree with that. >> >> I can instantiate any function I wish as an NFV function, be it a well >> known function such as a load balancer, or it can be some relatively >> unknown function such as a homomorphic packet timestamper, or it could >> be some function only known to the customer but hosted in the network >> as an opaque function. >> >> I can dynamically provision such functions on CPU and add or remove >> them from a path. >> >> Thus I see no difference between a softwarized system and a system of >> NFV components stitched together with SFC, at least with the >> definition provided above. > As I mentioned in my following paragraph, what you are describing is a > softwarized "infrastructure" composed of non-softwarized functions. Thus > you are true that they are related, I am not saying the opposite, but it > is not the same. > > We can say that "NFV is a mechanism to sofwarize the infrastructure > aspects of a network system" but it does not mean that "softwarization > is virtualization" or that "NFV is a subset of softarization". They are > different mechanisms/techniques for purposes that overlap, but only to > some extent. > >>> Taking this into account I would say that NFV is a mechanism for >>> softwarizing a network infrastructure (making it more flexible, >>> programmable, etc.) but it is only limited to the infrastructure >>> boundary because the functions themselves are "hard-fixed" unless >>> they are also softwarized. >> Obviously I don't agree with that. What constrains them to be >> hard-fixed? > I think that Pete's message in this thread gives a better illustration > of the meaning of such "hard-fixed" concept. In summary is that although > the infrastructure, as I mentioned above, can be programmable (flexible, > soft-ware), the individual mechanisms that compose do not usually expose > such degree of programmability. As you mentioned, a homomorphic packet > time stamper or a load balancer, for instance, usually have pre-defined > behaviours which are configurable but not programmable. > > To sum up, I am not arguing that NFV "is not softwarization", just that > softwarization is not virtualization, at least "not just". They can have > some common goals but the former emphasizes the migration from pre-fixed > to dynamic *behaviors* while the latter lies in the migration from fixed > to dynamic *elements* (services, devices, infrastructures). > >> - Stewart > Regards, > Pedro > From nobody Wed Feb 8 02:33:12 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CA01299E8 for ; Wed, 8 Feb 2017 02:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 xb6m-o2VkooH for ; Wed, 8 Feb 2017 02:33:09 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 BFF411299E5 for ; Wed, 8 Feb 2017 02:33:08 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id c85so32478786wmi.1 for ; Wed, 08 Feb 2017 02:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=MR4638InlzEfoven6z2UHzu9zYBuYYuernSLvMdkTJE=; b=no2a6HYWxyCD90XHp7H5dhp9RrOZHzgl3x+XeV/pNsacpL6LLl2ORNsqAUwDD7V9SC lrCWvdnGUjVp4FUO3TBICJ41QUCszzsPRGcPKaPsPrAwWVMCBz7JwlQNPJD6HOF/Ats+ HA/vE5i2H+vjHJNveRX+dV/gLgo7jEqrzhLqKvFQIJ0H8gPpCOIgdAK5w8aHXnPH5BkX xA9qlR8+T3PeTLKn7yPvVarilrJ7IOkuIpGNblXTXXfCF7d3W4wdS0wGkIAkWdt0wGz+ AsoRbP0Uys2mos1vzacVtos5pmwSwVJSiFhJ6WEc+5Em90ceePYk1oxTPnzP+2Fq5P8W HIPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MR4638InlzEfoven6z2UHzu9zYBuYYuernSLvMdkTJE=; b=Q3+CW0PUtfL9HxWonlRIommpG9ioy5uW6J/ZHwka+J9ibX7q9PZIuR0P5qS2VuXRYp L1d6i2LnqBQMksci/IgZGqryRBI8cfsyl9ADwK8gczFRTMVHglzUlz6wxQJMIfcjfmxI nQ40El8iuWyp9oE3LnjfUeBLZ95gLPqRaGHItMYODMOMAJ7nj4L+jS8I60ZkZsj2U4EF BhcQ9o5Tqa/f0XF78Vw8Re1KwvPR8tkTvW4llVRTMi3leCDPoUqXo+ciNjT9VHZj4nAT yp+wXb5WUQ3M40pyEXid8sI1d0tTOQm4Zz2550PYvIsC/cTV2sjddlcP5S6s045Lsopl 8JKg== X-Gm-Message-State: AMke39lofRPI1wfHpZvtIwTQHGAYYSkNfbKgEeXNvcq3JXCK+sAkpHYgXoNiqoo54FithA== X-Received: by 10.28.199.206 with SMTP id x197mr16023020wmf.5.1486549987281; Wed, 08 Feb 2017 02:33:07 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id g71sm2596507wmc.9.2017.02.08.02.33.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 02:33:06 -0800 (PST) To: Pedro Martinez-Julia , Loa Andersson References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> <20170208041658.GW12800@spectre> From: Stewart Bryant Message-ID: Date: Wed, 8 Feb 2017 10:33:05 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <20170208041658.GW12800@spectre> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Smith, Kevin, \(R&D\) Vodafone Group" , "netslices@ietf.org" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 10:33:10 -0000 On 08/02/2017 04:16, Pedro Martinez-Julia wrote: > On Wed, Feb 08, 2017 at 11:51:16AM +0800, Loa Andersson wrote: >> So we have a BIG and resourceful network, from which we can cut slices >> in such a way that a particular slice may serve a particular network >> user exactly as a purpose built network woud? > This is a key definition for network slicing. However, we have also to > consider two different manners to provision such slices: > > - That the slice is provided "as a set of resources" (which would be > most probably virtual) without being pre-configured. This way, the > user is responsible of the management of such resources to form and > control/manage its infrastructure. So what you are saying here is that one organization sells bit pipes, compute cycles and storage. A second organization loads software of its choosing that consumes those compute cycles and bit pipes, and this is sold to a third organization as a bespoke service? So at the lower layer this is in essence what DC providers already provide but with tight SLA on the compute cycles and data paths? Applied to the cellular market this includes a wireless component, but in the general case it applies to any last mile technology. Is that correct? > > - That the slice is provided as an infrastructure for a specific purpose > requested by the user. The provider is responsible of the management > of both the underlying and overlaying infrastructures and the user is > limited to consume it and make any management-related request to the > provider. Doesn't this describe the normal VPN business model updated with virtual functions? > > As we are trying to get a proper definition of slice and its scope, I > think we have to clarify those two alternatives or, at least, be sure > that the definition we finally push forward is not tied to just one of > them. > > Regards, > Pedro > Regards Stewart From nobody Wed Feb 8 03:08:44 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592601293DB for ; Wed, 8 Feb 2017 03:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com 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 h57i2J3Qdr6A for ; Wed, 8 Feb 2017 03:08:39 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0133.outbound.protection.outlook.com [104.47.36.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AD77126579 for ; Wed, 8 Feb 2017 03:08:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=R9S94r1zhRWj+CMUfwHs3zKTnjB+6F3KVE4bxqBeN8k=; b=ADI9ivS/rg88zcdEYfjm0vQjGLsqnkiujdO4kAPB8jdPq62m1+xG14QHQVYwSsEMNJ5fAUEaDJ6XSizA2a5SWi0VE3Ken55oz++ZDtwsb0sxYIuu7GIf+vJrm+AagsMsSZMn94J1oMO1ocmKopgL9PrFMxzJTig6LbR9dLP7KFU= Received: from CY1PR0501MB1115.namprd05.prod.outlook.com (10.160.144.145) by CY1PR0501MB1116.namprd05.prod.outlook.com (10.160.144.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Wed, 8 Feb 2017 11:08:36 +0000 Received: from CY1PR0501MB1115.namprd05.prod.outlook.com ([10.160.144.145]) by CY1PR0501MB1115.namprd05.prod.outlook.com ([10.160.144.145]) with mapi id 15.01.0888.026; Wed, 8 Feb 2017 11:08:36 +0000 From: Javier Antich Romaguera To: Stewart Bryant , Pedro Martinez-Julia Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvq3aDT+LV2al0OATW2u0IG8zqFcEv2AgACPBICAACsogIAASScAgAAJGwCAANcZAIAAXXWAgACuCgCAACArAA== Date: Wed, 8 Feb 2017 11:08:36 +0000 Message-ID: <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> In-Reply-To: <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.151206 authentication-results: spf=none (sender IP is ) smtp.mailfrom=jantich@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [193.110.55.12] x-ms-office365-filtering-correlation-id: 53674f32-ac08-4c92-0b9f-08d45012d44a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY1PR0501MB1116; x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1116; 7:8hWUYLayAAAQ1CXQJmBKKrJlYPg4mMTPFjyXLnKJaoKWSrAc2K9y+unClwtaW9vErVkPbU0DA9f2Vo07LSQ6Iubo5CpYL217+y/Hozlbvo2BO4QUpPrGkrhWmru0UBrGh82w843sziKy4AAUlGAzJll9tTsw98dekrOtsKdVHop9qPfOqoZkiskAQIPBsSlNABdHB9pA/eDYzqb1OChgkz+AONhkjafW5TKKQQRYi722jmcsNUKdhwghg9otB84YhixoQO8x94W0RVXLTvhHLWOXqYF1g2fO3hWdlj5fqTuk5ZdSqfCAbdZ2jdzuuZ83IZ6xG9slwz+mfm+qgL6HS/q+gUiItZCEff9KOWN8nmC/CcMISVN3K1otj0tuInRYEnRxEn0PZsl+GQse7Qfg2d6ziASaJO78vXv+w/CDHQk9DVnFrrsxM8KVlarIH/ht//W1yOFD2hCG5c+aAgcV95A+R9aY9DXRSQ/FtEY+9ZAiPDn9X5MqqtirbG5B3u3dabgUljUNCc0Hjt2vzg8KKQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(138986009662008)(57025502571588)(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(2017020702029)(8121501046)(5005006)(20170203043)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(20161123558025)(6072148); SRVR:CY1PR0501MB1116; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1116; x-forefront-prvs: 0212BDE3BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39850400002)(39860400002)(39410400002)(39840400002)(51444003)(189002)(377454003)(252514010)(199003)(24454002)(6306002)(106356001)(2900100001)(54896002)(92566002)(6512007)(8936002)(189998001)(81166006)(236005)(81156014)(54906002)(8676002)(4001350100001)(6506006)(97736004)(77096006)(122556002)(39060400001)(25786008)(66066001)(105586002)(31430400001)(229853002)(6486002)(93886004)(6436002)(99286003)(606005)(2906002)(38730400002)(36756003)(5660300001)(86362001)(4326007)(68736007)(54356999)(106116001)(53546003)(3280700002)(6246003)(7736002)(33656002)(7906003)(3660700001)(102836003)(82746002)(53936002)(101416001)(3846002)(6116002)(83716003)(76176999)(2950100002)(50986999)(83506001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1116; H:CY1PR0501MB1115.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_5336C72FFDDA4303876F576C3F14F7C3junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2017 11:08:36.6088 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1116 Archived-At: Cc: "Dongjie \(Jimmy\)" , Network Slices , AshwoodsmithPeter , "Kiran.Makhijani" , "Natale, Bob" , Alex Galis Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 11:08:43 -0000 --_000_5336C72FFDDA4303876F576C3F14F7C3junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3Rld2FydC9hbGwsDQogICBJIGFkbWl0IG1heSBoYXZlIGdvdCBsb3N0IGEgYml0IG9uIHRo ZSBzdWJ0bGV0aWVzIG9mIHRoZSB0ZXJtaW5vbG9neSwgYnV0IGZyb20gbXkgcG9pbnQgb2Ygdmll dyBpdCBpcyBpbXBvcnRhbnQgdG8gZW1waGFzaXplIHRoYXQgTkZWIGlzIG9uZSBwb3NzaWJsZSBt ZWNoYW5pc20vdmVoaWNsZSBmb3IgbmV0d29yayBzbGljaW5nLCBidXQgdGhlcmUgY291bGQgYmUg b3RoZXJzLiBJZiBieSBzb2Z0d2FyaXphdGlvbiB3ZSBhcmUgaW1wbHlpbmcgYSBtb3JlIGdlbmVy YWwgZGVmaW5pdGlvbiwgdGhhdCBpbiBzb21lIGNhc2VzIG1heSBiZSByZXByZXNlbnRlZCBieSBO RlYsIGFuZCBpbiBvdGhlcnMgbWF5IGJlIGEgZGlmZmVyZW50IGFwcHJvYWNoLCBJIHN1cHBvcnQg dGhhdCB2aWV3LiBXZSBzaG91bGQgZW1waGFzaXplIG9uIHRoZSByZXF1aXJlbWVudHMgYW5kIGhv dyBuZXR3b3JrIHNsaWNpbmcgY2FuIGFkZHJlc3MgdGhlbS4gTkZWIHNlZW1zIHRvIG1lIG1vcmUg YW4gZXhhbXBsZSBvZiBpbXBsZW1lbnRhdGlvbiBvZiBuZXR3b3JrLXNsaWNpbmcgZm9yIGNlcnRh aW4gdXNlIGNhc2VzLg0KDQpUaGFua3MNCkphdmllci4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KSmF2aWVyIEFudGljaCBSb21hZ3VlcmENClByb2R1 Y3QgTGluZSBNYW5hZ2VyLiBKVU5PUyBUZWFtLg0KSnVuaXBlciBOZXR3b3Jrcw0KZW1haWw6IGph bnRpY2hAanVuaXBlci5uZXQ8bWFpbHRvOmphbnRpY2hAanVuaXBlci5uZXQ+DQptLiArMzQ2Mzky MTg0MjgNCuKAnEFjaGlldmluZyB0aGUgZGlmZmljdWx0LCB0cnlpbmcgdGhlIGltcG9zc2libGUi DQoNCg0KRnJvbTogTmV0c2xpY2VzIDxuZXRzbGljZXMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 bmV0c2xpY2VzLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgU3Rld2FydCBCcnlhbnQg PHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbTxtYWlsdG86c3Rld2FydC5icnlhbnRAZ21haWwuY29t Pj4NCkRhdGU6IFdlZG5lc2RheSwgRmVicnVhcnkgOCwgMjAxNyBhdCAxMToxMyBBTQ0KVG86IFBl ZHJvIE1hcnRpbmV6LUp1bGlhIDxwZWRyb0BuaWN0LmdvLmpwPG1haWx0bzpwZWRyb0BuaWN0Lmdv LmpwPj4NCkNjOiAiRG9uZ2ppZSAoSmltbXkpIiA8amllLmRvbmdAaHVhd2VpLmNvbTxtYWlsdG86 amllLmRvbmdAaHVhd2VpLmNvbT4+LCBOZXR3b3JrIFNsaWNlcyA8bmV0c2xpY2VzQGlldGYub3Jn PG1haWx0bzpuZXRzbGljZXNAaWV0Zi5vcmc+PiwgQXNod29vZHNtaXRoUGV0ZXIgPFBldGVyLkFz aHdvb2RTbWl0aEBodWF3ZWkuY29tPG1haWx0bzpQZXRlci5Bc2h3b29kU21pdGhAaHVhd2VpLmNv bT4+LCAiS2lyYW4uTWFraGlqYW5pIiA8S2lyYW4uTWFraGlqYW5pQGh1YXdlaS5jb208bWFpbHRv OktpcmFuLk1ha2hpamFuaUBodWF3ZWkuY29tPj4sICJOYXRhbGUsIEJvYiIgPFJOQVRBTEVAbWl0 cmUub3JnPG1haWx0bzpSTkFUQUxFQG1pdHJlLm9yZz4+LCBBbGV4IEdhbGlzIDxhLmdhbGlzQHVj bC5hYy51azxtYWlsdG86YS5nYWxpc0B1Y2wuYWMudWs+Pg0KU3ViamVjdDogUmU6IFtOZXRzbGlj ZXNdIE5ldHdvcmsgU2xpY2luZyAtIEludHJvZHVjdG9yeSBEb2N1bWVudCBhbmQgUmV2aXNlZCBQ cm9ibGVtIFN0YXRlbWVudA0KDQpQZWRybw0KDQpNYXliZSB3ZSBzdGFydCBmcm9tIGRpZmZlcmVu dCBwb3NpdGlvbnMuDQoNCk15IGFzc3VtcHRpb24gaXMgdGhhdCBJIGNhbiBjcmVhdGUgYXQgd2ls bCBhIG5ldyB2aXJ0dWFsIGZ1bmN0aW9uLCBhbmQNCmluc3RhbnRpYXRlIGl0IGF0IHdpbGwgYW5k IGNvbmZpZ3VyZSBpdCBhdCB3aWxsLCBhbmQgY3JlYXRlIGFuZCBtb2RpZnkNCnRoZSBTRkMgY2hh aW4gYXQgd2lsbC4gTXkgZnVydGhlciBhc3N1bXB0aW9uIGlzIHRoYXQgd2UgYXJlIGJ1aWxkaW5n DQpwcm9ncmFtbWF0aWMgc3lzdGVtcyB3aGVyZWJ5IHRoZSBjb250cm9scyB0byBkbyB0aGUgYWJv dmUgY2FuIGJlDQphc3Nlc3NlZCBieSBzb21lb25lIGNyZWF0aW5nIGEgc2VydmljZSBhbmQgdGhh dCB0aGV5IGNhbiBkbyBzbyBpbiBhDQpwcm9ncmFtbWluZyBlbnZpcm9ubWVudCBvZiB0aGVpciBj aG9pY2UuDQoNCklmIHlvdXIgZnVuZGFtZW50YWwgYXNzdW1wdGlvbiBpcyB0aGF0IE5GViBmdW5j dGlvbmFsaXR5IGlzIGNyZWF0ZWQgb24NCnRoZSBiYXNpcyBvZiB0aGUgY3VycmVudCBoYXJkd2Fy ZSBjYXRhbG9ndWUsIGFuZCBpcyBmb3JldmVyIGZpeGVkLCB0aGVuDQp3ZSBoYXZlIHJhZGljYWxs eSBkaWZmZXJlbnQgdmlld3Mgb2Ygd2hhdCBORlYgd2lsbCBiZS4NCg0KQXQgdGhlIGVuZCBvZiB0 aGUgZGF5IGEgdmlydHVhbCBORiBpcyBhIGNvbXB1dGVyIHByb2dyYW0gcnVubmluZyBvbiBhDQpk ZXZpY2UgdGhhdCBwcm92aWRlcyBpdCB3aXRoIGEgbmV0d29yayBpbnRlcmZhY2UsIENQVSBjeWNs ZXMgYW5kDQpzdG9yYWdlLCBhbiBvcGVyYXRvciBjYW4gc3BpbiB1cCBhbnkgcHJvZ3JhbSB0aGV5 IHdpc2ggb24gdGhlIGRldmljZQ0KdGhhdCBob3N0cyB0aGUgTkYuDQoNCkkgdGhpbmsgdGhhdCB3 aGF0IHlvdSBhcmUgc2F5aW5nIGlzIHRoYXQgc29mdHdhcml6YXRpb24gYSBzdGVwIGZvcndhcmQN CnRoYXQgYWxsb3cgdGhlIGR5bmFtaWMgIGluc3RhbnRpYXRpb24gb2YgZ2VuZXJhbCBmdW5jdGlv bnMgdG8gY3JlYXRlDQpzZXJ2aWNlcywgd2hlcmVhcyBJIGhhZCBhc3N1bWVkIHRoYXQgdGhpcyB3 YXMgYWx3YXlzIHRoZSBlbmQtZ2FtZSBpbiBORlYNCmFuZCBTRkMuDQoNCi0gU3Rld2FydA0KDQoN Ck9uIDA3LzAyLzIwMTcgMjM6NTAsIFBlZHJvIE1hcnRpbmV6LUp1bGlhIHdyb3RlOg0KRGVhciBT dGV3YXJ0LA0KDQpGaW5kIG15IGNvbW1lbnRzIGluLWxpbmUuDQoNCk9uIFR1ZSwgRmViIDA3LCAy MDE3IGF0IDA2OjE2OjAyUE0gKzAwMDAsIFN0ZXdhcnQgQnJ5YW50IHdyb3RlOg0KVGhleSBjYW4g YmUgc29tZWhvdyByZWxhdGVkIGJ1dCBpdCBpcyBub3QgdGhlIHNhbWUgY29uY2VwdC4gVXNpbmcN Ck5GViB0byBpbGx1c3RyYXRlIHRoZSBkaWZmZXJlbmNlLCBpdCBkZWZpbmVzIGEgc2V0IG9mIGZp eGVkDQpmdW5jdGlvbnMgdGhhdCBhcmUgdmlydHVhbGl6ZWQsIGJ1dCB0aGUgcmVzdWx0aW5nIGZ1 bmN0aW9ucyBhcmUgbm90DQoxMDAlIHNvZnQtd2FyZSBiZWNhdXNlIHRoZXkgcmVzZW1ibGUgdGhl IGNvcnJlc3BvbmRpbmcgImhhcmR3YXJlIiwNCndoaWNoIGlzIHF1aXRlIGZpeGVkLg0KSSBkb24n dCBhZ3JlZSB3aXRoIHRoYXQuDQoNCkkgY2FuIGluc3RhbnRpYXRlIGFueSBmdW5jdGlvbiBJIHdp c2ggYXMgYW4gTkZWIGZ1bmN0aW9uLCBiZSBpdCBhIHdlbGwNCmtub3duIGZ1bmN0aW9uIHN1Y2gg YXMgYSBsb2FkIGJhbGFuY2VyLCBvciBpdCBjYW4gYmUgc29tZSByZWxhdGl2ZWx5DQp1bmtub3du IGZ1bmN0aW9uIHN1Y2ggYXMgYSBob21vbW9ycGhpYyBwYWNrZXQgdGltZXN0YW1wZXIsIG9yIGl0 IGNvdWxkDQpiZSBzb21lIGZ1bmN0aW9uIG9ubHkga25vd24gdG8gdGhlIGN1c3RvbWVyIGJ1dCBo b3N0ZWQgaW4gdGhlIG5ldHdvcmsNCmFzIGFuIG9wYXF1ZSBmdW5jdGlvbi4NCg0KSSBjYW4gZHlu YW1pY2FsbHkgcHJvdmlzaW9uIHN1Y2ggZnVuY3Rpb25zIG9uIENQVSBhbmQgYWRkIG9yIHJlbW92 ZQ0KdGhlbSBmcm9tIGEgcGF0aC4NCg0KVGh1cyBJIHNlZSBubyBkaWZmZXJlbmNlIGJldHdlZW4g YSBzb2Z0d2FyaXplZCBzeXN0ZW0gYW5kIGEgc3lzdGVtIG9mDQpORlYgY29tcG9uZW50cyBzdGl0 Y2hlZCB0b2dldGhlciB3aXRoIFNGQywgYXQgbGVhc3Qgd2l0aCB0aGUNCmRlZmluaXRpb24gcHJv dmlkZWQgYWJvdmUuDQpBcyBJIG1lbnRpb25lZCBpbiBteSBmb2xsb3dpbmcgcGFyYWdyYXBoLCB3 aGF0IHlvdSBhcmUgZGVzY3JpYmluZyBpcyBhDQpzb2Z0d2FyaXplZCAiaW5mcmFzdHJ1Y3R1cmUi IGNvbXBvc2VkIG9mIG5vbi1zb2Z0d2FyaXplZCBmdW5jdGlvbnMuIFRodXMNCnlvdSBhcmUgdHJ1 ZSB0aGF0IHRoZXkgYXJlIHJlbGF0ZWQsIEkgYW0gbm90IHNheWluZyB0aGUgb3Bwb3NpdGUsIGJ1 dCBpdA0KaXMgbm90IHRoZSBzYW1lLg0KDQpXZSBjYW4gc2F5IHRoYXQgIk5GViBpcyBhIG1lY2hh bmlzbSB0byBzb2Z3YXJpemUgdGhlIGluZnJhc3RydWN0dXJlDQphc3BlY3RzIG9mIGEgbmV0d29y ayBzeXN0ZW0iIGJ1dCBpdCBkb2VzIG5vdCBtZWFuIHRoYXQgInNvZnR3YXJpemF0aW9uDQppcyB2 aXJ0dWFsaXphdGlvbiIgb3IgdGhhdCAiTkZWIGlzIGEgc3Vic2V0IG9mIHNvZnRhcml6YXRpb24i LiBUaGV5IGFyZQ0KZGlmZmVyZW50IG1lY2hhbmlzbXMvdGVjaG5pcXVlcyBmb3IgcHVycG9zZXMg dGhhdCBvdmVybGFwLCBidXQgb25seSB0bw0Kc29tZSBleHRlbnQuDQoNClRha2luZyB0aGlzIGlu dG8gYWNjb3VudCBJIHdvdWxkIHNheSB0aGF0IE5GViBpcyBhIG1lY2hhbmlzbSBmb3INCnNvZnR3 YXJpemluZyBhIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUgKG1ha2luZyBpdCBtb3JlIGZsZXhpYmxl LA0KcHJvZ3JhbW1hYmxlLCBldGMuKSBidXQgaXQgaXMgb25seSBsaW1pdGVkIHRvIHRoZSBpbmZy YXN0cnVjdHVyZQ0KYm91bmRhcnkgYmVjYXVzZSB0aGUgZnVuY3Rpb25zIHRoZW1zZWx2ZXMgYXJl ICJoYXJkLWZpeGVkIiB1bmxlc3MNCnRoZXkgYXJlIGFsc28gc29mdHdhcml6ZWQuDQpPYnZpb3Vz bHkgSSBkb24ndCBhZ3JlZSB3aXRoIHRoYXQuIFdoYXQgY29uc3RyYWlucyB0aGVtIHRvIGJlDQpo YXJkLWZpeGVkPw0KSSB0aGluayB0aGF0IFBldGUncyBtZXNzYWdlIGluIHRoaXMgdGhyZWFkIGdp dmVzIGEgYmV0dGVyIGlsbHVzdHJhdGlvbg0Kb2YgdGhlIG1lYW5pbmcgb2Ygc3VjaCAiaGFyZC1m aXhlZCIgY29uY2VwdC4gSW4gc3VtbWFyeSBpcyB0aGF0IGFsdGhvdWdoDQp0aGUgaW5mcmFzdHJ1 Y3R1cmUsIGFzIEkgbWVudGlvbmVkIGFib3ZlLCBjYW4gYmUgcHJvZ3JhbW1hYmxlIChmbGV4aWJs ZSwNCnNvZnQtd2FyZSksIHRoZSBpbmRpdmlkdWFsIG1lY2hhbmlzbXMgdGhhdCBjb21wb3NlIGRv IG5vdCB1c3VhbGx5IGV4cG9zZQ0Kc3VjaCBkZWdyZWUgb2YgcHJvZ3JhbW1hYmlsaXR5LiBBcyB5 b3UgbWVudGlvbmVkLCBhIGhvbW9tb3JwaGljIHBhY2tldA0KdGltZSBzdGFtcGVyIG9yIGEgbG9h ZCBiYWxhbmNlciwgZm9yIGluc3RhbmNlLCB1c3VhbGx5IGhhdmUgcHJlLWRlZmluZWQNCmJlaGF2 aW91cnMgd2hpY2ggYXJlIGNvbmZpZ3VyYWJsZSBidXQgbm90IHByb2dyYW1tYWJsZS4NCg0KVG8g c3VtIHVwLCBJIGFtIG5vdCBhcmd1aW5nIHRoYXQgTkZWICJpcyBub3Qgc29mdHdhcml6YXRpb24i LCBqdXN0IHRoYXQNCnNvZnR3YXJpemF0aW9uIGlzIG5vdCB2aXJ0dWFsaXphdGlvbiwgYXQgbGVh c3QgIm5vdCBqdXN0Ii4gVGhleSBjYW4gaGF2ZQ0Kc29tZSBjb21tb24gZ29hbHMgYnV0IHRoZSBm b3JtZXIgZW1waGFzaXplcyB0aGUgbWlncmF0aW9uIGZyb20gcHJlLWZpeGVkDQp0byBkeW5hbWlj ICpiZWhhdmlvcnMqIHdoaWxlIHRoZSBsYXR0ZXIgbGllcyBpbiB0aGUgbWlncmF0aW9uIGZyb20g Zml4ZWQNCnRvIGR5bmFtaWMgKmVsZW1lbnRzKiAoc2VydmljZXMsIGRldmljZXMsIGluZnJhc3Ry dWN0dXJlcykuDQoNCi0gU3Rld2FydA0KUmVnYXJkcywNClBlZHJvDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldHNsaWNlcyBtYWlsaW5nIGxp c3QNCk5ldHNsaWNlc0BpZXRmLm9yZzxtYWlsdG86TmV0c2xpY2VzQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRzbGljZXMNCg0K --_000_5336C72FFDDA4303876F576C3F14F7C3junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <4331967D93361B4B8F56554C1846BBA9@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkhpIFN0ZXdhcnQvYWxsLCZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7SSBhZG1p dCBtYXkgaGF2ZSBnb3QgbG9zdCBhIGJpdCBvbiB0aGUgc3VidGxldGllcyBvZiB0aGUgdGVybWlu b2xvZ3ksIGJ1dCBmcm9tIG15IHBvaW50IG9mIHZpZXcgaXQgaXMgaW1wb3J0YW50IHRvIGVtcGhh c2l6ZSB0aGF0IE5GViBpcyBvbmUgcG9zc2libGUgbWVjaGFuaXNtL3ZlaGljbGUgZm9yIG5ldHdv cmsgc2xpY2luZywgYnV0IHRoZXJlIGNvdWxkIGJlIG90aGVycy4gSWYgYnkgc29mdHdhcml6YXRp b24gd2UgYXJlIGltcGx5aW5nDQogYSBtb3JlIGdlbmVyYWwgZGVmaW5pdGlvbiwgdGhhdCBpbiBz b21lIGNhc2VzIG1heSBiZSByZXByZXNlbnRlZCBieSBORlYsIGFuZCBpbiBvdGhlcnMgbWF5IGJl IGEgZGlmZmVyZW50IGFwcHJvYWNoLCBJIHN1cHBvcnQgdGhhdCB2aWV3LiBXZSBzaG91bGQgZW1w aGFzaXplIG9uIHRoZSByZXF1aXJlbWVudHMgYW5kIGhvdyBuZXR3b3JrIHNsaWNpbmcgY2FuIGFk ZHJlc3MgdGhlbS4gTkZWIHNlZW1zIHRvIG1lIG1vcmUgYW4gZXhhbXBsZSBvZiBpbXBsZW1lbnRh dGlvbg0KIG9mIG5ldHdvcmstc2xpY2luZyBmb3IgY2VydGFpbiB1c2UgY2FzZXMuJm5ic3A7PC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3M8L2Rpdj4NCjxkaXY+SmF2aWVyLjwv ZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7Jm5ic3A7PC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFD X09VVExPT0tfU0lHTkFUVVJFIj4NCjxkaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogQ2FsaWJyaTsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188L3NwYW4+PC9kaXY+DQo8ZGl2PjxiPkphdmllciBBbnRpY2ggUm9tYWd1ZXJhPC9iPjwvZGl2 Pg0KPGRpdiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+UHJvZHVjdCBMaW5lIE1hbmFnZXIuIEpV Tk9TIFRlYW0uPGI+Jm5ic3A7PC9iPjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNh bnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHg7Ij5KdW5pcGVyIE5ldHdvcmtz PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlm Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB4OyI+ZW1haWw6Jm5ic3A7PGEgaHJlZj0ibWFp bHRvOmphbnRpY2hAanVuaXBlci5uZXQiPmphbnRpY2hAanVuaXBlci5uZXQ8L2E+PC9zcGFuPjwv Zm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMnB4OyI+bS4gJiM0MzszNDYzOTIxODQyODwvc3Bhbj48L2ZvbnQ+ PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTJweDsiPuKAnEFjaGlldmluZyB0aGUgZGlmZmljdWx0LCB0cnlpbmcgdGhl IGltcG9zc2libGUmcXVvdDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNr OyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQ QURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGlu OyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9u ZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJv bTogPC9zcGFuPk5ldHNsaWNlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldHNsaWNlcy1ib3VuY2Vz QGlldGYub3JnIj5uZXRzbGljZXMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBv ZiBTdGV3YXJ0IEJyeWFudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWls LmNvbSI+c3Rld2FydC5icnlhbnRAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPldlZG5lc2RheSwgRmVicnVhcnkgOCwgMjAx NyBhdCAxMToxMyBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9z cGFuPlBlZHJvIE1hcnRpbmV6LUp1bGlhICZsdDs8YSBocmVmPSJtYWlsdG86cGVkcm9AbmljdC5n by5qcCI+cGVkcm9AbmljdC5nby5qcDwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkNjOiA8L3NwYW4+JnF1b3Q7RG9uZ2ppZSAoSmltbXkpJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86amllLmRvbmdAaHVhd2VpLmNvbSI+amllLmRvbmdAaHVhd2VpLmNvbTwvYT4m Z3Q7LCBOZXR3b3JrIFNsaWNlcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldHNsaWNlc0BpZXRmLm9y ZyI+bmV0c2xpY2VzQGlldGYub3JnPC9hPiZndDssIEFzaHdvb2RzbWl0aFBldGVyICZsdDs8YSBo cmVmPSJtYWlsdG86UGV0ZXIuQXNod29vZFNtaXRoQGh1YXdlaS5jb20iPlBldGVyLkFzaHdvb2RT bWl0aEBodWF3ZWkuY29tPC9hPiZndDssDQogJnF1b3Q7S2lyYW4uTWFraGlqYW5pJnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86S2lyYW4uTWFraGlqYW5pQGh1YXdlaS5jb20iPktpcmFuLk1ha2hp amFuaUBodWF3ZWkuY29tPC9hPiZndDssICZxdW90O05hdGFsZSwgQm9iJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86Uk5BVEFMRUBtaXRyZS5vcmciPlJOQVRBTEVAbWl0cmUub3JnPC9hPiZndDss IEFsZXggR2FsaXMgJmx0OzxhIGhyZWY9Im1haWx0bzphLmdhbGlzQHVjbC5hYy51ayI+YS5nYWxp c0B1Y2wuYWMudWs8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5T dWJqZWN0OiA8L3NwYW4+UmU6IFtOZXRzbGljZXNdIE5ldHdvcmsgU2xpY2luZyAtIEludHJvZHVj dG9yeSBEb2N1bWVudCBhbmQgUmV2aXNlZCBQcm9ibGVtIFN0YXRlbWVudDxicj4NCjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj5QZWRybzwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxkaXY+TWF5YmUgd2Ugc3RhcnQgZnJvbSBkaWZmZXJlbnQgcG9zaXRpb25z LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+TXkgYXNzdW1wdGlvbiBpcyB0aGF0IEkg Y2FuIGNyZWF0ZSBhdCB3aWxsIGEgbmV3IHZpcnR1YWwgZnVuY3Rpb24sIGFuZCA8L2Rpdj4NCjxk aXY+aW5zdGFudGlhdGUgaXQgYXQgd2lsbCBhbmQgY29uZmlndXJlIGl0IGF0IHdpbGwsIGFuZCBj cmVhdGUgYW5kIG1vZGlmeSA8L2Rpdj4NCjxkaXY+dGhlIFNGQyBjaGFpbiBhdCB3aWxsLiBNeSBm dXJ0aGVyIGFzc3VtcHRpb24gaXMgdGhhdCB3ZSBhcmUgYnVpbGRpbmcgPC9kaXY+DQo8ZGl2PnBy b2dyYW1tYXRpYyBzeXN0ZW1zIHdoZXJlYnkgdGhlIGNvbnRyb2xzIHRvIGRvIHRoZSBhYm92ZSBj YW4gYmUgPC9kaXY+DQo8ZGl2PmFzc2Vzc2VkIGJ5IHNvbWVvbmUgY3JlYXRpbmcgYSBzZXJ2aWNl IGFuZCB0aGF0IHRoZXkgY2FuIGRvIHNvIGluIGEgPC9kaXY+DQo8ZGl2PnByb2dyYW1taW5nIGVu dmlyb25tZW50IG9mIHRoZWlyIGNob2ljZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 PklmIHlvdXIgZnVuZGFtZW50YWwgYXNzdW1wdGlvbiBpcyB0aGF0IE5GViBmdW5jdGlvbmFsaXR5 IGlzIGNyZWF0ZWQgb24gPC9kaXY+DQo8ZGl2PnRoZSBiYXNpcyBvZiB0aGUgY3VycmVudCBoYXJk d2FyZSBjYXRhbG9ndWUsIGFuZCBpcyBmb3JldmVyIGZpeGVkLCB0aGVuIDwvZGl2Pg0KPGRpdj53 ZSBoYXZlIHJhZGljYWxseSBkaWZmZXJlbnQgdmlld3Mgb2Ygd2hhdCBORlYgd2lsbCBiZS48L2Rp dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkF0IHRoZSBlbmQgb2YgdGhlIGRheSBhIHZpcnR1 YWwgTkYgaXMgYSBjb21wdXRlciBwcm9ncmFtIHJ1bm5pbmcgb24gYSA8L2Rpdj4NCjxkaXY+ZGV2 aWNlIHRoYXQgcHJvdmlkZXMgaXQgd2l0aCBhIG5ldHdvcmsgaW50ZXJmYWNlLCBDUFUgY3ljbGVz IGFuZCA8L2Rpdj4NCjxkaXY+c3RvcmFnZSwgYW4gb3BlcmF0b3IgY2FuIHNwaW4gdXAgYW55IHBy b2dyYW0gdGhleSB3aXNoIG9uIHRoZSBkZXZpY2UgPC9kaXY+DQo8ZGl2PnRoYXQgaG9zdHMgdGhl IE5GLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SSB0aGluayB0aGF0IHdoYXQgeW91 IGFyZSBzYXlpbmcgaXMgdGhhdCBzb2Z0d2FyaXphdGlvbiBhIHN0ZXAgZm9yd2FyZCA8L2Rpdj4N CjxkaXY+dGhhdCBhbGxvdyB0aGUgZHluYW1pYyZuYnNwOyZuYnNwO2luc3RhbnRpYXRpb24gb2Yg Z2VuZXJhbCBmdW5jdGlvbnMgdG8gY3JlYXRlIDwvZGl2Pg0KPGRpdj5zZXJ2aWNlcywgd2hlcmVh cyBJIGhhZCBhc3N1bWVkIHRoYXQgdGhpcyB3YXMgYWx3YXlzIHRoZSBlbmQtZ2FtZSBpbiBORlYg PC9kaXY+DQo8ZGl2PmFuZCBTRkMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4tIFN0 ZXdhcnQ8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5P biAwNy8wMi8yMDE3IDIzOjUwLCBQZWRybyBNYXJ0aW5lei1KdWxpYSB3cm90ZTo8L2Rpdj4NCjxi bG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0i Qk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAw IDAgNTsiPg0KPGRpdj5EZWFyIFN0ZXdhcnQsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5GaW5kIG15IGNvbW1lbnRzIGluLWxpbmUuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj5PbiBUdWUsIEZlYiAwNywgMjAxNyBhdCAwNjoxNjowMlBNICYjNDM7MDAwMCwgU3Rld2FydCBC cnlhbnQgd3JvdGU6PC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJ T05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJ Tkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9P S19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBz b2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdj5UaGV5IGNhbiBi ZSBzb21laG93IHJlbGF0ZWQgYnV0IGl0IGlzIG5vdCB0aGUgc2FtZSBjb25jZXB0LiBVc2luZzwv ZGl2Pg0KPGRpdj5ORlYgdG8gaWxsdXN0cmF0ZSB0aGUgZGlmZmVyZW5jZSwgaXQgZGVmaW5lcyBh IHNldCBvZiBmaXhlZDwvZGl2Pg0KPGRpdj5mdW5jdGlvbnMgdGhhdCBhcmUgdmlydHVhbGl6ZWQs IGJ1dCB0aGUgcmVzdWx0aW5nIGZ1bmN0aW9ucyBhcmUgbm90PC9kaXY+DQo8ZGl2PjEwMCUgc29m dC13YXJlIGJlY2F1c2UgdGhleSByZXNlbWJsZSB0aGUgY29ycmVzcG9uZGluZyAmcXVvdDtoYXJk d2FyZSZxdW90Oyw8L2Rpdj4NCjxkaXY+d2hpY2ggaXMgcXVpdGUgZml4ZWQuPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2PkkgZG9uJ3QgYWdyZWUgd2l0aCB0aGF0LjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+SSBjYW4gaW5zdGFudGlhdGUgYW55IGZ1bmN0aW9uIEkgd2lzaCBhcyBh biBORlYgZnVuY3Rpb24sIGJlIGl0IGEgd2VsbDwvZGl2Pg0KPGRpdj5rbm93biBmdW5jdGlvbiBz dWNoIGFzIGEgbG9hZCBiYWxhbmNlciwgb3IgaXQgY2FuIGJlIHNvbWUgcmVsYXRpdmVseTwvZGl2 Pg0KPGRpdj51bmtub3duIGZ1bmN0aW9uIHN1Y2ggYXMgYSBob21vbW9ycGhpYyBwYWNrZXQgdGlt ZXN0YW1wZXIsIG9yIGl0IGNvdWxkPC9kaXY+DQo8ZGl2PmJlIHNvbWUgZnVuY3Rpb24gb25seSBr bm93biB0byB0aGUgY3VzdG9tZXIgYnV0IGhvc3RlZCBpbiB0aGUgbmV0d29yazwvZGl2Pg0KPGRp dj5hcyBhbiBvcGFxdWUgZnVuY3Rpb24uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5J IGNhbiBkeW5hbWljYWxseSBwcm92aXNpb24gc3VjaCBmdW5jdGlvbnMgb24gQ1BVIGFuZCBhZGQg b3IgcmVtb3ZlPC9kaXY+DQo8ZGl2PnRoZW0gZnJvbSBhIHBhdGguPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5UaHVzIEkgc2VlIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBhIHNvZnR3YXJp emVkIHN5c3RlbSBhbmQgYSBzeXN0ZW0gb2Y8L2Rpdj4NCjxkaXY+TkZWIGNvbXBvbmVudHMgc3Rp dGNoZWQgdG9nZXRoZXIgd2l0aCBTRkMsIGF0IGxlYXN0IHdpdGggdGhlPC9kaXY+DQo8ZGl2PmRl ZmluaXRpb24gcHJvdmlkZWQgYWJvdmUuPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PkFzIEkg bWVudGlvbmVkIGluIG15IGZvbGxvd2luZyBwYXJhZ3JhcGgsIHdoYXQgeW91IGFyZSBkZXNjcmli aW5nIGlzIGE8L2Rpdj4NCjxkaXY+c29mdHdhcml6ZWQgJnF1b3Q7aW5mcmFzdHJ1Y3R1cmUmcXVv dDsgY29tcG9zZWQgb2Ygbm9uLXNvZnR3YXJpemVkIGZ1bmN0aW9ucy4gVGh1czwvZGl2Pg0KPGRp dj55b3UgYXJlIHRydWUgdGhhdCB0aGV5IGFyZSByZWxhdGVkLCBJIGFtIG5vdCBzYXlpbmcgdGhl IG9wcG9zaXRlLCBidXQgaXQ8L2Rpdj4NCjxkaXY+aXMgbm90IHRoZSBzYW1lLjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+V2UgY2FuIHNheSB0aGF0ICZxdW90O05GViBpcyBhIG1lY2hh bmlzbSB0byBzb2Z3YXJpemUgdGhlIGluZnJhc3RydWN0dXJlPC9kaXY+DQo8ZGl2PmFzcGVjdHMg b2YgYSBuZXR3b3JrIHN5c3RlbSZxdW90OyBidXQgaXQgZG9lcyBub3QgbWVhbiB0aGF0ICZxdW90 O3NvZnR3YXJpemF0aW9uPC9kaXY+DQo8ZGl2PmlzIHZpcnR1YWxpemF0aW9uJnF1b3Q7IG9yIHRo YXQgJnF1b3Q7TkZWIGlzIGEgc3Vic2V0IG9mIHNvZnRhcml6YXRpb24mcXVvdDsuIFRoZXkgYXJl PC9kaXY+DQo8ZGl2PmRpZmZlcmVudCBtZWNoYW5pc21zL3RlY2huaXF1ZXMgZm9yIHB1cnBvc2Vz IHRoYXQgb3ZlcmxhcCwgYnV0IG9ubHkgdG88L2Rpdj4NCjxkaXY+c29tZSBleHRlbnQuPC9kaXY+ DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVU SU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURE SU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUg c29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+VGFraW5nIHRo aXMgaW50byBhY2NvdW50IEkgd291bGQgc2F5IHRoYXQgTkZWIGlzIGEgbWVjaGFuaXNtIGZvcjwv ZGl2Pg0KPGRpdj5zb2Z0d2FyaXppbmcgYSBuZXR3b3JrIGluZnJhc3RydWN0dXJlIChtYWtpbmcg aXQgbW9yZSBmbGV4aWJsZSw8L2Rpdj4NCjxkaXY+cHJvZ3JhbW1hYmxlLCBldGMuKSBidXQgaXQg aXMgb25seSBsaW1pdGVkIHRvIHRoZSBpbmZyYXN0cnVjdHVyZTwvZGl2Pg0KPGRpdj5ib3VuZGFy eSBiZWNhdXNlIHRoZSBmdW5jdGlvbnMgdGhlbXNlbHZlcyBhcmUgJnF1b3Q7aGFyZC1maXhlZCZx dW90OyB1bmxlc3M8L2Rpdj4NCjxkaXY+dGhleSBhcmUgYWxzbyBzb2Z0d2FyaXplZC48L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+T2J2aW91c2x5IEkgZG9uJ3QgYWdyZWUgd2l0aCB0aGF0LiBX aGF0IGNvbnN0cmFpbnMgdGhlbSB0byBiZTwvZGl2Pg0KPGRpdj5oYXJkLWZpeGVkPzwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGRpdj5JIHRoaW5rIHRoYXQgUGV0ZSdzIG1lc3NhZ2UgaW4gdGhpcyB0 aHJlYWQgZ2l2ZXMgYSBiZXR0ZXIgaWxsdXN0cmF0aW9uPC9kaXY+DQo8ZGl2Pm9mIHRoZSBtZWFu aW5nIG9mIHN1Y2ggJnF1b3Q7aGFyZC1maXhlZCZxdW90OyBjb25jZXB0LiBJbiBzdW1tYXJ5IGlz IHRoYXQgYWx0aG91Z2g8L2Rpdj4NCjxkaXY+dGhlIGluZnJhc3RydWN0dXJlLCBhcyBJIG1lbnRp b25lZCBhYm92ZSwgY2FuIGJlIHByb2dyYW1tYWJsZSAoZmxleGlibGUsPC9kaXY+DQo8ZGl2PnNv ZnQtd2FyZSksIHRoZSBpbmRpdmlkdWFsIG1lY2hhbmlzbXMgdGhhdCBjb21wb3NlIGRvIG5vdCB1 c3VhbGx5IGV4cG9zZTwvZGl2Pg0KPGRpdj5zdWNoIGRlZ3JlZSBvZiBwcm9ncmFtbWFiaWxpdHku IEFzIHlvdSBtZW50aW9uZWQsIGEgaG9tb21vcnBoaWMgcGFja2V0PC9kaXY+DQo8ZGl2PnRpbWUg c3RhbXBlciBvciBhIGxvYWQgYmFsYW5jZXIsIGZvciBpbnN0YW5jZSwgdXN1YWxseSBoYXZlIHBy ZS1kZWZpbmVkPC9kaXY+DQo8ZGl2PmJlaGF2aW91cnMgd2hpY2ggYXJlIGNvbmZpZ3VyYWJsZSBi dXQgbm90IHByb2dyYW1tYWJsZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRvIHN1 bSB1cCwgSSBhbSBub3QgYXJndWluZyB0aGF0IE5GViAmcXVvdDtpcyBub3Qgc29mdHdhcml6YXRp b24mcXVvdDssIGp1c3QgdGhhdDwvZGl2Pg0KPGRpdj5zb2Z0d2FyaXphdGlvbiBpcyBub3Qgdmly dHVhbGl6YXRpb24sIGF0IGxlYXN0ICZxdW90O25vdCBqdXN0JnF1b3Q7LiBUaGV5IGNhbiBoYXZl PC9kaXY+DQo8ZGl2PnNvbWUgY29tbW9uIGdvYWxzIGJ1dCB0aGUgZm9ybWVyIGVtcGhhc2l6ZXMg dGhlIG1pZ3JhdGlvbiBmcm9tIHByZS1maXhlZDwvZGl2Pg0KPGRpdj50byBkeW5hbWljICpiZWhh dmlvcnMqIHdoaWxlIHRoZSBsYXR0ZXIgbGllcyBpbiB0aGUgbWlncmF0aW9uIGZyb20gZml4ZWQ8 L2Rpdj4NCjxkaXY+dG8gZHluYW1pYyAqZWxlbWVudHMqIChzZXJ2aWNlcywgZGV2aWNlcywgaW5m cmFzdHJ1Y3R1cmVzKS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0i TUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAj YjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+ LSBTdGV3YXJ0PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2 PlBlZHJvPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188L2Rpdj4NCjxkaXY+TmV0c2xpY2VzIG1haWxpbmcgbGlzdDwvZGl2Pg0KPGRpdj48YSBo cmVmPSJtYWlsdG86TmV0c2xpY2VzQGlldGYub3JnIj5OZXRzbGljZXNAaWV0Zi5vcmc8L2E+PC9k aXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0c2xpY2VzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldHNsaWNl czwvYT48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_5336C72FFDDA4303876F576C3F14F7C3junipernet_-- From nobody Wed Feb 8 04:09:43 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4231294F8 for ; Wed, 8 Feb 2017 04:09:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 FzTDO_Qa252u for ; Wed, 8 Feb 2017 04:09:40 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1452612946A for ; Wed, 8 Feb 2017 04:09:40 -0800 (PST) Received: from [192.168.1.11] (unknown [112.204.169.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 737D218013D1; Wed, 8 Feb 2017 13:09:36 +0100 (CET) To: Pedro Martinez-Julia References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> <20170208041658.GW12800@spectre> From: Loa Andersson Message-ID: <540fb8ef-b2bf-a88a-1d6f-52d546945132@pi.nu> Date: Wed, 8 Feb 2017 20:09:30 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170208041658.GW12800@spectre> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Smith, Kevin, \(R&D\) Vodafone Group" , "netslices@ietf.org" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 12:09:42 -0000 Pedro, On 2017-02-08 12:16, Pedro Martinez-Julia wrote: > On Wed, Feb 08, 2017 at 11:51:16AM +0800, Loa Andersson wrote: >> So we have a BIG and resourceful network, from which we can cut slices >> in such a way that a particular slice may serve a particular network >> user exactly as a purpose built network would? > > This is a key definition for network slicing. However, we have also to > consider two different manners to provision such slices: I think I understand your comments about "two different manners", but what I was trying to figure out was the E2E discussion and how it relates to network slicing. From the discussion I got the impression that E2E there were opinions that E2E were one of the characteristic of network slizing. While I always thought that any network characteristic has the same relationship to networks in general as they have to network slices. I just wanted to verify this. /Loa > > - That the slice is provided "as a set of resources" (which would be > most probably virtual) without being pre-configured. This way, the > user is responsible of the management of such resources to form and > control/manage its infrastructure. > > - That the slice is provided as an infrastructure for a specific purpose > requested by the user. The provider is responsible of the management > of both the underlying and overlaying infrastructures and the user is > limited to consume it and make any management-related request to the > provider. > > As we are trying to get a proper definition of slice and its scope, I > think we have to clarify those two alternatives or, at least, be sure > that the definition we finally push forward is not tied to just one of > them. > > Regards, > Pedro > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From nobody Wed Feb 8 06:09:11 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30158129A9A for ; Wed, 8 Feb 2017 06:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 OMtvSLJT-C4k for ; Wed, 8 Feb 2017 06:09:06 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0094.outbound.protection.outlook.com [104.47.1.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94A312949F for ; Wed, 8 Feb 2017 06:09:05 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=a.galis@ucl.ac.uk; Received: from eduroam-int-dhcp-97-254-8.ucl.ac.uk (144.82.8.254) by HE1PR0101MB2346.eurprd01.prod.exchangelabs.com (10.168.143.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 8 Feb 2017 14:09:01 +0000 From: Message-ID: <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> Content-Type: multipart/alternative; boundary="Apple-Mail=_B4639925-8A68-407B-BAB9-76C82E40A4BA" MIME-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 8 Feb 2017 14:08:59 +0000 In-Reply-To: <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> To: Javier Antich Romaguera References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> X-Mailer: Apple Mail (2.3259) X-Originating-IP: [144.82.8.254] X-ClientProxiedBy: HE1PR0101CA0011.eurprd01.prod.exchangelabs.com (10.168.141.149) To HE1PR0101MB2346.eurprd01.prod.exchangelabs.com (10.168.143.140) X-MS-Office365-Filtering-Correlation-Id: 42972755-c287-45c7-fc4e-08d4502c08d1 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0101MB2346; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0101MB2346; 3:19K+zVMaOWrWi6bB4UR37jmQ4bbekLzikwUgAX8b0BP2PMJCJC1IMHkhtEZqLcUTFZ/LCAD8ODHg3rAH6SSicXboP0qWfFKE6xt23AJwIFN1yzxJrUJPGmbFw2F9Ktv9fKdtU/YCbX68gAbJvvH2jtYy09KvJT2A45eTnQzYCmHF2wKa7azxGZL7ijqWzz2Vut9M01iKkIajjcWpQl5n3sf7K+OH4tGFuH6kJpgxgQZ/gmrKn7rEW4TjfSf8aBjkENMy+HDkS3DlyCT8vB7Iuw==; 25:JBWV0wFMmMySJk8Up2PC9rMWG3UzyQUR/Z/s6yaffTU3FVTwR0LHSkDqfo9MXTqzCUbplLp9WPuAertgpjXG7GsxPjAGCcpl4eNhEX2wG5mb2toU38x3ZnZNNW12zbWpGmYLsTc0VyzM9i2zZkz2qj3LJ2eQft0D2P5qtfrdSg2zD25IQy/TMUYMuTI4KsLonNWp4NkOgiiPgMFdls3ZINrg8OOd7x+qSR3ROZLXqxL9j44PyyhhZntrxK2rUPXijX7tvmtF3fddfvSDZYu+FHWVpXBY9W9b3xQNBBvjtDLhjcWZj09lIw6jUvBYDldyynK1S42g9lxkcGpfk0NZd8DJxW9Hn7x1SNEiJQn/VhF5+kmQxWjPA8lxxP2fXHyIB5GzyRsoa4LFTQXigr7RlcC1fzLstdMcQwYJVG0eEa+wCTxWfpEgiYESQDdd10JIj75SkcVjjf4rIEuKFTyJOg== X-Microsoft-Exchange-Diagnostics: 1; HE1PR0101MB2346; 31:jr+W4m4phhSvaLqX8NdhRGpKnrQ3e1fpd78m2WUo0aXsUMOLVh6+i3nq2fJy89ne6OoFU2rE8A7LPUpx7FloFLzOUs3Bp20oam5AaJulT2DWOMcs2BDYNriywmPzA+qFfDsTeNt+aHafioMtKQ8DBWf4UdCdYt2XH0a8WeeSa+x8Qv76R0B2R3sbr5kpWsVwckYBFKX5HKpRgQUODFU7M0QZUImZfT51MY3BSae0FxtzqynGRHxniygShOcPWMbiBv4an8GKJnf6jObcHjjWlQ==; 20:m21x/3GCTZHg3fof+DRSgqzk5iGplYjb7eEB4jgv7ZpU5l9GGeadaddAYFuiX9jle6TJ7kL5ASdedR1J9s816I0bWtXRdMsw9/ucERzlNrPyH1WqS+88TXEo+aOxzhYv/lRt6GpFGuy6WMkeAac1DZldZcRO4/QbumQauxe4ulBLZy9nTgnltDk043Z4oqHkV3tEggWNVuEGqzN1ud2/7MnDlhJiqot049SW47gH7HFi8YCiiqZjNm/ANZ5jxP9yB61z6LIbxqbgjysxUnpiBSlOEs2+KJIi5OvQPvqSeU22VazmGjkxkdbQVVQwYr9Nd0Am95EvZZ+jmFrUIHc06NhcwPonC3Cr34bly7YWrF46CY4XRTYbdkTtYvs/idSRwZUfjF2yLatUaHaiCy9makz5R9UDLZoXYNPkAJa8X+IaxzVc6yJfrbvA7qtJFAuifx1gsmHdTEue4ghSApvp5nKUpKk+h+3WJx+eynp/R2VL6uIBz34hkdCs6yGsIlDT X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(57025502571588)(50582790962513); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(20170203043)(2017020702029)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123558025)(20161123555025)(20161123562025)(6072148); SRVR:HE1PR0101MB2346; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0101MB2346; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0101MB2346; 4:gkW3J8qnfEZXfORVXSZUebeFhQegg5f8JQMRehHgnoP4bMa82xH8Da765OpDeDh1hOLwtHM54YYzs+PXUA93SPPQyPjfMqpMYP04Szv1bJinN7vLO9m0KcVWPk0BR+3QGJ8n2apoZRC+Er6dVslBDtYOvDzWabeVhz8QbqqZKcS2n1ldki1QYvWGdaAvzP5pDLAd5/yq0s30KM6uCl7kgfOrPtclZoA5UB79fFFFQB90WQOyaTtQg0c/EYVQtm23YzAkgcGaGuYgMUkOaB4rPXkZb4S/ZeGJ0XY5lL/6RMXGArySAnNKCcNISQDZDOK0qP09zyZY6VdnCdsyGSdBS+n2iR2IL6OoD/UCvvZgmxtgb6RfeJaaNMl5j/9LaTtjlahqJrL+EKwFlaSeso1TuaWoOPg2ltOU36wAGHRnlDtRIkMCieHPEFvqWJ7tng0hQJ5gz22UMjSNL1HOGrwwgmzHuIB9ck7/qWNVD7/1UekFLLR3Tsd6xdxjCcIiaYsnFY8b4y9qHFNQp4x263LDvlAw2Fd/R7dt/c7Rd1UJ4ZARzXYbAG8d6VPNLrNkokU9tt3Ot6MVvjd8AkztoO832kbM48S47Pp7eljiSSF6Uxh06nnpTqh8/PjUCuouJ46Vkf2TZf354PHrkBgfzxePhYkVuDeWHnfjdar91F62JqA0OPY3qw5HZWlj6mY8/t8g2nPdbTbXozM8m8kDT5TwFbeK8lBE2nHNE85/YPWELsaTSpRZ0pXE/IvvGjw9lVVoLrGIhi/gLkZxG6+XCcVaXA== X-Forefront-PRVS: 0212BDE3BE X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7916002)(39450400003)(504954002)(199003)(377454003)(377424004)(252514010)(26244003)(51444003)(24454002)(189002)(512874002)(8666007)(6916009)(189998001)(84326002)(31430400001)(101416001)(606005)(50986999)(6306002)(74826001)(74482002)(69556001)(8676002)(110136004)(229853002)(38730400002)(25786008)(82746002)(81156014)(83716003)(81166006)(6246003)(50226002)(53546003)(6486002)(42882006)(86152003)(15974865002)(54906002)(5660300001)(97736004)(2950100002)(39060400001)(236005)(2876002)(66066001)(4326007)(7736002)(68736007)(3846002)(7906003)(966004)(86362001)(53946003)(6116002)(53936002)(105586002)(106356001)(53416004)(76176999)(93886004)(15187005004)(2906002)(33656002)(42186005)(36756003)(57306001)(92566002)(1941001)(104396002)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0101MB2346; H:eduroam-int-dhcp-97-254-8.ucl.ac.uk; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: ucl.ac.uk does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; HE1PR0101MB2346; 23:chZ00qct1TvW8mNQ90U/ix1sZE+W3gGtLJ3QzqO?= =?us-ascii?Q?lXpsO9IIF182iQaFqONwms7H+hybD1PqZFxlUTQi6tn14BE6na3rJfwGabu+?= =?us-ascii?Q?+mM+cN8T+W2PTTYHDxO1O7GKrmrbMp72UxvxGqnkQvmMwlrzNbuf/VI24uyA?= =?us-ascii?Q?MPw8vWs/eZHmnipL1JzsVlpj+neGsiAz4kcFalpCcF757aGgyy+619v6i+nn?= =?us-ascii?Q?iNwZ9yj7U/Q5qy7Q5iLSqZMHhX1PLTgkqzL++i9QPgHxxShWQ8vFbCBllUFb?= =?us-ascii?Q?U1fT0rNHMxU+VpPXyIYnuRyKWJLpPz7uV6YHK/fY+aJGNGZ6YYl9bapwh2Eq?= =?us-ascii?Q?skPrM9IL1u5mBEjzJ8DNWjxdJ2wuMtNw0r6Jzk255PqkjRvaEEDmd2s0fAxG?= =?us-ascii?Q?zeoYh/jvDaAm4EasqV7MH7L10iaJQ99S/Jn8NlDA3URvFIVaAXgLG1P0YZF7?= =?us-ascii?Q?oeVKT9+7sEoEHzRFjNdTAjxdVprm35oFs8tWlo4FmSoJ2Ljf48SBta/rMBED?= =?us-ascii?Q?6hn67BD49is9Mjf5Qr7jaj0DANhr5ZZSZGFaoxbryVp0GFxKK+6+ooo/N4gp?= =?us-ascii?Q?Qk88bKpx4KoDuJG6ijGtSi8dq5ZoyYl+2NDHBQdM2QpRkdvbggt3IRFuHB3I?= =?us-ascii?Q?MjORel9LfuLcDUsa2bGPyyRMLp+s1+qLmNKIwmWQll0VpnPldCAz08Q1rws7?= =?us-ascii?Q?R0gE8rct+f5xUBHBDunN3bkqA/mGGgR+NgSkGsb1uoYWwrIal3ins7qZVzfq?= =?us-ascii?Q?BXHaORpXxFkPhSnsWzMxX/5lRtZx0SeA0daR780BKHLq5+asN+ciprUtbP/f?= =?us-ascii?Q?IKbIcoX19pRiTfG1j4gFP2KF0grmteV/VuSJo3/ZHvxYAdkmz8NNt2fiXcMd?= =?us-ascii?Q?yNO+AS2IGaAAcivWzpiKN6M4r+SpeswpdpaLmLadRtcB2/O1OXSCLISMkdwF?= =?us-ascii?Q?bU7yLrlkUWjN6/yyT79Ek28UlCiLbx6oRPR4xae/NIBveijbs64eES3Z1kx6?= =?us-ascii?Q?mpqxUNeAIPyd+zm6UqD8ql3l3RuomjP0LV+rCDILvXwR/as/aeBoglHXkcFZ?= =?us-ascii?Q?pVHWuQWnNM2TtqZuf2Bh5KZPM9XSasMBQvQHa1vF1glFNu9FDPqiQzQY0+bo?= =?us-ascii?Q?0gypxqw4WRnTQsE11UI/0Kn+tC07WZpcO2eNFTmnh/N4hTArHILGVEdLxUd4?= =?us-ascii?Q?rT1ZZ2ycopSc+BO9ybYFI8x2SWJ9PhZ4gNAV7PkbHnMc/Ub2VX7wHBurnROV?= =?us-ascii?Q?YU3o7TTHRWAPOW0fbb5lj+tO7ZifWwSCDqQuBCYVoBmKBEoKYPvPsD3wI4dS?= =?us-ascii?Q?Se/fwr+uDq22u+juVLhVaVP02HIESNgngKtOb2UpTrGb81Ff9wREG+qMRZUM?= =?us-ascii?Q?xGTsr9U3ZjP0IrLdlTim5Af85QQX8YW4k7ls/hkFc6WSkUkVeeSve9kWDj87?= =?us-ascii?Q?F99UszcmwoymqT/MoZrVzGiKJ4t5PElRdIReiCqp2wzU+8RHsy5P/542Jmwi?= =?us-ascii?Q?vS5MFInWHoJN08dxUsSERp4m0qj5fgXHL6DWqiPA/3+qmuu/ApGe3UaUDquW?= =?us-ascii?Q?X2kH1XIKo+s+mJv3UDcURwDzrE3SGnuqUmuqXrC7EFiLS/YAtYfOZcHk6PoR?= =?us-ascii?Q?dpIMnjLVc8AGWmLo+atyGN2D0oBaW39TK7tZfXybuU0h3e5ERrC6he5w36dM?= =?us-ascii?Q?e82bYRlsLgtOzSyn2rxeIA39sSmGWKuMBi9SMCwocBpbrZk4VoeGe/+lM4SI?= =?us-ascii?Q?MM+pSn8nQ?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0101MB2346; 6:lNmHzSX/ucqUTZab2RCnAet+UJkBpOMc1EndY6rrEZoDzBYDgcNnn1CBVx05D7fyZKw1UXHP8w8lQdY8Cz4bHME5sCWQ7fbA4LMpf+m4j5A9rTB2Jwirz+xVKUqxC7bVPHS4xIvoCmtQfKuy5KZV0f/FVjm8irO55UgO2OnQNNU8TfH14yEIjo3dZ6W/Ewg4WHoKvKyOxOUbpFP293wAbSud+zpFYRxdOX+0ebI67Hn4YMCngp1YF0SGeOQchKFntFznQLNOZ9+JR7VgcHIS7l5aElCRV0esJNeJBtYs06kvhlMEm4RJKeJhSyLQRhza6MgqgK6ZhGkp4ehjPy8six5ZH1NA9mFaaDx4seTLKQ0Z7+/zJ+Jq7Oy1QkdWvRqb/RknkpDGINE7DjbsuXM4VA==; 5:b+28tkCayMDH+2Fwxct588sSHq5wET38TagjGS9CAG+rPOsoRpv6YidSxKI4rV++F8DrWS0UFyf3yKAF11tEjiDdvmsrun+8QCQzLjGH1nHoPrBDCC3GhytJApEpkOPe6UU3nOne5eRTCC4NTy4Jyg==; 24:s8mFTV/+ExcTHiq1shl/iEQeVFoffrp9C8eWadyJYugiSDdXHhq0O8WVRJxYIISmlWzOKoBY4ee1QEtuYwFSPDIQ9EsorPrdO78YemrxQrg= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0101MB2346; 7:w4s7b2GDeBuiR48LWa+C2jGFD4ev/4EezZcVuDgjb0waScDR/XRi4qnQOkyuonWYO6IjVlQ8vQrJed3R4IONLGny1pezG6dA5Hi1Nj1wYm8RuzZcoTWLnz6qqQGYlxIzSIvR8c8QCMyils1NAu/m5ha7e6Uv5BmMWRN7Pw8tgLxbeHG334UPODeJSr8ZTEw/MhduN9z1RSqajQmASUoMcD/XhBzOQWl+rFxrgcuiJWjUbKhXgcRsIcwpPKm1x3owHqlrJlDKVMEfxs0jfuyjeCVIO+mJBgljzBZhlRU7Dt+Qx2x2e2mYPJW1c2ihbKWXo6zu153LEiZd3OhJnadWBaxEmqe55qaG86IyrWD7dxZ9sHqxIHbwFxzXlAetUjrlTC3HCwxtP/3Lt7S7RGybLRO0sdOTxy6Jsv0rs4gbVqZIhwBiAF/dS+TQhZUDooo+fsW48UX5ay2VWmuvy6xrrUglLtMaEC1solFv8dxJoSjMJtD/QxtecfzReCffmhmpAdLUake0HrfTjT7bV+cEjw== X-OriginatorOrg: ucl.ac.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2017 14:09:01.7410 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0101MB2346 Archived-At: Cc: "Dongjie \(Jimmy\)" , Network Slices , AshwoodsmithPeter , Pedro Martinez-Julia , "Kiran.Makhijani" , "Natale, Bob" , Stewart Bryant , Alex Galis Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 14:09:10 -0000 --Apple-Mail=_B4639925-8A68-407B-BAB9-76C82E40A4BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Javier,=20 Re: Network Softwarization Vs. Network Slicing=20 It may be useful for you to consider the context of the term "network = softwarization=E2=80=9D which was coined in the preparation of the IEEE = Network Softwarization -NetSoft 2015 conference [13-17 April 2015 hosted = by University College London (UCL) in London - = http://sites.ieee.org/netsoft2015/ ] Network softwarization - it is an overall transformation trend for = designing, implementing, deploying, managing and maintaining network = equipment and/or network components by software programming, exploiting = the natures of software such as flexibility and rapidity all along the = lifecycle of network equipment/components, for the sake of creating = conditions enabling the re-design of network and services architectures, = optimizing costs and processes, enabling self-management and bringing = added values in network infrastructures.=20 In this context Software-Defined Networks (SDN), Network Function = Virtualization (NFV), Software-Defined Clouds, Network Virtualization, = Network Programmability could be seen as different expressions of = network softwarization which would deeply impacting and bridging Telecom = and IT industries. This trend is also transforming several other = Industries, in using =E2=80=9Csoftwarization=E2=80=9D to optimize costs = and processes and in bringing new values in infrastructures. In = particular, SDN, NFV and network programmability are creating the = conditions to reinvent network and cloud architectures, accelerate = service deployment and facilitate infrastructure management. In practice softwarization would be embedded across all layers and = network components by explicitly leveraging programmability of the data, = control and management planes. On the other hand Network Slicing may be viewed as a partitioning of = networking where different types of programmability enables could be = activated and use. As such it would be practical to envisaged separate = and isolated SDN enabled slices, NFV enabled slices, etc. I hope that the above clarification of terms would be of help to you. Best Regards Alex =20 Professor in Networked and Service Systems Communications and Information Systems Group Department of Electronic and Electrical Engineering =20 University College London Torrington Place, London WC1E 7JE United Kingdom Skype: AlexGalis Phone +44-20-3108 9441 Mobile +44-7768 493 095 Fax +44-20-7916 0388 /+44-20-7388 9325 E-mail: a.galis@ucl.ac.uk Personal Web Page: www.ee.ucl.ac.uk/~agalis Disclaimer: The information in this email and in any files transmitted with it is = intended only for the addressee and may contain confidential and/or = privileged material. Access to this email by anyone else is = unauthorized. If you receive this in error, please contact the sender = immediately and delete the material from any computer. If you are not = the intended recipient, any disclosure, copying, distribution or any = action taken or omitted to be taken in reliance on it, is strictly = prohibited. Statement and opinions expressed in this e-mail are those of = the sender, and do not necessarily reflect those of University College = London. Examples > On 8 Feb 2017, at 11:08, Javier Antich Romaguera = wrote: >=20 > Hi Stewart/all,=20 > I admit may have got lost a bit on the subtleties of the = terminology, but from my point of view it is important to emphasize that = NFV is one possible mechanism/vehicle for network slicing, but there = could be others. If by softwarization we are implying a more general = definition, that in some cases may be represented by NFV, and in others = may be a different approach, I support that view. We should emphasize on = the requirements and how network slicing can address them. NFV seems to = me more an example of implementation of network-slicing for certain use = cases.=20 >=20 > Thanks > Javier. > =20 > ______________________________________________ > Javier Antich Romaguera > Product Line Manager. JUNOS Team.=20 > Juniper Networks > email: jantich@juniper.net > m. +34639218428 > =E2=80=9CAchieving the difficult, trying the impossible" >=20 >=20 > From: Netslices > on behalf of Stewart Bryant = > > Date: Wednesday, February 8, 2017 at 11:13 AM > To: Pedro Martinez-Julia > > Cc: "Dongjie (Jimmy)" >, Network Slices >, AshwoodsmithPeter = >, = "Kiran.Makhijani" >, "Natale, Bob" >, Alex Galis > > Subject: Re: [Netslices] Network Slicing - Introductory Document and = Revised Problem Statement >=20 > Pedro >=20 > Maybe we start from different positions. >=20 > My assumption is that I can create at will a new virtual function, and > instantiate it at will and configure it at will, and create and modify > the SFC chain at will. My further assumption is that we are building > programmatic systems whereby the controls to do the above can be > assessed by someone creating a service and that they can do so in a > programming environment of their choice. >=20 > If your fundamental assumption is that NFV functionality is created on > the basis of the current hardware catalogue, and is forever fixed, = then > we have radically different views of what NFV will be. >=20 > At the end of the day a virtual NF is a computer program running on a > device that provides it with a network interface, CPU cycles and > storage, an operator can spin up any program they wish on the device > that hosts the NF. >=20 > I think that what you are saying is that softwarization a step forward > that allow the dynamic instantiation of general functions to create > services, whereas I had assumed that this was always the end-game in = NFV > and SFC. >=20 > - Stewart >=20 >=20 > On 07/02/2017 23:50, Pedro Martinez-Julia wrote: >> Dear Stewart, >>=20 >> Find my comments in-line. >>=20 >> On Tue, Feb 07, 2017 at 06:16:02PM +0000, Stewart Bryant wrote: >>>> They can be somehow related but it is not the same concept. Using >>>> NFV to illustrate the difference, it defines a set of fixed >>>> functions that are virtualized, but the resulting functions are not >>>> 100% soft-ware because they resemble the corresponding "hardware", >>>> which is quite fixed. >>> I don't agree with that. >>>=20 >>> I can instantiate any function I wish as an NFV function, be it a = well >>> known function such as a load balancer, or it can be some relatively >>> unknown function such as a homomorphic packet timestamper, or it = could >>> be some function only known to the customer but hosted in the = network >>> as an opaque function. >>>=20 >>> I can dynamically provision such functions on CPU and add or remove >>> them from a path. >>>=20 >>> Thus I see no difference between a softwarized system and a system = of >>> NFV components stitched together with SFC, at least with the >>> definition provided above. >> As I mentioned in my following paragraph, what you are describing is = a >> softwarized "infrastructure" composed of non-softwarized functions. = Thus >> you are true that they are related, I am not saying the opposite, but = it >> is not the same. >>=20 >> We can say that "NFV is a mechanism to sofwarize the infrastructure >> aspects of a network system" but it does not mean that = "softwarization >> is virtualization" or that "NFV is a subset of softarization". They = are >> different mechanisms/techniques for purposes that overlap, but only = to >> some extent. >>=20 >>>> Taking this into account I would say that NFV is a mechanism for >>>> softwarizing a network infrastructure (making it more flexible, >>>> programmable, etc.) but it is only limited to the infrastructure >>>> boundary because the functions themselves are "hard-fixed" unless >>>> they are also softwarized. >>> Obviously I don't agree with that. What constrains them to be >>> hard-fixed? >> I think that Pete's message in this thread gives a better = illustration >> of the meaning of such "hard-fixed" concept. In summary is that = although >> the infrastructure, as I mentioned above, can be programmable = (flexible, >> soft-ware), the individual mechanisms that compose do not usually = expose >> such degree of programmability. As you mentioned, a homomorphic = packet >> time stamper or a load balancer, for instance, usually have = pre-defined >> behaviours which are configurable but not programmable. >>=20 >> To sum up, I am not arguing that NFV "is not softwarization", just = that >> softwarization is not virtualization, at least "not just". They can = have >> some common goals but the former emphasizes the migration from = pre-fixed >> to dynamic *behaviors* while the latter lies in the migration from = fixed >> to dynamic *elements* (services, devices, infrastructures). >>=20 >>> - Stewart >> Regards, >> Pedro >>=20 >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices = >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices --Apple-Mail=_B4639925-8A68-407B-BAB9-76C82E40A4BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Hi Javier, 

Re: Network Softwarization Vs. Network Slicing 

It may be useful for you to consider the context of the term "network softwarization=E2=80=9D which was coined in = the preparation of the IEEE Network Softwarization -NetSoft 2015 conference = [13-17 April 2015 hosted by University College London (UCL) in London - http://sites.ieee.org/netsoft2015/]

Network softwarization - it is an overall transformation trend for designing, implementing, deploying, managing = and maintaining network equipment and/or network components by software programming, exploiting the natures of software such as flexibility and rapidity all along the lifecycle of network equipment/components, for = the sake of creating conditions enabling the re-design of network and services architectures, optimizing costs and processes, enabling self-management = and bringing added values in network infrastructures. 

In this context = Software-Defined Networks (SDN), Network Function Virtualization (NFV), Software-Defined Clouds, = Network Virtualization, Network Programmability could be seen as different = expressions of network softwarization which would deeply impacting and bridging = Telecom and IT industries. This trend is also transforming several other Industries, = in using =E2=80=9Csoftwarization=E2=80=9D to optimize costs and processes = and in bringing new values in infrastructures. In particular, SDN, NFV and network = programmability are creating the conditions to reinvent network and cloud architectures, accelerate service deployment and facilitate infrastructure = management.

In practice softwarization would be embedded across all layers and network components by explicitly = leveraging programmability of the data, control and management planes.

On the other hand Network Slicing may be viewed as a partitioning of networking where different types of programmability enables could be activated and use. As such it would be practical to = envisaged separate and isolated SDN enabled slices, NFV enabled slices, etc.

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

Best Regards

Alex

 


Professor in Networked and Service Systems
Communications and Information Systems Group
Department of Electronic and Electrical = Engineering  
University College London
Torrington Place, London WC1E 7JE
United = Kingdom

Skype: AlexGalis
Phone +44-20-3108 9441
Mobile +44-7768 493 095
Fax +44-20-7916 0388 /+44-20-7388 = 9325
E-mail: a.galis@ucl.ac.uk
Personal= Web Page: www.ee.ucl.ac.uk/~agalis

Disclaimer:

The = information in this email and in any files transmitted with it is = intended only for the addressee and may contain confidential and/or = privileged material. Access to this email by anyone else is = unauthorized. If you receive this in error, please contact the sender = immediately and delete the material from any computer. If you are not = the intended recipient, any disclosure, copying, distribution or any = action taken or omitted to be taken in reliance on it, is strictly = prohibited. Statement and opinions expressed in this e-mail are those of = the sender, and do not necessarily reflect those of University College = London.




Examples
On 8 Feb 2017, at 11:08, Javier = Antich Romaguera <jantich@juniper.net> wrote:

Hi Stewart/all, 
   I admit may have got lost a bit on the = subtleties of the terminology, but from my point of view it is important = to emphasize that NFV is one possible mechanism/vehicle for network = slicing, but there could be others. If by softwarization we are implying a more general definition, that in some cases may be represented by = NFV, and in others may be a different approach, I support that view. We = should emphasize on the requirements and how network slicing can address = them. NFV seems to me more an example of implementation of network-slicing for certain use cases. 

Thanks
Javier.
    
______________________________________________
Javier Antich Romaguera
Product Line Manager. JUNOS Team. 
Juniper Networks
email: jantich@juniper.net
m. +34639218428
=E2=80=9CAchieving the difficult, trying the = impossible"


From: Netslices <netslices-bounces@ietf.org> on behalf of Stewart = Bryant <stewart.bryant@gmail.com>
Date: Wednesday, February 8, 2017 at 11:13 AM
To: Pedro Martinez-Julia <pedro@nict.go.jp>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Network Slices <netslices@ietf.org>, = AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>, "Kiran.Makhijani" <Kiran.Makhijani@huawei.com>, "Natale, Bob" <RNATALE@mitre.org>, = Alex Galis <a.galis@ucl.ac.uk>
Subject: Re: [Netslices] Network Slicing - = Introductory Document and Revised Problem Statement

Pedro

Maybe we start from different positions.

My assumption is that I can create at will a new virtual = function, and
instantiate it at will and configure it at will, and = create and modify
the SFC chain at will. My further assumption is that we = are building
programmatic systems whereby the controls to do the = above can be
assessed by someone creating a service and that they can = do so in a
programming environment of their choice.

If your fundamental assumption is that NFV functionality = is created on
the basis of the current hardware catalogue, and is = forever fixed, then
we have radically different views of what NFV will = be.

At the end of the day a virtual NF is a computer program = running on a
device that provides it with a network interface, CPU = cycles and
storage, an operator can spin up any program they wish = on the device
that hosts the NF.

I think that what you are saying is that softwarization = a step forward
that allow the dynamic  instantiation of = general functions to create
services, whereas I had assumed that this was always the = end-game in NFV
and SFC.

- Stewart


On 07/02/2017 23:50, Pedro Martinez-Julia wrote:
Dear Stewart,

Find my comments in-line.

On Tue, Feb 07, 2017 at 06:16:02PM +0000, Stewart Bryant = wrote:
They can be somehow related but it is not the same = concept. Using
NFV to illustrate the difference, it defines a set of = fixed
functions that are virtualized, but the resulting = functions are not
100% soft-ware because they resemble the corresponding = "hardware",
which is quite fixed.
I don't agree with that.

I can instantiate any function I wish as an NFV = function, be it a well
known function such as a load balancer, or it can be = some relatively
unknown function such as a homomorphic packet = timestamper, or it could
be some function only known to the customer but hosted = in the network
as an opaque function.

I can dynamically provision such functions on CPU and = add or remove
them from a path.

Thus I see no difference between a softwarized system = and a system of
NFV components stitched together with SFC, at least with = the
definition provided above.
As I mentioned in my following paragraph, what you are = describing is a
softwarized "infrastructure" composed of non-softwarized = functions. Thus
you are true that they are related, I am not saying the = opposite, but it
is not the same.

We can say that "NFV is a mechanism to sofwarize the = infrastructure
aspects of a network system" but it does not mean that = "softwarization
is virtualization" or that "NFV is a subset of = softarization". They are
different mechanisms/techniques for purposes that = overlap, but only to
some extent.

Taking this into account I would say that NFV is a = mechanism for
softwarizing a network infrastructure (making it more = flexible,
programmable, etc.) but it is only limited to the = infrastructure
boundary because the functions themselves are = "hard-fixed" unless
they are also softwarized.
Obviously I don't agree with that. What constrains them = to be
hard-fixed?
I think that Pete's message in this thread gives a = better illustration
of the meaning of such "hard-fixed" concept. In summary = is that although
the infrastructure, as I mentioned above, can be = programmable (flexible,
soft-ware), the individual mechanisms that compose do = not usually expose
such degree of programmability. As you mentioned, a = homomorphic packet
time stamper or a load balancer, for instance, usually = have pre-defined
behaviours which are configurable but not = programmable.

To sum up, I am not arguing that NFV "is not = softwarization", just that
softwarization is not virtualization, at least "not = just". They can have
some common goals but the former emphasizes the = migration from pre-fixed
to dynamic *behaviors* while the latter lies in the = migration from fixed
to dynamic *elements* (services, devices, = infrastructures).

- Stewart
Regards,
Pedro


_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices
_______________________________________________
Netslices = mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

= --Apple-Mail=_B4639925-8A68-407B-BAB9-76C82E40A4BA-- From nobody Wed Feb 8 06:28:55 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FD6129B34 for ; Wed, 8 Feb 2017 06:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 mqkr6xq3E9Xb for ; Wed, 8 Feb 2017 06:28:52 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FCA9129B1F for ; Wed, 8 Feb 2017 06:28:52 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v18ESbZi019572; Wed, 8 Feb 2017 14:28:37 GMT Received: from 950129200 ([176.241.250.4]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v18ESV4Z019556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Feb 2017 14:28:35 GMT From: "Adrian Farrel" To: , "'Javier Antich Romaguera'" References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> In-Reply-To: <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> Date: Wed, 8 Feb 2017 14:28:30 -0000 Message-ID: <06e901d28217$a27dfc70$e779f550$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDRcT5+JTP9KmmueWKg00wrBgSOBwIe2CqdAeW45ekBs7eOJgICIL1jAs6qULMBqLLE5gJdPZ8vAmeaYL0CffLK9gHep3TvorayMAA= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22872.006 X-TM-AS-Result: No--3.436-10.0-31-10 X-imss-scan-details: No--3.436-10.0-31-10 X-TMASE-MatchedRID: wQVy7q402w04HKI/yaqRm8WUKBjERoYTBmJItUsTG9T8bD+4PAZXi4Xr nQ9eYMT0XombZAMNfY7T/4dXba431xPKKFgVM89tlY5qr7f6fHJBldmDYjwlplZt4We6JrdSLF9 jbxvK1+1HV1fX3u4bHl+24nCsUSFNo15kJcETr3lq8/xv2Um1avoLR4+zsDTtHtexZ1+/9Pl2qa oWpugrac4JHMzvEXE6cBsO+3YALKzS+VNStcAhKh1/04aeX17m5ZWXVQzl3osA4I5VvHoWBljUq CiFWEe0ZypUI5K1emaHx/3593XRE+S+ZTuCPZ+tPifujgI13dqh071fQj6NysC+ksT6a9fy Archived-At: Cc: "'Dongjie \(Jimmy\)'" , 'Network Slices' , 'AshwoodsmithPeter' , 'Pedro Martinez-Julia' , "'Kiran.Makhijani'" , "'Natale, Bob'" , 'Stewart Bryant' Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 14:28:54 -0000 > It may be useful for you to consider the context of the term > "network softwarization=E2=80=9D which was coined in the preparation > of the IEEE Network Softwarization -NetSoft 2015 conference=20 > [13-17 April 2015 hosted by University College London (UCL) in > London - http://sites.ieee.org/netsoft2015/] Alex, don't run yourself down, mate. You were using the term way back in 2013. http://www.iaria.org/conferences2013/filesICDT13/NexCOMM-KeyNote_AGalis_v= 5.pdf (Doesn't mean I like the term, but it has a long and proud history.) Adrian From nobody Wed Feb 8 06:40:55 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE53E129B28 for ; Wed, 8 Feb 2017 06:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=realsdn.org 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 d9smWp0kvU7M for ; Wed, 8 Feb 2017 06:40:49 -0800 (PST) Received: from ajmclachlan.com (pigmail.ajmclachlan.com [78.31.107.96]) (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 37805129547 for ; Wed, 8 Feb 2017 06:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=realsdn.org; s=default; t=1486564849; bh=7OGprqvb+TQAl5OzRzD+hYWiqQrlTjFMgJuS5UfFYVE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=FzuuYLHZIDGy+IPV+uW9fMCdmhBtxH75E2C8BWdpyYMZGMHUD1uM1/9a2sVXjrF6p 6JvBCLvp/M/9/w8o1/4G0AVXI7YrmD0M9S1jUlNA2SkVMxDhg4k0Ke0SA0WfCgCIG/ nOX4ZUT7okOyrHiqHA7rSzlVfLcuC9hiez4na7/0= X-Default-Received-SPF: pass (skip=forwardok (res=PASS)); Content-Type: multipart/alternative; boundary="Apple-Mail=_516F1A54-1760-4A39-BC12-954BEB549513" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Andrew McLachlan In-Reply-To: <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> Date: Wed, 8 Feb 2017 14:40:24 +0000 Message-Id: <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> To: a.galis@ucl.ac.uk X-Mailer: Apple Mail (2.3124) X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted Archived-At: Cc: "Dongjie \(Jimmy\)" , Javier Antich Romaguera , Network Slices , AshwoodsmithPeter , Pedro Martinez-Julia , "Kiran.Makhijani" , "Natale, Bob" , Stewart Bryant Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 14:40:53 -0000 --Apple-Mail=_516F1A54-1760-4A39-BC12-954BEB549513 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Networks have always been software driven and also been programable via = multiple methods, CLI, SNMP (occasionally), and the myriad of = orchestration tools, some open and some not. Networks themselves are not being re-invented, we are literally going = full circle back to using an NMS approach to manage blocks of = elements..but today we now call them =E2=80=98controllers'. We are already seeing the impact of moving features from hardware into = software now being returned to hardware in order to achieve the = performance that is required and to meet the low power consumption = requirements. Yes some services can and should move to a virtual environment, to = achieve better scale and faster deployment, but when we start to look at = the requirements for latency, path failover and other features needing = extremely tight restoration=E2=80=A6 we quickly move back to needing = hardware based feature sets to achieve this. I think we need to ditch this term softwareization, as it is extremely = misleading.=20 Also SDN is really about software driven networks, not defined = networking. Networking, services, infrastructure are not defined by = software, they are operated by software, via programable interfaces (if = available) and or by a controller/NMS layer. As for Network Slicing, this has been done for years. It might be new in = a 5G world, but should not be confused with being something actually = new. The question for this group in the IETF should surely be.. do we need = any new protocols or enhancements in this area, bearing in might that = most of the =E2=80=98glue=E2=80=99 for E2E will be done at the high = orchestration layer. =20 > On 8 Feb 2017, at 14:08, = wrote: >=20 > Hi Javier,=20 >=20 > Re: Network Softwarization Vs. Network Slicing=20 >=20 > It may be useful for you to consider the context of the term "network = softwarization=E2=80=9D which was coined in the preparation of the IEEE = Network Softwarization -NetSoft 2015 conference [13-17 April 2015 hosted = by University College London (UCL) in London - = http://sites.ieee.org/netsoft2015/ ] >=20 > Network softwarization - it is an overall transformation trend for = designing, implementing, deploying, managing and maintaining network = equipment and/or network components by software programming, exploiting = the natures of software such as flexibility and rapidity all along the = lifecycle of network equipment/components, for the sake of creating = conditions enabling the re-design of network and services architectures, = optimizing costs and processes, enabling self-management and bringing = added values in network infrastructures.=20 >=20 > In this context Software-Defined Networks (SDN), Network Function = Virtualization (NFV), Software-Defined Clouds, Network Virtualization, = Network Programmability could be seen as different expressions of = network softwarization which would deeply impacting and bridging Telecom = and IT industries. This trend is also transforming several other = Industries, in using =E2=80=9Csoftwarization=E2=80=9D to optimize costs = and processes and in bringing new values in infrastructures. In = particular, SDN, NFV and network programmability are creating the = conditions to reinvent network and cloud architectures, accelerate = service deployment and facilitate infrastructure management. >=20 > In practice softwarization would be embedded across all layers and = network components by explicitly leveraging programmability of the data, = control and management planes. >=20 > On the other hand Network Slicing may be viewed as a partitioning of = networking where different types of programmability enables could be = activated and use. As such it would be practical to envisaged separate = and isolated SDN enabled slices, NFV enabled slices, etc. >=20 > I hope that the above clarification of terms would be of help to you. >=20 > Best Regards >=20 > Alex >=20 > =20 >=20 > Professor in Networked and Service Systems > Communications and Information Systems Group > Department of Electronic and Electrical Engineering =20 > University College London > Torrington Place, London WC1E 7JE > United Kingdom >=20 > Skype: AlexGalis > Phone +44-20-3108 9441 > Mobile +44-7768 493 095 > Fax +44-20-7916 0388 /+44-20-7388 9325 > E-mail: a.galis@ucl.ac.uk > Personal Web Page: www.ee.ucl.ac.uk/~agalis = >=20 > Disclaimer: >=20 > The information in this email and in any files transmitted with it is = intended only for the addressee and may contain confidential and/or = privileged material. Access to this email by anyone else is = unauthorized. If you receive this in error, please contact the sender = immediately and delete the material from any computer. If you are not = the intended recipient, any disclosure, copying, distribution or any = action taken or omitted to be taken in reliance on it, is strictly = prohibited. Statement and opinions expressed in this e-mail are those of = the sender, and do not necessarily reflect those of University College = London. >=20 >=20 >=20 >=20 > Examples >> On 8 Feb 2017, at 11:08, Javier Antich Romaguera > wrote: >>=20 >> Hi Stewart/all,=20 >> I admit may have got lost a bit on the subtleties of the = terminology, but from my point of view it is important to emphasize that = NFV is one possible mechanism/vehicle for network slicing, but there = could be others. If by softwarization we are implying a more general = definition, that in some cases may be represented by NFV, and in others = may be a different approach, I support that view. We should emphasize on = the requirements and how network slicing can address them. NFV seems to = me more an example of implementation of network-slicing for certain use = cases.=20 >>=20 >> Thanks >> Javier. >> =20 >> ______________________________________________ >> Javier Antich Romaguera >> Product Line Manager. JUNOS Team.=20 >> Juniper Networks >> email: jantich@juniper.net >> m. +34639218428 >> =E2=80=9CAchieving the difficult, trying the impossible" >>=20 >>=20 >> From: Netslices > on behalf of Stewart Bryant = > >> Date: Wednesday, February 8, 2017 at 11:13 AM >> To: Pedro Martinez-Julia > >> Cc: "Dongjie (Jimmy)" >, Network Slices >, AshwoodsmithPeter = >, = "Kiran.Makhijani" >, "Natale, Bob" >, Alex Galis > >> Subject: Re: [Netslices] Network Slicing - Introductory Document and = Revised Problem Statement >>=20 >> Pedro >>=20 >> Maybe we start from different positions. >>=20 >> My assumption is that I can create at will a new virtual function, = and >> instantiate it at will and configure it at will, and create and = modify >> the SFC chain at will. My further assumption is that we are building >> programmatic systems whereby the controls to do the above can be >> assessed by someone creating a service and that they can do so in a >> programming environment of their choice. >>=20 >> If your fundamental assumption is that NFV functionality is created = on >> the basis of the current hardware catalogue, and is forever fixed, = then >> we have radically different views of what NFV will be. >>=20 >> At the end of the day a virtual NF is a computer program running on a >> device that provides it with a network interface, CPU cycles and >> storage, an operator can spin up any program they wish on the device >> that hosts the NF. >>=20 >> I think that what you are saying is that softwarization a step = forward >> that allow the dynamic instantiation of general functions to create >> services, whereas I had assumed that this was always the end-game in = NFV >> and SFC. >>=20 >> - Stewart >>=20 >>=20 >> On 07/02/2017 23:50, Pedro Martinez-Julia wrote: >>> Dear Stewart, >>>=20 >>> Find my comments in-line. >>>=20 >>> On Tue, Feb 07, 2017 at 06:16:02PM +0000, Stewart Bryant wrote: >>>>> They can be somehow related but it is not the same concept. Using >>>>> NFV to illustrate the difference, it defines a set of fixed >>>>> functions that are virtualized, but the resulting functions are = not >>>>> 100% soft-ware because they resemble the corresponding "hardware", >>>>> which is quite fixed. >>>> I don't agree with that. >>>>=20 >>>> I can instantiate any function I wish as an NFV function, be it a = well >>>> known function such as a load balancer, or it can be some = relatively >>>> unknown function such as a homomorphic packet timestamper, or it = could >>>> be some function only known to the customer but hosted in the = network >>>> as an opaque function. >>>>=20 >>>> I can dynamically provision such functions on CPU and add or remove >>>> them from a path. >>>>=20 >>>> Thus I see no difference between a softwarized system and a system = of >>>> NFV components stitched together with SFC, at least with the >>>> definition provided above. >>> As I mentioned in my following paragraph, what you are describing is = a >>> softwarized "infrastructure" composed of non-softwarized functions. = Thus >>> you are true that they are related, I am not saying the opposite, = but it >>> is not the same. >>>=20 >>> We can say that "NFV is a mechanism to sofwarize the infrastructure >>> aspects of a network system" but it does not mean that = "softwarization >>> is virtualization" or that "NFV is a subset of softarization". They = are >>> different mechanisms/techniques for purposes that overlap, but only = to >>> some extent. >>>=20 >>>>> Taking this into account I would say that NFV is a mechanism for >>>>> softwarizing a network infrastructure (making it more flexible, >>>>> programmable, etc.) but it is only limited to the infrastructure >>>>> boundary because the functions themselves are "hard-fixed" unless >>>>> they are also softwarized. >>>> Obviously I don't agree with that. What constrains them to be >>>> hard-fixed? >>> I think that Pete's message in this thread gives a better = illustration >>> of the meaning of such "hard-fixed" concept. In summary is that = although >>> the infrastructure, as I mentioned above, can be programmable = (flexible, >>> soft-ware), the individual mechanisms that compose do not usually = expose >>> such degree of programmability. As you mentioned, a homomorphic = packet >>> time stamper or a load balancer, for instance, usually have = pre-defined >>> behaviours which are configurable but not programmable. >>>=20 >>> To sum up, I am not arguing that NFV "is not softwarization", just = that >>> softwarization is not virtualization, at least "not just". They can = have >>> some common goals but the former emphasizes the migration from = pre-fixed >>> to dynamic *behaviors* while the latter lies in the migration from = fixed >>> to dynamic *elements* (services, devices, infrastructures). >>>=20 >>>> - Stewart >>> Regards, >>> Pedro >>>=20 >>=20 >> _______________________________________________ >> Netslices mailing list >> Netslices@ietf.org >> https://www.ietf.org/mailman/listinfo/netslices = >>=20 >> _______________________________________________ >> Netslices mailing list >> Netslices@ietf.org >> https://www.ietf.org/mailman/listinfo/netslices >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices --Apple-Mail=_516F1A54-1760-4A39-BC12-954BEB549513 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


Networks have always been software = driven and also been programable via multiple methods, CLI, SNMP = (occasionally), and the myriad of orchestration tools, some open and = some not.

Networks themselves are not being re-invented, we are = literally going full circle back to using an NMS approach to manage = blocks of elements..but today we now call them = =E2=80=98controllers'.

We are already seeing the impact of moving features from = hardware into software now being returned to hardware in order to = achieve the performance that is required and to meet the low power = consumption requirements.

Yes some services can and should move to a virtual = environment, to achieve better scale and faster deployment, but when we = start to look at the requirements for latency, path failover and other = features needing extremely tight restoration=E2=80=A6 we quickly move = back to needing hardware based feature sets to achieve this.

I think we need to ditch = this term softwareization, as it is extremely = misleading. 

Also SDN is really about software driven networks, not = defined networking. Networking, services, infrastructure are not defined = by software, they are operated by software, via programable interfaces = (if available) and or by a controller/NMS layer.

As for Network Slicing, this has been = done for years. It might be new in a 5G world, but should not be = confused with being something actually new.

The question for this group in the IETF = should surely be.. do we need any new protocols or enhancements in this = area, bearing in might that most of the =E2=80=98glue=E2=80=99 for E2E = will be done at the high orchestration layer.
 



On 8 Feb 2017, at 14:08, <a.galis@ucl.ac.uk> = <a.galis@ucl.ac.uk> wrote:

Hi Javier, 

Re: Network Softwarization Vs. Network Slicing 

It may be useful for you to consider the context of the term "network softwarization=E2=80=9D which was coined in = the preparation of the IEEE Network Softwarization -NetSoft 2015 conference = [13-17 April 2015 hosted by University College London (UCL) in London - http://sites.ieee.org/netsoft2015/]

Network softwarization - it is an overall transformation trend for designing, implementing, deploying, managing = and maintaining network equipment and/or network components by software programming, exploiting the natures of software such as flexibility and rapidity all along the lifecycle of network equipment/components, for = the sake of creating conditions enabling the re-design of network and services architectures, optimizing costs and processes, enabling self-management = and bringing added values in network infrastructures. 

In this context = Software-Defined Networks (SDN), Network Function Virtualization (NFV), Software-Defined Clouds, = Network Virtualization, Network Programmability could be seen as different = expressions of network softwarization which would deeply impacting and bridging = Telecom and IT industries. This trend is also transforming several other Industries, = in using =E2=80=9Csoftwarization=E2=80=9D to optimize costs and processes = and in bringing new values in infrastructures. In particular, SDN, NFV and network = programmability are creating the conditions to reinvent network and cloud architectures, accelerate service deployment and facilitate infrastructure = management.

In practice softwarization would be embedded across all layers and network components by explicitly = leveraging programmability of the data, control and management planes.

On the other hand Network Slicing may be viewed as a partitioning of networking where different types of programmability enables could be activated and use. As such it would be practical to = envisaged separate and isolated SDN enabled slices, NFV enabled slices, etc.

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

Best Regards

Alex

 

Professor in Networked and Service Systems
Communications and Information Systems Group
Department of Electronic and Electrical = Engineering  
University College London
Torrington Place, London WC1E 7JE
United = Kingdom

Skype: AlexGalis
Phone +44-20-3108 9441
Mobile +44-7768 493 095
Fax +44-20-7916 0388 /+44-20-7388 = 9325
E-mail: a.galis@ucl.ac.uk
Personal= Web Page: www.ee.ucl.ac.uk/~agalis

Disclaimer:

The = information in this email and in any files transmitted with it is = intended only for the addressee and may contain confidential and/or = privileged material. Access to this email by anyone else is = unauthorized. If you receive this in error, please contact the sender = immediately and delete the material from any computer. If you are not = the intended recipient, any disclosure, copying, distribution or any = action taken or omitted to be taken in reliance on it, is strictly = prohibited. Statement and opinions expressed in this e-mail are those of = the sender, and do not necessarily reflect those of University College = London.




Examples
On 8 Feb 2017, at = 11:08, Javier Antich Romaguera <jantich@juniper.net> wrote:

Hi Stewart/all, 
   I admit may have got lost a bit on the = subtleties of the terminology, but from my point of view it is important = to emphasize that NFV is one possible mechanism/vehicle for network = slicing, but there could be others. If by softwarization we are implying a more general definition, that in some cases may be represented by = NFV, and in others may be a different approach, I support that view. We = should emphasize on the requirements and how network slicing can address = them. NFV seems to me more an example of implementation of network-slicing for certain use cases. 

Thanks
Javier.
    
______________________________________________
Javier Antich Romaguera
Product Line Manager. JUNOS Team. 
Juniper Networks
email: jantich@juniper.net
m. +34639218428
=E2=80=9CAchieving the difficult, trying the = impossible"


From: Netslices <netslices-bounces@ietf.org> on behalf of Stewart = Bryant <stewart.bryant@gmail.com>
Date: Wednesday, February 8, 2017 at 11:13 AM
To: Pedro Martinez-Julia <pedro@nict.go.jp>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Network Slices <netslices@ietf.org>, = AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>, "Kiran.Makhijani" <Kiran.Makhijani@huawei.com>, "Natale, Bob" <RNATALE@mitre.org>, = Alex Galis <a.galis@ucl.ac.uk>
Subject: Re: [Netslices] Network Slicing - = Introductory Document and Revised Problem Statement

Pedro

Maybe we start from different positions.

My assumption is that I can create at will a new virtual = function, and
instantiate it at will and configure it at will, and = create and modify
the SFC chain at will. My further assumption is that we = are building
programmatic systems whereby the controls to do the = above can be
assessed by someone creating a service and that they can = do so in a
programming environment of their choice.

If your fundamental assumption is that NFV functionality = is created on
the basis of the current hardware catalogue, and is = forever fixed, then
we have radically different views of what NFV will = be.

At the end of the day a virtual NF is a computer program = running on a
device that provides it with a network interface, CPU = cycles and
storage, an operator can spin up any program they wish = on the device
that hosts the NF.

I think that what you are saying is that softwarization = a step forward
that allow the dynamic  instantiation of = general functions to create
services, whereas I had assumed that this was always the = end-game in NFV
and SFC.

- Stewart


On 07/02/2017 23:50, Pedro Martinez-Julia wrote:
Dear Stewart,

Find my comments in-line.

On Tue, Feb 07, 2017 at 06:16:02PM +0000, Stewart Bryant = wrote:
They can be somehow related but it is not the same = concept. Using
NFV to illustrate the difference, it defines a set of = fixed
functions that are virtualized, but the resulting = functions are not
100% soft-ware because they resemble the corresponding = "hardware",
which is quite fixed.
I don't agree with that.

I can instantiate any function I wish as an NFV = function, be it a well
known function such as a load balancer, or it can be = some relatively
unknown function such as a homomorphic packet = timestamper, or it could
be some function only known to the customer but hosted = in the network
as an opaque function.

I can dynamically provision such functions on CPU and = add or remove
them from a path.

Thus I see no difference between a softwarized system = and a system of
NFV components stitched together with SFC, at least with = the
definition provided above.
As I mentioned in my following paragraph, what you are = describing is a
softwarized "infrastructure" composed of non-softwarized = functions. Thus
you are true that they are related, I am not saying the = opposite, but it
is not the same.

We can say that "NFV is a mechanism to sofwarize the = infrastructure
aspects of a network system" but it does not mean that = "softwarization
is virtualization" or that "NFV is a subset of = softarization". They are
different mechanisms/techniques for purposes that = overlap, but only to
some extent.

Taking this into account I would say that NFV is a = mechanism for
softwarizing a network infrastructure (making it more = flexible,
programmable, etc.) but it is only limited to the = infrastructure
boundary because the functions themselves are = "hard-fixed" unless
they are also softwarized.
Obviously I don't agree with that. What constrains them = to be
hard-fixed?
I think that Pete's message in this thread gives a = better illustration
of the meaning of such "hard-fixed" concept. In summary = is that although
the infrastructure, as I mentioned above, can be = programmable (flexible,
soft-ware), the individual mechanisms that compose do = not usually expose
such degree of programmability. As you mentioned, a = homomorphic packet
time stamper or a load balancer, for instance, usually = have pre-defined
behaviours which are configurable but not = programmable.

To sum up, I am not arguing that NFV "is not = softwarization", just that
softwarization is not virtualization, at least "not = just". They can have
some common goals but the former emphasizes the = migration from pre-fixed
to dynamic *behaviors* while the latter lies in the = migration from fixed
to dynamic *elements* (services, devices, = infrastructures).

- Stewart
Regards,
Pedro


_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices
_______________________________________________
Netslices = mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

= --Apple-Mail=_516F1A54-1760-4A39-BC12-954BEB549513-- From nobody Wed Feb 8 06:46:50 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BDB129B92 for ; Wed, 8 Feb 2017 06:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 BXKl6DAQ6OYT for ; Wed, 8 Feb 2017 06:46:45 -0800 (PST) Received: from www.kot-begemot.co.uk (ivanoab5.miniserver.com [78.31.111.25]) (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 84D74129B91 for ; Wed, 8 Feb 2017 06:46:44 -0800 (PST) Received: from tun5.smaug.kot-begemot.co.uk ([192.168.18.6] helo=smaug.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cbTW6-00041O-Nf for netslices@ietf.org; Wed, 08 Feb 2017 14:46:42 +0000 Received: from monstrousnightmare.kot-begemot.co.uk ([192.168.11.207]) by smaug.kot-begemot.co.uk with esmtp (Exim 4.84_2) (envelope-from ) id 1cbTW6-0004DL-Eb for netslices@ietf.org; Wed, 08 Feb 2017 14:46:42 +0000 To: netslices@ietf.org References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> From: Anton Ivanov Message-ID: Date: Wed, 8 Feb 2017 14:46:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> Content-Type: multipart/alternative; boundary="------------F13D8791368427126C0CFF7D" X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 14:46:48 -0000 This is a multi-part message in MIME format. --------------F13D8791368427126C0CFF7D Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 08/02/17 14:40, Andrew McLachlan wrote: > > > Networks have always been software driven and also been programable > via multiple methods, CLI, SNMP (occasionally), and the myriad of > orchestration tools, some open and some not. > > Networks themselves are not being re-invented, we are literally going > full circle back to using an NMS approach to manage blocks of > elements..but today we now call them controllers'. > > We are already seeing the impact of moving features from hardware into > software now being returned to hardware in order to achieve the > performance that is required and to meet the low power consumption > requirements. > > Yes some services can and should move to a virtual environment, to > achieve better scale and faster deployment, but when we start to look > at the requirements for latency, path failover and other features > needing extremely tight restoration we quickly move back to needing > hardware based feature sets to achieve this. > > I think we need to ditch this term softwareization, as it is extremely > misleading. > > Also SDN is really about software driven networks, not defined > networking. Networking, services, infrastructure are not defined by > software, they are operated by software, via programable interfaces > (if available) and or by a controller/NMS layer. > > As for Network Slicing, this has been done for years. It might be new > in a 5G world, but should not be confused with being something > actually new. > > The question for this group in the IETF should surely be.. do we need > any new protocols or enhancements in this area, bearing in might that > most of the glue for E2E will be done at the high orchestration layer. No. A. > > > >> On 8 Feb 2017, at 14:08, > > > > wrote: >> >> Hi Javier, >> >> Re: Network Softwarization Vs. Network Slicing >> >> It may be useful for you to consider the context of the term "network >> softwarization which was coined in the preparation of the IEEE >> Network Softwarization -NetSoft 2015 conference [13-17 April 2015 >> hosted by University College London (UCL) in London - >> http://sites.ieee.org/netsoft2015/] >> >> Network softwarization - it is an overall transformation trend for >> designing, implementing, deploying, managing and maintaining network >> equipment and/or network components by software programming, >> exploiting the natures of software such as flexibility and rapidity >> all along the lifecycle of network equipment/components, for the sake >> of creating conditions enabling the re-design of network and services >> architectures, optimizing costs and processes, enabling >> self-management and bringing added values in network infrastructures. >> >> In this context Software-Defined Networks (SDN), Network Function >> Virtualization (NFV), Software-Defined Clouds, Network >> Virtualization, Network Programmability could be seen as different >> expressions of network softwarization which would deeply impacting >> and bridging Telecom and IT industries. This trend is also >> transforming several other Industries, in using softwarization to >> optimize costs and processes and in bringing new values in >> infrastructures. In particular, SDN, NFV and network programmability >> are creating the conditions to reinvent network and cloud >> architectures, accelerate service deployment and facilitate >> infrastructure management. >> >> In practice softwarization would be embedded across all layers and >> network components by explicitly leveraging programmability of the >> data, control and management planes. >> >> On the other hand Network Slicing may be viewed as a partitioning of >> networking where different types of programmability enables could be >> activated and use. As such it would be practical to envisaged >> separate and isolated SDN enabled slices, NFV enabled slices, etc. >> >> I hope that the above clarification of terms would be of help to you. >> >> Best Regards >> >> Alex >> >> >> >> Professor in Networked and Service Systems >> Communications and Information Systems Group >> Department of Electronic and Electrical Engineering >> University College London >> Torrington Place, London WC1E 7JE >> United Kingdom >> >> Skype: AlexGalis >> Phone +44-20-3108 9441 >> Mobile +44-7768 493 095 >> Fax +44-20-7916 0388 /+44-20-7388 9325 >> E-mail: a.galis@ucl.ac.uk >> Personal Web Page: www.ee.ucl.ac.uk/~agalis >> >> >> Disclaimer: >> >> The information in this email and in any files transmitted with it is >> intended only for the addressee and may contain confidential and/or >> privileged material. Access to this email by anyone else is >> unauthorized. If you receive this in error, please contact the sender >> immediately and delete the material from any computer. If you are not >> the intended recipient, any disclosure, copying, distribution or any >> action taken or omitted to be taken in reliance on it, is strictly >> prohibited. Statement and opinions expressed in this e-mail are those >> of the sender, and do not necessarily reflect those of University >> College London. >> >> >> >> >> Examples >>> On 8 Feb 2017, at 11:08, Javier Antich Romaguera >>> > wrote: >>> >>> Hi Stewart/all, >>> I admit may have got lost a bit on the subtleties of the >>> terminology, but from my point of view it is important to emphasize >>> that NFV is one possible mechanism/vehicle for network slicing, but >>> there could be others. If by softwarization we are implying a more >>> general definition, that in some cases may be represented by NFV, >>> and in others may be a different approach, I support that view. We >>> should emphasize on the requirements and how network slicing can >>> address them. NFV seems to me more an example of implementation of >>> network-slicing for certain use cases. >>> >>> Thanks >>> Javier. >>> ______________________________________________ >>> Javier Antich Romaguera >>> Product Line Manager. JUNOS Team. >>> Juniper Networks >>> email: jantich@juniper.net >>> m. +34639218428 >>> Achieving the difficult, trying the impossible" >>> >>> >>> From: Netslices >> > on behalf of Stewart Bryant >>> > >>> Date: Wednesday, February 8, 2017 at 11:13 AM >>> To: Pedro Martinez-Julia > >>> Cc: "Dongjie (Jimmy)" >> >, Network Slices >> >, AshwoodsmithPeter >>> >> >, "Kiran.Makhijani" >>> >, >>> "Natale, Bob" >, Alex >>> Galis > >>> Subject: Re: [Netslices] Network Slicing - Introductory Document and >>> Revised Problem Statement >>> >>> Pedro >>> >>> Maybe we start from different positions. >>> >>> My assumption is that I can create at will a new virtual function, and >>> instantiate it at will and configure it at will, and create and modify >>> the SFC chain at will. My further assumption is that we are building >>> programmatic systems whereby the controls to do the above can be >>> assessed by someone creating a service and that they can do so in a >>> programming environment of their choice. >>> >>> If your fundamental assumption is that NFV functionality is created on >>> the basis of the current hardware catalogue, and is forever fixed, then >>> we have radically different views of what NFV will be. >>> >>> At the end of the day a virtual NF is a computer program running on a >>> device that provides it with a network interface, CPU cycles and >>> storage, an operator can spin up any program they wish on the device >>> that hosts the NF. >>> >>> I think that what you are saying is that softwarization a step forward >>> that allow the dynamic instantiation of general functions to create >>> services, whereas I had assumed that this was always the end-game in >>> NFV >>> and SFC. >>> >>> - Stewart >>> >>> >>> On 07/02/2017 23:50, Pedro Martinez-Julia wrote: >>>> Dear Stewart, >>>> >>>> Find my comments in-line. >>>> >>>> On Tue, Feb 07, 2017 at 06:16:02PM +0000, Stewart Bryant wrote: >>>>>> They can be somehow related but it is not the same concept. Using >>>>>> NFV to illustrate the difference, it defines a set of fixed >>>>>> functions that are virtualized, but the resulting functions are not >>>>>> 100% soft-ware because they resemble the corresponding "hardware", >>>>>> which is quite fixed. >>>>> I don't agree with that. >>>>> >>>>> I can instantiate any function I wish as an NFV function, be it a well >>>>> known function such as a load balancer, or it can be some relatively >>>>> unknown function such as a homomorphic packet timestamper, or it could >>>>> be some function only known to the customer but hosted in the network >>>>> as an opaque function. >>>>> >>>>> I can dynamically provision such functions on CPU and add or remove >>>>> them from a path. >>>>> >>>>> Thus I see no difference between a softwarized system and a system of >>>>> NFV components stitched together with SFC, at least with the >>>>> definition provided above. >>>> As I mentioned in my following paragraph, what you are describing is a >>>> softwarized "infrastructure" composed of non-softwarized functions. >>>> Thus >>>> you are true that they are related, I am not saying the opposite, >>>> but it >>>> is not the same. >>>> >>>> We can say that "NFV is a mechanism to sofwarize the infrastructure >>>> aspects of a network system" but it does not mean that "softwarization >>>> is virtualization" or that "NFV is a subset of softarization". They are >>>> different mechanisms/techniques for purposes that overlap, but only to >>>> some extent. >>>> >>>>>> Taking this into account I would say that NFV is a mechanism for >>>>>> softwarizing a network infrastructure (making it more flexible, >>>>>> programmable, etc.) but it is only limited to the infrastructure >>>>>> boundary because the functions themselves are "hard-fixed" unless >>>>>> they are also softwarized. >>>>> Obviously I don't agree with that. What constrains them to be >>>>> hard-fixed? >>>> I think that Pete's message in this thread gives a better illustration >>>> of the meaning of such "hard-fixed" concept. In summary is that >>>> although >>>> the infrastructure, as I mentioned above, can be programmable >>>> (flexible, >>>> soft-ware), the individual mechanisms that compose do not usually >>>> expose >>>> such degree of programmability. As you mentioned, a homomorphic packet >>>> time stamper or a load balancer, for instance, usually have pre-defined >>>> behaviours which are configurable but not programmable. >>>> >>>> To sum up, I am not arguing that NFV "is not softwarization", just that >>>> softwarization is not virtualization, at least "not just". They can >>>> have >>>> some common goals but the former emphasizes the migration from >>>> pre-fixed >>>> to dynamic *behaviors* while the latter lies in the migration from >>>> fixed >>>> to dynamic *elements* (services, devices, infrastructures). >>>> >>>>> - Stewart >>>> Regards, >>>> Pedro >>>> >>> >>> _______________________________________________ >>> Netslices mailing list >>> Netslices@ietf.org >>> https://www.ietf.org/mailman/listinfo/netslices >>> >>> _______________________________________________ >>> Netslices mailing list >>> Netslices@ietf.org >>> https://www.ietf.org/mailman/listinfo/netslices >> >> _______________________________________________ >> Netslices mailing list >> Netslices@ietf.org >> https://www.ietf.org/mailman/listinfo/netslices > > > > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices --------------F13D8791368427126C0CFF7D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 08/02/17 14:40, Andrew McLachlan wrote:


Networks have always been software driven and also been programable via multiple methods, CLI, SNMP (occasionally), and the myriad of orchestration tools, some open and some not.

Networks themselves are not being re-invented, we are literally going full circle back to using an NMS approach to manage blocks of elements..but today we now call them controllers'.

We are already seeing the impact of moving features from hardware into software now being returned to hardware in order to achieve the performance that is required and to meet the low power consumption requirements.

Yes some services can and should move to a virtual environment, to achieve better scale and faster deployment, but when we start to look at the requirements for latency, path failover and other features needing extremely tight restoration we quickly move back to needing hardware based feature sets to achieve this.

I think we need to ditch this term softwareization, as it is extremely misleading.

Also SDN is really about software driven networks, not defined networking. Networking, services, infrastructure are not defined by software, they are operated by software, via programable interfaces (if available) and or by a controller/NMS layer.

As for Network Slicing, this has been done for years. It might be new in a 5G world, but should not be confused with being something actually new.

The question for this group in the IETF should surely be.. do we need any new protocols or enhancements in this area, bearing in might that most of the glue for E2E will be done at the high orchestration layer.

No.

A.




On 8 Feb 2017, at 14:08, <a.galis@ucl.ac.uk> <a.galis@ucl.ac.uk> wrote:

Hi Javier,

Re: Network Softwarization Vs. Network Slicing

It may be useful for you to consider the context of the term "network softwarization which was coined in the preparation of the IEEE Network Softwarization -NetSoft 2015 conference [13-17 April 2015 hosted by University College London (UCL) in London -http://sites.ieee.org/netsoft2015/]

Network softwarization - it is an overall transformation trend for designing, implementing, deploying, managing and maintaining network equipment and/or network components by software programming, exploiting the natures of software such as flexibility and rapidity all along the lifecycle of network equipment/components, for the sake of creating conditions enabling the re-design of network and services architectures, optimizing costs and processes, enabling self-management and bringing added values in network infrastructures.

In this context Software-Defined Networks (SDN), Network Function Virtualization (NFV), Software-Defined Clouds, Network Virtualization, Network Programmability could be seen as different expressions of network softwarization which would deeply impacting and bridging Telecom and IT industries. This trend is also transforming several other Industries, in using softwarization to optimize costs and processes and in bringing new values in infrastructures. In particular, SDN, NFV and network programmability are creating the conditions to reinvent network and cloud architectures, accelerate service deployment and facilitate infrastructure management.

In practice softwarization would be embedded across all layers and network components by explicitly leveraging programmability of the data, control and management planes.

On the other hand Network Slicing may be viewed as a partitioning of networking where different types of programmability enables could be activated and use. As such it would be practical to envisaged separate and isolated SDN enabled slices, NFV enabled slices, etc.

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

Best Regards

Alex



Professor in Networked and Service Systems
Communications and Information Systems Group
Department of Electronic and Electrical Engineering
University College London
Torrington Place, London WC1E 7JE
United Kingdom

Skype: AlexGalis
Phone +44-20-3108 9441
Mobile +44-7768 493 095
Fax +44-20-7916 0388 /+44-20-7388 9325
Personal Web Page: www.ee.ucl.ac.uk/~agalis

Disclaimer:

The information in this email and in any files transmitted with it is intended only for the addressee and may contain confidential and/or privileged material. Access to this email by anyone else is unauthorized. If you receive this in error, please contact the sender immediately and delete the material from any computer. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is strictly prohibited. Statement and opinions expressed in this e-mail are those of the sender, and do not necessarily reflect those of University College London.




Examples
On 8 Feb 2017, at 11:08, Javier Antich Romaguera <jantich@juniper.net> wrote:
Hi Stewart/all,
I admit may have got lost a bit on the subtleties of the terminology, but from my point of view it is important to emphasize that NFV is one possible mechanism/vehicle for network slicing, but there could be others. If by softwarization we are implying a more general definition, that in some cases may be represented by NFV, and in others may be a different approach, I support that view. We should emphasize on the requirements and how network slicing can address them. NFV seems to me more an example of implementation of network-slicing for certain use cases.

Thanks
Javier.
______________________________________________
Javier Antich Romaguera
Product Line Manager. JUNOS Team.
Juniper Networks
m. +34639218428
Achieving the difficult, trying the impossible"


From: Netslices <netslices-bounces@ietf.org> on behalf of Stewart Bryant <stewart.bryant@gmail.com>
Date: Wednesday, February 8, 2017 at 11:13 AM
To: Pedro Martinez-Julia <pedro@nict.go.jp>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Network Slices <netslices@ietf.org>, AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>, "Kiran.Makhijani" <Kiran.Makhijani@huawei.com>, "Natale, Bob" <RNATALE@mitre.org>, Alex Galis <a.galis@ucl.ac.uk>
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

Pedro

Maybe we start from different positions.

My assumption is that I can create at will a new virtual function, and
instantiate it at will and configure it at will, and create and modify
the SFC chain at will. My further assumption is that we are building
programmatic systems whereby the controls to do the above can be
assessed by someone creating a service and that they can do so in a
programming environment of their choice.

If your fundamental assumption is that NFV functionality is created on
the basis of the current hardware catalogue, and is forever fixed, then
we have radically different views of what NFV will be.

At the end of the day a virtual NF is a computer program running on a
device that provides it with a network interface, CPU cycles and
storage, an operator can spin up any program they wish on the device
that hosts the NF.

I think that what you are saying is that softwarization a step forward
that allow the dynamicinstantiation of general functions to create
services, whereas I had assumed that this was always the end-game in NFV
and SFC.

- Stewart


On 07/02/2017 23:50, Pedro Martinez-Julia wrote:
Dear Stewart,

Find my comments in-line.

On Tue, Feb 07, 2017 at 06:16:02PM +0000, Stewart Bryant wrote:
They can be somehow related but it is not the same concept. Using
NFV to illustrate the difference, it defines a set of fixed
functions that are virtualized, but the resulting functions are not
100% soft-ware because they resemble the corresponding "hardware",
which is quite fixed.
I don't agree with that.

I can instantiate any function I wish as an NFV function, be it a well
known function such as a load balancer, or it can be some relatively
unknown function such as a homomorphic packet timestamper, or it could
be some function only known to the customer but hosted in the network
as an opaque function.

I can dynamically provision such functions on CPU and add or remove
them from a path.

Thus I see no difference between a softwarized system and a system of
NFV components stitched together with SFC, at least with the
definition provided above.
As I mentioned in my following paragraph, what you are describing is a
softwarized "infrastructure" composed of non-softwarized functions. Thus
you are true that they are related, I am not saying the opposite, but it
is not the same.

We can say that "NFV is a mechanism to sofwarize the infrastructure
aspects of a network system" but it does not mean that "softwarization
is virtualization" or that "NFV is a subset of softarization". They are
different mechanisms/techniques for purposes that overlap, but only to
some extent.

Taking this into account I would say that NFV is a mechanism for
softwarizing a network infrastructure (making it more flexible,
programmable, etc.) but it is only limited to the infrastructure
boundary because the functions themselves are "hard-fixed" unless
they are also softwarized.
Obviously I don't agree with that. What constrains them to be
hard-fixed?
I think that Pete's message in this thread gives a better illustration
of the meaning of such "hard-fixed" concept. In summary is that although
the infrastructure, as I mentioned above, can be programmable (flexible,
soft-ware), the individual mechanisms that compose do not usually expose
such degree of programmability. As you mentioned, a homomorphic packet
time stamper or a load balancer, for instance, usually have pre-defined
behaviours which are configurable but not programmable.

To sum up, I am not arguing that NFV "is not softwarization", just that
softwarization is not virtualization, at least "not just". They can have
some common goals but the former emphasizes the migration from pre-fixed
to dynamic *behaviors* while the latter lies in the migration from fixed
to dynamic *elements* (services, devices, infrastructures).

- Stewart
Regards,
Pedro


_______________________________________________
Netslices mailing list
_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices



_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices


--------------F13D8791368427126C0CFF7D-- From nobody Wed Feb 8 07:28:02 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EB8129BB1 for ; Wed, 8 Feb 2017 07:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8gvUPO4zj951 for ; Wed, 8 Feb 2017 07:27:58 -0800 (PST) Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 6E371120724 for ; Wed, 8 Feb 2017 07:27:57 -0800 (PST) Received: by mail-wm0-x243.google.com with SMTP id v77so33700724wmv.0 for ; Wed, 08 Feb 2017 07:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=xt55cWKMPzoxCtG9Tk5ubIv57jdQmFRQNmC4uql5leE=; b=FZ/28v9GJdTX7kfzNFJu+HKefCicI+B6lW+8fkcXFJlFpH5OFsOjHe4Y6tOTJnxs9T 5meKgEUgoic6xQSo1kBzDPFLEQqfrK+5s8kqfmz9Iz1UDOymNjGiWgSjPqCN9AAWTEJB YUwTLLVz1FKZc2Kg3EOdCQhxbrvPOr6+OmnkXMZiuLVZsXwbkO+IGX0ahRyuv+mQJYMA r5EBxilebQNJrZw2zW/SoZfn3NQHEHU4YMEdIP+4LEQAs01SwI+dTiTmWgf90eSLaThd MJbtK+xI0IAoEnFZ7QPW5+K2TcAVA0RCNSRaxSNt/Z22OefwWjL9ZAh05t2E+IR0apVZ uq4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=xt55cWKMPzoxCtG9Tk5ubIv57jdQmFRQNmC4uql5leE=; b=cU9hsC/FYK/edOSigttANcwFfoq+8KtbIjhVUtX6hTGkz6fBNTekfhpL6RHUB67tMy 0AWD1X+ZLdoQ5mOlAyXxLuoQnCeHaHV2zXY7rntVNhUz2H5SeTPqkP3ZBMZb11IgwA6c foKzA/pnds1pJzgDqHO8KeGTqz1KioR+XDnXY44Y/pKOYHM9vx1hLc4aQUfMqalZ0dXl RkvhmuzamFQvmDShGIObWvh0cwRZBwnNKO78eZkmFysbYDuFA2eoWswLdoNl1ZUadve4 n3ExaOLgXROIZQH4qDf2k1v2TfYAUdf42334yIzHal3Gedm+IVTjW5VNsZ26YyMpGyFQ wHNw== X-Gm-Message-State: AMke39niVlnQkRruXuXNjynNpZwks/f1BzZjDG55Athxf3I52MABlbAIeSjQFRu35uAXzw== X-Received: by 10.28.45.197 with SMTP id t188mr19857032wmt.15.1486567675633; Wed, 08 Feb 2017 07:27:55 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id g5sm13623133wrd.0.2017.02.08.07.27.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 07:27:54 -0800 (PST) To: Anton Ivanov , netslices@ietf.org References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> From: Stewart Bryant Message-ID: <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> Date: Wed, 8 Feb 2017 15:27:53 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------30C7B49DAA3331D3CF4FE648" Archived-At: Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:28:00 -0000 This is a multi-part message in MIME format. --------------30C7B49DAA3331D3CF4FE648 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I agree with the points that Andrew makes, and I understand the sentiment in Anton's statement, but am open minded, particularly when it comes to the lower layers. 5G is driving NS and 5G is placing stricter requirements on the lower layers which need to be supported, quite possibly in hardware. On 08/02/2017 14:46, Anton Ivanov wrote: > On 08/02/17 14:40, Andrew McLachlan wrote: >> >> >> Networks have always been software driven and also been programable >> via multiple methods, CLI, SNMP (occasionally), and the myriad of >> orchestration tools, some open and some not. >> We do indeed seem to be going round a very large circle and I don't think any of us know where it will pause its rotation. The original forwarders were s/w on dedicated h/w, then they were s/w on general purpose computers, then they went round a tight circle between micro-code and full h/w, now they are drifting back to s/w on multi-purpose computers, who knows where this will settle and how the network context will drive it. >> Networks themselves are not being re-invented, we are literally going >> full circle back to using an NMS approach to manage blocks of >> elements..but today we now call them controllers'. >> >> We are already seeing the impact of moving features from hardware >> into software now being returned to hardware in order to achieve the >> performance that is required and to meet the low power consumption >> requirements. >> >> Yes some services can and should move to a virtual environment, to >> achieve better scale and faster deployment, but when we start to look >> at the requirements for latency, path failover and other features >> needing extremely tight restoration we quickly move back to needing >> hardware based feature sets to achieve this. >> >> I think we need to ditch this term softwareization, as it is >> extremely misleading. >> >> Also SDN is really about software driven networks, not defined >> networking. Networking, services, infrastructure are not defined by >> software, they are operated by software, via programable interfaces >> (if available) and or by a controller/NMS layer. In a recent seminar, Giles used the term model driven networks, and I think that fits better. Of course the models are driven from both sides of the interface by software, how else would you do it? >> >> As for Network Slicing, this has been done for years. It might be new >> in a 5G world, but should not be confused with being something >> actually new. >> >> The question for this group in the IETF should surely be.. do we need >> any new protocols or enhancements in this area, bearing in might that >> most of the glue for E2E will be done at the high orchestration layer. > > No. > > A. > I am more open minded. We need to be careful not to make gratuitous changes, but I am none the less unconvinced that what we currently have is perfect. - Stewart >> >> >> >>> On 8 Feb 2017, at 14:08, >> > >> > wrote: >>> >>> Hi Javier, >>> >>> Re: Network Softwarization Vs. Network Slicing >>> >>> It may be useful for you to consider the context of the term >>> "network softwarization which was coined in the preparation of the >>> IEEE Network Softwarization -NetSoft 2015 conference [13-17 April >>> 2015 hosted by University College London (UCL) in London - >>> http://sites.ieee.org/netsoft2015/] >>> >>> Network softwarization - it is an overall transformation trend for >>> designing, implementing, deploying, managing and maintaining network >>> equipment and/or network components by software programming, >>> exploiting the natures of software such as flexibility and rapidity >>> all along the lifecycle of network equipment/components, for the >>> sake of creating conditions enabling the re-design of network and >>> services architectures, optimizing costs and processes, enabling >>> self-management and bringing added values in network infrastructures. >>> >>> In this context Software-Defined Networks (SDN), Network Function >>> Virtualization (NFV), Software-Defined Clouds, Network >>> Virtualization, Network Programmability could be seen as different >>> expressions of network softwarization which would deeply impacting >>> and bridging Telecom and IT industries. This trend is also >>> transforming several other Industries, in using softwarization to >>> optimize costs and processes and in bringing new values in >>> infrastructures. In particular, SDN, NFV and network programmability >>> are creating the conditions to reinvent network and cloud >>> architectures, accelerate service deployment and facilitate >>> infrastructure management. >>> >>> In practice softwarization would be embedded across all layers and >>> network components by explicitly leveraging programmability of the >>> data, control and management planes. >>> >>> On the other hand Network Slicing may be viewed as a partitioning of >>> networking where different types of programmability enables could be >>> activated and use. As such it would be practical to envisaged >>> separate and isolated SDN enabled slices, NFV enabled slices, etc. >>> >>> I hope that the above clarification of terms would be of help to you. >>> >>> Best Regards >>> >>> Alex >>> >>> >>> >>> Professor in Networked and Service Systems >>> Communications and Information Systems Group >>> Department of Electronic and Electrical Engineering >>> University College London >>> Torrington Place, London WC1E 7JE >>> United Kingdom >>> >>> Skype: AlexGalis >>> Phone +44-20-3108 9441 >>> Mobile +44-7768 493 095 >>> Fax +44-20-7916 0388 /+44-20-7388 9325 >>> E-mail: a.galis@ucl.ac.uk >>> Personal Web Page: www.ee.ucl.ac.uk/~agalis >>> >>> >>> Disclaimer: >>> >>> The information in this email and in any files transmitted with it >>> is intended only for the addressee and may contain confidential >>> and/or privileged material. Access to this email by anyone else is >>> unauthorized. If you receive this in error, please contact the >>> sender immediately and delete the material from any computer. If you >>> are not the intended recipient, any disclosure, copying, >>> distribution or any action taken or omitted to be taken in reliance >>> on it, is strictly prohibited. Statement and opinions expressed in >>> this e-mail are those of the sender, and do not necessarily reflect >>> those of University College London. >>> >>> >>> >>> >>> Examples >>>> On 8 Feb 2017, at 11:08, Javier Antich Romaguera >>>> > wrote: >>>> >>>> Hi Stewart/all, >>>> I admit may have got lost a bit on the subtleties of the >>>> terminology, but from my point of view it is important to emphasize >>>> that NFV is one possible mechanism/vehicle for network slicing, but >>>> there could be others. If by softwarization we are implying a more >>>> general definition, that in some cases may be represented by NFV, >>>> and in others may be a different approach, I support that view. We >>>> should emphasize on the requirements and how network slicing can >>>> address them. NFV seems to me more an example of implementation of >>>> network-slicing for certain use cases. >>>> >>>> Thanks >>>> Javier. >>>> ______________________________________________ >>>> Javier Antich Romaguera >>>> Product Line Manager. JUNOS Team. >>>> Juniper Networks >>>> email: jantich@juniper.net >>>> m. +34639218428 >>>> Achieving the difficult, trying the impossible" >>>> >>>> >>>> From: Netslices >>> > on behalf of Stewart Bryant >>>> > >>>> Date: Wednesday, February 8, 2017 at 11:13 AM >>>> To: Pedro Martinez-Julia > >>>> Cc: "Dongjie (Jimmy)" >>> >, Network Slices >>> >, AshwoodsmithPeter >>>> >>> >, "Kiran.Makhijani" >>>> >, >>>> "Natale, Bob" >, Alex >>>> Galis > >>>> Subject: Re: [Netslices] Network Slicing - Introductory Document >>>> and Revised Problem Statement >>>> >>>> Pedro >>>> >>>> Maybe we start from different positions. >>>> >>>> My assumption is that I can create at will a new virtual function, and >>>> instantiate it at will and configure it at will, and create and modify >>>> the SFC chain at will. My further assumption is that we are building >>>> programmatic systems whereby the controls to do the above can be >>>> assessed by someone creating a service and that they can do so in a >>>> programming environment of their choice. >>>> >>>> If your fundamental assumption is that NFV functionality is created on >>>> the basis of the current hardware catalogue, and is forever fixed, >>>> then >>>> we have radically different views of what NFV will be. >>>> >>>> At the end of the day a virtual NF is a computer program running on a >>>> device that provides it with a network interface, CPU cycles and >>>> storage, an operator can spin up any program they wish on the device >>>> that hosts the NF. >>>> >>>> I think that what you are saying is that softwarization a step forward >>>> that allow the dynamic instantiation of general functions to create >>>> services, whereas I had assumed that this was always the end-game >>>> in NFV >>>> and SFC. >>>> >>>> - Stewart >>>> >>>> >>>> On 07/02/2017 23:50, Pedro Martinez-Julia wrote: >>>>> Dear Stewart, >>>>> >>>>> Find my comments in-line. >>>>> >>>>> On Tue, Feb 07, 2017 at 06:16:02PM +0000, Stewart Bryant wrote: >>>>>>> They can be somehow related but it is not the same concept. Using >>>>>>> NFV to illustrate the difference, it defines a set of fixed >>>>>>> functions that are virtualized, but the resulting functions are not >>>>>>> 100% soft-ware because they resemble the corresponding "hardware", >>>>>>> which is quite fixed. >>>>>> I don't agree with that. >>>>>> >>>>>> I can instantiate any function I wish as an NFV function, be it a >>>>>> well >>>>>> known function such as a load balancer, or it can be some relatively >>>>>> unknown function such as a homomorphic packet timestamper, or it >>>>>> could >>>>>> be some function only known to the customer but hosted in the network >>>>>> as an opaque function. >>>>>> >>>>>> I can dynamically provision such functions on CPU and add or remove >>>>>> them from a path. >>>>>> >>>>>> Thus I see no difference between a softwarized system and a system of >>>>>> NFV components stitched together with SFC, at least with the >>>>>> definition provided above. >>>>> As I mentioned in my following paragraph, what you are describing is a >>>>> softwarized "infrastructure" composed of non-softwarized >>>>> functions. Thus >>>>> you are true that they are related, I am not saying the opposite, >>>>> but it >>>>> is not the same. >>>>> >>>>> We can say that "NFV is a mechanism to sofwarize the infrastructure >>>>> aspects of a network system" but it does not mean that "softwarization >>>>> is virtualization" or that "NFV is a subset of softarization". >>>>> They are >>>>> different mechanisms/techniques for purposes that overlap, but only to >>>>> some extent. >>>>> >>>>>>> Taking this into account I would say that NFV is a mechanism for >>>>>>> softwarizing a network infrastructure (making it more flexible, >>>>>>> programmable, etc.) but it is only limited to the infrastructure >>>>>>> boundary because the functions themselves are "hard-fixed" unless >>>>>>> they are also softwarized. >>>>>> Obviously I don't agree with that. What constrains them to be >>>>>> hard-fixed? >>>>> I think that Pete's message in this thread gives a better illustration >>>>> of the meaning of such "hard-fixed" concept. In summary is that >>>>> although >>>>> the infrastructure, as I mentioned above, can be programmable >>>>> (flexible, >>>>> soft-ware), the individual mechanisms that compose do not usually >>>>> expose >>>>> such degree of programmability. As you mentioned, a homomorphic packet >>>>> time stamper or a load balancer, for instance, usually have >>>>> pre-defined >>>>> behaviours which are configurable but not programmable. >>>>> >>>>> To sum up, I am not arguing that NFV "is not softwarization", just >>>>> that >>>>> softwarization is not virtualization, at least "not just". They >>>>> can have >>>>> some common goals but the former emphasizes the migration from >>>>> pre-fixed >>>>> to dynamic *behaviors* while the latter lies in the migration from >>>>> fixed >>>>> to dynamic *elements* (services, devices, infrastructures). >>>>> >>>>>> - Stewart >>>>> Regards, >>>>> Pedro >>>>> >>>> >>>> _______________________________________________ >>>> Netslices mailing list >>>> Netslices@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netslices >>>> >>>> _______________________________________________ >>>> Netslices mailing list >>>> Netslices@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netslices >>> >>> _______________________________________________ >>> Netslices mailing list >>> Netslices@ietf.org >>> https://www.ietf.org/mailman/listinfo/netslices >> >> >> >> _______________________________________________ >> Netslices mailing list >> Netslices@ietf.org >> https://www.ietf.org/mailman/listinfo/netslices > > > > > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices --------------30C7B49DAA3331D3CF4FE648 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I agree with the points that Andrew makes, and I understand the sentiment in Anton's statement, but am open minded, particularly when it comes to the lower layers. 5G is driving NS and 5G is placing stricter requirements on the lower layers which need to be supported, quite possibly in hardware.


On 08/02/2017 14:46, Anton Ivanov wrote:
On 08/02/17 14:40, Andrew McLachlan wrote:


Networks have always been software driven and also been programable via multiple methods, CLI, SNMP (occasionally), and the myriad of orchestration tools, some open and some not.

We do indeed seem to be going round a very large circle and I don't think any of us know where it will pause its rotation. The original forwarders were s/w on dedicated h/w, then they were s/w on general purpose computers, then they went round a tight circle between micro-code and full h/w, now they are drifting back to s/w on multi-purpose computers, who knows where this will settle and how the network context will drive it.

Networks themselves are not being re-invented, we are literally going full circle back to using an NMS approach to manage blocks of elements..but today we now call them controllers'.

We are already seeing the impact of moving features from hardware into software now being returned to hardware in order to achieve the performance that is required and to meet the low power consumption requirements.

Yes some services can and should move to a virtual environment, to achieve better scale and faster deployment, but when we start to look at the requirements for latency, path failover and other features needing extremely tight restoration we quickly move back to needing hardware based feature sets to achieve this.

I think we need to ditch this term softwareization, as it is extremely misleading.

Also SDN is really about software driven networks, not defined networking. Networking, services, infrastructure are not defined by software, they are operated by software, via programable interfaces (if available) and or by a controller/NMS layer.

In a recent seminar, Giles used the term model driven networks, and I think that fits better. Of course the models are driven from both sides of the interface by software, how else would you do it?


As for Network Slicing, this has been done for years. It might be new in a 5G world, but should not be confused with being something actually new.

The question for this group in the IETF should surely be.. do we need any new protocols or enhancements in this area, bearing in might that most of the glue for E2E will be done at the high orchestration layer.

No.

A.


I am more open minded. We need to be careful not to make gratuitous changes, but I am none the less unconvinced that what we currently have is perfect.

- Stewart




On 8 Feb 2017, at 14:08, <a.galis@ucl.ac.uk> <a.galis@ucl.ac.uk> wrote:

Hi Javier,

Re: Network Softwarization Vs. Network Slicing

It may be useful for you to consider the context of the term "network softwarization which was coined in the preparation of the IEEE Network Softwarization -NetSoft 2015 conference [13-17 April 2015 hosted by University College London (UCL) in London -http://sites.ieee.org/netsoft2015/]

Network softwarization - it is an overall transformation trend for designing, implementing, deploying, managing and maintaining network equipment and/or network components by software programming, exploiting the natures of software such as flexibility and rapidity all along the lifecycle of network equipment/components, for the sake of creating conditions enabling the re-design of network and services architectures, optimizing costs and processes, enabling self-management and bringing added values in network infrastructures.

In this context Software-Defined Networks (SDN), Network Function Virtualization (NFV), Software-Defined Clouds, Network Virtualization, Network Programmability could be seen as different expressions of network softwarization which would deeply impacting and bridging Telecom and IT industries. This trend is also transforming several other Industries, in using softwarization to optimize costs and processes and in bringing new values in infrastructures. In particular, SDN, NFV and network programmability are creating the conditions to reinvent network and cloud architectures, accelerate service deployment and facilitate infrastructure management.

In practice softwarization would be embedded across all layers and network components by explicitly leveraging programmability of the data, control and management planes.

On the other hand Network Slicing may be viewed as a partitioning of networking where different types of programmability enables could be activated and use. As such it would be practical to envisaged separate and isolated SDN enabled slices, NFV enabled slices, etc.

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

Best Regards

Alex



Professor in Networked and Service Systems
Communications and Information Systems Group
Department of Electronic and Electrical Engineering
University College London
Torrington Place, London WC1E 7JE
United Kingdom

Skype: AlexGalis
Phone +44-20-3108 9441
Mobile +44-7768 493 095
Fax +44-20-7916 0388 /+44-20-7388 9325
Personal Web Page: www.ee.ucl.ac.uk/~agalis

Disclaimer:

The information in this email and in any files transmitted with it is intended only for the addressee and may contain confidential and/or privileged material. Access to this email by anyone else is unauthorized. If you receive this in error, please contact the sender immediately and delete the material from any computer. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is strictly prohibited. Statement and opinions expressed in this e-mail are those of the sender, and do not necessarily reflect those of University College London.




Examples
On 8 Feb 2017, at 11:08, Javier Antich Romaguera <jantich@juniper.net> wrote:
Hi Stewart/all,
I admit may have got lost a bit on the subtleties of the terminology, but from my point of view it is important to emphasize that NFV is one possible mechanism/vehicle for network slicing, but there could be others. If by softwarization we are implying a more general definition, that in some cases may be represented by NFV, and in others may be a different approach, I support that view. We should emphasize on the requirements and how network slicing can address them. NFV seems to me more an example of implementation of network-slicing for certain use cases.

Thanks
Javier.
______________________________________________
Javier Antich Romaguera
Product Line Manager. JUNOS Team.
Juniper Networks
m. +34639218428
Achieving the difficult, trying the impossible"


From: Netslices <netslices-bounces@ietf.org> on behalf of Stewart Bryant <stewart.bryant@gmail.com>
Date: Wednesday, February 8, 2017 at 11:13 AM
To: Pedro Martinez-Julia <pedro@nict.go.jp>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Network Slices <netslices@ietf.org>, AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>, "Kiran.Makhijani" <Kiran.Makhijani@huawei.com>, "Natale, Bob" <RNATALE@mitre.org>, Alex Galis <a.galis@ucl.ac.uk>
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

Pedro

Maybe we start from different positions.

My assumption is that I can create at will a new virtual function, and
instantiate it at will and configure it at will, and create and modify
the SFC chain at will. My further assumption is that we are building
programmatic systems whereby the controls to do the above can be
assessed by someone creating a service and that they can do so in a
programming environment of their choice.

If your fundamental assumption is that NFV functionality is created on
the basis of the current hardware catalogue, and is forever fixed, then
we have radically different views of what NFV will be.

At the end of the day a virtual NF is a computer program running on a
device that provides it with a network interface, CPU cycles and
storage, an operator can spin up any program they wish on the device
that hosts the NF.

I think that what you are saying is that softwarization a step forward
that allow the dynamicinstantiation of general functions to create
services, whereas I had assumed that this was always the end-game in NFV
and SFC.

- Stewart


On 07/02/2017 23:50, Pedro Martinez-Julia wrote:
Dear Stewart,

Find my comments in-line.

On Tue, Feb 07, 2017 at 06:16:02PM +0000, Stewart Bryant wrote:
They can be somehow related but it is not the same concept. Using
NFV to illustrate the difference, it defines a set of fixed
functions that are virtualized, but the resulting functions are not
100% soft-ware because they resemble the corresponding "hardware",
which is quite fixed.
I don't agree with that.

I can instantiate any function I wish as an NFV function, be it a well
known function such as a load balancer, or it can be some relatively
unknown function such as a homomorphic packet timestamper, or it could
be some function only known to the customer but hosted in the network
as an opaque function.

I can dynamically provision such functions on CPU and add or remove
them from a path.

Thus I see no difference between a softwarized system and a system of
NFV components stitched together with SFC, at least with the
definition provided above.
As I mentioned in my following paragraph, what you are describing is a
softwarized "infrastructure" composed of non-softwarized functions. Thus
you are true that they are related, I am not saying the opposite, but it
is not the same.

We can say that "NFV is a mechanism to sofwarize the infrastructure
aspects of a network system" but it does not mean that "softwarization
is virtualization" or that "NFV is a subset of softarization". They are
different mechanisms/techniques for purposes that overlap, but only to
some extent.

Taking this into account I would say that NFV is a mechanism for
softwarizing a network infrastructure (making it more flexible,
programmable, etc.) but it is only limited to the infrastructure
boundary because the functions themselves are "hard-fixed" unless
they are also softwarized.
Obviously I don't agree with that. What constrains them to be
hard-fixed?
I think that Pete's message in this thread gives a better illustration
of the meaning of such "hard-fixed" concept. In summary is that although
the infrastructure, as I mentioned above, can be programmable (flexible,
soft-ware), the individual mechanisms that compose do not usually expose
such degree of programmability. As you mentioned, a homomorphic packet
time stamper or a load balancer, for instance, usually have pre-defined
behaviours which are configurable but not programmable.

To sum up, I am not arguing that NFV "is not softwarization", just that
softwarization is not virtualization, at least "not just". They can have
some common goals but the former emphasizes the migration from pre-fixed
to dynamic *behaviors* while the latter lies in the migration from fixed
to dynamic *elements* (services, devices, infrastructures).

- Stewart
Regards,
Pedro


_______________________________________________
Netslices mailing list
_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices



_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices





_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

--------------30C7B49DAA3331D3CF4FE648-- From nobody Wed Feb 8 07:38:18 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C614E129BBD for ; Wed, 8 Feb 2017 07:38:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 7t1XOa8Ox7IN for ; Wed, 8 Feb 2017 07:38:16 -0800 (PST) Received: from www.kot-begemot.co.uk (ivanoab5.miniserver.com [78.31.111.25]) (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 10433129405 for ; Wed, 8 Feb 2017 07:38:15 -0800 (PST) Received: from tun5.smaug.kot-begemot.co.uk ([192.168.18.6] helo=smaug.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cbUJw-00046v-1j for netslices@ietf.org; Wed, 08 Feb 2017 15:38:12 +0000 Received: from monstrousnightmare.kot-begemot.co.uk ([192.168.11.207]) by smaug.kot-begemot.co.uk with esmtp (Exim 4.84_2) (envelope-from ) id 1cbUJv-0004fM-Qn for netslices@ietf.org; Wed, 08 Feb 2017 15:38:11 +0000 To: netslices@ietf.org References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> From: Anton Ivanov Message-ID: <84a6d967-0b6f-203c-903b-01e493fa5265@kot-begemot.co.uk> Date: Wed, 8 Feb 2017 15:38:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:38:18 -0000 [snip] > >>> >>> As for Network Slicing, this has been done for years. It might be >>> new in a 5G world, but should not be confused with being something >>> actually new. >>> >>> The question for this group in the IETF should surely be.. do we >>> need any new protocols or enhancements in this area, bearing in >>> might that most of the glue for E2E will be done at the high >>> orchestration layer. >> >> No. >> >> A. >> > > I am more open minded. We need to be careful not to make gratuitous > changes, but I am none the less unconvinced that what we currently > have is perfect. IMHO what we have across the various WGs suffices for the needs of mobile, it is more of a question of settling down on a small subset of available candidates which have already been defined, standardized and proven in the field. We also need need to make sure that the chosen candidate(s) will not become obsolete by the time they are standardized in the other mobile organizations. 3GPP has a superb form in choosing archaeological specimens for standardization. Frame Relay for GPRS, ATM for 3G, etc. There is no need to reinvent the wheel unless there is a specific use case and a test case which proves that this is needed. A. From nobody Wed Feb 8 07:52:19 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F96129BF7 for ; Wed, 8 Feb 2017 07:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lucidvision.com 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 4mZ4L7ZdcAe5 for ; Wed, 8 Feb 2017 07:52:15 -0800 (PST) Received: from lucidvision.com (lucidab1.miniserver.com [78.31.106.147]) (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 94850129BF6 for ; Wed, 8 Feb 2017 07:52:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1486569040; bh=hWE4DZVdzPdFnVbz4OD1egn7XLrTS18bOcNZcA+11ew=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=1aKuGK/IgpwxevZlboHwPiBNqUPcNGa5iHiK2bGrrmn0Q16T6If+FIhtx1WD0vgP3 p85mONlgHYIGv0sRr2vwzM2+WON5lZC5RT5qHLEGCqurOB1D1LYkXSI+glempqKUam rUOt+NIk9QTRDo6G9tKlI4rvwPal/XqdF8/E1FAg= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_E201E8C0-1357-4F80-A417-7D20DDDD3254" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Thomas Nadeau In-Reply-To: <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> Date: Wed, 8 Feb 2017 10:51:52 -0500 Message-Id: References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> To: Stewart Bryant X-Mailer: Apple Mail (2.3124) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=3 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 0, First 635, in=4786, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: Anton Ivanov , netslices@ietf.org Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:52:17 -0000 --Apple-Mail=_E201E8C0-1357-4F80-A417-7D20DDDD3254 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Feb 8, 2017:10:27 AM, at 10:27 AM, Stewart Bryant = wrote: >=20 > I agree with the points that Andrew makes, and I understand the = sentiment in Anton's statement, but am open minded, particularly when it = comes to the lower layers. 5G is driving NS and 5G is placing stricter = requirements on the lower layers which need to be supported, quite = possibly in hardware. >=20 > On 08/02/2017 14:46, Anton Ivanov wrote: >> On 08/02/17 14:40, Andrew McLachlan wrote: >>>=20 >>>=20 >>> Networks have always been software driven and also been programable = via multiple methods, CLI, SNMP (occasionally), and the myriad of = orchestration tools, some open and some not. >>>=20 > We do indeed seem to be going round a very large circle and I don't = think any of us know where it will pause its rotation. The original = forwarders were s/w on dedicated h/w, then they were s/w on general = purpose computers, then they went round a tight circle between = micro-code and full h/w, now they are drifting back to s/w on = multi-purpose computers, who knows where this will settle and how the = network context will drive it. >=20 >>> Networks themselves are not being re-invented, we are literally = going full circle back to using an NMS approach to manage blocks of = elements..but today we now call them =91controllers'. >>>=20 >>> We are already seeing the impact of moving features from hardware = into software now being returned to hardware in order to achieve the = performance that is required and to meet the low power consumption = requirements. >>>=20 >>> Yes some services can and should move to a virtual environment, to = achieve better scale and faster deployment, but when we start to look at = the requirements for latency, path failover and other features needing = extremely tight restoration=85 we quickly move back to needing hardware = based feature sets to achieve this. >>>=20 >>> I think we need to ditch this term softwareization, as it is = extremely misleading.=20 >>>=20 >>> Also SDN is really about software driven networks, not defined = networking. Networking, services, infrastructure are not defined by = software, they are operated by software, via programable interfaces (if = available) and or by a controller/NMS layer. >=20 > In a recent seminar, Giles used the term model driven networks, and I = think that fits better. Of course the models are driven from both sides = of the interface by software, how else would you do it? >=20 >>>=20 >>> As for Network Slicing, this has been done for years. It might be = new in a 5G world, but should not be confused with being something = actually new. >>>=20 >>> The question for this group in the IETF should surely be.. do we = need any new protocols or enhancements in this area, bearing in might = that most of the =91glue=92 for E2E will be done at the high = orchestration layer. >>=20 >> No. >>=20 >> A. >>=20 >=20 > I am more open minded. We need to be careful not to make gratuitous = changes, but I am none the less unconvinced that what we currently have = is perfect. >=20 > - Stewart I don=92t believe anyone is saying what we have is perfect by = any means; what you should ask is: is it good enough to achieve the = goals and requirements of network operators? =97Tom >=20 >>> =20 >>>=20 >>>=20 >>>=20 >>>> On 8 Feb 2017, at 14:08, > > wrote: >>>>=20 >>>> Hi Javier,=20 >>>>=20 >>>> Re: Network Softwarization Vs. Network Slicing=20 >>>>=20 >>>> It may be useful for you to consider the context of the term = "network softwarization=94 which was coined in the preparation of the = IEEE Network Softwarization -NetSoft 2015 conference [13-17 April 2015 = hosted by University College London (UCL) in London - = http://sites.ieee.org/netsoft2015/ ] >>>>=20 >>>> Network softwarization - it is an overall transformation trend for = designing, implementing, deploying, managing and maintaining network = equipment and/or network components by software programming, exploiting = the natures of software such as flexibility and rapidity all along the = lifecycle of network equipment/components, for the sake of creating = conditions enabling the re-design of network and services architectures, = optimizing costs and processes, enabling self-management and bringing = added values in network infrastructures.=20 >>>>=20 >>>> In this context Software-Defined Networks (SDN), Network Function = Virtualization (NFV), Software-Defined Clouds, Network Virtualization, = Network Programmability could be seen as different expressions of = network softwarization which would deeply impacting and bridging Telecom = and IT industries. This trend is also transforming several other = Industries, in using =93softwarization=94 to optimize costs and = processes and in bringing new values in infrastructures. In particular, = SDN, NFV and network programmability are creating the conditions to = reinvent network and cloud architectures, accelerate service deployment = and facilitate infrastructure management. >>>>=20 >>>> In practice softwarization would be embedded across all layers and = network components by explicitly leveraging programmability of the data, = control and management planes. >>>>=20 >>>> On the other hand Network Slicing may be viewed as a partitioning = of networking where different types of programmability enables could be = activated and use. As such it would be practical to envisaged separate = and isolated SDN enabled slices, NFV enabled slices, etc. >>>>=20 >>>> I hope that the above clarification of terms would be of help to = you. >>>>=20 >>>> Best Regards >>>>=20 >>>> Alex >>>>=20 >>>> =20 >>>>=20 >>>> Professor in Networked and Service Systems >>>> Communications and Information Systems Group >>>> Department of Electronic and Electrical Engineering =20 >>>> University College London >>>> Torrington Place, London WC1E 7JE >>>> United Kingdom >>>>=20 >>>> Skype: AlexGalis >>>> Phone +44-20-3108 9441 >>>> Mobile +44-7768 493 095 >>>> Fax +44-20-7916 0388 /+44-20-7388 9325 >>>> E-mail: a.galis@ucl.ac.uk >>>> Personal Web Page: www.ee.ucl.ac.uk/~agalis = >>>>=20 >>>> Disclaimer: >>>>=20 >>>> The information in this email and in any files transmitted with it = is intended only for the addressee and may contain confidential and/or = privileged material. Access to this email by anyone else is = unauthorized. If you receive this in error, please contact the sender = immediately and delete the material from any computer. If you are not = the intended recipient, any disclosure, copying, distribution or any = action taken or omitted to be taken in reliance on it, is strictly = prohibited. Statement and opinions expressed in this e-mail are those of = the sender, and do not necessarily reflect those of University College = London. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Examples >>>>> On 8 Feb 2017, at 11:08, Javier Antich Romaguera = > wrote: >>>>>=20 >>>>> Hi Stewart/all,=20 >>>>> I admit may have got lost a bit on the subtleties of the = terminology, but from my point of view it is important to emphasize that = NFV is one possible mechanism/vehicle for network slicing, but there = could be others. If by softwarization we are implying a more general = definition, that in some cases may be represented by NFV, and in others = may be a different approach, I support that view. We should emphasize on = the requirements and how network slicing can address them. NFV seems to = me more an example of implementation of network-slicing for certain use = cases.=20 >>>>>=20 >>>>> Thanks >>>>> Javier. >>>>> =20 >>>>> ______________________________________________ >>>>> Javier Antich Romaguera >>>>> Product Line Manager. JUNOS Team.=20 >>>>> Juniper Networks >>>>> email: jantich@juniper.net >>>>> m. +34639218428 >>>>> =93Achieving the difficult, trying the impossible" >>>>>=20 >>>>>=20 >>>>> From: Netslices > on behalf of Stewart Bryant = > >>>>> Date: Wednesday, February 8, 2017 at 11:13 AM >>>>> To: Pedro Martinez-Julia > >>>>> Cc: "Dongjie (Jimmy)" >, Network Slices >, AshwoodsmithPeter = >, = "Kiran.Makhijani" >, "Natale, Bob" >, Alex Galis > >>>>> Subject: Re: [Netslices] Network Slicing - Introductory Document = and Revised Problem Statement >>>>>=20 >>>>> Pedro >>>>>=20 >>>>> Maybe we start from different positions. >>>>>=20 >>>>> My assumption is that I can create at will a new virtual function, = and >>>>> instantiate it at will and configure it at will, and create and = modify >>>>> the SFC chain at will. My further assumption is that we are = building >>>>> programmatic systems whereby the controls to do the above can be >>>>> assessed by someone creating a service and that they can do so in = a >>>>> programming environment of their choice. >>>>>=20 >>>>> If your fundamental assumption is that NFV functionality is = created on >>>>> the basis of the current hardware catalogue, and is forever fixed, = then >>>>> we have radically different views of what NFV will be. >>>>>=20 >>>>> At the end of the day a virtual NF is a computer program running = on a >>>>> device that provides it with a network interface, CPU cycles and >>>>> storage, an operator can spin up any program they wish on the = device >>>>> that hosts the NF. >>>>>=20 >>>>> I think that what you are saying is that softwarization a step = forward >>>>> that allow the dynamic instantiation of general functions to = create >>>>> services, whereas I had assumed that this was always the end-game = in NFV >>>>> and SFC. >>>>>=20 >>>>> - Stewart >>>>>=20 >>>>>=20 >>>>> On 07/02/2017 23:50, Pedro Martinez-Julia wrote: >>>>>> Dear Stewart, >>>>>>=20 >>>>>> Find my comments in-line. >>>>>>=20 >>>>>> On Tue, Feb 07, 2017 at 06:16:02PM +0000, Stewart Bryant wrote: >>>>>>>> They can be somehow related but it is not the same concept. = Using >>>>>>>> NFV to illustrate the difference, it defines a set of fixed >>>>>>>> functions that are virtualized, but the resulting functions are = not >>>>>>>> 100% soft-ware because they resemble the corresponding = "hardware", >>>>>>>> which is quite fixed. >>>>>>> I don't agree with that. >>>>>>>=20 >>>>>>> I can instantiate any function I wish as an NFV function, be it = a well >>>>>>> known function such as a load balancer, or it can be some = relatively >>>>>>> unknown function such as a homomorphic packet timestamper, or it = could >>>>>>> be some function only known to the customer but hosted in the = network >>>>>>> as an opaque function. >>>>>>>=20 >>>>>>> I can dynamically provision such functions on CPU and add or = remove >>>>>>> them from a path. >>>>>>>=20 >>>>>>> Thus I see no difference between a softwarized system and a = system of >>>>>>> NFV components stitched together with SFC, at least with the >>>>>>> definition provided above. >>>>>> As I mentioned in my following paragraph, what you are describing = is a >>>>>> softwarized "infrastructure" composed of non-softwarized = functions. Thus >>>>>> you are true that they are related, I am not saying the opposite, = but it >>>>>> is not the same. >>>>>>=20 >>>>>> We can say that "NFV is a mechanism to sofwarize the = infrastructure >>>>>> aspects of a network system" but it does not mean that = "softwarization >>>>>> is virtualization" or that "NFV is a subset of softarization". = They are >>>>>> different mechanisms/techniques for purposes that overlap, but = only to >>>>>> some extent. >>>>>>=20 >>>>>>>> Taking this into account I would say that NFV is a mechanism = for >>>>>>>> softwarizing a network infrastructure (making it more flexible, >>>>>>>> programmable, etc.) but it is only limited to the = infrastructure >>>>>>>> boundary because the functions themselves are "hard-fixed" = unless >>>>>>>> they are also softwarized. >>>>>>> Obviously I don't agree with that. What constrains them to be >>>>>>> hard-fixed? >>>>>> I think that Pete's message in this thread gives a better = illustration >>>>>> of the meaning of such "hard-fixed" concept. In summary is that = although >>>>>> the infrastructure, as I mentioned above, can be programmable = (flexible, >>>>>> soft-ware), the individual mechanisms that compose do not usually = expose >>>>>> such degree of programmability. As you mentioned, a homomorphic = packet >>>>>> time stamper or a load balancer, for instance, usually have = pre-defined >>>>>> behaviours which are configurable but not programmable. >>>>>>=20 >>>>>> To sum up, I am not arguing that NFV "is not softwarization", = just that >>>>>> softwarization is not virtualization, at least "not just". They = can have >>>>>> some common goals but the former emphasizes the migration from = pre-fixed >>>>>> to dynamic *behaviors* while the latter lies in the migration = from fixed >>>>>> to dynamic *elements* (services, devices, infrastructures). >>>>>>=20 >>>>>>> - Stewart >>>>>> Regards, >>>>>> Pedro >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Netslices mailing list >>>>> Netslices@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netslices = >>>>>=20 >>>>> _______________________________________________ >>>>> Netslices mailing list >>>>> Netslices@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netslices = >>>>=20 >>>> _______________________________________________ >>>> Netslices mailing list >>>> Netslices@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netslices = >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Netslices mailing list >>> Netslices@ietf.org >>> https://www.ietf.org/mailman/listinfo/netslices = >>=20 >>=20 >>=20 >> _______________________________________________ >> Netslices mailing list >> Netslices@ietf.org >> https://www.ietf.org/mailman/listinfo/netslices = >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices --Apple-Mail=_E201E8C0-1357-4F80-A417-7D20DDDD3254 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Feb 8, 2017:10:27 AM, at 10:27 AM, Stewart Bryant <stewart.bryant@gmail.com> wrote:

=20 =20

I = agree with the points that Andrew makes, and I understand the sentiment in Anton's statement, but am open minded, particularly when it comes to the lower layers. 5G is driving NS and 5G is placing stricter requirements on the lower layers which need to be supported, quite possibly in hardware.


On 08/02/2017 14:46, Anton Ivanov wrote:
On 08/02/17 14:40, Andrew McLachlan wrote:


Networks have always been software driven and = also been programable via multiple methods, CLI, SNMP (occasionally), and the myriad of orchestration tools, some open and some not.

We do indeed seem to be going round a very large circle and I don't think any of us know where it will pause its rotation. The original forwarders were s/w on dedicated h/w, then they were s/w on general purpose computers, then they went round a tight circle between micro-code and full h/w, now they are drifting back to s/w on multi-purpose computers, who knows where this will settle and how the network context will drive it.

Networks themselves are not being re-invented, = we are literally going full circle back to using an NMS approach to manage blocks of elements..but today we now call them =91controllers'.

We are already seeing the impact of moving features from hardware into software now being returned to hardware in order to achieve the performance that is required and to meet the low power consumption requirements.

Yes some services can and should move to a = virtual environment, to achieve better scale and faster deployment, but when we start to look at the requirements for latency, path failover and other features needing extremely tight restoration=85 we quickly move back to needing hardware based feature sets to achieve this.

I think we need to ditch this term softwareization, as it is extremely misleading. 

Also SDN is really about software driven = networks, not defined networking. Networking, services, infrastructure are not defined by software, they are operated by software, via programable interfaces (if available) and or by a controller/NMS layer.

In a recent seminar, Giles used the term model driven networks, and I think that fits better. Of course the models are driven from both sides of the interface by software, how else would you do it?


As for Network Slicing, this has been done for years. It might be new in a 5G world, but should not be confused with being something actually new.

The question for this group in the IETF should surely be.. do we need any new protocols or enhancements in this area, bearing in might that most of the =91glue=92 for = E2E will be done at the high orchestration layer.

No.

A.


I am more open minded. We need to be careful not to make gratuitous changes, but I am none the less unconvinced that what we currently have is perfect.

- Stewart

I don=92t believe anyone is = saying what we have is perfect by any means; what you should ask is: is = it good enough to achieve the goals and requirements of network = operators?

= =97Tom



 



On 8 Feb 2017, at 14:08, <a.galis@ucl.ac.uk> <a.galis@ucl.ac.uk> = wrote:

=

Hi Javier, 

Re: Network Softwarization Vs. Network = Slicing 

It may be useful for you to consider the context of the term "network softwarization=94 which was coined in the preparation of the IEEE Network Softwarization -NetSoft 2015 conference [13-17 April 2015 hosted by University College London (UCL) in London - http://sites.ieee.org/netsoft2015/]

Network softwarization - it is an overall transformation trend for designing, implementing, deploying, managing and maintaining network equipment and/or network components by software programming, exploiting the natures of software such as flexibility and rapidity all along the lifecycle of network equipment/components, for the sake of creating conditions enabling the re-design of network and services architectures, optimizing costs and processes, enabling self-management and bringing added values in network = infrastructures. 

In this context Software-Defined Networks (SDN), Network Function Virtualization (NFV), Software-Defined Clouds, Network Virtualization, Network Programmability could be seen as different expressions of network softwarization which would deeply impacting and bridging Telecom and IT industries. This trend is also transforming several other Industries, in using =93softwarization=94 to optimize costs and processes and in bringing new values in infrastructures. In particular, SDN, NFV and network programmability are creating the conditions to reinvent network and cloud architectures, accelerate service deployment and facilitate infrastructure management.

In practice softwarization would be embedded across all layers and network components by explicitly leveraging programmability of the data, control and management planes.

On the other hand Network Slicing may be viewed as a partitioning of networking where different types of programmability enables could be activated and use. As such it would be practical to envisaged separate and isolated SDN enabled slices, NFV enabled slices, etc.

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

Best Regards

Alex

 

Professor in Networked and Service Systems
Communications and Information Systems Group
Department= of Electronic and Electrical Engineering  
University= College London
Torrington= Place, London WC1E 7JE
United Kingdom

Skype: AlexGalis
Phone +44-20-3108 9441
Mobile +44-7768 493 095
Fax +44-20-7916 0388 /+44-20-7388 9325
E-mail: = a.galis@ucl.ac.uk
Personal Web Page: www.ee.ucl.ac.uk/~agalis

Disclaimer:

The information in this email and in any files transmitted with it is intended only for the addressee and may contain confidential and/or privileged material. Access to this email by anyone else is unauthorized. If you receive this in error, please contact the sender immediately and delete the material from any computer. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is strictly prohibited. Statement and opinions expressed in this e-mail are those of the sender, and do not necessarily reflect those of University College London.




Examples
On 8 Feb 2017, at 11:08, Javier Antich Romaguera = <jantich@juniper.net> wrote:
Hi = Stewart/all, 
   I admit may have got lost a = bit on the subtleties of the terminology, but from my point of view it is important to emphasize that NFV is one possible mechanism/vehicle for network slicing, but there could be others. If by softwarization we are implying a more general definition, that in some cases may be represented by NFV, and in others may be a different approach, I support that view. We should emphasize on the requirements and how network slicing can address them. NFV seems to me more an example of implementation of network-slicing for certain use cases. 

=
Thanks
Javier.
    
______________________________________________
Javier Antich = Romaguera
Product Line = Manager. JUNOS Team. 
Juniper Networks
email: jantich@juniper.net
m. = +34639218428
=93Achieving the difficult, trying the = impossible"

=

=
From: Netslices <netslices-bounces@ietf.org> on behalf of Stewart Bryant <stewart.bryant@gmail.com>
Date: = Wednesday, February 8, 2017 at 11:13 AM
To: Pedro Martinez-Julia <pedro@nict.go.jp>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Network Slices <netslices@ietf.org>, AshwoodsmithPeter <Peter.AshwoodSmith@huawei.com>, "Kiran.Makhijani" <Kiran.Makhijani@huawei.com>, "Natale, Bob" <RNATALE@mitre.org>, Alex Galis <a.galis@ucl.ac.uk>
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

Pedro

Maybe we start from different positions.

My assumption is = that I can create at will a new virtual function, and
instantiate it at = will and configure it at will, and create and modify
the SFC chain at = will. My further assumption is that we are building
programmatic systems whereby the controls to do the above can be
assessed by someone creating a service and that they can do so in a
programming environment of their choice.

If your fundamental assumption is that NFV functionality is created on
the basis of the current hardware catalogue, and is forever fixed, then
we have radically different views of what NFV will be.

At the end of the = day a virtual NF is a computer program running on a
device that provides it with a network interface, CPU cycles and
storage, an operator can spin up any program they wish on the device
that hosts the = NF.

I think that what = you are saying is that softwarization a step forward
that allow the dynamic  instantiation = of general functions to create
services, whereas I had assumed that this was always the end-game in NFV
and SFC.

- Stewart


On 07/02/2017 23:50, Pedro Martinez-Julia wrote:
Dear = Stewart,

Find my comments in-line.

On Tue, Feb 07, = 2017 at 06:16:02PM +0000, Stewart Bryant wrote:
They can be somehow related but it is not the same concept. = Using
NFV to illustrate the difference, it defines a set of = fixed
functions that are virtualized, but the resulting functions are = not
100% soft-ware because they resemble the corresponding = "hardware",
which is quite fixed.
I don't agree = with that.

I can = instantiate any function I wish as an NFV function, be it a well
known function such as a load balancer, or it can be some relatively
unknown function such as a homomorphic packet timestamper, or it could
be some function only known to the customer but hosted in the network
as an opaque function.

I can = dynamically provision such functions on CPU and add or remove
them from a = path.

Thus I see no difference between a softwarized system and a system of
NFV components stitched together with SFC, at least with the
definition provided above.
As I mentioned in = my following paragraph, what you are describing is a
softwarized "infrastructure" composed of non-softwarized functions. = Thus
you are true that they are related, I am not saying the opposite, but = it
is not the = same.

We can say that = "NFV is a mechanism to sofwarize the infrastructure
aspects of a = network system" but it does not mean that "softwarization
is virtualization" or that "NFV is a subset of softarization". They are
different mechanisms/techniques for purposes that overlap, but only to
some extent.

Taking this = into account I would say that NFV is a mechanism for
softwarizing a network infrastructure (making it more = flexible,
programmable, etc.) but it is only limited to the infrastructure
boundary = because the functions themselves are "hard-fixed" unless
they are also softwarized.
Obviously I = don't agree with that. What constrains them to be
hard-fixed?
I think that = Pete's message in this thread gives a better illustration
of the meaning of such "hard-fixed" concept. In summary is that although
the = infrastructure, as I mentioned above, can be programmable (flexible,
soft-ware), the individual mechanisms that compose do not usually = expose
such degree of programmability. As you mentioned, a homomorphic = packet
time stamper or a load balancer, for instance, usually have pre-defined
behaviours which = are configurable but not programmable.

To sum up, I am = not arguing that NFV "is not softwarization", just that
softwarization is not virtualization, at least "not just". They can have
some common goals but the former emphasizes the migration from pre-fixed
to dynamic *behaviors* while the latter lies in the migration from = fixed
to dynamic *elements* (services, devices, infrastructures).

- Stewart
Regards,
Pedro


_______________________________________________
Netslices mailing = list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices
_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.= org/mailman/listinfo/netslices



_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.=
org/mailman/listinfo/netslices





_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.=
org/mailman/listinfo/netslices

_______________________________________________
Netslices = mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

= --Apple-Mail=_E201E8C0-1357-4F80-A417-7D20DDDD3254-- From nobody Wed Feb 8 07:59:20 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50944129BFF for ; Wed, 8 Feb 2017 07:59:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8FAY8ArT6tKb for ; Wed, 8 Feb 2017 07:59:18 -0800 (PST) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 0C43D129BFE for ; Wed, 8 Feb 2017 07:59:18 -0800 (PST) Received: by mail-wm0-x242.google.com with SMTP id c85so33944180wmi.1 for ; Wed, 08 Feb 2017 07:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=iZ/EwyZQUZLPZGPKu8RkPSiybIB8TwsSSRO3DVP6ZcU=; b=nrMiE+p6aAsICZRaY8BsfUR5m38TfuDggxepO+M8NotIW/CpnYnE4kad7NVOeb7pby 2EVre1OkwF7ufBh2yPr8548i5pS1MPmKMkwGoP3+1n47iIHVw+T2sM4MFmG47QlemzQU 22JoAZzLYodU97tpqa3iJQsNSdQxtIfZFIYf0ibXNLd37p+S4WR3DpzLhVymIQY1n5kw ra8tY+qouw4IkkPM7i0aidXkMUXvFgnlI0JRofCCeDIVD/czFjKZZ6v/nprvTghAUBlc DbK1fkEHmTf9lu9k8lJzyT9ak0z4PsWOQSsGy+9Qb45MMFDnk8JU5aM172y4ItjAJ1C0 S3og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=iZ/EwyZQUZLPZGPKu8RkPSiybIB8TwsSSRO3DVP6ZcU=; b=Fv27r8cZWdo5ColsAYnfzvNTrfNTtvAge5/174plLhaEwHMS2fnkKAnCKiGqmfOn9h hXtkgVFSlRRCH4e7zcLlL0SRkogrS52xggMB0VlXIIZoULlVHUHKF2995vpSeQGQOStN bXhiDNVVRFm3ogHHWlGXucmXIMX9C1T7uFNe0ca6d5Cpe4QK9PR7cCBEMXnsaFuqlr9t B8RVjkK/dXxniyZByEnGGAWk+kecO1zvG6lqo6/d1YKnDf6k7fE5RGN6519wBepD+aS5 N/Ap/7W6Tg5syjRVN0Xs9tHPfStsFuJDG7JMy+TRJVmHK6EOcXm96f0NFW1vMuWN9rQv a5gQ== X-Gm-Message-State: AMke39loFSPt67UjBiRTGCnoGwH82mmq3DeG9POg83LjyC1iDRkO4kgSAZCv6dhL/aznQw== X-Received: by 10.28.232.91 with SMTP id f88mr17502845wmh.27.1486569556224; Wed, 08 Feb 2017 07:59:16 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id b15sm13685128wra.4.2017.02.08.07.59.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Feb 2017 07:59:15 -0800 (PST) To: Thomas Nadeau References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> From: Stewart Bryant Message-ID: <37956fc6-5f3e-bc54-4411-63721d5a299a@gmail.com> Date: Wed, 8 Feb 2017 15:59:13 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------364FC2D45EE7ADDF990C3301" Archived-At: Cc: Anton Ivanov , netslices@ietf.org Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 15:59:19 -0000 This is a multi-part message in MIME format. --------------364FC2D45EE7ADDF990C3301 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 08/02/2017 15:51, Thomas Nadeau wrote: > I dont believe anyone is saying what we have is perfect by any means; > what you should ask is: is it good enough to achieve the goals and > requirements of network operators? > > Tom Agreed, and assuming the delay jitter and isolation requirements hold up, I think these need new work. People with experience on controller systems and models are better placed to consider whether this is a good enough fit for the requirements that have been expressed by the mobile operators. - Stewart --------------364FC2D45EE7ADDF990C3301 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 08/02/2017 15:51, Thomas Nadeau wrote:
I dont believe anyone is saying what we have is perfect by any means; what you should ask is: is it good enough to achieve the goals and requirements of network operators?

Tom

Agreed, and assuming the delay jitter and isolation requirements hold up, I think these need new work.

People with experience on controller systems and models are better placed to consider whether this is a good enough fit for the requirements that have been expressed by the mobile operators.

- Stewart
--------------364FC2D45EE7ADDF990C3301-- From nobody Wed Feb 8 08:21:24 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6ECC129C2D for ; Wed, 8 Feb 2017 08:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 U1X4xyAkW6qh for ; Wed, 8 Feb 2017 08:21:21 -0800 (PST) Received: from www.kot-begemot.co.uk (ivanoab5.miniserver.com [78.31.111.25]) (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 9F3F6129C2A for ; Wed, 8 Feb 2017 08:21:21 -0800 (PST) Received: from tun5.smaug.kot-begemot.co.uk ([192.168.18.6] helo=smaug.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cbUze-0004DD-QB for netslices@ietf.org; Wed, 08 Feb 2017 16:21:18 +0000 Received: from monstrousnightmare.kot-begemot.co.uk ([192.168.11.207]) by smaug.kot-begemot.co.uk with esmtp (Exim 4.84_2) (envelope-from ) id 1cbUze-00054L-IT for netslices@ietf.org; Wed, 08 Feb 2017 16:21:18 +0000 To: netslices@ietf.org References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> <37956fc6-5f3e-bc54-4411-63721d5a299a@gmail.com> From: Anton Ivanov Message-ID: Date: Wed, 8 Feb 2017 16:21:16 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <37956fc6-5f3e-bc54-4411-63721d5a299a@gmail.com> Content-Type: multipart/alternative; boundary="------------19CF48BB31C2989F497840DC" X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 16:21:23 -0000 This is a multi-part message in MIME format. --------------19CF48BB31C2989F497840DC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 08/02/17 15:59, Stewart Bryant wrote: > > > > On 08/02/2017 15:51, Thomas Nadeau wrote: >> I dont believe anyone is saying what we have is perfect by any >> means; what you should ask is: is it good enough to achieve the goals >> and requirements of network operators? >> >> Tom > > Agreed, and assuming the delay jitter and isolation requirements hold > up, I think these need new work. > > People with experience on controller systems and models are better > placed to consider whether this is a good enough fit for the > requirements that have been expressed by the mobile operators. My exact point - as someone who works on various software aspects related to this. I would like to see a negative test case proving that what is currently available is insufficient. More importantly, I would like to see quantifiable negative test case - the stuff which we presently have on offer is off by X us (or ms), Y Gbit, Z size of address space of particular type, etc. We can generate the requirements based on the difference (if such difference can be demonstrated) and work on the gap from that point onwards. If there is no negative test case showing a clear quantifiable deficiency in the standards and architectures presently available across the IETF and the other standard bodies, then..., well..., we are back to my original answer: "No". A. > > - Stewart > > > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices --------------19CF48BB31C2989F497840DC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 08/02/17 15:59, Stewart Bryant wrote:



On 08/02/2017 15:51, Thomas Nadeau wrote:
I dont believe anyone is saying what we have is perfect by any means; what you should ask is: is it good enough to achieve the goals and requirements of network operators?

Tom

Agreed, and assuming the delay jitter and isolation requirements hold up, I think these need new work.

People with experience on controller systems and models are better placed to consider whether this is a good enough fit for the requirements that have been expressed by the mobile operators.

My exact point - as someone who works on various software aspects related to this. I would like to see a negative test case proving that what is currently available is insufficient.

More importantly, I would like to see quantifiable negative test case - the stuff which we presently have on offer is off by X us (or ms), Y Gbit, Z size of address space of particular type, etc.

We can generate the requirements based on the difference (if such difference can be demonstrated) and work on the gap from that point onwards.

If there is no negative test case showing a clear quantifiable deficiency in the standards and architectures presently available across the IETF and the other standard bodies, then..., well..., we are back to my original answer: "No".

A.


- Stewart


_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices


--------------19CF48BB31C2989F497840DC-- From nobody Wed Feb 8 15:51:42 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3CB1295AD for ; Wed, 8 Feb 2017 15:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 3XqbtCow9rDu for ; Wed, 8 Feb 2017 15:51:38 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89947129581 for ; Wed, 8 Feb 2017 15:51:38 -0800 (PST) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id v18NpZOA057923; Thu, 9 Feb 2017 08:51:35 +0900 (JST) Received: from mail2.nict.go.jp (mail2.nict.go.jp [133.243.18.15]) by gw1.nict.go.jp with ESMTP id v18NpZqf057920; Thu, 9 Feb 2017 08:51:35 +0900 (JST) Received: from spectre (unknown [133.243.115.68]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.nict.go.jp (NICT Mail Spool Server2) with ESMTPS id 4E4C19162; Thu, 9 Feb 2017 08:51:35 +0900 (JST) Date: Thu, 9 Feb 2017 08:51:34 +0900 From: Pedro Martinez-Julia To: Stewart Bryant Message-ID: <20170208235134.GA12800@spectre> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <86e9ff35-50c3-895b-9e49-910f3745e234@pi.nu> <20170208041658.GW12800@spectre> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-Virus-Scanned: clamav-milter 0.98.7 at zenith1 X-Virus-Status: Clean Archived-At: Cc: "Smith, Kevin, \(R&D\) Vodafone Group" , "netslices@ietf.org" , Loa Andersson Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 23:51:41 -0000 On Wed, Feb 08, 2017 at 10:33:05AM +0000, Stewart Bryant wrote: > On 08/02/2017 04:16, Pedro Martinez-Julia wrote: > > On Wed, Feb 08, 2017 at 11:51:16AM +0800, Loa Andersson wrote: > > > So we have a BIG and resourceful network, from which we can cut > > > slices in such a way that a particular slice may serve a > > > particular network user exactly as a purpose built network woud? > > This is a key definition for network slicing. However, we have also > > to consider two different manners to provision such slices: > > > > - That the slice is provided "as a set of resources" (which would be > > most probably virtual) without being pre-configured. This way, the > > user is responsible of the management of such resources to form and > > control/manage its infrastructure. > > So what you are saying here is that one organization sells bit pipes, > compute cycles and storage. A second organization loads software of > its choosing that consumes those compute cycles and bit pipes, and > this is sold to a third organization as a bespoke service? > > So at the lower layer this is in essence what DC providers already > provide but with tight SLA on the compute cycles and data paths? > > Applied to the cellular market this includes a wireless component, but > in the general case it applies to any last mile technology. > > Is that correct? It is. However, the objective of my position is to push the flexible and even genericity into the definition of "slice", surrounded by the needed functions to implement such aspects when delivering slices. > > - That the slice is provided as an infrastructure for a specific > > purpose requested by the user. The provider is responsible of the > > management of both the underlying and overlaying infrastructures and > > the user is limited to consume it and make any management-related > > request to the provider. > > Doesn't this describe the normal VPN business model updated with > virtual functions? If you limit the infrastructure to connectivity, yes. But, as I mention above, this manner only shows the flexibility of slices. Thus, a VPN can be seen as "a slice consisting on connectivity with some properties" but it does NOT mean that "a slice is a VPN" :-D. Regards, Pedro -- Pedro Martinez-Julia Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: pedro@nict.go.jp --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** From nobody Wed Feb 8 15:56:34 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D99129539 for ; Wed, 8 Feb 2017 15:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 pkUBPpncJINF for ; Wed, 8 Feb 2017 15:56:29 -0800 (PST) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id 74CC5129533 for ; Wed, 8 Feb 2017 15:56:29 -0800 (PST) Received: from gw2.nict.go.jp (gw2.nict.go.jp [133.243.18.251]) by ns2.nict.go.jp with ESMTP id v18NuL0f003371; Thu, 9 Feb 2017 08:56:21 +0900 (JST) Received: from mail2.nict.go.jp (mail2.nict.go.jp [133.243.18.15]) by gw2.nict.go.jp with ESMTP id v18NuL5w003368; Thu, 9 Feb 2017 08:56:21 +0900 (JST) Received: from spectre (unknown [133.243.115.68]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail2.nict.go.jp (NICT Mail Spool Server2) with ESMTPS id 6EAF891F0; Thu, 9 Feb 2017 08:56:21 +0900 (JST) Date: Thu, 9 Feb 2017 08:56:20 +0900 From: Pedro Martinez-Julia To: Stewart Bryant Message-ID: <20170208235620.GB12800@spectre> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> User-Agent: Mutt/1.7.1 (2016-10-04) X-Virus-Scanned: clamav-milter 0.98.7 at zenith2 X-Virus-Status: Clean Archived-At: Cc: "Dongjie \(Jimmy\)" , Network Slices , AshwoodsmithPeter , "Kiran.Makhijani" , "Natale, Bob" , Alex Galis Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2017 23:56:31 -0000 On Wed, Feb 08, 2017 at 10:13:26AM +0000, Stewart Bryant wrote: > Pedro Dear Stewart, > Maybe we start from different positions. > > My assumption is that I can create at will a new virtual function, and > instantiate it at will and configure it at will, and create and modify > the SFC chain at will. My further assumption is that we are building > programmatic systems whereby the controls to do the above can be > assessed by someone creating a service and that they can do so in a > programming environment of their choice. > > If your fundamental assumption is that NFV functionality is created on > the basis of the current hardware catalogue, and is forever fixed, > then we have radically different views of what NFV will be. > > At the end of the day a virtual NF is a computer program running on a > device that provides it with a network interface, CPU cycles and > storage, an operator can spin up any program they wish on the device > that hosts the NF. > > I think that what you are saying is that softwarization a step forward > that allow the dynamic instantiation of general functions to create > services, whereas I had assumed that this was always the end-game in > NFV and SFC. In summary you are true, we started from different positions. Although I understand you view of NFV/SFC in the long term, the reality is that you cannot match it with softwarization. As it has been mentioned before and in other threads, NFV is a particularization of softwarization, but as I also mentioned, that depends on the scope and level of programmability that the VNF you are instantiating provides. Nevertheless, as it ensures flexibility, we can assume that it can be true for all layers of NFV, regardless of that the VNF is fixed (e.g. simple L2 learning switch) or more dynamic (e.g. OpenFlow switch). > - Stewart Regards, Pedro -- Pedro Martinez-Julia Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: pedro@nict.go.jp --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** From nobody Wed Feb 8 16:55:51 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89E911294C8 for ; Wed, 8 Feb 2017 16:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Zr8adSpK7Jut for ; Wed, 8 Feb 2017 16:55:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94C131293FC for ; Wed, 8 Feb 2017 16:55:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGB99402; Thu, 09 Feb 2017 00:55:44 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 9 Feb 2017 00:55:43 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Wed, 8 Feb 2017 16:55:38 -0800 From: "Kiran.Makhijani" To: Anton Ivanov , "netslices@ietf.org" Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvq86lUQQ6X0fEWhV+RYwp29OaFcmRmAgACPBICAACsogIAASScAgAAJHACAANcZAIAAXXSAgACuCgCAAA9qAIAAMmaAgAAIxwCAAAHDAIAAC4GAgAAGtACAAAIOgIAABikAgAAJmgA= Date: Thu, 9 Feb 2017 00:55:37 +0000 Message-ID: <85570854-8C8B-4D06-81BD-2BDB2BDA7DB3@huawei.com> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> <37956fc6-5f3e-bc54-4411-63721d5a299a@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.200] Content-Type: multipart/alternative; boundary="_000_855708548C8B4D0681BD2BDB2BDA7DB3huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.589BBE11.003E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e11c4844924cfc89b2e8e347351acc1c Archived-At: Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 00:55:49 -0000 --_000_855708548C8B4D0681BD2BDB2BDA7DB3huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgZXhhY3QgcG9pbnQgLSBhcyBzb21lb25lIHdobyB3b3JrcyBvbiB2YXJpb3VzIHNvZnR3YXJl IGFzcGVjdHMgcmVsYXRlZCB0byB0aGlzLiBJIHdvdWxkIGxpa2UgdG8gc2VlIGEgbmVnYXRpdmUg dGVzdCBjYXNlIHByb3ZpbmcgdGhhdCB3aGF0IGlzIGN1cnJlbnRseSBhdmFpbGFibGUgaXMgaW5z dWZmaWNpZW50Lg0KXl5eXl5eXg0KSGkgQW50b24sDQpJdCBpcyBhbHNvIGltcG9ydGFudCB0byBj b25zaWRlciBlZmZpY2llbmN5IG9mIGN1cnJlbnQgc29sdXRpb25zLiBUaGUgZGVncmVlIG9mIGN1 c3RvbWl6YXRpb24gYW50aWNpcGF0ZWQgZm9yIDVnIGFuZCBzbGljaW5nIHdpbGwgYmUgbXVjaCBo aWdoZXIuIE5TIHNob3VsZCBiZSBsb29rZWQgYXQgYXMgYSBsZWFuIG5ldHdvcmsgaW5mcmFzdHJ1 Y3R1cmUgZnJvbSB0b3AtZG93biBhbmQgZTJlIGluIHRlcm1zIG9mIG1pbmltaXppbmcgb3Zlcmhl YWRzIGFsbCBhY3Jvc3MgKGluIGNvbmZpZ3MsIHByb3RvY29scywgbWdtdC4sIE9TU+KApikgYW5k IHN0cmljdGx5IGlzb2xhdGluZyBwYXJ0aXRpb25lZC1yZXNvdXJjZXMgZnJvbSBlYWNoIG90aGVy Lg0KDQpSZWdhcmRzDQpLaXJhbg0KDQpGcm9tOiBOZXRzbGljZXMgPG5ldHNsaWNlcy1ib3VuY2Vz QGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQW50b24gSXZhbm92IDxhbnRvbi5pdmFub3ZAa290LWJl Z2Vtb3QuY28udWs+DQpEYXRlOiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDgsIDIwMTcgYXQgODoyMSBB TQ0KVG86ICJuZXRzbGljZXNAaWV0Zi5vcmciIDxuZXRzbGljZXNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW05ldHNsaWNlc10gTmV0d29yayBTbGljaW5nIC0gSW50cm9kdWN0b3J5IERvY3VtZW50 IGFuZCBSZXZpc2VkIFByb2JsZW0gU3RhdGVtZW50DQoNCk9uIDA4LzAyLzE3IDE1OjU5LCBTdGV3 YXJ0IEJyeWFudCB3cm90ZToNCg0KDQoNCk9uIDA4LzAyLzIwMTcgMTU6NTEsIFRob21hcyBOYWRl YXUgd3JvdGU6DQpJIGRvbuKAmXQgYmVsaWV2ZSBhbnlvbmUgaXMgc2F5aW5nIHdoYXQgd2UgaGF2 ZSBpcyBwZXJmZWN0IGJ5IGFueSBtZWFuczsgd2hhdCB5b3Ugc2hvdWxkIGFzayBpczogaXMgaXQg Z29vZCBlbm91Z2ggdG8gYWNoaWV2ZSB0aGUgZ29hbHMgYW5kIHJlcXVpcmVtZW50cyBvZiBuZXR3 b3JrIG9wZXJhdG9ycz8NCg0K4oCUVG9tDQoNCkFncmVlZCwgYW5kIGFzc3VtaW5nIHRoZSBkZWxh eSBqaXR0ZXIgYW5kIGlzb2xhdGlvbiByZXF1aXJlbWVudHMgaG9sZCB1cCwgSSB0aGluayB0aGVz ZSBuZWVkIG5ldyB3b3JrLg0KDQpQZW9wbGUgIHdpdGggZXhwZXJpZW5jZSBvbiBjb250cm9sbGVy IHN5c3RlbXMgYW5kIG1vZGVscyBhcmUgYmV0dGVyIHBsYWNlZCB0byBjb25zaWRlciB3aGV0aGVy IHRoaXMgaXMgYSBnb29kIGVub3VnaCBmaXQgZm9yIHRoZSByZXF1aXJlbWVudHMgdGhhdCBoYXZl IGJlZW4gZXhwcmVzc2VkIGJ5IHRoZSBtb2JpbGUgb3BlcmF0b3JzLg0KDQpNeSBleGFjdCBwb2lu dCAtIGFzIHNvbWVvbmUgd2hvIHdvcmtzIG9uIHZhcmlvdXMgc29mdHdhcmUgYXNwZWN0cyByZWxh dGVkIHRvIHRoaXMuIEkgd291bGQgbGlrZSB0byBzZWUgYSBuZWdhdGl2ZSB0ZXN0IGNhc2UgcHJv dmluZyB0aGF0IHdoYXQgaXMgY3VycmVudGx5IGF2YWlsYWJsZSBpcyBpbnN1ZmZpY2llbnQuDQoN Ck1vcmUgaW1wb3J0YW50bHksIEkgd291bGQgbGlrZSB0byBzZWUgcXVhbnRpZmlhYmxlIG5lZ2F0 aXZlIHRlc3QgY2FzZSAtIHRoZSBzdHVmZiB3aGljaCB3ZSBwcmVzZW50bHkgaGF2ZSBvbiBvZmZl ciBpcyBvZmYgYnkgWCB1cyAob3IgbXMpLCBZIEdiaXQsIFogc2l6ZSBvZiBhZGRyZXNzIHNwYWNl IG9mICBwYXJ0aWN1bGFyIHR5cGUsIGV0Yy4NCg0KV2UgY2FuIGdlbmVyYXRlIHRoZSByZXF1aXJl bWVudHMgYmFzZWQgb24gdGhlIGRpZmZlcmVuY2UgKGlmIHN1Y2ggZGlmZmVyZW5jZSBjYW4gYmUg ZGVtb25zdHJhdGVkKSBhbmQgd29yayBvbiB0aGUgZ2FwIGZyb20gdGhhdCBwb2ludCBvbndhcmRz Lg0KDQpJZiB0aGVyZSBpcyBubyBuZWdhdGl2ZSB0ZXN0IGNhc2Ugc2hvd2luZyBhIGNsZWFyIHF1 YW50aWZpYWJsZSBkZWZpY2llbmN5IGluIHRoZSBzdGFuZGFyZHMgYW5kIGFyY2hpdGVjdHVyZXMg cHJlc2VudGx5IGF2YWlsYWJsZSBhY3Jvc3MgdGhlIElFVEYgYW5kIHRoZSBvdGhlciBzdGFuZGFy ZCBib2RpZXMsIHRoZW4uLi4sIHdlbGwuLi4sIHdlIGFyZSBiYWNrIHRvIG15IG9yaWdpbmFsIGFu c3dlcjogIk5vIi4NCg0KQS4NCg0KDQoNCi0gU3Rld2FydA0KDQoNCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpOZXRzbGljZXMgbWFpbGluZyBs aXN0DQoNCk5ldHNsaWNlc0BpZXRmLm9yZzxtYWlsdG86TmV0c2xpY2VzQGlldGYub3JnPg0KDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldHNsaWNlcw0KDQoNCg== --_000_855708548C8B4D0681BD2BDB2BDA7DB3huaweicom_ Content-Type: text/html; charset="utf-8" Content-ID: <0091F7509574EB4D88067930CA350153@huawei.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvdXJp ZXI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5z DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpDYWxpYnJpIj5NeSBleGFjdCBwb2ludCAtIGFzIHNvbWVvbmUgd2hvIHdvcmtzIG9uIHZh cmlvdXMgc29mdHdhcmUgYXNwZWN0cyByZWxhdGVkIHRvIHRoaXMuIEkgd291bGQgbGlrZSB0byBz ZWUgYSBuZWdhdGl2ZSB0ZXN0IGNhc2UgcHJvdmluZyB0aGF0IHdoYXQgaXMgY3VycmVudGx5IGF2 YWlsYWJsZSBpcyBpbnN1ZmZpY2llbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSI+Xl5eXl5eXjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkhpIEFu dG9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkl0IGlzIGFsc28gaW1w b3J0YW50IHRvIGNvbnNpZGVyIGVmZmljaWVuY3kgb2YgY3VycmVudCBzb2x1dGlvbnMuIFRoZSBk ZWdyZWUgb2YgY3VzdG9taXphdGlvbiBhbnRpY2lwYXRlZCBmb3IgNWcgYW5kIHNsaWNpbmcgd2ls bCBiZSBtdWNoIGhpZ2hlci4gTlMgc2hvdWxkIGJlIGxvb2tlZCBhdCBhcyBhIGxlYW4gbmV0d29y aw0KIGluZnJhc3RydWN0dXJlIGZyb20gdG9wLWRvd24gYW5kIGUyZSBpbiB0ZXJtcyBvZiBtaW5p bWl6aW5nIG92ZXJoZWFkcyBhbGwgYWNyb3NzIChpbiBjb25maWdzLCBwcm90b2NvbHMsIG1nbXQu LCBPU1PigKYpIGFuZCBzdHJpY3RseSBpc29sYXRpbmcgcGFydGl0aW9uZWQtcmVzb3VyY2VzIGZy b20gZWFjaCBvdGhlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtjb2xvcjpibGFj ayI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTtj b2xvcjpibGFjayI+S2lyYW4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJp Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJy aTtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5OZXRzbGljZXMgJmx0O25ldHNsaWNlcy1ib3VuY2VzQGll dGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgQW50b24gSXZhbm92ICZsdDthbnRvbi5pdmFub3ZAa290 LWJlZ2Vtb3QuY28udWsmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPldlZG5lc2RheSwgRmVicnVhcnkg OCwgMjAxNyBhdCA4OjIxIEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtuZXRzbGljZXNAaWV0Zi5v cmcmcXVvdDsgJmx0O25ldHNsaWNlc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ UmU6IFtOZXRzbGljZXNdIE5ldHdvcmsgU2xpY2luZyAtIEludHJvZHVjdG9yeSBEb2N1bWVudCBh bmQgUmV2aXNlZCBQcm9ibGVtIFN0YXRlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDgvMDIvMTcgMTU6NTksIFN0ZXdh cnQgQnJ5YW50IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMDgvMDIvMjAxNyAxNTo1MSwgVGhvbWFzIE5h ZGVhdSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBkb27igJl0IGJlbGlldmUgYW55b25lIGlzIHNheWluZyB3aGF0IHdlIGhhdmUg aXMgcGVyZmVjdCBieSBhbnkgbWVhbnM7IHdoYXQgeW91IHNob3VsZCBhc2sgaXM6IGlzIGl0IGdv b2QgZW5vdWdoIHRvIGFjaGlldmUgdGhlIGdvYWxzIGFuZCByZXF1aXJlbWVudHMgb2YgbmV0d29y ayBvcGVyYXRvcnM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPuKAlFRvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpBZ3JlZWQsIGFuZCBhc3N1bWluZyB0aGUgZGVsYXkg aml0dGVyIGFuZCBpc29sYXRpb24gcmVxdWlyZW1lbnRzIGhvbGQgdXAsIEkgdGhpbmsgdGhlc2Ug bmVlZCBuZXcgd29yay48YnI+DQo8YnI+DQpQZW9wbGUmbmJzcDsgd2l0aCBleHBlcmllbmNlIG9u IGNvbnRyb2xsZXIgc3lzdGVtcyBhbmQgbW9kZWxzIGFyZSBiZXR0ZXIgcGxhY2VkIHRvIGNvbnNp ZGVyIHdoZXRoZXIgdGhpcyBpcyBhIGdvb2QgZW5vdWdoIGZpdCBmb3IgdGhlIHJlcXVpcmVtZW50 cyB0aGF0IGhhdmUgYmVlbiBleHByZXNzZWQgYnkgdGhlIG1vYmlsZSBvcGVyYXRvcnMuPG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpNeSBl eGFjdCBwb2ludCAtIGFzIHNvbWVvbmUgd2hvIHdvcmtzIG9uIHZhcmlvdXMgc29mdHdhcmUgYXNw ZWN0cyByZWxhdGVkIHRvIHRoaXMuIEkgd291bGQgbGlrZSB0byBzZWUgYSBuZWdhdGl2ZSB0ZXN0 IGNhc2UgcHJvdmluZyB0aGF0IHdoYXQgaXMgY3VycmVudGx5IGF2YWlsYWJsZSBpcyBpbnN1ZmZp Y2llbnQuPGJyPg0KPGJyPg0KTW9yZSBpbXBvcnRhbnRseSwgSSB3b3VsZCBsaWtlIHRvIHNlZSBx dWFudGlmaWFibGUgbmVnYXRpdmUgdGVzdCBjYXNlIC0gdGhlIHN0dWZmIHdoaWNoIHdlIHByZXNl bnRseSBoYXZlIG9uIG9mZmVyIGlzIG9mZiBieSBYIHVzIChvciBtcyksIFkgR2JpdCwgWiBzaXpl IG9mIGFkZHJlc3Mgc3BhY2Ugb2YmbmJzcDsgcGFydGljdWxhciB0eXBlLCBldGMuPGJyPg0KPGJy Pg0KV2UgY2FuIGdlbmVyYXRlIHRoZSByZXF1aXJlbWVudHMgYmFzZWQgb24gdGhlIGRpZmZlcmVu Y2UgKGlmIHN1Y2ggZGlmZmVyZW5jZSBjYW4gYmUgZGVtb25zdHJhdGVkKSBhbmQgd29yayBvbiB0 aGUgZ2FwIGZyb20gdGhhdCBwb2ludCBvbndhcmRzLjxicj4NCjxicj4NCklmIHRoZXJlIGlzIG5v IG5lZ2F0aXZlIHRlc3QgY2FzZSBzaG93aW5nIGEgY2xlYXIgcXVhbnRpZmlhYmxlIGRlZmljaWVu Y3kgaW4gdGhlIHN0YW5kYXJkcyBhbmQgYXJjaGl0ZWN0dXJlcyBwcmVzZW50bHkgYXZhaWxhYmxl IGFjcm9zcyB0aGUgSUVURiBhbmQgdGhlIG90aGVyIHN0YW5kYXJkIGJvZGllcywgdGhlbi4uLiwg d2VsbC4uLiwgd2UgYXJlIGJhY2sgdG8gbXkgb3JpZ2luYWwgYW5zd2VyOiAmcXVvdDtObyZxdW90 Oy4NCjxicj4NCjxicj4NCkEuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi0gU3Rld2FydDxicj4NCjxicj4NCjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPk5ldHNsaWNlcyBtYWlsaW5nIGxp c3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86TmV0c2xpY2VzQGlldGYu b3JnIj5OZXRzbGljZXNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+PGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRzbGljZXMiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0c2xpY2VzPC9hPjxvOnA+PC9vOnA+ PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_855708548C8B4D0681BD2BDB2BDA7DB3huaweicom_-- From nobody Wed Feb 8 22:56:21 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7495129490 for ; Wed, 8 Feb 2017 22:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 JcdGmaI5Ps29 for ; Wed, 8 Feb 2017 22:56:15 -0800 (PST) Received: from www.kot-begemot.co.uk (ivanoab5.miniserver.com [78.31.111.25]) (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 5E6201298B5 for ; Wed, 8 Feb 2017 22:56:14 -0800 (PST) Received: from tun5.smaug.kot-begemot.co.uk ([192.168.18.6] helo=smaug.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cbieK-0005nM-G4 for netslices@ietf.org; Thu, 09 Feb 2017 06:56:12 +0000 Received: from wyvern.kot-begemot.co.uk ([192.168.3.72]) by smaug.kot-begemot.co.uk with esmtp (Exim 4.84_2) (envelope-from ) id 1cbieK-0004i9-7r for netslices@ietf.org; Thu, 09 Feb 2017 06:56:12 +0000 Date: Thu, 9 Feb 2017 06:56:11 +0000 From: Anton Ivanov To: "netslices@ietf.org" Message-ID: <20170209065611.097a0f96@wyvern.kot-begemot.co.uk> In-Reply-To: <85570854-8C8B-4D06-81BD-2BDB2BDA7DB3@huawei.com> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> <37956fc6-5f3e-bc54-4411-63721d5a299a@gmail.com> <85570854-8C8B-4D06-81BD-2BDB2BDA7DB3@huawei.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 06:56:17 -0000 On Thu, 9 Feb 2017 00:55:37 +0000 "Kiran.Makhijani" wrote: > My exact point - as someone who works on various software aspects > related to this. I would like to see a negative test case proving > that what is currently available is insufficient. ^^^^^^^ Hi Anton, > It is also important to consider efficiency of current solutions. The > degree of customization anticipated for 5g and slicing will be much > higher. NS should be looked at as a lean network infrastructure from > top-down and e2e in terms of minimizing overheads all across (in > configs, protocols, mgmt., OSS=E2=80=A6) and strictly isolating > partitioned-resources from each other. Apologies, I am an engineer and as most engineers I am not particularly good at parsing Markitechture-speak mumbo-jumbo like lean top-down e2e.=20 Can you please express in clear engineering terms suitable for an IETF WG mailing list what is exactly wrong with the current spectrum of solutions.=20 By the way "Anticipation" !=3D "Requirement". What is the REQUIREMENT which we are failing to address in l2vpn, l3vpn, etc.=20 As I said in my original email - Numbers of microseconds, Gigabits, sizes of address spaces, sizes of config spaces, model defficiencies, etc. At least ONE example where we are failing to address a defined requirement and "citation needed" for that requirement please. A. >=20 > Regards > Kiran >=20 > From: Netslices on behalf of Anton > Ivanov Date: Wednesday, February 8, > 2017 at 8:21 AM To: "netslices@ietf.org" > Subject: Re: [Netslices] Network Slicing - Introductory Document and > Revised Problem Statement >=20 > On 08/02/17 15:59, Stewart Bryant wrote: >=20 >=20 >=20 > On 08/02/2017 15:51, Thomas Nadeau wrote: > I don=E2=80=99t believe anyone is saying what we have is perfect by any > means; what you should ask is: is it good enough to achieve the goals > and requirements of network operators? >=20 > =E2=80=94Tom >=20 > Agreed, and assuming the delay jitter and isolation requirements hold > up, I think these need new work. >=20 > People with experience on controller systems and models are better > placed to consider whether this is a good enough fit for the > requirements that have been expressed by the mobile operators. >=20 > My exact point - as someone who works on various software aspects > related to this. I would like to see a negative test case proving > that what is currently available is insufficient. >=20 > More importantly, I would like to see quantifiable negative test case > - the stuff which we presently have on offer is off by X us (or ms), > Y Gbit, Z size of address space of particular type, etc. >=20 > We can generate the requirements based on the difference (if such > difference can be demonstrated) and work on the gap from that point > onwards. >=20 > If there is no negative test case showing a clear quantifiable > deficiency in the standards and architectures presently available > across the IETF and the other standard bodies, then..., well..., we > are back to my original answer: "No". >=20 > A. >=20 >=20 >=20 > - Stewart >=20 >=20 >=20 >=20 > _______________________________________________ >=20 > Netslices mailing list >=20 > Netslices@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/netslices >=20 >=20 From nobody Thu Feb 9 02:33:58 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EFE12996F for ; Thu, 9 Feb 2017 02:33:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 U8dngwS3su0O for ; Thu, 9 Feb 2017 02:33:55 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 1B254129565 for ; Thu, 9 Feb 2017 02:33:55 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id v184so57024121pgv.3 for ; Thu, 09 Feb 2017 02:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BG15Z5hoz1MPmP90Wu19j3/3i3AuLLJZ3u7TSztH+0g=; b=vaeayis22+PrOaeEe/+v4uYUi3xX7kdte8OnJfMtPG6Lft6bftNpRz85wG+2byisuo hha8UKkLaD5xP6UydW9ClPRQZjfhgjbDzkAoHq8rL+7TUndwdEvX/a6ySy4/O3yX4zrF h4Griyp8pp8McBXt9s5tNvdan1hF9p8auK2eMnPvjrRkqsHukjn4+EY2wQMi1XARw1n7 eniQFO7T32KxBVYh4lK6hWZ6TR/OcpHtJ9AnX+4fbi+csoy1ODPaTO5M4RF1X+LD2Y/V qjtHPA9Zj8pXQAZpE9iofp47/IQOhdU2+y5qo4Af/JHCPTtDy+J6/2vJDLi17HBZIqDb s2PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BG15Z5hoz1MPmP90Wu19j3/3i3AuLLJZ3u7TSztH+0g=; b=Q66RkHPFPLq0WO3eO5sbXvXt2Io5W8XGUUEkCUkLk5eV4nxJ0Pm+/YnQ3mIQpPsYax cfE8tpuTINexiPBTu7m0xjRHgojOhM5c1s14dV1g4zsQrNV2ce6aRz43HUccMSXtOIoH wOv0RZQX+tb1M0OHgEKFbsRMGg1w82TvEkEzQ947Gdu/SMlbXHvYZRSXWdajW8WHmo9h dp7n7uHX3ctIaW2Ve2eChe6ai+zT7EzO8McxSZrrWpUt9fe8DHAeqa/0KaM2I7LKbCfw 943r8stRaQPdfywCqt7doV3iilpV6rWv744B0VsjGBUSoUw9TSwqti3y6Ow2C9uF3Si5 qylQ== X-Gm-Message-State: AMke39kCZDkDMiv+SNo/X3ETobvzoq2MI6YP35qiQoXowFxQJ8RLH6X6XoNOqkjrtB2fYA== X-Received: by 10.98.212.23 with SMTP id a23mr2954429pfh.18.1486636433690; Thu, 09 Feb 2017 02:33:53 -0800 (PST) Received: from [10.207.114.125] ([202.45.12.164]) by smtp.gmail.com with ESMTPSA id e25sm27767358pfk.3.2017.02.09.02.33.52 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Feb 2017 02:33:53 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: Satoru Matsushima In-Reply-To: <76CD132C3ADEF848BD84D028D243C9279357B4CB@NKGEML515-MBX.china.huawei.com> Date: Thu, 9 Feb 2017 19:33:51 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <503A1908-2068-47A2-B8E0-5D7E3BF88444@gmail.com> <76CD132C3ADEF848BD84D028D243C9279357B4CB@NKGEML515-MBX.china.huawei.com> To: "Dongjie (Jimmy)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "netslices@ietf.org" Subject: Re: [Netslices] Data-plane work in DMM WG with slicing concept X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 10:33:57 -0000 Hi Jie, >=20 > Thanks for introducing the network slicing related work in DMM.=20 >=20 > While I don't have much expertise in DMM, my rough understanding is = the separation of data plane and control plane in mobile network may = have some requirement on network slicing, and for E2E network slicing it = may be needed to jointly consider the slicing in mobile network and = transport network. It would be great if you could help to describe the = slicing requirements from DMM perspective.=20 >=20 Thanks, but sorry just terse introduction for that DMM work. Yes you=E2=80=99re right. The DMM work named Forwarding Policy Configuration (FPC) is a neutral = interface from specific mobility management systems, like 3GPP GTP or = IETF (P)MIP for example, that to manage data-plane configurations. One = of original motivations of DMM is to provide optimal data-path for = mobile applications. Each application may see different path as its = optimal path so that FPC need to be able to provide that. Let me explain a little bit about it. FPC is designed to support that an = infrastructure operator provides its network as data-plane for multiple = mobile operators as tenants who are able to virtually construct multiple = Domain (slices) to meet requirements of their applications. The entities = of mobility management in a Domain are abstracted as FPC-topology model = on the FPC agent which configure data-plane nodes in the infrastructure. = That configurations are based on the constructed model and the session = states of which mobile control-plane or applications generated with its = policies. For sure that, the virtually constructed model of Domains should be = bound to appropriate infrastructure resources, like links, bandwidth and = queueing schedule priorities, etc,. Let me think for that with YANG = model, I suppose that resources would also be abstracted as a slice = topology using i2rs based schemas, ACTN for example, and be instantiated = statically or dynamically on demand basis. Then the constructed FPC = model can be able to bind that slice instance as its data-plane. In that = FPC model if some specific mobile data-plane entities which require NFV = infrastructure to be instantiated on it, the data-plane model should = also be able to include NFVI as its part of resources as well. Hope it helps you to understand DMM FPC work, and I=E2=80=99m happy if = we can discuss on this perspective. Best regards, --satoru > Best regards, > Jie >=20 >> -----Original Message----- >> From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of = Satoru >> Matsushima >> Sent: Tuesday, February 07, 2017 2:02 PM >> To: netslices@ietf.org >> Subject: [Netslices] Data-plane work in DMM WG with slicing concept >>=20 >> All, >>=20 >> IETF DMM (Distributed Mobility Management) working group has been >> chartered to make separation of data-plane from mobile control-plane, = which >> defines data-plane obstruction models with network slicing concept. >>=20 >> Through the discussion on the Netslices list, I=E2=80=99ve noticed = what the draft calls >> =E2=80=9CDomain=E2=80=9D would almost close to =E2=80=9CNetwork = Slicing=E2=80=9D. >>=20 >> Data-plane model of FPC provides information and data model by YANG = for >> mobile network which IMO would be helpful to figure slicing model = out. >>=20 >> FPC-topology tree is one for that. FPC-policy would be requirements = to the slice. >>=20 >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/ >>=20 >>=20 >> Protocol for Forwarding Policy Configuration (FPC) in DMM >> draft-ietf-dmm-fpc-cpdp-05.txt >>=20 >>=20 >> Abstract >>=20 >>=20 >> This document describes the solution of data-plane separation from >> control-plane which enables a flexible mobility management system >> using agent and client functions. To configure data-plane nodes = and >> functions, the data-plane is abstracted by an agent interface to = the >> client. The data-plane abstraction model is extensible in order to >> support many different type of mobility management systems and = data- >> plane functions. >>=20 >> Best regards, >> --satoru >> _______________________________________________ >> Netslices mailing list >> Netslices@ietf.org >> https://www.ietf.org/mailman/listinfo/netslices From nobody Mon Feb 13 00:42:13 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C2D12955C for ; Mon, 13 Feb 2017 00:42:11 -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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 g0b7Tyd-8WG2 for ; Mon, 13 Feb 2017 00:42:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15FC512955B for ; Mon, 13 Feb 2017 00:42:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAN47785; Mon, 13 Feb 2017 08:42:00 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 13 Feb 2017 08:41:56 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 13 Feb 2017 16:41:30 +0800 From: "Dongjie (Jimmy)" To: Anton Ivanov , "netslices@ietf.org" Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvq7wX2ECP+/oEWl791jc0LWbKFbjOGAgACPA4CAACspgIAASSYAgAAJHACAANcZAIAAXXSAgACuCwCAAA9qAIAAMmaAgAAIxwCAAAHCAIAAC4KAgAAGswCAAAIOgIAABikAgAfPp0A= Date: Mon, 13 Feb 2017 08:42:33 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9279357E254@NKGEML515-MBX.china.huawei.com> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> <37956fc6-5f3e-bc54-4411-63721d5a299a@gmail.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C9279357E254NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0208.58A17159.0091, 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: 4a463013224896b063d859c77b66bc81 Archived-At: Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 08:42:11 -0000 --_000_76CD132C3ADEF848BD84D028D243C9279357E254NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Anton, Yes, the use cases which cannot be fully met with existing solutions are ex= actly what we would like to discuss on this mailing list. As you said, quan= tifiable use cases would be quite useful, while since it is just the beginn= ing of the network slicing discussion in IETF, qualitative use cases would= also be helpful. I'd like to encourage people who has specific use cases t= o briefly introduce them to the list, so that we could have further discuss= ion based on that. One use case discussed on the side meeting is the banking service which has= strict requirements on low latency and security, currently it is still usi= ng a dedicated network which is not economical. If we aim to migrate such k= ind of service onto the common network infrastructure in 5G, the latency, i= solation and security must be guaranteed. And in 5G more critical service s= uch as industrial control, remote surgery, automated-driving, etc. are emer= ging, they would need guaranteed network performance and different levels o= f isolation if the infrastructure is shared with other services. Best regards, Jie From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Anton Ivan= ov Sent: Thursday, February 09, 2017 12:21 AM To: netslices@ietf.org Subject: Re: [Netslices] Network Slicing - Introductory Document and Revise= d Problem Statement On 08/02/17 15:59, Stewart Bryant wrote: On 08/02/2017 15:51, Thomas Nadeau wrote: I don't believe anyone is saying what we have is perfect by any means; wh= at you should ask is: is it good enough to achieve the goals and requiremen= ts of network operators? -Tom Agreed, and assuming the delay jitter and isolation requirements hold up, I= think these need new work. People with experience on controller systems and models are better placed = to consider whether this is a good enough fit for the requirements that hav= e been expressed by the mobile operators. My exact point - as someone who works on various software aspects related t= o this. I would like to see a negative test case proving that what is curre= ntly available is insufficient. More importantly, I would like to see quantifiable negative test case - the= stuff which we presently have on offer is off by X us (or ms), Y Gbit, Z s= ize of address space of particular type, etc. We can generate the requirements based on the difference (if such differenc= e can be demonstrated) and work on the gap from that point onwards. If there is no negative test case showing a clear quantifiable deficiency i= n the standards and architectures presently available across the IETF and t= he other standard bodies, then..., well..., we are back to my original answ= er: "No". A. - Stewart _______________________________________________ Netslices mailing list Netslices@ietf.org https://www.ietf.org/mailman/listinfo/netslices --_000_76CD132C3ADEF848BD84D028D243C9279357E254NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Anton,

 

Yes, the use cases whi= ch cannot be fully met with existing solutions are exactly what we would li= ke to discuss on this mailing list. As you said, quantifiable use cases would be quite useful, while since it is just the b= eginning of the network slicing discussion in IETF,  qualitative use c= ases would also be helpful. I’d like to encourage people who has spec= ific use cases to briefly introduce them to the list, so that we could have further discussion based on that.

 

One use case discussed= on the side meeting is the banking service which has strict requirements o= n low latency and security, currently it is still using a dedicated network which is not economical. If we aim to migrate su= ch kind of service onto the common network infrastructure in 5G, the latenc= y, isolation and security must be guaranteed. And in 5G more critical servi= ce such as industrial control, remote surgery, automated-driving, etc. are emerging, they would need guaranteed = network performance and different levels of isolation if the infrastructure= is shared with other services.

 

Best regards,

Jie<= /p>

 

From:= Netslices [mailto:netslices-bounces@ietf.= org] On Behalf Of Anton Ivanov
Sent: Thursday, February 09, 2017 12:21 AM
To: netslices@ietf.org
Subject: Re: [Netslices] Network Slicing - Introductory Document and= Revised Problem Statement

 

On 08/02/17 15:59, Stewart Brya= nt wrote:

 

 

On 08/02/2017 15:51, Thomas Nad= eau wrote:

=   I don’t believe anyone is s= aying what we have is perfect by any means; what you should ask is: is it g= ood enough to achieve the goals and requirements of network operators?

 

=   —Tom


Agreed, and assuming the delay jitter and isolation requirements hold up, I= think these need new work.

People  with experience on controller systems and models are better pl= aced to consider whether this is a good enough fit for the requirements tha= t have been expressed by the mobile operators.


My exact point - as someone who works on various software aspects related t= o this. I would like to see a negative test case proving that what is curre= ntly available is insufficient.

More importantly, I would like to see quantifiable negative test case - the= stuff which we presently have on offer is off by X us (or ms), Y Gbit, Z s= ize of address space of  particular type, etc.

We can generate the requirements based on the difference (if such differenc= e can be demonstrated) and work on the gap from that point onwards.

If there is no negative test case showing a clear quantifiable deficiency i= n the standards and architectures presently available across the IETF and t= he other standard bodies, then..., well..., we are back to my original answ= er: "No".

A.



- Stewart



_______________________________________________
Netslices mailing list
Netslices@i=
etf.org
https://www.ietf.org/mailman/listinfo/netslices

 

--_000_76CD132C3ADEF848BD84D028D243C9279357E254NKGEML515MBXchi_-- From nobody Mon Feb 13 09:05:10 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 315731296DF for ; Mon, 13 Feb 2017 09:05:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lucidvision.com 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 lVWpV0ZzvZ9t for ; Mon, 13 Feb 2017 09:05:03 -0800 (PST) Received: from lucidvision.com (lucidab1.miniserver.com [78.31.106.147]) (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 C5E5F128B38 for ; Mon, 13 Feb 2017 09:05:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1487005401; bh=rNFR7URMX/jG9GAxCdKuBH/odhWT9WZ4N00Jsyps5Mg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=MC5jEXBahKoRtioA6SwAZkZkbVil7CJQUV6XQvxo59TQXgyz+/G+NYfb03T17P5gD CZh5eL20P8CgRBZ8YTuXy5AMksb46j3BFZFzd6cK6XjFfuqAhDrVStDYF2vmiEooBi gtT5hL3l8SsLE6YCrcjjiuvEjzPOX6zsxnJjFNHE= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; Content-Type: multipart/alternative; boundary="Apple-Mail=_5AA918D9-45B5-4B4C-919E-DD1A4696D944" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Thomas Nadeau In-Reply-To: <76CD132C3ADEF848BD84D028D243C9279357E254@NKGEML515-MBX.china.huawei.com> Date: Mon, 13 Feb 2017 12:04:41 -0500 Message-Id: References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> <37956fc6-5f3e-bc54-4411-63721d5a299a@gmail.com> <76CD132C3ADEF848BD84D028D243C9279357E254@NKGEML515-MBX.china.huawei.com> To: "Dongjie (Jimmy)" X-Mailer: Apple Mail (2.3124) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Unknown ip=50.255.148.181 X-IP-stats: Notspam Incoming Last 1, First 640, in=4800, out=0, spam=0 Known=true ip=50.255.148.181 Archived-At: Cc: Anton Ivanov , "netslices@ietf.org" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 17:05:09 -0000 --Apple-Mail=_5AA918D9-45B5-4B4C-919E-DD1A4696D944 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Perhaps you could write up a short draft explaining the details = of that use case? On the surface, I can see how existing=20 tech can work but you may have some requirements that I am missing from = your high level description. =E2=80=94Tom > On Feb 13, 2017:3:42 AM, at 3:42 AM, Dongjie (Jimmy) = wrote: >=20 > Hi Anton, > =20 > Yes, the use cases which cannot be fully met with existing solutions = are exactly what we would like to discuss on this mailing list. As you = said, quantifiable use cases would be quite useful, while since it is = just the beginning of the network slicing discussion in IETF, = qualitative use cases would also be helpful. I=E2=80=99d like to = encourage people who has specific use cases to briefly introduce them to = the list, so that we could have further discussion based on that. > =20 > One use case discussed on the side meeting is the banking service = which has strict requirements on low latency and security, currently it = is still using a dedicated network which is not economical. If we aim to = migrate such kind of service onto the common network infrastructure in = 5G, the latency, isolation and security must be guaranteed. And in 5G = more critical service such as industrial control, remote surgery, = automated-driving, etc. are emerging, they would need guaranteed network = performance and different levels of isolation if the infrastructure is = shared with other services. > =20 > Best regards, > Jie > =20 > From: Netslices [mailto:netslices-bounces@ietf.org = ] On Behalf Of Anton Ivanov > Sent: Thursday, February 09, 2017 12:21 AM > To: netslices@ietf.org > Subject: Re: [Netslices] Network Slicing - Introductory Document and = Revised Problem Statement > =20 > On 08/02/17 15:59, Stewart Bryant wrote: > =20 >=20 > =20 > On 08/02/2017 15:51, Thomas Nadeau wrote: > I don=E2=80=99t believe anyone is saying what we have is perfect by = any means; what you should ask is: is it good enough to achieve the = goals and requirements of network operators? > =20 > =E2=80=94Tom >=20 > Agreed, and assuming the delay jitter and isolation requirements hold = up, I think these need new work. >=20 > People with experience on controller systems and models are better = placed to consider whether this is a good enough fit for the = requirements that have been expressed by the mobile operators. >=20 > My exact point - as someone who works on various software aspects = related to this. I would like to see a negative test case proving that = what is currently available is insufficient. >=20 > More importantly, I would like to see quantifiable negative test case = - the stuff which we presently have on offer is off by X us (or ms), Y = Gbit, Z size of address space of particular type, etc. >=20 > We can generate the requirements based on the difference (if such = difference can be demonstrated) and work on the gap from that point = onwards. >=20 > If there is no negative test case showing a clear quantifiable = deficiency in the standards and architectures presently available across = the IETF and the other standard bodies, then..., well..., we are back to = my original answer: "No".=20 >=20 > A. >=20 >=20 >=20 > - Stewart >=20 >=20 >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices = > =20 >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices = --Apple-Mail=_5AA918D9-45B5-4B4C-919E-DD1A4696D944 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Perhaps = you could write up a short draft explaining the details of that use = case? On the surface, I can see how existing 
tech = can work but you may have some requirements that I am missing from your = high level description.

= =E2=80=94Tom



On = Feb 13, 2017:3:42 AM, at 3:42 AM, Dongjie (Jimmy) <jie.dong@huawei.com>= wrote:

Hi Anton,
 
Yes, the use = cases which cannot be fully met with existing solutions are exactly what = we would like to discuss on this mailing list. As you said, quantifiable = use cases would be quite useful, while since it is just the beginning of = the network slicing discussion in IETF,  qualitative use cases = would also be helpful. I=E2=80=99d like to encourage people who has = specific use cases to briefly introduce them to the list, so that we = could have further discussion based on that.
 
One use case = discussed on the side meeting is the banking service which has strict = requirements on low latency and security, currently it is still using a = dedicated network which is not economical. If we aim to migrate such = kind of service onto the common network infrastructure in 5G, the = latency, isolation and security must be guaranteed. And in 5G more = critical service such as industrial control, remote surgery, = automated-driving, etc. are emerging, they would need guaranteed network = performance and different levels of isolation if the infrastructure is = shared with other services.
 
Best regards,
Jie
 
From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf = Of Anton Ivanov
Sent: Thursday, February 09, 2017 = 12:21 AM
To: netslices@ietf.org
Subject: Re: [Netslices] Network = Slicing - Introductory Document and Revised Problem Statement
 
On 08/02/17 15:59, = Stewart Bryant wrote:

 

 
On 08/02/2017 15:51, = Thomas Nadeau wrote:
  I don=E2=80=99t believe anyone is saying what = we have is perfect by any means; what you should ask is: is it good = enough to achieve the goals and requirements of network operators?
 
  =E2=80=94Tom

Agreed, = and assuming the delay jitter and isolation requirements hold up, I = think these need new work.

People  = with experience on controller systems and models are better placed to = consider whether this is a good enough fit for the requirements that = have been expressed by the mobile operators.

My exact point = - as someone who works on various software aspects related to this. I = would like to see a negative test case proving that what is currently = available is insufficient.

More = importantly, I would like to see quantifiable negative test case - the = stuff which we presently have on offer is off by X us (or ms), Y Gbit, Z = size of address space of  particular type, etc.

We can generate the requirements based on the difference (if = such difference can be demonstrated) and work on the gap from that point = onwards.

If there is no negative test case = showing a clear quantifiable deficiency in the standards and = architectures presently available across the IETF and the other standard = bodies, then..., well..., we are back to my original answer: "No". 

A.



- Stewart



_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

 

_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

= --Apple-Mail=_5AA918D9-45B5-4B4C-919E-DD1A4696D944-- From nobody Mon Feb 13 10:28:36 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E11912973A for ; Mon, 13 Feb 2017 10:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.78 X-Spam-Level: X-Spam-Status: No, score=-1.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=realsdn.org 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 quV4MFLJRQCX for ; Mon, 13 Feb 2017 10:28:33 -0800 (PST) Received: from ajmclachlan.com (pigmail.ajmclachlan.com [78.31.107.96]) (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 B7AF21294A0 for ; Mon, 13 Feb 2017 10:28:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=realsdn.org; s=default; t=1487010512; bh=mdP2rqZBhpKJPJJxNLpCG7OYDZfxGw4CVo/4KpYuaes=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=hfq0BAkjWVTw+lwwTj9YNraqwck/YdMQI1DxOUonYPEJkyLJjSK07wOCWQsOnc+Xd M9MlTvS8cH/hBUzeiQLdz2aM1ypiof2ZmX59x4ZjocCtUQ90Juf+gz4/ZgKCuTD8n4 7o1utLB52TMaQlElADQY4DvpMCxteuvlrJi5XvGs= X-Default-Received-SPF: pass (skip=forwardok (res=PASS)); Content-Type: multipart/alternative; boundary="Apple-Mail=_FBEE5836-9451-4E8C-A317-76576E06567C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Andrew McLachlan In-Reply-To: Date: Mon, 13 Feb 2017 18:28:28 +0000 Message-Id: <0D357DFF-34D4-4224-9046-77DFF5F42759@realsdn.org> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> <37956fc6-5f3e-bc54-4411-63721d5a299a@gmail.com> <76CD132C3ADEF848BD84D028D243C9279357E254@NKGEML515-MBX.china.huawei.com> To: Thomas Nadeau X-Mailer: Apple Mail (2.3124) X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted Archived-At: Cc: "Dongjie \(Jimmy\)" , Anton Ivanov , "netslices@ietf.org" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 18:28:35 -0000 --Apple-Mail=_FBEE5836-9451-4E8C-A317-76576E06567C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jie I agree that there are emerging scenarios in the mobile networking space = along the lines of what you have described. However do they generate = requirements which necessitate new standards/functions or enhancements = to existing solutions? So far the described use cases do seem to be covered by existing = methods, they have just so far not been so far widely used in the mobile = space. Agree with Tom, adding that the use cases need to go beyond the = conceptual problem and into specific missing functions, since we already = have multiple methods for separation and at multiple layers using for = =E2=80=98slicing=E2=80=99 up infrastructures, both physical and virtual. In addition as I have stated previously in this thread, the problem = space imo, lies mostly above the network/protocol layer and more in the = orchestration domain. Andrew > On 13 Feb 2017, at 17:04, Thomas Nadeau = wrote: >=20 >=20 > Perhaps you could write up a short draft explaining the details = of that use case? On the surface, I can see how existing=20 > tech can work but you may have some requirements that I am missing = from your high level description. >=20 > =E2=80=94Tom >=20 >=20 >=20 >> On Feb 13, 2017:3:42 AM, at 3:42 AM, Dongjie (Jimmy) = > wrote: >>=20 >> Hi Anton, >> =20 >> Yes, the use cases which cannot be fully met with existing solutions = are exactly what we would like to discuss on this mailing list. As you = said, quantifiable use cases would be quite useful, while since it is = just the beginning of the network slicing discussion in IETF, = qualitative use cases would also be helpful. I=E2=80=99d like to = encourage people who has specific use cases to briefly introduce them to = the list, so that we could have further discussion based on that. >> =20 >> One use case discussed on the side meeting is the banking service = which has strict requirements on low latency and security, currently it = is still using a dedicated network which is not economical. If we aim to = migrate such kind of service onto the common network infrastructure in = 5G, the latency, isolation and security must be guaranteed. And in 5G = more critical service such as industrial control, remote surgery, = automated-driving, etc. are emerging, they would need guaranteed network = performance and different levels of isolation if the infrastructure is = shared with other services. >> =20 >> Best regards, >> Jie >> =20 >> From: Netslices [mailto:netslices-bounces@ietf.org = ] On Behalf Of Anton Ivanov >> Sent: Thursday, February 09, 2017 12:21 AM >> To: netslices@ietf.org >> Subject: Re: [Netslices] Network Slicing - Introductory Document and = Revised Problem Statement >> =20 >> On 08/02/17 15:59, Stewart Bryant wrote: >> =20 >>=20 >> =20 >> On 08/02/2017 15:51, Thomas Nadeau wrote: >> I don=E2=80=99t believe anyone is saying what we have is perfect by = any means; what you should ask is: is it good enough to achieve the = goals and requirements of network operators? >> =20 >> =E2=80=94Tom >>=20 >> Agreed, and assuming the delay jitter and isolation requirements hold = up, I think these need new work. >>=20 >> People with experience on controller systems and models are better = placed to consider whether this is a good enough fit for the = requirements that have been expressed by the mobile operators. >>=20 >> My exact point - as someone who works on various software aspects = related to this. I would like to see a negative test case proving that = what is currently available is insufficient. >>=20 >> More importantly, I would like to see quantifiable negative test case = - the stuff which we presently have on offer is off by X us (or ms), Y = Gbit, Z size of address space of particular type, etc. >>=20 >> We can generate the requirements based on the difference (if such = difference can be demonstrated) and work on the gap from that point = onwards. >>=20 >> If there is no negative test case showing a clear quantifiable = deficiency in the standards and architectures presently available across = the IETF and the other standard bodies, then..., well..., we are back to = my original answer: "No".=20 >>=20 >> A. >>=20 >>=20 >>=20 >> - Stewart >>=20 >>=20 >>=20 >> _______________________________________________ >> Netslices mailing list >> Netslices@ietf.org >> https://www.ietf.org/mailman/listinfo/netslices = >> =20 >>=20 >> _______________________________________________ >> Netslices mailing list >> Netslices@ietf.org >> https://www.ietf.org/mailman/listinfo/netslices = >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices --Apple-Mail=_FBEE5836-9451-4E8C-A317-76576E06567C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi = Jie

I agree = that there are emerging scenarios in the mobile networking space along = the lines of what you have described. However do they generate = requirements which necessitate new standards/functions or enhancements = to existing solutions?

So far the described use cases do seem to be covered by = existing methods, they have just so far not been so far widely used in = the mobile space.

Agree with Tom, adding that the use cases need to go beyond = the conceptual problem and into specific missing functions, since we = already have multiple methods for separation and at multiple layers = using for =E2=80=98slicing=E2=80=99 up infrastructures, both physical = and virtual.

In = addition as I have stated previously in this thread, the problem space = imo, lies mostly above the network/protocol layer and more in the = orchestration domain.

Andrew


On = 13 Feb 2017, at 17:04, Thomas Nadeau <tnadeau@lucidvision.com> wrote:


Perhaps you could write up a = short draft explaining the details of that use case? On the surface, I = can see how existing 
tech can work but you may have = some requirements that I am missing from your high level = description.

= =E2=80=94Tom



On Feb = 13, 2017:3:42 AM, at 3:42 AM, Dongjie (Jimmy) <jie.dong@huawei.com>= wrote:

Hi Anton,
 
Yes, the use = cases which cannot be fully met with existing solutions are exactly what = we would like to discuss on this mailing list. As you said, quantifiable = use cases would be quite useful, while since it is just the beginning of = the network slicing discussion in IETF,  qualitative use cases = would also be helpful. I=E2=80=99d like to encourage people who has = specific use cases to briefly introduce them to the list, so that we = could have further discussion based on that.
 
One use case = discussed on the side meeting is the banking service which has strict = requirements on low latency and security, currently it is still using a = dedicated network which is not economical. If we aim to migrate such = kind of service onto the common network infrastructure in 5G, the = latency, isolation and security must be guaranteed. And in 5G more = critical service such as industrial control, remote surgery, = automated-driving, etc. are emerging, they would need guaranteed network = performance and different levels of isolation if the infrastructure is = shared with other services.
 
Best regards,
Jie
 
From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf = Of Anton Ivanov
Sent: Thursday, February 09, 2017 = 12:21 AM
To: netslices@ietf.org
Subject: Re: [Netslices] Network = Slicing - Introductory Document and Revised Problem Statement
 
On 08/02/17 15:59, = Stewart Bryant wrote:

 

 
On 08/02/2017 15:51, = Thomas Nadeau wrote:
  I don=E2=80=99t believe anyone is saying what = we have is perfect by any means; what you should ask is: is it good = enough to achieve the goals and requirements of network operators?
 
  =E2=80=94Tom

Agreed, = and assuming the delay jitter and isolation requirements hold up, I = think these need new work.

People  = with experience on controller systems and models are better placed to = consider whether this is a good enough fit for the requirements that = have been expressed by the mobile operators.

My exact point = - as someone who works on various software aspects related to this. I = would like to see a negative test case proving that what is currently = available is insufficient.

More = importantly, I would like to see quantifiable negative test case - the = stuff which we presently have on offer is off by X us (or ms), Y Gbit, Z = size of address space of  particular type, etc.

We can generate the requirements based on the difference (if = such difference can be demonstrated) and work on the gap from that point = onwards.

If there is no negative test case = showing a clear quantifiable deficiency in the standards and = architectures presently available across the IETF and the other standard = bodies, then..., well..., we are back to my original answer: "No". 

A.



- Stewart



_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

 

_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

= --Apple-Mail=_FBEE5836-9451-4E8C-A317-76576E06567C-- From nobody Mon Feb 13 11:41:42 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9369112989C for ; Mon, 13 Feb 2017 11:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 dzhq9JZ94nh5 for ; Mon, 13 Feb 2017 11:41:28 -0800 (PST) Received: from www.kot-begemot.co.uk (ivanoab5.miniserver.com [78.31.111.25]) (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 EB7A0129898 for ; Mon, 13 Feb 2017 11:41:27 -0800 (PST) Received: from tun5.smaug.kot-begemot.co.uk ([192.168.18.6] helo=smaug.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cdMV1-0001e3-5w; Mon, 13 Feb 2017 19:41:23 +0000 Received: from 85-118-69-252.mtel.net ([85.118.69.252] helo=[192.168.14.3]) by smaug.kot-begemot.co.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cdMV0-000254-Cm; Mon, 13 Feb 2017 19:41:22 +0000 To: Thomas Nadeau , "Dongjie (Jimmy)" References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> <37956fc6-5f3e-bc54-4411-63721d5a299a@gmail.com> <76CD132C3ADEF848BD84D028D243C9279357E254@NKGEML515-MBX.china.huawei.com> From: Anton Ivanov Message-ID: <25ffb53a-5522-e621-25ea-7c8655a8cb27@kot-begemot.co.uk> Date: Mon, 13 Feb 2017 19:41:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9BE3ADC91E0909DE576C3DFA" X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Cc: "netslices@ietf.org" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 19:41:35 -0000 This is a multi-part message in MIME format. --------------9BE3ADC91E0909DE576C3DFA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit +1 While there are trading scenarios which demand dedicated networks most of them have been put in place to achieve very specific use cases. None of these has any intention to share as far as I know as they are part of what gives the company the special advantage. I would definitely like to see this written up so we can see how we can work towards a SHARING solution - something we can drive towards a standard within the concepts being discussed here. So I concur with Tom, I would like to see this use case written out so it can be analyzed in context. As far as the other ones - surgery, etc - the ones that have known working prototypes with known actual parameters can be dealt with using existing solutions. I would be interested to see some numbers proving a specific use case that they cannot. Similar - a draft describing a use case would be needed as a part of forming the requirements. A. On 13/02/17 17:04, Thomas Nadeau wrote: > > Perhaps you could write up a short draft explaining the details of > that use case? On the surface, I can see how existing > tech can work but you may have some requirements that I am missing > from your high level description. > > —Tom > > > >> On Feb 13, 2017:3:42 AM, at 3:42 AM, Dongjie (Jimmy) >> > wrote: >> >> Hi Anton, >> Yes, the use cases which cannot be fully met with existing solutions >> are exactly what we would like to discuss on this mailing list. As >> you said, quantifiable use cases would be quite useful, while since >> it is just the beginning of the network slicing discussion in IETF, >> qualitative use cases would also be helpful. I’d like to encourage >> people who has specific use cases to briefly introduce them to the >> list, so that we could have further discussion based on that. >> One use case discussed on the side meeting is the banking service >> which has strict requirements on low latency and security, currently >> it is still using a dedicated network which is not economical. If we >> aim to migrate such kind of service onto the common network >> infrastructure in 5G, the latency, isolation and security must be >> guaranteed. And in 5G more critical service such as industrial >> control, remote surgery, automated-driving, etc. are emerging, they >> would need guaranteed network performance and different levels of >> isolation if the infrastructure is shared with other services. >> Best regards, >> Jie >> *From:*Netslices [mailto:netslices-bounces@ietf.org]*On Behalf >> Of*Anton Ivanov >> *Sent:*Thursday, February 09, 2017 12:21 AM >> *To:*netslices@ietf.org >> *Subject:*Re: [Netslices] Network Slicing - Introductory Document and >> Revised Problem Statement >> On 08/02/17 15:59, Stewart Bryant wrote: >> >> On 08/02/2017 15:51, Thomas Nadeau wrote: >> >> I don’t believe anyone is saying what we have is perfect by >> any means; what you should ask is: is it good enough to >> achieve the goals and requirements of network operators? >> —Tom >> >> >> Agreed, and assuming the delay jitter and isolation requirements >> hold up, I think these need new work. >> >> People with experience on controller systems and models are >> better placed to consider whether this is a good enough fit for >> the requirements that have been expressed by the mobile operators. >> >> >> My exact point - as someone who works on various software aspects >> related to this. I would like to see a negative test case proving >> that what is currently available is insufficient. >> >> More importantly, I would like to see quantifiable negative test case >> - the stuff which we presently have on offer is off by X us (or ms), >> Y Gbit, Z size of address space of particular type, etc. >> >> We can generate the requirements based on the difference (if such >> difference can be demonstrated) and work on the gap from that point >> onwards. >> >> If there is no negative test case showing a clear quantifiable >> deficiency in the standards and architectures presently available >> across the IETF and the other standard bodies, then..., well..., we >> are back to my original answer: "No". >> >> A. >> >> >> >> - Stewart >> >> >> >> _______________________________________________ >> >> Netslices mailing list >> >> Netslices@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netslices >> >> _______________________________________________ >> Netslices mailing list >> Netslices@ietf.org >> https://www.ietf.org/mailman/listinfo/netslices > --------------9BE3ADC91E0909DE576C3DFA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

+1

While there are trading scenarios which demand dedicated networks most of them have been put in place to achieve very specific use cases. None of these has any intention to share as far as I know as they are part of what gives the company the special advantage.

I would definitely like to see this written up so we can see how we can work towards a SHARING solution - something we can drive towards a standard within the concepts being discussed here.

So I concur with Tom, I would like to see this use case written out so it can be analyzed in context.

As far as the other ones - surgery, etc - the ones that have known working prototypes with known actual parameters can be dealt with using existing solutions. I would be interested to see some numbers proving a specific use case that they cannot. Similar - a draft describing a use case would be needed as a part of forming the requirements.

A.

On 13/02/17 17:04, Thomas Nadeau wrote:

Perhaps you could write up a short draft explaining the details of that use case? On the surface, I can see how existing 
tech can work but you may have some requirements that I am missing from your high level description.

—Tom



On Feb 13, 2017:3:42 AM, at 3:42 AM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Hi Anton,
 
Yes, the use cases which cannot be fully met with existing solutions are exactly what we would like to discuss on this mailing list. As you said, quantifiable use cases would be quite useful, while since it is just the beginning of the network slicing discussion in IETF,  qualitative use cases would also be helpful. I’d like to encourage people who has specific use cases to briefly introduce them to the list, so that we could have further discussion based on that.
 
One use case discussed on the side meeting is the banking service which has strict requirements on low latency and security, currently it is still using a dedicated network which is not economical. If we aim to migrate such kind of service onto the common network infrastructure in 5G, the latency, isolation and security must be guaranteed. And in 5G more critical service such as industrial control, remote surgery, automated-driving, etc. are emerging, they would need guaranteed network performance and different levels of isolation if the infrastructure is shared with other services.
 
Best regards,
Jie
 
From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Anton Ivanov
Sent: Thursday, February 09, 2017 12:21 AM
To: netslices@ietf.org
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement
 
On 08/02/17 15:59, Stewart Bryant wrote:

 

 
On 08/02/2017 15:51, Thomas Nadeau wrote:
  I don’t believe anyone is saying what we have is perfect by any means; what you should ask is: is it good enough to achieve the goals and requirements of network operators?
 
  —Tom

Agreed, and assuming the delay jitter and isolation requirements hold up, I think these need new work.

People  with experience on controller systems and models are better placed to consider whether this is a good enough fit for the requirements that have been expressed by the mobile operators.

My exact point - as someone who works on various software aspects related to this. I would like to see a negative test case proving that what is currently available is insufficient.

More importantly, I would like to see quantifiable negative test case - the stuff which we presently have on offer is off by X us (or ms), Y Gbit, Z size of address space of  particular type, etc.

We can generate the requirements based on the difference (if such difference can be demonstrated) and work on the gap from that point onwards.

If there is no negative test case showing a clear quantifiable deficiency in the standards and architectures presently available across the IETF and the other standard bodies, then..., well..., we are back to my original answer: "No". 

A.



- Stewart



_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

 

_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices


--------------9BE3ADC91E0909DE576C3DFA-- From nobody Tue Feb 14 12:46:29 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27ED1129857 for ; Tue, 14 Feb 2017 12:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 moBSjXRav-FE for ; Tue, 14 Feb 2017 12:45:09 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0127.outbound.protection.outlook.com [104.47.1.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EBF2129849 for ; Tue, 14 Feb 2017 12:45:06 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=a.galis@ucl.ac.uk; Received: from alex-galiss-mbp.connect (90.252.132.30) by DB6PR0101MB2342.eurprd01.prod.exchangelabs.com (10.169.220.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 14 Feb 2017 20:45:03 +0000 From: Alex Galis Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-ID: <5B526793-E0F0-4842-9D22-5DEC416154D1@ucl.ac.uk> Date: Tue, 14 Feb 2017 20:45:01 +0000 To: Network Slices X-Mailer: Apple Mail (2.3259) X-Originating-IP: [90.252.132.30] X-ClientProxiedBy: AM5PR0101CA0015.eurprd01.prod.exchangelabs.com (10.169.240.25) To DB6PR0101MB2342.eurprd01.prod.exchangelabs.com (10.169.220.140) X-MS-Office365-Filtering-Correlation-Id: 9523c232-95bc-46e4-b303-08d4551a5a5b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:DB6PR0101MB2342; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0101MB2342; 3:vSk/yYs8Rg9lMmcBsn0QiITATGcZrJKbB2vytqU2czfoyPC4mYWW5rmWlQC2CENjIvqYWGTyktrl1ykwJOGQNFo+EiaZ8JxrLSrmkAOpjnoY9RHhjv1A8B9eEC7aS8sBW09Iys+7Zu54ChexatOmuL4CaBWMY4oQGjdi65L20DOiayf3subo3M7KGLnFimNHCgNdV307j15zEEAd20XjM6yRJLanCbHemIEF0R3VSVFqinEfKR1SCMjtGp6c3XWRU32Xc0OKXLaV90JlOWm8Ig==; 25:6F1E4PgJ446Hbg9B+xDJg055mnBdqmHjSU0ZFuKII4O4rYjYEJMqivlOoet0v0jCeZbnOUeB+WYmv5PWsrK3i9HXotKBYR5dEYKShW0yfaBM9XJ8OyazH26PUXwDGKmSUy4/qZh6j4Pd4vzBObWhGf7gwoKngzbhKvGQDt37nvCmoDm4kkj8WDZpEzM7nHoIqUthIg7YyjGfT3a3zzALRd62yGNpgLREYK9edEQOCXWyT0BoSffNwd6+EwdJiIHGxohPMMsMX1KiEPB/CvksLOeWldTdBRIl5jEOLScvhtsIPhxScK/iSVQTNOA0X0AXcruEOCx5apPXhfZjtksNxd6lJE+CQ/UYoMw3op9qpfSPIGiTWKH1u4Rc7eps2bWHR9uwDk5EkEbQV3NkXkDJ9UOWDXTaMKT7GvwaK2P2GKtEnCqNooIvm+qoY9I9C4mIhwFFDeKcq7zPMZialMInlQ== X-Microsoft-Exchange-Diagnostics: 1; DB6PR0101MB2342; 31:DcHfQSvXaSUPzf6qRAbuNNFPL4keoiu/eoqHrfMaHzVmSmD2F7bnsyhbo7lwZrpfapUWQtSJXMtwCpYkkL9IAb6We8uHul6931m2EXmR+HvTG0OZhmpF1/uU26x9MFgnK6FdwePDGk0tvyK3j1/JWqYdgzYK4oiBKdxn4AWbyXvc/ZyH7XCnGm9+hQ9JqPVgrH2cUQn5UHF8HiNGzaWSP8gDisnCbQV72mVXLwVLehbiY5GcyHQNhW2/BD/EQThK; 20:f47HMLuCUbOm04ChPqC/LAv8utGN5yngH3T2CdKiBRNrJsoPLi7tHZm5XQ/RbJhaFbAEu6SBl3wver5OhKR/SiqtW7Ty0bbDv5wid6Msu3jAjrNcTy9GwbScFO7vgsHAc3nx0wObivu/6Ovt1phbKGdr6UQ8cxbpLAVnfAhRGQel/clM3N0IgFQDR9hbUir2FwWDSmxil3/EZ/wZXPLXH1h72Zs8S2O01bQGxxZ+sq3MVrDY/slLG/o2tNoHAlu+pZHwhFZMIx39VqU6gih67tyv8kk79n0LJuflw99O6wwZFoWP5LDwJP3U+uyqMefAWV5FsHzOCzxtucCDNUbl6KlyfI9Dw5xk14PUCe82pVfxP9OsglqDxbIpBafT/YKpOUy27FZxGSmRim6Fc/WmataZewBzq1K9qsoWUYSF2wh5k6VM/u5uovzcjOsqCNmnJUfRUfhSTmK2CyUFrZZZobCy6wHvvew8h6eUotT19rwTHJS10p7IA1xSa/oqGX5G X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:DB6PR0101MB2342; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0101MB2342; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0101MB2342; 4:wR295JkzbDkWz75JyjVEEoFmBVhI7nyOZMTbJmOuBS2XH1vJElw0021UBu+dojuv+NTTRDdYnwSmvatWGV65nZIEorLDfpK2Xx3hNxQTGrXO9auY1JbL5oCtsdEJ/2Hpp6xiY+CQyWwoxjaT6nGpAwxC4wcy08vxSN8DG47NuwPvHXzsBbx7ECrf74I2Eb9z3o8GDVT+Zf0lCGbW3h/J6QxNpTQYnd41ap1QrFfG9qJH729Wk+Z2I/NFNmK/UJpzfVXE+a4BScyO6z4ezvEciAaquZYA79pdN34Q7uJQKnF5Cus9lVEtfZqL7S/fNkGfz1v2OyLgSnfXF5zvCmgIeB6TjC9Wj+35u8YOf64vqJdGDFUtr5dsyqAbeFiIbuko8x4X6qqY2oUzYtG3ZQ8zMrzJUU28ysTH2wo3xudAuFw4EBcPOx7o8pUaqhLExgsa5ThEi6zIMkmLk84ovpKAL6e2a4iQoGw9Js88irEhtXC/41yK7XvvZ7rGovy7uU5y9lVYZsGjxA4+y2oMH94YmZ9e/QUTGG2RH7aFXpdefNerUJRqjR+laU7KFSnKEomy4TL2sRbQD0ZwGAIFogzyoxNAWK9pzwLWSMoJLUQAnHozvDcgyVCd6fqAz9kNjMvKlEiZ6Xfdp1EDpG5SXLzdzg== X-Forefront-PRVS: 0218A015FA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(979002)(6009001)(7916002)(39450400003)(199003)(377424004)(189002)(50466002)(345774005)(106356001)(110136004)(105586002)(38730400002)(36756003)(97736004)(42186005)(5660300001)(6512007)(6486002)(6506006)(33656002)(54906002)(25786008)(81003)(6916009)(6306002)(92566002)(8656002)(229853002)(53936002)(86362001)(68736007)(42882006)(83716003)(66066001)(101416001)(305945005)(23676002)(47776003)(6246003)(189998001)(7736002)(82746002)(4326007)(74482002)(2906002)(6116002)(74826001)(8676002)(81156014)(81166006)(57306001)(8746002)(50226002)(50986999)(3846002)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0101MB2342; H:alex-galiss-mbp.connect; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: ucl.ac.uk does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjAxMDFNQjIzNDI7MjM6M1MzV3I3S2tJNFNaZHQ2Ui9jL1JqZjdN?= =?utf-8?B?UDFHODZZNTZqS3B1VXNsbkFEZGdKaWJjaEhkYnlBRjFNVVJDK2NjMWdZNzU3?= =?utf-8?B?VlJDdlJRVEY1U1l4QkRoWjI5Z0RqdVcrZ3hXbTZZaWIrVTYrR3dMbzdIYnZ4?= =?utf-8?B?TEZ6UWZTVngvZUtlcE00VE1RT3lZUHZJWUNVMHI2YTN4dnFEazk0SG9QSEpv?= =?utf-8?B?N2JQT05hanR5cEp1OW1Pakw5bUs4OEsxWng3RWRKbEgxVnp5cXBKWkhPK0s0?= =?utf-8?B?RndhOHFtQjV2YWtHUExLbmVLM2hDODU5cWJ5UGRYSE8rRTNna2R1OGZSdFhl?= =?utf-8?B?cCtDL09sR1dkZWVmUXBTR3FDRUJUcFc0NFhYMlpteHpXSU0rZHdmOW1oWWVD?= =?utf-8?B?MG1QTnRNNWdVVlgvOFZXclJ3QWlEV29mYVVPQk56eGY5OHBzUGJOdWxQUjlY?= =?utf-8?B?NXV1S2hRdENFZlhFN2tGSVlpOGRhVFNMMjhoYTJvNEZJYit6SU1sMVkwSFA5?= =?utf-8?B?eEJjNjNyVU1EbXFlSy9YY2VIUk1mR0lpVmthM0ZHRGZDZ2tCNWQyVGpNUUJo?= =?utf-8?B?OHNLMVNhNVlGUWswRnR4OTlIUHozemFPMzdpTW11eGtXRU4xYTdRM0k3ZE9K?= =?utf-8?B?cGZyaWp2ZGUzWjdpY2ZhclIyWW14b3NtOEVsTnZnMGEwSkZIRGRkV0dyOUNF?= =?utf-8?B?NXhWeXdraWRzWFRQTE9aMVJ1ZWFBM3U5b1l3aCt1TWRQNnpWNGsrSnFhM1h5?= =?utf-8?B?M1B2Uzl5Q1dJTlgreGdQWnpqU3c2d1FsaEoxbjJRYnpVZFh4NWZ1ODlZQlJt?= =?utf-8?B?UFlUZSs4cXNzdE42OFQ5bDJKeWd2Y3RidXl5WjhjSGcvVkdGeFRoRFh4MGpv?= =?utf-8?B?bnFyVGlha1NjZUkvRGhSbU5lS2kwTFNJZ3k1YUJzVEJNMjFNckpjNE91NitS?= =?utf-8?B?SHEyT2hReUhmSzloY2FxSlBqdEZ2U1ZXbk9oZWtsSjQ4MjJiUjFPQU11cExL?= =?utf-8?B?ekxJZzE5emF6a1JHZFlSWGdvR1ZDQ3hBWUVZeVlobU1Ramhzb0NjQUJJZHJl?= =?utf-8?B?UnovV2RaN0E1L2lMTGROeXI3ejNrVklHSVdEODNuVE44TmFzTWtkREYvK01J?= =?utf-8?B?bUM1UmNnSUdveEdmTmR2dVc5M2g4YXVxb0lZOFFLVjlKZWhabHlUM0NBOVBT?= =?utf-8?B?UEFHeW4vUnhLU0dzVkt3d0Eyc1l1bFJyOWRqYlc2VFlOMFEvRW03bmhyWjJQ?= =?utf-8?B?S0gzeUtvdmt1bkViS3QzNFBkd0oxUllzenVhbzNBcXdGcjYrK2ZXQzY2Q090?= =?utf-8?B?bnZ5MVRhR0dOME5rcFJieFFlejE4b3pmVTNPYlNWRGR2V2hSdy9uQk1LcGMx?= =?utf-8?B?WXAwRHVBZHpBWjJ0cTRJOUxySDVYM3hvaWJvakRmUDAxY0k0WGt0Nmw1a3Jw?= =?utf-8?B?NEk1M2hyK2VCUU5qbTZkdkRzVVU0TDVsTCtqd3hSOENhYzhTbEhCNkNjaWhw?= =?utf-8?B?YXFpTDc0MWErV2NGbXlOaW5VMy8zVW5hTzZwRmVOR1VNeHA3T3lha0dYc0tG?= =?utf-8?B?OXYvUlZmZzdyY2dNRXhEK3FxMXh1ZjAwbjI1eEc0bUlqOEh1UlM5Rit3aVd1?= =?utf-8?B?THA3UHJEYTBKYTBkbkVYdXJtWDBML3NCRVdYb2Nsc0F2aEY1Zk9pN0s4U2Nz?= =?utf-8?B?YXhlKysybExxYitZUzdKVk9xWkd1VWRQZzhabElrQytiRGZLRFdrc0NjcE5C?= =?utf-8?B?dlZ2M25kV1gzOU0wNlF4MlNuYkFjdXpiSWt0Nkd0T0ZuK3Z0U25ySEYxN2g0?= =?utf-8?B?NVFsN0pmZVpaYWwvbFhsWXdldGMzUnZVVndtdzg0djlBK0IrdlUvWERpb0lj?= =?utf-8?B?NjVYN0lTZnZySG0wZ010bmFYallUOGNDbXlTNVpFZ0F0ZHJKUUdoUVV3TmZI?= =?utf-8?B?NXdvcU5jWlNBZmc9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0101MB2342; 6:r0VXi+ZD4Yabwct8qAndTjyZnRreiMMtChyWpPKWvD09wsxhL0G7YTm275noPEm7A9q5pSPNmhC+tp08f/wDZillTN0PBWeiC8HO/q91T8kZtZh9aO6n1k6jagGnbrh2VYkPr0nkJxrAykEmLbmPU0lSkiHX1dNy8DQ8hBotyYQzO1HXYnDcqArivOSYVpX+wVCI5lz4eaa3GTTRo6UT8qsYQupL97NTgBj5bxT3tlWQVxZcfv8Qjdlpetid0vQctv5tiHr1lfXGew3JS8rrJvtOHuPWXMWHIl/ObngvQjGFteypN2tbFh6f5XlT3YYuoXvc8UXJ+5Wov8o1qj9IVGf4JTSALnT7uFzTKMjNs3efGmg2/KYZPXO+biqXbrcdZRJvMu3mRLAVp7cORGzB1w==; 5:7L6G485wPeYOjyH8twQOGUWUjqLFYusSA+nRGqgIL98fsVLyJOEe73Mzai361OdBSTCbTZ0KP9RcyOOdDSyd1JnSKTKwBhEMb6jT32Ur8GDbqdQrZKTWt+RMttQWoyD/8B7Tb7kqbej9xUZ3cRxQ/g==; 24:VhrLvAoIUWJMgGN1JIE3aLyLds4h8iJPWVJ7xQH/meeCZKqyyOAVLwmkbmQVVmDGECkmeIEG/wzDVhs8241WibFCCtNt1tUemCMNW++FODc= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0101MB2342; 7:MuVX0kevLkW14Q3xujVucla8EX5Mq01OOA26ct21CIhEbsWr6cjFSeGunNXWAs6wk8F0zEV/un3Kh4La3abQBmogVXL2HriWCVUHNlAT5iRFm+okQrXcSP7mWFsEifQLfzJfTIgIysl/SkjsI9nS1cExCrQ6kcFTvFuNO9TW1RV1mjJeDXZtI4flY7/Eh3oRRZk4MwZ2ZTWamsUN6haMZEjWr+d2hOA2cMMlhoB9Bu9L3zGjtKGVPKkeFE+xB0M3af4JzMLS8Ep5SkodqSZf3aVUPSCpI1dWCfMYpguSuqC/eus0nILY2OKRDPW8WPVK9NPkmciiN2F7H8DfbS3DEHZ1I2C0h8yN0pavhZ1wKL9pwtCx86TAnDutxJ/R3F4E+DxjgMIrjGvn6d4GSr15Lx22q+qHL2F8UfKFBDdzERhgxuBvPFxxE89IESre0VQCdR6ZmSjE6utBmID1VYIO5EPxt6kQ0XbF/H38ARTf8XZE5eUC7+vO4JsVuI0Bk+hESSXePKPt/SwP8dl/FgijOA== X-OriginatorOrg: ucl.ac.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2017 20:45:03.4387 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0101MB2342 Archived-At: X-Mailman-Approved-At: Tue, 14 Feb 2017 12:46:28 -0800 Cc: "Dongjie \(Jimmy\)" , "smith Kevin \(R&D\) Vodafone Group" , "Flinck, Hannu \(Nokia - FI/Espoo\)" , Pedro Martinez-Julia , "Kiran.Makhijani" , "stewart.bryant" , Mohamed Boucadair , Alex Galis , Sheng Jiang Subject: Re: [Netslices] "Network Slicing - Introductory Document and Revised Problem Statement" draft 02 X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 20:45:11 -0000 14th February 2017 Dear All, Re: "Network Slicing - Introductory Document and Revised Problem = Statement" draft 02 Thank you for your contributions, reviews and discussions on the = "Network Slicing - Introductory Document and Revised Problem = Statement=E2=80=9D draft 00. An update as draft 02 was produced and submitted to the IETF repository. This is a king request for you to consider this draft as input to : =E2=80=A2 further discussions on the mailing list. =E2=80=A2 further updates and clarifications with the view of update it = before the IETF98 In Chicago (26-31 March 2017). =E2=80=A2 starting new drafts before IETF98 In Chicago on the following = topics:=20 I) relevant use cases ;=20 II) reference model for network slices ;=20 III) Exposure Interface specification and Data model for = Network Slicing ;=20 iV) detailed problem statements (i.e. based on already = identified list of 20 problems) We are planning for a side meeting on Network Slicing at IETF 98. Best Regards Alex, Jimmy, Kiran, Stewart, Mod, Petro N.B. A new version of I-D, draft-gdmb-netslices-intro-and-ps-02.txt has been successfully submitted by Alex Galis and posted to the IETF repository. Name: draft-gdmb-netslices-intro-and-ps Revision: 02 Title: Network Slicing - Introductory Document and Revised = Problem Statement Document date: 2017-02-14 Group: Individual Submission Pages: 11 URL: = https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-and-ps-02.= txt Status: = https://datatracker.ietf.org/doc/draft-gdmb-netslices-intro-and-ps/ Htmlized: = https://tools.ietf.org/html/draft-gdmb-netslices-intro-and-ps-02 Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-gdmb-netslices-intro-and-ps-02 Abstract: This document introduces Network Slicing problems and the motivation for new work areas. It represents an initial revision of the Network Slicing problem statement derived from the analysis of the technical gaps in IETF protocols ecosystem. It complements and brings together the silo efforts being carried out in several other IETF working = groups to achieve certain aspects of Network Slicing functions and = operations. From nobody Fri Feb 17 01:54:46 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2418A129538 for ; Fri, 17 Feb 2017 01:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=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 qAmTNNy_iJKG for ; Fri, 17 Feb 2017 01:54:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83015129490 for ; Fri, 17 Feb 2017 01:47:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAT98307; Fri, 17 Feb 2017 09:47:13 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 17 Feb 2017 09:47:12 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Fri, 17 Feb 2017 17:47:07 +0800 From: "Dongjie (Jimmy)" To: Thomas Nadeau Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvq7wX2ECP+/oEWl791jc0LWbKFbjOGAgACPA4CAACspgIAASSYAgAAJHACAANcZAIAAXXSAgACuCwCAAA9qAIAAMmaAgAAIxwCAAAHCAIAAC4KAgAAGswCAAAIOgIAABikAgAfPp0CAABgjgIAGUzZA Date: Fri, 17 Feb 2017 09:48:04 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927935825EE@NKGEML515-MBX.china.huawei.com> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> <37956fc6-5f3e-bc54-4411-63721d5a299a@gmail.com> <76CD132C3ADEF848BD84D028D243C9279357E254@NKGEML515-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927935825EENKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58A6C6A2.0216, 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: 4a463013224896b063d859c77b66bc81 Archived-At: Cc: Anton Ivanov , "netslices@ietf.org" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 09:54:45 -0000 --_000_76CD132C3ADEF848BD84D028D243C927935825EENKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVG9tLA0KDQpTb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuDQoNClllcyB3ZSBwbGFuIHRvIHdy aXRlIHVwIGEgZHJhZnQgdG8gZGVzY3JpYmUgdGhlIHVzZSBjYXNlcyB3aGljaCB0cmlnZ2VycyB0 aGUgcmVxdWlyZW1lbnQgb2YgNUcgbmV0d29yayBzbGljaW5nLiBJbnB1dCBhbmQgaW52b2x2ZW1l bnQgZnJvbSBuZXR3b3JrIG9wZXJhdG9ycyBhbmQgdGhlIHBvdGVudGlhbCB1c2VycyBvZiBuZXR3 b3JrIHNsaWNlcyB3b3VsZCBiZSBtdWNoIGFwcHJlY2lhdGVkLg0KDQpCZXN0IHJlZ2FyZHMsDQpK aWUNCg0KRnJvbTogVGhvbWFzIE5hZGVhdSBbbWFpbHRvOnRuYWRlYXVAbHVjaWR2aXNpb24uY29t XQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMTQsIDIwMTcgMTowNSBBTQ0KVG86IERvbmdqaWUg KEppbW15KSA8amllLmRvbmdAaHVhd2VpLmNvbT4NCkNjOiBBbnRvbiBJdmFub3YgPGFudG9uLml2 YW5vdkBrb3QtYmVnZW1vdC5jby51az47IG5ldHNsaWNlc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtOZXRzbGljZXNdIE5ldHdvcmsgU2xpY2luZyAtIEludHJvZHVjdG9yeSBEb2N1bWVudCBhbmQg UmV2aXNlZCBQcm9ibGVtIFN0YXRlbWVudA0KDQoNCiAgIFBlcmhhcHMgeW91IGNvdWxkIHdyaXRl IHVwIGEgc2hvcnQgZHJhZnQgZXhwbGFpbmluZyB0aGUgZGV0YWlscyBvZiB0aGF0IHVzZSBjYXNl PyBPbiB0aGUgc3VyZmFjZSwgSSBjYW4gc2VlIGhvdyBleGlzdGluZw0KdGVjaCBjYW4gd29yayBi dXQgeW91IG1heSBoYXZlIHNvbWUgcmVxdWlyZW1lbnRzIHRoYXQgSSBhbSBtaXNzaW5nIGZyb20g eW91ciBoaWdoIGxldmVsIGRlc2NyaXB0aW9uLg0KDQogICDigJRUb20NCg0KDQoNCk9uIEZlYiAx MywgMjAxNzozOjQyIEFNLCBhdCAzOjQyIEFNLCBEb25namllIChKaW1teSkgPGppZS5kb25nQGh1 YXdlaS5jb208bWFpbHRvOmppZS5kb25nQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KSGkgQW50b24s DQoNClllcywgdGhlIHVzZSBjYXNlcyB3aGljaCBjYW5ub3QgYmUgZnVsbHkgbWV0IHdpdGggZXhp c3Rpbmcgc29sdXRpb25zIGFyZSBleGFjdGx5IHdoYXQgd2Ugd291bGQgbGlrZSB0byBkaXNjdXNz IG9uIHRoaXMgbWFpbGluZyBsaXN0LiBBcyB5b3Ugc2FpZCwgcXVhbnRpZmlhYmxlIHVzZSBjYXNl cyB3b3VsZCBiZSBxdWl0ZSB1c2VmdWwsIHdoaWxlIHNpbmNlIGl0IGlzIGp1c3QgdGhlIGJlZ2lu bmluZyBvZiB0aGUgbmV0d29yayBzbGljaW5nIGRpc2N1c3Npb24gaW4gSUVURiwgIHF1YWxpdGF0 aXZlIHVzZSBjYXNlcyB3b3VsZCBhbHNvIGJlIGhlbHBmdWwuIEnigJlkIGxpa2UgdG8gZW5jb3Vy YWdlIHBlb3BsZSB3aG8gaGFzIHNwZWNpZmljIHVzZSBjYXNlcyB0byBicmllZmx5IGludHJvZHVj ZSB0aGVtIHRvIHRoZSBsaXN0LCBzbyB0aGF0IHdlIGNvdWxkIGhhdmUgZnVydGhlciBkaXNjdXNz aW9uIGJhc2VkIG9uIHRoYXQuDQoNCk9uZSB1c2UgY2FzZSBkaXNjdXNzZWQgb24gdGhlIHNpZGUg bWVldGluZyBpcyB0aGUgYmFua2luZyBzZXJ2aWNlIHdoaWNoIGhhcyBzdHJpY3QgcmVxdWlyZW1l bnRzIG9uIGxvdyBsYXRlbmN5IGFuZCBzZWN1cml0eSwgY3VycmVudGx5IGl0IGlzIHN0aWxsIHVz aW5nIGEgZGVkaWNhdGVkIG5ldHdvcmsgd2hpY2ggaXMgbm90IGVjb25vbWljYWwuIElmIHdlIGFp bSB0byBtaWdyYXRlIHN1Y2gga2luZCBvZiBzZXJ2aWNlIG9udG8gdGhlIGNvbW1vbiBuZXR3b3Jr IGluZnJhc3RydWN0dXJlIGluIDVHLCB0aGUgbGF0ZW5jeSwgaXNvbGF0aW9uIGFuZCBzZWN1cml0 eSBtdXN0IGJlIGd1YXJhbnRlZWQuIEFuZCBpbiA1RyBtb3JlIGNyaXRpY2FsIHNlcnZpY2Ugc3Vj aCBhcyBpbmR1c3RyaWFsIGNvbnRyb2wsIHJlbW90ZSBzdXJnZXJ5LCBhdXRvbWF0ZWQtZHJpdmlu ZywgZXRjLiBhcmUgZW1lcmdpbmcsIHRoZXkgd291bGQgbmVlZCBndWFyYW50ZWVkIG5ldHdvcmsg cGVyZm9ybWFuY2UgYW5kIGRpZmZlcmVudCBsZXZlbHMgb2YgaXNvbGF0aW9uIGlmIHRoZSBpbmZy YXN0cnVjdHVyZSBpcyBzaGFyZWQgd2l0aCBvdGhlciBzZXJ2aWNlcy4NCg0KQmVzdCByZWdhcmRz LA0KSmllDQoNCkZyb206IE5ldHNsaWNlcyBbbWFpbHRvOm5ldHNsaWNlcy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQW50b24gSXZhbm92DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkg MDksIDIwMTcgMTI6MjEgQU0NClRvOiBuZXRzbGljZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldHNsaWNl c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTmV0c2xpY2VzXSBOZXR3b3JrIFNsaWNpbmcgLSBJ bnRyb2R1Y3RvcnkgRG9jdW1lbnQgYW5kIFJldmlzZWQgUHJvYmxlbSBTdGF0ZW1lbnQNCg0KT24g MDgvMDIvMTcgMTU6NTksIFN0ZXdhcnQgQnJ5YW50IHdyb3RlOg0KDQoNCk9uIDA4LzAyLzIwMTcg MTU6NTEsIFRob21hcyBOYWRlYXUgd3JvdGU6DQogIEkgZG9u4oCZdCBiZWxpZXZlIGFueW9uZSBp cyBzYXlpbmcgd2hhdCB3ZSBoYXZlIGlzIHBlcmZlY3QgYnkgYW55IG1lYW5zOyB3aGF0IHlvdSBz aG91bGQgYXNrIGlzOiBpcyBpdCBnb29kIGVub3VnaCB0byBhY2hpZXZlIHRoZSBnb2FscyBhbmQg cmVxdWlyZW1lbnRzIG9mIG5ldHdvcmsgb3BlcmF0b3JzPw0KDQogIOKAlFRvbQ0KDQpBZ3JlZWQs IGFuZCBhc3N1bWluZyB0aGUgZGVsYXkgaml0dGVyIGFuZCBpc29sYXRpb24gcmVxdWlyZW1lbnRz IGhvbGQgdXAsIEkgdGhpbmsgdGhlc2UgbmVlZCBuZXcgd29yay4NCg0KUGVvcGxlICB3aXRoIGV4 cGVyaWVuY2Ugb24gY29udHJvbGxlciBzeXN0ZW1zIGFuZCBtb2RlbHMgYXJlIGJldHRlciBwbGFj ZWQgdG8gY29uc2lkZXIgd2hldGhlciB0aGlzIGlzIGEgZ29vZCBlbm91Z2ggZml0IGZvciB0aGUg cmVxdWlyZW1lbnRzIHRoYXQgaGF2ZSBiZWVuIGV4cHJlc3NlZCBieSB0aGUgbW9iaWxlIG9wZXJh dG9ycy4NCg0KTXkgZXhhY3QgcG9pbnQgLSBhcyBzb21lb25lIHdobyB3b3JrcyBvbiB2YXJpb3Vz IHNvZnR3YXJlIGFzcGVjdHMgcmVsYXRlZCB0byB0aGlzLiBJIHdvdWxkIGxpa2UgdG8gc2VlIGEg bmVnYXRpdmUgdGVzdCBjYXNlIHByb3ZpbmcgdGhhdCB3aGF0IGlzIGN1cnJlbnRseSBhdmFpbGFi bGUgaXMgaW5zdWZmaWNpZW50Lg0KDQpNb3JlIGltcG9ydGFudGx5LCBJIHdvdWxkIGxpa2UgdG8g c2VlIHF1YW50aWZpYWJsZSBuZWdhdGl2ZSB0ZXN0IGNhc2UgLSB0aGUgc3R1ZmYgd2hpY2ggd2Ug cHJlc2VudGx5IGhhdmUgb24gb2ZmZXIgaXMgb2ZmIGJ5IFggdXMgKG9yIG1zKSwgWSBHYml0LCBa IHNpemUgb2YgYWRkcmVzcyBzcGFjZSBvZiAgcGFydGljdWxhciB0eXBlLCBldGMuDQoNCldlIGNh biBnZW5lcmF0ZSB0aGUgcmVxdWlyZW1lbnRzIGJhc2VkIG9uIHRoZSBkaWZmZXJlbmNlIChpZiBz dWNoIGRpZmZlcmVuY2UgY2FuIGJlIGRlbW9uc3RyYXRlZCkgYW5kIHdvcmsgb24gdGhlIGdhcCBm cm9tIHRoYXQgcG9pbnQgb253YXJkcy4NCg0KSWYgdGhlcmUgaXMgbm8gbmVnYXRpdmUgdGVzdCBj YXNlIHNob3dpbmcgYSBjbGVhciBxdWFudGlmaWFibGUgZGVmaWNpZW5jeSBpbiB0aGUgc3RhbmRh cmRzIGFuZCBhcmNoaXRlY3R1cmVzIHByZXNlbnRseSBhdmFpbGFibGUgYWNyb3NzIHRoZSBJRVRG IGFuZCB0aGUgb3RoZXIgc3RhbmRhcmQgYm9kaWVzLCB0aGVuLi4uLCB3ZWxsLi4uLCB3ZSBhcmUg YmFjayB0byBteSBvcmlnaW5hbCBhbnN3ZXI6ICJObyIuDQoNCkEuDQoNCg0KDQoNCi0gU3Rld2Fy dA0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCk5ldHNsaWNlcyBtYWlsaW5nIGxpc3QNCg0KTmV0c2xpY2VzQGlldGYub3JnPG1haWx0 bzpOZXRzbGljZXNAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0c2xpY2VzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpOZXRzbGljZXMgbWFpbGluZyBsaXN0DQpOZXRzbGljZXNAaWV0Zi5vcmc8bWFp bHRvOk5ldHNsaWNlc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0c2xpY2VzDQoNCg== --_000_76CD132C3ADEF848BD84D028D243C927935825EENKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1M IOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLmFwcGxl LXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uYXBwbGUt Y29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9 DQpzcGFuLkhUTUxDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+ 5qC85byPIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1haWxTdHlsZTIx DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIu MHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIFRvbSwNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5Tb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WWVzIHdlIHBsYW4gdG8g d3JpdGUgdXAgYSBkcmFmdCB0byBkZXNjcmliZSB0aGUgdXNlIGNhc2VzIHdoaWNoIHRyaWdnZXJz IHRoZSByZXF1aXJlbWVudCBvZiA1RyBuZXR3b3JrIHNsaWNpbmcuIElucHV0IGFuZCBpbnZvbHZl bWVudCBmcm9tIG5ldHdvcmsNCiBvcGVyYXRvcnMgYW5kIHRoZSBwb3RlbnRpYWwgdXNlcnMgb2Yg bmV0d29yayBzbGljZXMgd291bGQgYmUgbXVjaCBhcHByZWNpYXRlZC4gJm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkppZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRob21hcyBOYWRl YXUgW21haWx0bzp0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBGZWJydWFyeSAxNCwgMjAxNyAxOjA1IEFNPGJyPg0KPGI+VG86PC9iPiBEb25namll IChKaW1teSkgJmx0O2ppZS5kb25nQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBBbnRv biBJdmFub3YgJmx0O2FudG9uLml2YW5vdkBrb3QtYmVnZW1vdC5jby51ayZndDs7IG5ldHNsaWNl c0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldHNsaWNlc10gTmV0d29yayBT bGljaW5nIC0gSW50cm9kdWN0b3J5IERvY3VtZW50IGFuZCBSZXZpc2VkIFByb2JsZW0gU3RhdGVt ZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IDwvc3Bh bj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPlBlcmhhcHMgeW91IGNvdWxkIHdyaXRlIHVwIGEg c2hvcnQgZHJhZnQgZXhwbGFpbmluZyB0aGUgZGV0YWlscyBvZiB0aGF0IHVzZSBjYXNlPyBPbiB0 aGUgc3VyZmFjZSwgSSBjYW4gc2VlIGhvdyBleGlzdGluZyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+dGVj aCBjYW4gd29yayBidXQgeW91IG1heSBoYXZlIHNvbWUgcmVxdWlyZW1lbnRzIHRoYXQgSSBhbSBt aXNzaW5nIGZyb20geW91ciBoaWdoIGxldmVsIGRlc2NyaXB0aW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+4oCUVG9t PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBGZWIg MTMsIDIwMTc6Mzo0MiBBTSwgYXQgMzo0MiBBTSwgRG9uZ2ppZSAoSmltbXkpICZsdDs8YSBocmVm PSJtYWlsdG86amllLmRvbmdAaHVhd2VpLmNvbSI+amllLmRvbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQW50b24sPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlllcywgdGhlIHVzZSBjYXNlcyB3aGljaCBjYW5ub3QgYmUgZnVs bHkgbWV0IHdpdGggZXhpc3Rpbmcgc29sdXRpb25zIGFyZSBleGFjdGx5IHdoYXQgd2Ugd291bGQg bGlrZSB0byBkaXNjdXNzIG9uIHRoaXMgbWFpbGluZw0KIGxpc3QuIEFzIHlvdSBzYWlkLCBxdWFu dGlmaWFibGUgdXNlIGNhc2VzIHdvdWxkIGJlIHF1aXRlIHVzZWZ1bCwgd2hpbGUgc2luY2UgaXQg aXMganVzdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBuZXR3b3JrIHNsaWNpbmcgZGlzY3Vzc2lvbiBp biBJRVRGLCAmbmJzcDtxdWFsaXRhdGl2ZSB1c2UgY2FzZXMgd291bGQgYWxzbyBiZSBoZWxwZnVs LiBJ4oCZZCBsaWtlIHRvIGVuY291cmFnZSBwZW9wbGUgd2hvIGhhcyBzcGVjaWZpYyB1c2UgY2Fz ZXMgdG8gYnJpZWZseQ0KIGludHJvZHVjZSB0aGVtIHRvIHRoZSBsaXN0LCBzbyB0aGF0IHdlIGNv dWxkIGhhdmUgZnVydGhlciBkaXNjdXNzaW9uIGJhc2VkIG9uIHRoYXQuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPk9uZSB1c2UgY2FzZSBkaXNjdXNzZWQgb24gdGhlIHNpZGUgbWVldGluZyBpcyB0 aGUgYmFua2luZyBzZXJ2aWNlIHdoaWNoIGhhcyBzdHJpY3QgcmVxdWlyZW1lbnRzIG9uIGxvdyBs YXRlbmN5IGFuZCBzZWN1cml0eSwNCiBjdXJyZW50bHkgaXQgaXMgc3RpbGwgdXNpbmcgYSBkZWRp Y2F0ZWQgbmV0d29yayB3aGljaCBpcyBub3QgZWNvbm9taWNhbC4gSWYgd2UgYWltIHRvIG1pZ3Jh dGUgc3VjaCBraW5kIG9mIHNlcnZpY2Ugb250byB0aGUgY29tbW9uIG5ldHdvcmsgaW5mcmFzdHJ1 Y3R1cmUgaW4gNUcsIHRoZSBsYXRlbmN5LCBpc29sYXRpb24gYW5kIHNlY3VyaXR5IG11c3QgYmUg Z3VhcmFudGVlZC4gQW5kIGluIDVHIG1vcmUgY3JpdGljYWwgc2VydmljZSBzdWNoIGFzDQogaW5k dXN0cmlhbCBjb250cm9sLCByZW1vdGUgc3VyZ2VyeSwgYXV0b21hdGVkLWRyaXZpbmcsIGV0Yy4g YXJlIGVtZXJnaW5nLCB0aGV5IHdvdWxkIG5lZWQgZ3VhcmFudGVlZCBuZXR3b3JrIHBlcmZvcm1h bmNlIGFuZCBkaWZmZXJlbnQgbGV2ZWxzIG9mIGlzb2xhdGlvbiBpZiB0aGUgaW5mcmFzdHJ1Y3R1 cmUgaXMgc2hhcmVkIHdpdGggb3RoZXIgc2VydmljZXMuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkJlc3QgcmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkppZTwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5OZXRzbGljZXMNCiBbPGEgaHJlZj0ibWFp bHRvOm5ldHNsaWNlcy1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5tYWlsdG86bmV0c2xpY2VzLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl08c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5BbnRvbiBJ dmFub3Y8YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+VGh1cnNkYXksIEZlYnJ1YXJ5IDA5LCAyMDE3IDEyOjIxIEFNPGJyPg0K PGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJtYWlsdG86bmV0c2xpY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6 cHVycGxlIj5uZXRzbGljZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW05l dHNsaWNlc10gTmV0d29yayBTbGljaW5nIC0gSW50cm9kdWN0b3J5IERvY3VtZW50IGFuZCBSZXZp c2VkIFByb2JsZW0gU3RhdGVtZW50PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5PbiAwOC8wMi8x NyAxNTo1OSwgU3Rld2FydCBCcnlhbnQgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi Pk9uIDA4LzAyLzIwMTcgMTU6NTEsIFRob21hcyBOYWRlYXUgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFu Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiI+SQ0KIGRvbuKAmXQgYmVsaWV2ZSBhbnlvbmUgaXMgc2F5aW5nIHdoYXQgd2Ug aGF2ZSBpcyBwZXJmZWN0IGJ5IGFueSBtZWFuczsgd2hhdCB5b3Ugc2hvdWxkIGFzayBpczogaXMg aXQgZ29vZCBlbm91Z2ggdG8gYWNoaWV2ZSB0aGUgZ29hbHMgYW5kIHJlcXVpcmVtZW50cyBvZiBu ZXR3b3JrIG9wZXJhdG9ycz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj7igJRUb208 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyxzZXJpZiI+PGJyPg0KQWdyZWVkLCBhbmQgYXNzdW1pbmcgdGhlIGRlbGF5IGppdHRlciBhbmQg aXNvbGF0aW9uIHJlcXVpcmVtZW50cyBob2xkIHVwLCBJIHRoaW5rIHRoZXNlIG5lZWQgbmV3IHdv cmsuPGJyPg0KPGJyPg0KUGVvcGxlJm5ic3A7IHdpdGggZXhwZXJpZW5jZSBvbiBjb250cm9sbGVy IHN5c3RlbXMgYW5kIG1vZGVscyBhcmUgYmV0dGVyIHBsYWNlZCB0byBjb25zaWRlciB3aGV0aGVy IHRoaXMgaXMgYSBnb29kIGVub3VnaCBmaXQgZm9yIHRoZSByZXF1aXJlbWVudHMgdGhhdCBoYXZl IGJlZW4gZXhwcmVzc2VkIGJ5IHRoZSBtb2JpbGUgb3BlcmF0b3JzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PGJyPg0KTXkgZXhhY3Qg cG9pbnQgLSBhcyBzb21lb25lIHdobyB3b3JrcyBvbiB2YXJpb3VzIHNvZnR3YXJlIGFzcGVjdHMg cmVsYXRlZCB0byB0aGlzLiBJIHdvdWxkIGxpa2UgdG8gc2VlIGEgbmVnYXRpdmUgdGVzdCBjYXNl IHByb3ZpbmcgdGhhdCB3aGF0IGlzIGN1cnJlbnRseSBhdmFpbGFibGUgaXMgaW5zdWZmaWNpZW50 Ljxicj4NCjxicj4NCk1vcmUgaW1wb3J0YW50bHksIEkgd291bGQgbGlrZSB0byBzZWUgcXVhbnRp ZmlhYmxlIG5lZ2F0aXZlIHRlc3QgY2FzZSAtIHRoZSBzdHVmZiB3aGljaCB3ZSBwcmVzZW50bHkg aGF2ZSBvbiBvZmZlciBpcyBvZmYgYnkgWCB1cyAob3IgbXMpLCBZIEdiaXQsIFogc2l6ZSBvZiBh ZGRyZXNzIHNwYWNlIG9mJm5ic3A7IHBhcnRpY3VsYXIgdHlwZSwgZXRjLjxicj4NCjxicj4NCldl IGNhbiBnZW5lcmF0ZSB0aGUgcmVxdWlyZW1lbnRzIGJhc2VkIG9uIHRoZSBkaWZmZXJlbmNlIChp ZiBzdWNoIGRpZmZlcmVuY2UgY2FuIGJlIGRlbW9uc3RyYXRlZCkgYW5kIHdvcmsgb24gdGhlIGdh cCBmcm9tIHRoYXQgcG9pbnQgb253YXJkcy48YnI+DQo8YnI+DQpJZiB0aGVyZSBpcyBubyBuZWdh dGl2ZSB0ZXN0IGNhc2Ugc2hvd2luZyBhIGNsZWFyIHF1YW50aWZpYWJsZSBkZWZpY2llbmN5IGlu IHRoZSBzdGFuZGFyZHMgYW5kIGFyY2hpdGVjdHVyZXMgcHJlc2VudGx5IGF2YWlsYWJsZSBhY3Jv c3MgdGhlIElFVEYgYW5kIHRoZSBvdGhlciBzdGFuZGFyZCBib2RpZXMsIHRoZW4uLi4sIHdlbGwu Li4sIHdlIGFyZSBiYWNrIHRvIG15IG9yaWdpbmFsIGFuc3dlcjogJnF1b3Q7Tm8mcXVvdDsuPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxicj4N CkEuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPjxicj4NCi0gU3Rld2FydDxicj4NCjxicj4NCjxicj4NCjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHByZSBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5OZXRzbGljZXMgbWFp bGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpOZXRzbGljZXNA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPk5ldHNsaWNlc0BpZXRmLm9yZzwv c3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0c2xpY2VzIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxl Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldHNsaWNlczwvc3Bhbj48 L2E+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2JhY2tncm91bmQ6d2hpdGUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxzcGFuIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj5OZXRzbGljZXMgbWFpbGluZyBsaXN0PC9zcGFuPjxicj4NCjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOk5ldHNsaWNlc0BpZXRmLm9yZyI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj5OZXRzbGljZXNAaWV0Zi5vcmc8L3NwYW4+PC9h Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0c2xpY2VzIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6cHVycGxlO2JhY2tncm91bmQ6d2hpdGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0c2xpY2VzPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_76CD132C3ADEF848BD84D028D243C927935825EENKGEML515MBXchi_-- From nobody Fri Feb 17 01:59:06 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115EE1295D7 for ; Fri, 17 Feb 2017 01:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 zYH41J7VlG0h for ; Fri, 17 Feb 2017 01:59:02 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86141129474 for ; Fri, 17 Feb 2017 01:59:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DAU00068; Fri, 17 Feb 2017 09:58:58 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 17 Feb 2017 09:58:55 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Fri, 17 Feb 2017 17:58:52 +0800 From: "Dongjie (Jimmy)" To: Andrew McLachlan , Thomas Nadeau Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvq7wX2ECP+/oEWl791jc0LWbKFbjOGAgACPA4CAACspgIAASSYAgAAJHACAANcZAIAAXXSAgACuCwCAAA9qAIAAMmaAgAAIxwCAAAHCAIAAC4KAgAAGswCAAAIOgIAABikAgAfPp0CAABgjgIAAF2gAgAY9m/A= Date: Fri, 17 Feb 2017 09:59:50 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92793582649@NKGEML515-MBX.china.huawei.com> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> <37956fc6-5f3e-bc54-4411-63721d5a299a@gmail.com> <76CD132C3ADEF848BD84D028D243C9279357E254@NKGEML515-MBX.china.huawei.com> <0D357DFF-34D4-4224-9046-77DFF5F42759@realsdn.org> In-Reply-To: <0D357DFF-34D4-4224-9046-77DFF5F42759@realsdn.org> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C92793582649NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.58A6C963.0084, 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: 4a463013224896b063d859c77b66bc81 Archived-At: Cc: Anton Ivanov , "netslices@ietf.org" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 09:59:05 -0000 --_000_76CD132C3ADEF848BD84D028D243C92793582649NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5kcmV3LA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgY29tbWVudHMuDQoNClllcyBuZXcg c2VydmljZXMgYXJlIGVtZXJnaW5nIGluIDVHLCB3aGV0aGVyIHRoZXkgaGF2ZSBuZXcgcmVxdWly ZW1lbnQgb24gdGhlIG5ldHdvcmsgb3IgdGhleSBjYW4ganVzdCBiZSBtZXQgd2l0aCBleGlzdGlu ZyBzb2x1dGlvbnMgZGVzZXJ2ZXMgZnVydGhlciBhbmFseXNpcyBhbmQgZGlzY3Vzc2lvbi4NCg0K QXMgZm9yIHRoZSB1c2UgY2FzZXMsIEkgd291bGQgbGlrZSB0byBlbmNvdXJhZ2UgcGVvcGxlIG9u IHRoaXMgbWFpbGluZyBsaXN0IHRvIHNwZWFrIHVwIGFib3V0IHRoZSB1c2UgY2FzZSB0aGV5IGNv bnNpZGVyZWQgaW4gNUcsIGFuZCB3ZSBjYW4gc2VlIHdoYXQgYXJlIHRoZSBtaXNzaW5nIGZ1bmN0 aW9ucyBvciBjYXBhYmlsaXRpZXMgZm9yIHNwZWNpZmljIHVzZSBjYXNlLg0KDQpJIGFncmVlIHdp dGggeW91IHRoYXQgdGhlIG9yY2hlc3RyYXRpb24gZG9tYWluIGlzIGltcG9ydGFudCAgdG8gbmV0 d29yayBzbGljaW5nLCBhbmQgd2UgbmVlZCB0byBmaWd1cmUgb3V0IHdoaWNoIHBhcnQgaW4gdGhp cyBkb21haW4gc2hvdWxkIGJlIGRpc2N1c3NlZCBhbmQgZGV2ZWxvcGVkIGluIElFVEYuIENvdWxk IHlvdSBoZWxwIHdpdGggdGhpcz8NCg0KQmVzdCByZWdhcmRzLA0KSmllDQoNCkZyb206IEFuZHJl dyBNY0xhY2hsYW4gW21haWx0bzppZXRmQHJlYWxzZG4ub3JnXQ0KU2VudDogVHVlc2RheSwgRmVi cnVhcnkgMTQsIDIwMTcgMjoyOCBBTQ0KVG86IFRob21hcyBOYWRlYXUgPHRuYWRlYXVAbHVjaWR2 aXNpb24uY29tPg0KQ2M6IERvbmdqaWUgKEppbW15KSA8amllLmRvbmdAaHVhd2VpLmNvbT47IEFu dG9uIEl2YW5vdiA8YW50b24uaXZhbm92QGtvdC1iZWdlbW90LmNvLnVrPjsgbmV0c2xpY2VzQGll dGYub3JnDQpTdWJqZWN0OiBSZTogW05ldHNsaWNlc10gTmV0d29yayBTbGljaW5nIC0gSW50cm9k dWN0b3J5IERvY3VtZW50IGFuZCBSZXZpc2VkIFByb2JsZW0gU3RhdGVtZW50DQoNCg0KSGkgSmll DQoNCkkgYWdyZWUgdGhhdCB0aGVyZSBhcmUgZW1lcmdpbmcgc2NlbmFyaW9zIGluIHRoZSBtb2Jp bGUgbmV0d29ya2luZyBzcGFjZSBhbG9uZyB0aGUgbGluZXMgb2Ygd2hhdCB5b3UgaGF2ZSBkZXNj cmliZWQuIEhvd2V2ZXIgZG8gdGhleSBnZW5lcmF0ZSByZXF1aXJlbWVudHMgd2hpY2ggbmVjZXNz aXRhdGUgbmV3IHN0YW5kYXJkcy9mdW5jdGlvbnMgb3IgZW5oYW5jZW1lbnRzIHRvIGV4aXN0aW5n IHNvbHV0aW9ucz8NCg0KU28gZmFyIHRoZSBkZXNjcmliZWQgdXNlIGNhc2VzIGRvIHNlZW0gdG8g YmUgY292ZXJlZCBieSBleGlzdGluZyBtZXRob2RzLCB0aGV5IGhhdmUganVzdCBzbyBmYXIgbm90 IGJlZW4gc28gZmFyIHdpZGVseSB1c2VkIGluIHRoZSBtb2JpbGUgc3BhY2UuDQoNCkFncmVlIHdp dGggVG9tLCBhZGRpbmcgdGhhdCB0aGUgdXNlIGNhc2VzIG5lZWQgdG8gZ28gYmV5b25kIHRoZSBj b25jZXB0dWFsIHByb2JsZW0gYW5kIGludG8gc3BlY2lmaWMgbWlzc2luZyBmdW5jdGlvbnMsIHNp bmNlIHdlIGFscmVhZHkgaGF2ZSBtdWx0aXBsZSBtZXRob2RzIGZvciBzZXBhcmF0aW9uIGFuZCBh dCBtdWx0aXBsZSBsYXllcnMgdXNpbmcgZm9yIOKAmHNsaWNpbmfigJkgdXAgaW5mcmFzdHJ1Y3R1 cmVzLCBib3RoIHBoeXNpY2FsIGFuZCB2aXJ0dWFsLg0KDQpJbiBhZGRpdGlvbiBhcyBJIGhhdmUg c3RhdGVkIHByZXZpb3VzbHkgaW4gdGhpcyB0aHJlYWQsIHRoZSBwcm9ibGVtIHNwYWNlIGltbywg bGllcyBtb3N0bHkgYWJvdmUgdGhlIG5ldHdvcmsvcHJvdG9jb2wgbGF5ZXIgYW5kIG1vcmUgaW4g dGhlIG9yY2hlc3RyYXRpb24gZG9tYWluLg0KDQpBbmRyZXcNCg0KDQpPbiAxMyBGZWIgMjAxNywg YXQgMTc6MDQsIFRob21hcyBOYWRlYXUgPHRuYWRlYXVAbHVjaWR2aXNpb24uY29tPG1haWx0bzp0 bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbT4+IHdyb3RlOg0KDQoNClBlcmhhcHMgeW91IGNvdWxkIHdy aXRlIHVwIGEgc2hvcnQgZHJhZnQgZXhwbGFpbmluZyB0aGUgZGV0YWlscyBvZiB0aGF0IHVzZSBj YXNlPyBPbiB0aGUgc3VyZmFjZSwgSSBjYW4gc2VlIGhvdyBleGlzdGluZw0KdGVjaCBjYW4gd29y ayBidXQgeW91IG1heSBoYXZlIHNvbWUgcmVxdWlyZW1lbnRzIHRoYXQgSSBhbSBtaXNzaW5nIGZy b20geW91ciBoaWdoIGxldmVsIGRlc2NyaXB0aW9uLg0KDQrigJRUb20NCg0KDQoNCk9uIEZlYiAx MywgMjAxNzozOjQyIEFNLCBhdCAzOjQyIEFNLCBEb25namllIChKaW1teSkgPGppZS5kb25nQGh1 YXdlaS5jb208bWFpbHRvOmppZS5kb25nQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KSGkgQW50b24s DQoNClllcywgdGhlIHVzZSBjYXNlcyB3aGljaCBjYW5ub3QgYmUgZnVsbHkgbWV0IHdpdGggZXhp c3Rpbmcgc29sdXRpb25zIGFyZSBleGFjdGx5IHdoYXQgd2Ugd291bGQgbGlrZSB0byBkaXNjdXNz IG9uIHRoaXMgbWFpbGluZyBsaXN0LiBBcyB5b3Ugc2FpZCwgcXVhbnRpZmlhYmxlIHVzZSBjYXNl cyB3b3VsZCBiZSBxdWl0ZSB1c2VmdWwsIHdoaWxlIHNpbmNlIGl0IGlzIGp1c3QgdGhlIGJlZ2lu bmluZyBvZiB0aGUgbmV0d29yayBzbGljaW5nIGRpc2N1c3Npb24gaW4gSUVURiwgIHF1YWxpdGF0 aXZlIHVzZSBjYXNlcyB3b3VsZCBhbHNvIGJlIGhlbHBmdWwuIEnigJlkIGxpa2UgdG8gZW5jb3Vy YWdlIHBlb3BsZSB3aG8gaGFzIHNwZWNpZmljIHVzZSBjYXNlcyB0byBicmllZmx5IGludHJvZHVj ZSB0aGVtIHRvIHRoZSBsaXN0LCBzbyB0aGF0IHdlIGNvdWxkIGhhdmUgZnVydGhlciBkaXNjdXNz aW9uIGJhc2VkIG9uIHRoYXQuDQoNCk9uZSB1c2UgY2FzZSBkaXNjdXNzZWQgb24gdGhlIHNpZGUg bWVldGluZyBpcyB0aGUgYmFua2luZyBzZXJ2aWNlIHdoaWNoIGhhcyBzdHJpY3QgcmVxdWlyZW1l bnRzIG9uIGxvdyBsYXRlbmN5IGFuZCBzZWN1cml0eSwgY3VycmVudGx5IGl0IGlzIHN0aWxsIHVz aW5nIGEgZGVkaWNhdGVkIG5ldHdvcmsgd2hpY2ggaXMgbm90IGVjb25vbWljYWwuIElmIHdlIGFp bSB0byBtaWdyYXRlIHN1Y2gga2luZCBvZiBzZXJ2aWNlIG9udG8gdGhlIGNvbW1vbiBuZXR3b3Jr IGluZnJhc3RydWN0dXJlIGluIDVHLCB0aGUgbGF0ZW5jeSwgaXNvbGF0aW9uIGFuZCBzZWN1cml0 eSBtdXN0IGJlIGd1YXJhbnRlZWQuIEFuZCBpbiA1RyBtb3JlIGNyaXRpY2FsIHNlcnZpY2Ugc3Vj aCBhcyBpbmR1c3RyaWFsIGNvbnRyb2wsIHJlbW90ZSBzdXJnZXJ5LCBhdXRvbWF0ZWQtZHJpdmlu ZywgZXRjLiBhcmUgZW1lcmdpbmcsIHRoZXkgd291bGQgbmVlZCBndWFyYW50ZWVkIG5ldHdvcmsg cGVyZm9ybWFuY2UgYW5kIGRpZmZlcmVudCBsZXZlbHMgb2YgaXNvbGF0aW9uIGlmIHRoZSBpbmZy YXN0cnVjdHVyZSBpcyBzaGFyZWQgd2l0aCBvdGhlciBzZXJ2aWNlcy4NCg0KQmVzdCByZWdhcmRz LA0KSmllDQoNCkZyb206IE5ldHNsaWNlcyBbbWFpbHRvOm5ldHNsaWNlcy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQW50b24gSXZhbm92DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkg MDksIDIwMTcgMTI6MjEgQU0NClRvOiBuZXRzbGljZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldHNsaWNl c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbTmV0c2xpY2VzXSBOZXR3b3JrIFNsaWNpbmcgLSBJ bnRyb2R1Y3RvcnkgRG9jdW1lbnQgYW5kIFJldmlzZWQgUHJvYmxlbSBTdGF0ZW1lbnQNCg0KT24g MDgvMDIvMTcgMTU6NTksIFN0ZXdhcnQgQnJ5YW50IHdyb3RlOg0KDQoNCk9uIDA4LzAyLzIwMTcg MTU6NTEsIFRob21hcyBOYWRlYXUgd3JvdGU6DQogIEkgZG9u4oCZdCBiZWxpZXZlIGFueW9uZSBp cyBzYXlpbmcgd2hhdCB3ZSBoYXZlIGlzIHBlcmZlY3QgYnkgYW55IG1lYW5zOyB3aGF0IHlvdSBz aG91bGQgYXNrIGlzOiBpcyBpdCBnb29kIGVub3VnaCB0byBhY2hpZXZlIHRoZSBnb2FscyBhbmQg cmVxdWlyZW1lbnRzIG9mIG5ldHdvcmsgb3BlcmF0b3JzPw0KDQogIOKAlFRvbQ0KDQpBZ3JlZWQs IGFuZCBhc3N1bWluZyB0aGUgZGVsYXkgaml0dGVyIGFuZCBpc29sYXRpb24gcmVxdWlyZW1lbnRz IGhvbGQgdXAsIEkgdGhpbmsgdGhlc2UgbmVlZCBuZXcgd29yay4NCg0KUGVvcGxlICB3aXRoIGV4 cGVyaWVuY2Ugb24gY29udHJvbGxlciBzeXN0ZW1zIGFuZCBtb2RlbHMgYXJlIGJldHRlciBwbGFj ZWQgdG8gY29uc2lkZXIgd2hldGhlciB0aGlzIGlzIGEgZ29vZCBlbm91Z2ggZml0IGZvciB0aGUg cmVxdWlyZW1lbnRzIHRoYXQgaGF2ZSBiZWVuIGV4cHJlc3NlZCBieSB0aGUgbW9iaWxlIG9wZXJh dG9ycy4NCg0KTXkgZXhhY3QgcG9pbnQgLSBhcyBzb21lb25lIHdobyB3b3JrcyBvbiB2YXJpb3Vz IHNvZnR3YXJlIGFzcGVjdHMgcmVsYXRlZCB0byB0aGlzLiBJIHdvdWxkIGxpa2UgdG8gc2VlIGEg bmVnYXRpdmUgdGVzdCBjYXNlIHByb3ZpbmcgdGhhdCB3aGF0IGlzIGN1cnJlbnRseSBhdmFpbGFi bGUgaXMgaW5zdWZmaWNpZW50Lg0KDQpNb3JlIGltcG9ydGFudGx5LCBJIHdvdWxkIGxpa2UgdG8g c2VlIHF1YW50aWZpYWJsZSBuZWdhdGl2ZSB0ZXN0IGNhc2UgLSB0aGUgc3R1ZmYgd2hpY2ggd2Ug cHJlc2VudGx5IGhhdmUgb24gb2ZmZXIgaXMgb2ZmIGJ5IFggdXMgKG9yIG1zKSwgWSBHYml0LCBa IHNpemUgb2YgYWRkcmVzcyBzcGFjZSBvZiAgcGFydGljdWxhciB0eXBlLCBldGMuDQoNCldlIGNh biBnZW5lcmF0ZSB0aGUgcmVxdWlyZW1lbnRzIGJhc2VkIG9uIHRoZSBkaWZmZXJlbmNlIChpZiBz dWNoIGRpZmZlcmVuY2UgY2FuIGJlIGRlbW9uc3RyYXRlZCkgYW5kIHdvcmsgb24gdGhlIGdhcCBm cm9tIHRoYXQgcG9pbnQgb253YXJkcy4NCg0KSWYgdGhlcmUgaXMgbm8gbmVnYXRpdmUgdGVzdCBj YXNlIHNob3dpbmcgYSBjbGVhciBxdWFudGlmaWFibGUgZGVmaWNpZW5jeSBpbiB0aGUgc3RhbmRh cmRzIGFuZCBhcmNoaXRlY3R1cmVzIHByZXNlbnRseSBhdmFpbGFibGUgYWNyb3NzIHRoZSBJRVRG IGFuZCB0aGUgb3RoZXIgc3RhbmRhcmQgYm9kaWVzLCB0aGVuLi4uLCB3ZWxsLi4uLCB3ZSBhcmUg YmFjayB0byBteSBvcmlnaW5hbCBhbnN3ZXI6ICJObyIuDQoNCkEuDQoNCg0KDQoNCi0gU3Rld2Fy dA0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCk5ldHNsaWNlcyBtYWlsaW5nIGxpc3QNCg0KTmV0c2xpY2VzQGlldGYub3JnPG1haWx0 bzpOZXRzbGljZXNAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0c2xpY2VzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpOZXRzbGljZXMgbWFpbGluZyBsaXN0DQpOZXRzbGljZXNAaWV0Zi5vcmc8bWFp bHRvOk5ldHNsaWNlc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0c2xpY2VzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpOZXRzbGljZXMgbWFpbGluZyBsaXN0DQpOZXRzbGljZXNAaWV0Zi5vcmc8bWFp bHRvOk5ldHNsaWNlc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0c2xpY2VzDQoNCg== --_000_76CD132C3ADEF848BD84D028D243C92793582649NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg MSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6 MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovk vZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJl DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7m oLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bh bg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRl ZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5I VE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBBbmRyZXcsDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhh bmtzIGEgbG90IGZvciB5b3VyIGNvbW1lbnRzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlllcyBuZXcgc2Vydmlj ZXMgYXJlIGVtZXJnaW5nIGluIDVHLCB3aGV0aGVyIHRoZXkgaGF2ZSBuZXcgcmVxdWlyZW1lbnQg b24gdGhlIG5ldHdvcmsgb3IgdGhleSBjYW4ganVzdCBiZSBtZXQgd2l0aCBleGlzdGluZyBzb2x1 dGlvbnMgZGVzZXJ2ZXMgZnVydGhlcg0KIGFuYWx5c2lzIGFuZCBkaXNjdXNzaW9uLiA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+QXMgZm9yIHRoZSB1c2UgY2FzZXMsIEkgd291bGQgbGlrZSB0byBlbmNvdXJhZ2UgcGVv cGxlIG9uIHRoaXMgbWFpbGluZyBsaXN0IHRvIHNwZWFrIHVwIGFib3V0IHRoZSB1c2UgY2FzZSB0 aGV5IGNvbnNpZGVyZWQgaW4gNUcsIGFuZCB3ZSBjYW4gc2VlDQogd2hhdCBhcmUgdGhlIG1pc3Np bmcgZnVuY3Rpb25zIG9yIGNhcGFiaWxpdGllcyBmb3Igc3BlY2lmaWMgdXNlIGNhc2UuIDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JIGFncmVlIHdpdGggeW91IHRoYXQgdGhlIG9yY2hlc3RyYXRpb24gZG9tYWluIGlz IGltcG9ydGFudCAmbmJzcDt0byBuZXR3b3JrIHNsaWNpbmcsIGFuZCB3ZSBuZWVkIHRvIGZpZ3Vy ZSBvdXQgd2hpY2ggcGFydCBpbiB0aGlzIGRvbWFpbiBzaG91bGQgYmUgZGlzY3Vzc2VkDQogYW5k IGRldmVsb3BlZCBpbiBJRVRGLiBDb3VsZCB5b3UgaGVscCB3aXRoIHRoaXM/IDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KaWU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBBbmRyZXcgTWNMYWNo bGFuIFttYWlsdG86aWV0ZkByZWFsc2RuLm9yZ10NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5 LCBGZWJydWFyeSAxNCwgMjAxNyAyOjI4IEFNPGJyPg0KPGI+VG86PC9iPiBUaG9tYXMgTmFkZWF1 ICZsdDt0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IERvbmdqaWUg KEppbW15KSAmbHQ7amllLmRvbmdAaHVhd2VpLmNvbSZndDs7IEFudG9uIEl2YW5vdiAmbHQ7YW50 b24uaXZhbm92QGtvdC1iZWdlbW90LmNvLnVrJmd0OzsgbmV0c2xpY2VzQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbTmV0c2xpY2VzXSBOZXR3b3JrIFNsaWNpbmcgLSBJbnRyb2R1 Y3RvcnkgRG9jdW1lbnQgYW5kIFJldmlzZWQgUHJvYmxlbSBTdGF0ZW1lbnQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PkhpIEppZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ SSBhZ3JlZSB0aGF0IHRoZXJlIGFyZSBlbWVyZ2luZyBzY2VuYXJpb3MgaW4gdGhlIG1vYmlsZSBu ZXR3b3JraW5nIHNwYWNlIGFsb25nIHRoZSBsaW5lcyBvZiB3aGF0IHlvdSBoYXZlIGRlc2NyaWJl ZC4gSG93ZXZlciBkbyB0aGV5IGdlbmVyYXRlIHJlcXVpcmVtZW50cyB3aGljaCBuZWNlc3NpdGF0 ZSBuZXcgc3RhbmRhcmRzL2Z1bmN0aW9ucyBvciBlbmhhbmNlbWVudHMgdG8gZXhpc3RpbmcNCiBz b2x1dGlvbnM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5TbyBmYXIgdGhlIGRlc2NyaWJlZCB1c2UgY2FzZXMgZG8gc2VlbSB0byBiZSBjb3ZlcmVkIGJ5 IGV4aXN0aW5nIG1ldGhvZHMsIHRoZXkgaGF2ZSBqdXN0IHNvIGZhciBub3QgYmVlbiBzbyBmYXIg d2lkZWx5IHVzZWQgaW4gdGhlIG1vYmlsZSBzcGFjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFncmVlIHdpdGggVG9tLCBhZGRpbmcgdGhhdCB0aGUg dXNlIGNhc2VzIG5lZWQgdG8gZ28gYmV5b25kIHRoZSBjb25jZXB0dWFsIHByb2JsZW0gYW5kIGlu dG8gc3BlY2lmaWMgbWlzc2luZyBmdW5jdGlvbnMsIHNpbmNlIHdlIGFscmVhZHkgaGF2ZSBtdWx0 aXBsZSBtZXRob2RzIGZvciBzZXBhcmF0aW9uIGFuZCBhdCBtdWx0aXBsZSBsYXllcnMgdXNpbmcg Zm9yIOKAmHNsaWNpbmfigJkNCiB1cCBpbmZyYXN0cnVjdHVyZXMsIGJvdGggcGh5c2ljYWwgYW5k IHZpcnR1YWwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5JbiBhZGRpdGlvbiBhcyBJIGhhdmUgc3RhdGVkIHByZXZpb3VzbHkgaW4gdGhpcyB0aHJlYWQs IHRoZSBwcm9ibGVtIHNwYWNlIGltbywgbGllcyBtb3N0bHkgYWJvdmUgdGhlIG5ldHdvcmsvcHJv dG9jb2wgbGF5ZXIgYW5kIG1vcmUgaW4gdGhlIG9yY2hlc3RyYXRpb24gZG9tYWluLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QW5kcmV3PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+T24gMTMgRmViIDIwMTcsIGF0IDE3OjA0LCBUaG9tYXMgTmFkZWF1ICZsdDs8YSBocmVm PSJtYWlsdG86dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20iPnRuYWRlYXVAbHVjaWR2aXNpb24uY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyI+ PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+UGVyaGFwcyB5b3UgY291bGQgd3JpdGUg dXAgYSBzaG9ydCBkcmFmdCBleHBsYWluaW5nIHRoZSBkZXRhaWxzIG9mIHRoYXQgdXNlIGNhc2U/ IE9uIHRoZSBzdXJmYWNlLCBJIGNhbiBzZWUgaG93IGV4aXN0aW5nJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij50ZWNoIGNhbiB3b3JrIGJ1dCB5b3UgbWF5IGhhdmUgc29tZSByZXF1aXJlbWVudHMgdGhhdCBJ IGFtIG1pc3NpbmcgZnJvbSB5b3VyIGhpZ2ggbGV2ZWwgZGVzY3JpcHRpb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PHNwYW4gbGFu Zz0iRU4tVVMiPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPuKAlFRvbTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gRmViIDEzLCAyMDE3 OjM6NDIgQU0sIGF0IDM6NDIgQU0sIERvbmdqaWUgKEppbW15KSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmppZS5kb25nQGh1YXdlaS5jb20iPmppZS5kb25nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEFudG9uLDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyxzZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5ZZXMsIHRoZSB1c2UgY2FzZXMgd2hpY2ggY2Fubm90IGJlIGZ1bGx5IG1ldCB3 aXRoIGV4aXN0aW5nIHNvbHV0aW9ucyBhcmUgZXhhY3RseSB3aGF0IHdlIHdvdWxkIGxpa2UgdG8g ZGlzY3VzcyBvbiB0aGlzIG1haWxpbmcNCiBsaXN0LiBBcyB5b3Ugc2FpZCwgcXVhbnRpZmlhYmxl IHVzZSBjYXNlcyB3b3VsZCBiZSBxdWl0ZSB1c2VmdWwsIHdoaWxlIHNpbmNlIGl0IGlzIGp1c3Qg dGhlIGJlZ2lubmluZyBvZiB0aGUgbmV0d29yayBzbGljaW5nIGRpc2N1c3Npb24gaW4gSUVURiwg Jm5ic3A7cXVhbGl0YXRpdmUgdXNlIGNhc2VzIHdvdWxkIGFsc28gYmUgaGVscGZ1bC4gSeKAmWQg bGlrZSB0byBlbmNvdXJhZ2UgcGVvcGxlIHdobyBoYXMgc3BlY2lmaWMgdXNlIGNhc2VzIHRvIGJy aWVmbHkNCiBpbnRyb2R1Y2UgdGhlbSB0byB0aGUgbGlzdCwgc28gdGhhdCB3ZSBjb3VsZCBoYXZl IGZ1cnRoZXIgZGlzY3Vzc2lvbiBiYXNlZCBvbiB0aGF0Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5PbmUgdXNlIGNhc2UgZGlzY3Vzc2VkIG9uIHRoZSBzaWRlIG1lZXRpbmcgaXMgdGhlIGJhbmtp bmcgc2VydmljZSB3aGljaCBoYXMgc3RyaWN0IHJlcXVpcmVtZW50cyBvbiBsb3cgbGF0ZW5jeSBh bmQgc2VjdXJpdHksDQogY3VycmVudGx5IGl0IGlzIHN0aWxsIHVzaW5nIGEgZGVkaWNhdGVkIG5l dHdvcmsgd2hpY2ggaXMgbm90IGVjb25vbWljYWwuIElmIHdlIGFpbSB0byBtaWdyYXRlIHN1Y2gg a2luZCBvZiBzZXJ2aWNlIG9udG8gdGhlIGNvbW1vbiBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGlu IDVHLCB0aGUgbGF0ZW5jeSwgaXNvbGF0aW9uIGFuZCBzZWN1cml0eSBtdXN0IGJlIGd1YXJhbnRl ZWQuIEFuZCBpbiA1RyBtb3JlIGNyaXRpY2FsIHNlcnZpY2Ugc3VjaCBhcw0KIGluZHVzdHJpYWwg Y29udHJvbCwgcmVtb3RlIHN1cmdlcnksIGF1dG9tYXRlZC1kcml2aW5nLCBldGMuIGFyZSBlbWVy Z2luZywgdGhleSB3b3VsZCBuZWVkIGd1YXJhbnRlZWQgbmV0d29yayBwZXJmb3JtYW5jZSBhbmQg ZGlmZmVyZW50IGxldmVscyBvZiBpc29sYXRpb24gaWYgdGhlIGluZnJhc3RydWN0dXJlIGlzIHNo YXJlZCB3aXRoIG90aGVyIHNlcnZpY2VzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CZXN0IHJl Z2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5KaWU8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TmV0c2xpY2VzDQogWzxhIGhyZWY9Im1haWx0bzpuZXRz bGljZXMtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRv Om5ldHNsaWNlcy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+QW50b24gSXZhbm92PGJy Pg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPlRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxNyAxMjoyMSBBTTxicj4NCjxiPlRvOjwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOm5ldHNsaWNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ bmV0c2xpY2VzQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtOZXRzbGljZXNd IE5ldHdvcmsgU2xpY2luZyAtIEludHJvZHVjdG9yeSBEb2N1bWVudCBhbmQgUmV2aXNlZCBQcm9i bGVtIFN0YXRlbWVudDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+T24gMDgvMDIvMTcgMTU6NTks IFN0ZXdhcnQgQnJ5YW50IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5PbiAwOC8w Mi8yMDE3IDE1OjUxLCBUaG9tYXMgTmFkZWF1IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPkkNCiBkb27igJl0IGJlbGlldmUgYW55b25lIGlzIHNheWluZyB3aGF0IHdlIGhhdmUgaXMg cGVyZmVjdCBieSBhbnkgbWVhbnM7IHdoYXQgeW91IHNob3VsZCBhc2sgaXM6IGlzIGl0IGdvb2Qg ZW5vdWdoIHRvIGFjaGlldmUgdGhlIGdvYWxzIGFuZCByZXF1aXJlbWVudHMgb2YgbmV0d29yayBv cGVyYXRvcnM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0 ZSI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+4oCUVG9tPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi Pjxicj4NCkFncmVlZCwgYW5kIGFzc3VtaW5nIHRoZSBkZWxheSBqaXR0ZXIgYW5kIGlzb2xhdGlv biByZXF1aXJlbWVudHMgaG9sZCB1cCwgSSB0aGluayB0aGVzZSBuZWVkIG5ldyB3b3JrLjxicj4N Cjxicj4NClBlb3BsZSZuYnNwOyB3aXRoIGV4cGVyaWVuY2Ugb24gY29udHJvbGxlciBzeXN0ZW1z IGFuZCBtb2RlbHMgYXJlIGJldHRlciBwbGFjZWQgdG8gY29uc2lkZXIgd2hldGhlciB0aGlzIGlz IGEgZ29vZCBlbm91Z2ggZml0IGZvciB0aGUgcmVxdWlyZW1lbnRzIHRoYXQgaGF2ZSBiZWVuIGV4 cHJlc3NlZCBieSB0aGUgbW9iaWxlIG9wZXJhdG9ycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4NCk15IGV4YWN0IHBvaW50IC0g YXMgc29tZW9uZSB3aG8gd29ya3Mgb24gdmFyaW91cyBzb2Z0d2FyZSBhc3BlY3RzIHJlbGF0ZWQg dG8gdGhpcy4gSSB3b3VsZCBsaWtlIHRvIHNlZSBhIG5lZ2F0aXZlIHRlc3QgY2FzZSBwcm92aW5n IHRoYXQgd2hhdCBpcyBjdXJyZW50bHkgYXZhaWxhYmxlIGlzIGluc3VmZmljaWVudC48YnI+DQo8 YnI+DQpNb3JlIGltcG9ydGFudGx5LCBJIHdvdWxkIGxpa2UgdG8gc2VlIHF1YW50aWZpYWJsZSBu ZWdhdGl2ZSB0ZXN0IGNhc2UgLSB0aGUgc3R1ZmYgd2hpY2ggd2UgcHJlc2VudGx5IGhhdmUgb24g b2ZmZXIgaXMgb2ZmIGJ5IFggdXMgKG9yIG1zKSwgWSBHYml0LCBaIHNpemUgb2YgYWRkcmVzcyBz cGFjZSBvZiZuYnNwOyBwYXJ0aWN1bGFyIHR5cGUsIGV0Yy48YnI+DQo8YnI+DQpXZSBjYW4gZ2Vu ZXJhdGUgdGhlIHJlcXVpcmVtZW50cyBiYXNlZCBvbiB0aGUgZGlmZmVyZW5jZSAoaWYgc3VjaCBk aWZmZXJlbmNlIGNhbiBiZSBkZW1vbnN0cmF0ZWQpIGFuZCB3b3JrIG9uIHRoZSBnYXAgZnJvbSB0 aGF0IHBvaW50IG9ud2FyZHMuPGJyPg0KPGJyPg0KSWYgdGhlcmUgaXMgbm8gbmVnYXRpdmUgdGVz dCBjYXNlIHNob3dpbmcgYSBjbGVhciBxdWFudGlmaWFibGUgZGVmaWNpZW5jeSBpbiB0aGUgc3Rh bmRhcmRzIGFuZCBhcmNoaXRlY3R1cmVzIHByZXNlbnRseSBhdmFpbGFibGUgYWNyb3NzIHRoZSBJ RVRGIGFuZCB0aGUgb3RoZXIgc3RhbmRhcmQgYm9kaWVzLCB0aGVuLi4uLCB3ZWxsLi4uLCB3ZSBh cmUgYmFjayB0byBteSBvcmlnaW5hbCBhbnN3ZXI6ICZxdW90O05vJnF1b3Q7LjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpBLjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj48YnI+DQotIFN0ZXdhcnQ8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+TmV0c2xpY2VzIG1haWxpbmcgbGlz dDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86TmV0c2xpY2VzQGlldGYub3Jn Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5OZXRzbGljZXNAaWV0Zi5vcmc8L3NwYW4+PC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldHNsaWNlcyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRzbGljZXM8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtiYWNr Z3JvdW5kOndoaXRlIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+TmV0c2xpY2VzIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzpOZXRzbGljZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpwdXJw bGU7YmFja2dyb3VuZDp3aGl0ZSI+TmV0c2xpY2VzQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldHNsaWNlcyI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOnB1 cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldHNsaWNlczwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KTmV0c2xpY2VzIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpOZXRzbGljZXNAaWV0Zi5vcmciPk5ldHNsaWNlc0BpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l dHNsaWNlcyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRzbGljZXM8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_76CD132C3ADEF848BD84D028D243C92793582649NKGEML515MBXchi_-- From nobody Fri Feb 17 02:11:34 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA28F1295E5 for ; Fri, 17 Feb 2017 02:11:33 -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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 2qCRyST_Apou for ; Fri, 17 Feb 2017 02:11:31 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67530129480 for ; Fri, 17 Feb 2017 02:11:30 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGS13758; Fri, 17 Feb 2017 10:11:25 +0000 (GMT) Received: from LHREML711-CAH.china.huawei.com (10.201.108.34) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 17 Feb 2017 10:11:23 +0000 Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 17 Feb 2017 10:11:22 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Fri, 17 Feb 2017 18:11:13 +0800 From: "Dongjie (Jimmy)" To: Anton Ivanov , Thomas Nadeau Thread-Topic: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement Thread-Index: AQHScvq7wX2ECP+/oEWl791jc0LWbKFbjOGAgACPA4CAACspgIAASSYAgAAJHACAANcZAIAAXXSAgACuCwCAAA9qAIAAMmaAgAAIxwCAAAHCAIAAC4KAgAAGswCAAAIOgIAABikAgAfPp0CAABgjgIAAK7mAgAYsqCA= Date: Fri, 17 Feb 2017 10:12:12 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92793582685@NKGEML515-MBX.china.huawei.com> References: <7AE6A4247B044C4ABE0A5B6BF427F8E230A5C304@YYZEML701-CHM.china.huawei.com> <20170207003145.GN12800@spectre> <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> <37956fc6-5f3e-bc54-4411-63721d5a299a@gmail.com> <76CD132C3ADEF848BD84D028D243C9279357E254@NKGEML515-MBX.china.huawei.com> <25ffb53a-5522-e621-25ea-7c8655a8cb27@kot-begemot.co.uk> In-Reply-To: <25ffb53a-5522-e621-25ea-7c8655a8cb27@kot-begemot.co.uk> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.151.75] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C92793582685NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58A6CC4F.01E5, 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: f6548cccac4325e6ded5c70cc1387d4d Archived-At: Cc: "netslices@ietf.org" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 10:11:34 -0000 --_000_76CD132C3ADEF848BD84D028D243C92793582685NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW50b24sDQoNClRoYW5rcyBhIGxvdCBmb3IgeW91ciBmZWVkYmFja3MuDQoNCkkgbWF5IG1p c3VuZGVyc3Rvb2QgeW91ciBoZXJlLCBkbyB5b3UgbWVhbiB0aGUgdHJhZGluZyBzY2VuYXJpb3Mg d2hpY2ggY3VycmVudGx5IHJlcXVpcmUgZGVkaWNhdGVkIG5ldHdvcmsgd2lsbCBub3QgYmUgY292 ZXJlZCB3aXRoIGEgY29tbW9uIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUgaW4gZnV0dXJlPyBCdXQg NUcgYWltcyB0byBjb3ZlciB2YXJpb3VzIHZlcnRpY2FsIGluZHVzdHJpZXMgd2hpY2ggY3VycmVu dGx5IG1heSB1c2UgZGVkaWNhdGVkIG5ldHdvcmtzLiBJdCBtYXkgYmUgYmVuZWZpY2lhbCB0byBi b3RoIHRoZSBuZXR3b3JrIG9wZXJhdG9ycyBhbmQgdGhlIHZlcnRpY2FsIGluZHVzdHJ5IHVzZXJz IGlmIHN1Y2ggc3RyaW5nZW50IHNlcnZpY2UgcmVxdWlyZW1lbnRzIGNhbiBiZSBtZXQgdXNpbmcg YSBzaGFyZWQgaW5mcmFzdHJ1Y3R1cmUuDQoNCldlIHBsYW4gdG8gd3JpdGUgdXAgYSB1c2UgY2Fz ZSBkcmFmdCByZWNlbnRseSBhbmQgaXQgd291bGQgYmUgZ3JlYXQgdG8gZ2V0IGlucHV0IGZyb20g eW91IGFuZCBwZW9wbGUgb24gdGhpcyBtYWlsaW5nIGxpc3QuDQoNCkJlc3QgcmVnYXJkcywNCkpp ZQ0KDQpGcm9tOiBBbnRvbiBJdmFub3YgW21haWx0bzphbnRvbi5pdmFub3ZAa290LWJlZ2Vtb3Qu Y28udWtdDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAxNCwgMjAxNyAzOjQxIEFNDQpUbzogVGhv bWFzIE5hZGVhdSA8dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20+OyBEb25namllIChKaW1teSkgPGpp ZS5kb25nQGh1YXdlaS5jb20+DQpDYzogbmV0c2xpY2VzQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W05ldHNsaWNlc10gTmV0d29yayBTbGljaW5nIC0gSW50cm9kdWN0b3J5IERvY3VtZW50IGFuZCBS ZXZpc2VkIFByb2JsZW0gU3RhdGVtZW50DQoNCg0KKzENCg0KV2hpbGUgdGhlcmUgYXJlIHRyYWRp bmcgc2NlbmFyaW9zIHdoaWNoIGRlbWFuZCBkZWRpY2F0ZWQgbmV0d29ya3MgbW9zdCBvZiB0aGVt IGhhdmUgYmVlbiBwdXQgaW4gcGxhY2UgdG8gYWNoaWV2ZSB2ZXJ5IHNwZWNpZmljIHVzZSBjYXNl cy4gTm9uZSBvZiB0aGVzZSBoYXMgYW55IGludGVudGlvbiB0byBzaGFyZSBhcyBmYXIgYXMgSSBr bm93IGFzIHRoZXkgYXJlIHBhcnQgb2Ygd2hhdCBnaXZlcyB0aGUgY29tcGFueSB0aGUgc3BlY2lh bCBhZHZhbnRhZ2UuDQoNCkkgd291bGQgZGVmaW5pdGVseSBsaWtlIHRvIHNlZSB0aGlzIHdyaXR0 ZW4gdXAgc28gd2UgY2FuIHNlZSBob3cgd2UgY2FuIHdvcmsgdG93YXJkcyBhIFNIQVJJTkcgc29s dXRpb24gLSBzb21ldGhpbmcgd2UgY2FuIGRyaXZlIHRvd2FyZHMgYSBzdGFuZGFyZCB3aXRoaW4g dGhlIGNvbmNlcHRzIGJlaW5nIGRpc2N1c3NlZCBoZXJlLg0KDQpTbyBJIGNvbmN1ciB3aXRoIFRv bSwgSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGlzIHVzZSBjYXNlIHdyaXR0ZW4gb3V0IHNvIGl0IGNh biBiZSBhbmFseXplZCBpbiBjb250ZXh0Lg0KDQpBcyBmYXIgYXMgdGhlIG90aGVyIG9uZXMgLSBz dXJnZXJ5LCBldGMgLSB0aGUgb25lcyB0aGF0IGhhdmUga25vd24gd29ya2luZyBwcm90b3R5cGVz IHdpdGgga25vd24gYWN0dWFsIHBhcmFtZXRlcnMgY2FuIGJlIGRlYWx0IHdpdGggdXNpbmcgZXhp c3Rpbmcgc29sdXRpb25zLiBJIHdvdWxkIGJlIGludGVyZXN0ZWQgdG8gc2VlIHNvbWUgbnVtYmVy cyBwcm92aW5nIGEgc3BlY2lmaWMgdXNlIGNhc2UgdGhhdCB0aGV5IGNhbm5vdC4gU2ltaWxhciAt IGEgZHJhZnQgZGVzY3JpYmluZyBhIHVzZSBjYXNlIHdvdWxkIGJlIG5lZWRlZCBhcyBhIHBhcnQg b2YgZm9ybWluZyB0aGUgcmVxdWlyZW1lbnRzLg0KDQpBLg0KT24gMTMvMDIvMTcgMTc6MDQsIFRo b21hcyBOYWRlYXUgd3JvdGU6DQoNClBlcmhhcHMgeW91IGNvdWxkIHdyaXRlIHVwIGEgc2hvcnQg ZHJhZnQgZXhwbGFpbmluZyB0aGUgZGV0YWlscyBvZiB0aGF0IHVzZSBjYXNlPyBPbiB0aGUgc3Vy ZmFjZSwgSSBjYW4gc2VlIGhvdyBleGlzdGluZw0KdGVjaCBjYW4gd29yayBidXQgeW91IG1heSBo YXZlIHNvbWUgcmVxdWlyZW1lbnRzIHRoYXQgSSBhbSBtaXNzaW5nIGZyb20geW91ciBoaWdoIGxl dmVsIGRlc2NyaXB0aW9uLg0KDQrigJRUb20NCg0KDQoNCk9uIEZlYiAxMywgMjAxNzozOjQyIEFN LCBhdCAzOjQyIEFNLCBEb25namllIChKaW1teSkgPGppZS5kb25nQGh1YXdlaS5jb208bWFpbHRv OmppZS5kb25nQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KSGkgQW50b24sDQoNClllcywgdGhlIHVz ZSBjYXNlcyB3aGljaCBjYW5ub3QgYmUgZnVsbHkgbWV0IHdpdGggZXhpc3Rpbmcgc29sdXRpb25z IGFyZSBleGFjdGx5IHdoYXQgd2Ugd291bGQgbGlrZSB0byBkaXNjdXNzIG9uIHRoaXMgbWFpbGlu ZyBsaXN0LiBBcyB5b3Ugc2FpZCwgcXVhbnRpZmlhYmxlIHVzZSBjYXNlcyB3b3VsZCBiZSBxdWl0 ZSB1c2VmdWwsIHdoaWxlIHNpbmNlIGl0IGlzIGp1c3QgdGhlIGJlZ2lubmluZyBvZiB0aGUgbmV0 d29yayBzbGljaW5nIGRpc2N1c3Npb24gaW4gSUVURiwgIHF1YWxpdGF0aXZlIHVzZSBjYXNlcyB3 b3VsZCBhbHNvIGJlIGhlbHBmdWwuIEnigJlkIGxpa2UgdG8gZW5jb3VyYWdlIHBlb3BsZSB3aG8g aGFzIHNwZWNpZmljIHVzZSBjYXNlcyB0byBicmllZmx5IGludHJvZHVjZSB0aGVtIHRvIHRoZSBs aXN0LCBzbyB0aGF0IHdlIGNvdWxkIGhhdmUgZnVydGhlciBkaXNjdXNzaW9uIGJhc2VkIG9uIHRo YXQuDQoNCk9uZSB1c2UgY2FzZSBkaXNjdXNzZWQgb24gdGhlIHNpZGUgbWVldGluZyBpcyB0aGUg YmFua2luZyBzZXJ2aWNlIHdoaWNoIGhhcyBzdHJpY3QgcmVxdWlyZW1lbnRzIG9uIGxvdyBsYXRl bmN5IGFuZCBzZWN1cml0eSwgY3VycmVudGx5IGl0IGlzIHN0aWxsIHVzaW5nIGEgZGVkaWNhdGVk IG5ldHdvcmsgd2hpY2ggaXMgbm90IGVjb25vbWljYWwuIElmIHdlIGFpbSB0byBtaWdyYXRlIHN1 Y2gga2luZCBvZiBzZXJ2aWNlIG9udG8gdGhlIGNvbW1vbiBuZXR3b3JrIGluZnJhc3RydWN0dXJl IGluIDVHLCB0aGUgbGF0ZW5jeSwgaXNvbGF0aW9uIGFuZCBzZWN1cml0eSBtdXN0IGJlIGd1YXJh bnRlZWQuIEFuZCBpbiA1RyBtb3JlIGNyaXRpY2FsIHNlcnZpY2Ugc3VjaCBhcyBpbmR1c3RyaWFs IGNvbnRyb2wsIHJlbW90ZSBzdXJnZXJ5LCBhdXRvbWF0ZWQtZHJpdmluZywgZXRjLiBhcmUgZW1l cmdpbmcsIHRoZXkgd291bGQgbmVlZCBndWFyYW50ZWVkIG5ldHdvcmsgcGVyZm9ybWFuY2UgYW5k IGRpZmZlcmVudCBsZXZlbHMgb2YgaXNvbGF0aW9uIGlmIHRoZSBpbmZyYXN0cnVjdHVyZSBpcyBz aGFyZWQgd2l0aCBvdGhlciBzZXJ2aWNlcy4NCg0KQmVzdCByZWdhcmRzLA0KSmllDQoNCkZyb206 IE5ldHNsaWNlcyBbbWFpbHRvOm5ldHNsaWNlcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgQW50b24gSXZhbm92DQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDksIDIwMTcgMTI6MjEg QU0NClRvOiBuZXRzbGljZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldHNsaWNlc0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbTmV0c2xpY2VzXSBOZXR3b3JrIFNsaWNpbmcgLSBJbnRyb2R1Y3RvcnkgRG9j dW1lbnQgYW5kIFJldmlzZWQgUHJvYmxlbSBTdGF0ZW1lbnQNCg0KT24gMDgvMDIvMTcgMTU6NTks IFN0ZXdhcnQgQnJ5YW50IHdyb3RlOg0KDQoNCk9uIDA4LzAyLzIwMTcgMTU6NTEsIFRob21hcyBO YWRlYXUgd3JvdGU6DQogIEkgZG9u4oCZdCBiZWxpZXZlIGFueW9uZSBpcyBzYXlpbmcgd2hhdCB3 ZSBoYXZlIGlzIHBlcmZlY3QgYnkgYW55IG1lYW5zOyB3aGF0IHlvdSBzaG91bGQgYXNrIGlzOiBp cyBpdCBnb29kIGVub3VnaCB0byBhY2hpZXZlIHRoZSBnb2FscyBhbmQgcmVxdWlyZW1lbnRzIG9m IG5ldHdvcmsgb3BlcmF0b3JzPw0KDQogIOKAlFRvbQ0KDQpBZ3JlZWQsIGFuZCBhc3N1bWluZyB0 aGUgZGVsYXkgaml0dGVyIGFuZCBpc29sYXRpb24gcmVxdWlyZW1lbnRzIGhvbGQgdXAsIEkgdGhp bmsgdGhlc2UgbmVlZCBuZXcgd29yay4NCg0KUGVvcGxlICB3aXRoIGV4cGVyaWVuY2Ugb24gY29u dHJvbGxlciBzeXN0ZW1zIGFuZCBtb2RlbHMgYXJlIGJldHRlciBwbGFjZWQgdG8gY29uc2lkZXIg d2hldGhlciB0aGlzIGlzIGEgZ29vZCBlbm91Z2ggZml0IGZvciB0aGUgcmVxdWlyZW1lbnRzIHRo YXQgaGF2ZSBiZWVuIGV4cHJlc3NlZCBieSB0aGUgbW9iaWxlIG9wZXJhdG9ycy4NCg0KTXkgZXhh Y3QgcG9pbnQgLSBhcyBzb21lb25lIHdobyB3b3JrcyBvbiB2YXJpb3VzIHNvZnR3YXJlIGFzcGVj dHMgcmVsYXRlZCB0byB0aGlzLiBJIHdvdWxkIGxpa2UgdG8gc2VlIGEgbmVnYXRpdmUgdGVzdCBj YXNlIHByb3ZpbmcgdGhhdCB3aGF0IGlzIGN1cnJlbnRseSBhdmFpbGFibGUgaXMgaW5zdWZmaWNp ZW50Lg0KDQpNb3JlIGltcG9ydGFudGx5LCBJIHdvdWxkIGxpa2UgdG8gc2VlIHF1YW50aWZpYWJs ZSBuZWdhdGl2ZSB0ZXN0IGNhc2UgLSB0aGUgc3R1ZmYgd2hpY2ggd2UgcHJlc2VudGx5IGhhdmUg b24gb2ZmZXIgaXMgb2ZmIGJ5IFggdXMgKG9yIG1zKSwgWSBHYml0LCBaIHNpemUgb2YgYWRkcmVz cyBzcGFjZSBvZiAgcGFydGljdWxhciB0eXBlLCBldGMuDQoNCldlIGNhbiBnZW5lcmF0ZSB0aGUg cmVxdWlyZW1lbnRzIGJhc2VkIG9uIHRoZSBkaWZmZXJlbmNlIChpZiBzdWNoIGRpZmZlcmVuY2Ug Y2FuIGJlIGRlbW9uc3RyYXRlZCkgYW5kIHdvcmsgb24gdGhlIGdhcCBmcm9tIHRoYXQgcG9pbnQg b253YXJkcy4NCg0KSWYgdGhlcmUgaXMgbm8gbmVnYXRpdmUgdGVzdCBjYXNlIHNob3dpbmcgYSBj bGVhciBxdWFudGlmaWFibGUgZGVmaWNpZW5jeSBpbiB0aGUgc3RhbmRhcmRzIGFuZCBhcmNoaXRl Y3R1cmVzIHByZXNlbnRseSBhdmFpbGFibGUgYWNyb3NzIHRoZSBJRVRGIGFuZCB0aGUgb3RoZXIg c3RhbmRhcmQgYm9kaWVzLCB0aGVuLi4uLCB3ZWxsLi4uLCB3ZSBhcmUgYmFjayB0byBteSBvcmln aW5hbCBhbnN3ZXI6ICJObyIuDQoNCkEuDQoNCg0KDQoNCi0gU3Rld2FydA0KDQoNCg0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCk5ldHNsaWNl cyBtYWlsaW5nIGxpc3QNCg0KTmV0c2xpY2VzQGlldGYub3JnPG1haWx0bzpOZXRzbGljZXNAaWV0 Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0c2xpY2Vz DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpOZXRz bGljZXMgbWFpbGluZyBsaXN0DQpOZXRzbGljZXNAaWV0Zi5vcmc8bWFpbHRvOk5ldHNsaWNlc0Bp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0c2xpY2Vz DQoNCg0K --_000_76CD132C3ADEF848BD84D028D243C92793582685NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk65a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OuWui+S9kzsNCgljb2xvcjpibGFjazt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21z by1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNl DQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkhUTUxDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uRW1haWxTdHlsZTIy DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIu MHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBB bnRvbiwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgYSBsb3QgZm9yIHlvdXIgZmVlZGJhY2tzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JIG1heSBtaXN1bmRlcnN0b29kIHlvdXIgaGVyZSwgZG8geW91IG1lYW4gdGhlIHRy YWRpbmcgc2NlbmFyaW9zIHdoaWNoIGN1cnJlbnRseSByZXF1aXJlIGRlZGljYXRlZCBuZXR3b3Jr IHdpbGwgbm90IGJlIGNvdmVyZWQgd2l0aCBhIGNvbW1vbiBuZXR3b3JrDQogaW5mcmFzdHJ1Y3R1 cmUgaW4gZnV0dXJlPyBCdXQgNUcgYWltcyB0byBjb3ZlciB2YXJpb3VzIHZlcnRpY2FsIGluZHVz dHJpZXMgd2hpY2ggY3VycmVudGx5IG1heSB1c2UgZGVkaWNhdGVkIG5ldHdvcmtzLiBJdCBtYXkg YmUgYmVuZWZpY2lhbCB0byBib3RoIHRoZSBuZXR3b3JrIG9wZXJhdG9ycyBhbmQgdGhlIHZlcnRp Y2FsIGluZHVzdHJ5IHVzZXJzIGlmIHN1Y2ggc3RyaW5nZW50IHNlcnZpY2UgcmVxdWlyZW1lbnRz IGNhbiBiZSBtZXQgdXNpbmcNCiBhIHNoYXJlZCBpbmZyYXN0cnVjdHVyZS4gPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PldlIHBsYW4gdG8gd3JpdGUgdXAgYSB1c2UgY2FzZSBkcmFmdCByZWNlbnRseSBhbmQgaXQgd291 bGQgYmUgZ3JlYXQgdG8gZ2V0IGlucHV0IGZyb20geW91IGFuZCBwZW9wbGUgb24gdGhpcyBtYWls aW5nIGxpc3QuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SmllPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IEFudG9uIEl2YW5vdiBb bWFpbHRvOmFudG9uLml2YW5vdkBrb3QtYmVnZW1vdC5jby51a10NCjxicj4NCjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCBGZWJydWFyeSAxNCwgMjAxNyAzOjQxIEFNPGJyPg0KPGI+VG86PC9iPiBUaG9t YXMgTmFkZWF1ICZsdDt0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbSZndDs7IERvbmdqaWUgKEppbW15 KSAmbHQ7amllLmRvbmdAaHVhd2VpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG5ldHNsaWNlc0Bp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldHNsaWNlc10gTmV0d29yayBTbGlj aW5nIC0gSW50cm9kdWN0b3J5IERvY3VtZW50IGFuZCBSZXZpc2VkIFByb2JsZW0gU3RhdGVtZW50 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1VUyI+JiM0MzsxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4g bGFuZz0iRU4tVVMiPldoaWxlIHRoZXJlIGFyZSB0cmFkaW5nIHNjZW5hcmlvcyB3aGljaCBkZW1h bmQgZGVkaWNhdGVkIG5ldHdvcmtzIG1vc3Qgb2YgdGhlbSBoYXZlIGJlZW4gcHV0IGluIHBsYWNl IHRvIGFjaGlldmUgdmVyeSBzcGVjaWZpYyB1c2UgY2FzZXMuIE5vbmUgb2YgdGhlc2UgaGFzIGFu eSBpbnRlbnRpb24gdG8gc2hhcmUgYXMgZmFyIGFzIEkga25vdyBhcyB0aGV5IGFyZSBwYXJ0IG9m IHdoYXQgZ2l2ZXMgdGhlIGNvbXBhbnkNCiB0aGUgc3BlY2lhbCBhZHZhbnRhZ2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkkgd291bGQgZGVmaW5pdGVseSBs aWtlIHRvIHNlZSB0aGlzIHdyaXR0ZW4gdXAgc28gd2UgY2FuIHNlZSBob3cgd2UgY2FuIHdvcmsg dG93YXJkcyBhIFNIQVJJTkcgc29sdXRpb24gLSBzb21ldGhpbmcgd2UgY2FuIGRyaXZlIHRvd2Fy ZHMgYSBzdGFuZGFyZCB3aXRoaW4gdGhlIGNvbmNlcHRzIGJlaW5nIGRpc2N1c3NlZCBoZXJlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5TbyBJIGNvbmN1ciB3 aXRoIFRvbSwgSSB3b3VsZCBsaWtlIHRvIHNlZSB0aGlzIHVzZSBjYXNlIHdyaXR0ZW4gb3V0IHNv IGl0IGNhbiBiZSBhbmFseXplZCBpbiBjb250ZXh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIj5BcyBmYXIgYXMgdGhlIG90aGVyIG9uZXMgLSBzdXJnZXJ5LCBl dGMgLSB0aGUgb25lcyB0aGF0IGhhdmUga25vd24gd29ya2luZyBwcm90b3R5cGVzIHdpdGgga25v d24gYWN0dWFsIHBhcmFtZXRlcnMgY2FuIGJlIGRlYWx0IHdpdGggdXNpbmcgZXhpc3Rpbmcgc29s dXRpb25zLiBJIHdvdWxkIGJlIGludGVyZXN0ZWQgdG8gc2VlIHNvbWUgbnVtYmVycyBwcm92aW5n IGEgc3BlY2lmaWMgdXNlIGNhc2UgdGhhdCB0aGV5DQogY2Fubm90LiBTaW1pbGFyIC0gYSBkcmFm dCBkZXNjcmliaW5nIGEgdXNlIGNhc2Ugd291bGQgYmUgbmVlZGVkIGFzIGEgcGFydCBvZiBmb3Jt aW5nIHRoZSByZXF1aXJlbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiPkEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiAxMy8wMi8xNyAxNzowNCwgVGhvbWFzIE5hZGVh dSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWIt c3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PlBlcmhhcHMgeW91IGNvdWxkIHdyaXRlIHVwIGEgc2hvcnQgZHJhZnQgZXhwbGFpbmluZyB0aGUg ZGV0YWlscyBvZiB0aGF0IHVzZSBjYXNlPyBPbiB0aGUgc3VyZmFjZSwgSSBjYW4gc2VlIGhvdyBl eGlzdGluZyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj50ZWNoIGNhbiB3b3JrIGJ1dCB5b3UgbWF5IGhh dmUgc29tZSByZXF1aXJlbWVudHMgdGhhdCBJIGFtIG1pc3NpbmcgZnJvbSB5b3VyIGhpZ2ggbGV2 ZWwgZGVzY3JpcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNz PSJhcHBsZS10YWItc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiPjwvc3Bhbj48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPuKAlFRvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+T24gRmViIDEzLCAyMDE3OjM6NDIgQU0sIGF0IDM6NDIgQU0sIERvbmdqaWUg KEppbW15KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmppZS5kb25nQGh1YXdlaS5jb20iPmppZS5kb25n QGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkhpIEFudG9uLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5ZZXMsIHRoZSB1c2UgY2FzZXMg d2hpY2ggY2Fubm90IGJlIGZ1bGx5IG1ldCB3aXRoIGV4aXN0aW5nIHNvbHV0aW9ucyBhcmUgZXhh Y3RseSB3aGF0IHdlIHdvdWxkIGxpa2UgdG8gZGlzY3VzcyBvbiB0aGlzIG1haWxpbmcNCiBsaXN0 LiBBcyB5b3Ugc2FpZCwgcXVhbnRpZmlhYmxlIHVzZSBjYXNlcyB3b3VsZCBiZSBxdWl0ZSB1c2Vm dWwsIHdoaWxlIHNpbmNlIGl0IGlzIGp1c3QgdGhlIGJlZ2lubmluZyBvZiB0aGUgbmV0d29yayBz bGljaW5nIGRpc2N1c3Npb24gaW4gSUVURiwgJm5ic3A7cXVhbGl0YXRpdmUgdXNlIGNhc2VzIHdv dWxkIGFsc28gYmUgaGVscGZ1bC4gSeKAmWQgbGlrZSB0byBlbmNvdXJhZ2UgcGVvcGxlIHdobyBo YXMgc3BlY2lmaWMgdXNlIGNhc2VzIHRvIGJyaWVmbHkNCiBpbnRyb2R1Y2UgdGhlbSB0byB0aGUg bGlzdCwgc28gdGhhdCB3ZSBjb3VsZCBoYXZlIGZ1cnRoZXIgZGlzY3Vzc2lvbiBiYXNlZCBvbiB0 aGF0Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5PbmUgdXNlIGNhc2UgZGlzY3Vzc2VkIG9uIHRo ZSBzaWRlIG1lZXRpbmcgaXMgdGhlIGJhbmtpbmcgc2VydmljZSB3aGljaCBoYXMgc3RyaWN0IHJl cXVpcmVtZW50cyBvbiBsb3cgbGF0ZW5jeSBhbmQgc2VjdXJpdHksDQogY3VycmVudGx5IGl0IGlz IHN0aWxsIHVzaW5nIGEgZGVkaWNhdGVkIG5ldHdvcmsgd2hpY2ggaXMgbm90IGVjb25vbWljYWwu IElmIHdlIGFpbSB0byBtaWdyYXRlIHN1Y2gga2luZCBvZiBzZXJ2aWNlIG9udG8gdGhlIGNvbW1v biBuZXR3b3JrIGluZnJhc3RydWN0dXJlIGluIDVHLCB0aGUgbGF0ZW5jeSwgaXNvbGF0aW9uIGFu ZCBzZWN1cml0eSBtdXN0IGJlIGd1YXJhbnRlZWQuIEFuZCBpbiA1RyBtb3JlIGNyaXRpY2FsIHNl cnZpY2Ugc3VjaCBhcw0KIGluZHVzdHJpYWwgY29udHJvbCwgcmVtb3RlIHN1cmdlcnksIGF1dG9t YXRlZC1kcml2aW5nLCBldGMuIGFyZSBlbWVyZ2luZywgdGhleSB3b3VsZCBuZWVkIGd1YXJhbnRl ZWQgbmV0d29yayBwZXJmb3JtYW5jZSBhbmQgZGlmZmVyZW50IGxldmVscyBvZiBpc29sYXRpb24g aWYgdGhlIGluZnJhc3RydWN0dXJlIGlzIHNoYXJlZCB3aXRoIG90aGVyIHNlcnZpY2VzLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5KaWU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+TmV0c2xpY2VzDQog WzxhIGhyZWY9Im1haWx0bzpuZXRzbGljZXMtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+bWFpbHRvOm5ldHNsaWNlcy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwv YT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9u IEJlaGFsZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L2I+QW50b24gSXZhbm92PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBGZWJydWFyeSAwOSwgMjAxNyAx MjoyMSBBTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5ldHNsaWNlc0BpZXRmLm9yZyI+PHNwYW4g c3R5bGU9ImNvbG9yOnB1cnBsZSI+bmV0c2xpY2VzQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8 Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+UmU6IFtOZXRzbGljZXNdIE5ldHdvcmsgU2xpY2luZyAtIEludHJvZHVjdG9yeSBEb2N1 bWVudCBhbmQgUmV2aXNlZCBQcm9ibGVtIFN0YXRlbWVudDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZiI+T24gMDgvMDIvMTcgMTU6NTksIFN0ZXdhcnQgQnJ5YW50IHdyb3RlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3Jv dW5kOndoaXRlIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIj5PbiAwOC8wMi8yMDE3IDE1OjUxLCBUaG9tYXMgTmFkZWF1IHdyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGNsYXNzPSJh cHBsZS10YWItc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bh bj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkkNCiBkb27igJl0IGJlbGlldmUgYW55b25lIGlzIHNh eWluZyB3aGF0IHdlIGhhdmUgaXMgcGVyZmVjdCBieSBhbnkgbWVhbnM7IHdoYXQgeW91IHNob3Vs ZCBhc2sgaXM6IGlzIGl0IGdvb2QgZW5vdWdoIHRvIGFjaGlldmUgdGhlIGdvYWxzIGFuZCByZXF1 aXJlbWVudHMgb2YgbmV0d29yayBvcGVyYXRvcnM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+4oCUVG9tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxicj4NCkFncmVlZCwgYW5kIGFzc3VtaW5nIHRoZSBkZWxh eSBqaXR0ZXIgYW5kIGlzb2xhdGlvbiByZXF1aXJlbWVudHMgaG9sZCB1cCwgSSB0aGluayB0aGVz ZSBuZWVkIG5ldyB3b3JrLjxicj4NCjxicj4NClBlb3BsZSZuYnNwOyB3aXRoIGV4cGVyaWVuY2Ug b24gY29udHJvbGxlciBzeXN0ZW1zIGFuZCBtb2RlbHMgYXJlIGJldHRlciBwbGFjZWQgdG8gY29u c2lkZXIgd2hldGhlciB0aGlzIGlzIGEgZ29vZCBlbm91Z2ggZml0IGZvciB0aGUgcmVxdWlyZW1l bnRzIHRoYXQgaGF2ZSBiZWVuIGV4cHJlc3NlZCBieSB0aGUgbW9iaWxlIG9wZXJhdG9ycy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPjxi cj4NCk15IGV4YWN0IHBvaW50IC0gYXMgc29tZW9uZSB3aG8gd29ya3Mgb24gdmFyaW91cyBzb2Z0 d2FyZSBhc3BlY3RzIHJlbGF0ZWQgdG8gdGhpcy4gSSB3b3VsZCBsaWtlIHRvIHNlZSBhIG5lZ2F0 aXZlIHRlc3QgY2FzZSBwcm92aW5nIHRoYXQgd2hhdCBpcyBjdXJyZW50bHkgYXZhaWxhYmxlIGlz IGluc3VmZmljaWVudC48YnI+DQo8YnI+DQpNb3JlIGltcG9ydGFudGx5LCBJIHdvdWxkIGxpa2Ug dG8gc2VlIHF1YW50aWZpYWJsZSBuZWdhdGl2ZSB0ZXN0IGNhc2UgLSB0aGUgc3R1ZmYgd2hpY2gg d2UgcHJlc2VudGx5IGhhdmUgb24gb2ZmZXIgaXMgb2ZmIGJ5IFggdXMgKG9yIG1zKSwgWSBHYml0 LCBaIHNpemUgb2YgYWRkcmVzcyBzcGFjZSBvZiZuYnNwOyBwYXJ0aWN1bGFyIHR5cGUsIGV0Yy48 YnI+DQo8YnI+DQpXZSBjYW4gZ2VuZXJhdGUgdGhlIHJlcXVpcmVtZW50cyBiYXNlZCBvbiB0aGUg ZGlmZmVyZW5jZSAoaWYgc3VjaCBkaWZmZXJlbmNlIGNhbiBiZSBkZW1vbnN0cmF0ZWQpIGFuZCB3 b3JrIG9uIHRoZSBnYXAgZnJvbSB0aGF0IHBvaW50IG9ud2FyZHMuPGJyPg0KPGJyPg0KSWYgdGhl cmUgaXMgbm8gbmVnYXRpdmUgdGVzdCBjYXNlIHNob3dpbmcgYSBjbGVhciBxdWFudGlmaWFibGUg ZGVmaWNpZW5jeSBpbiB0aGUgc3RhbmRhcmRzIGFuZCBhcmNoaXRlY3R1cmVzIHByZXNlbnRseSBh dmFpbGFibGUgYWNyb3NzIHRoZSBJRVRGIGFuZCB0aGUgb3RoZXIgc3RhbmRhcmQgYm9kaWVzLCB0 aGVuLi4uLCB3ZWxsLi4uLCB3ZSBhcmUgYmFjayB0byBteSBvcmlnaW5hbCBhbnN3ZXI6ICZxdW90 O05vJnF1b3Q7LjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YnI+DQo8YnI+DQpBLjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj48YnI+DQotIFN0ZXdhcnQ8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwcmUgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ TmV0c2xpY2VzIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJtYWls dG86TmV0c2xpY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5OZXRzbGlj ZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldHNsaWNlcyI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRz bGljZXM8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO2JhY2tncm91bmQ6d2hpdGUiPg0KPHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtiYWNrZ3JvdW5kOndoaXRlIj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8c3Bh biBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+TmV0c2xpY2VzIG1haWxpbmcgbGlzdDwvc3Bhbj48 YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzpOZXRzbGljZXNA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpwdXJwbGU7YmFja2dyb3VuZDp3aGl0ZSI+TmV0c2xpY2VzQGlldGYu b3JnPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldHNsaWNlcyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOnB1cnBsZTtiYWNrZ3JvdW5kOndoaXRlIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldHNsaWNlczwvc3Bhbj48L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_76CD132C3ADEF848BD84D028D243C92793582685NKGEML515MBXchi_-- From nobody Fri Feb 17 10:49:44 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 042F4129572 for ; Fri, 17 Feb 2017 10:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 SUo4jtFeOiWV for ; Fri, 17 Feb 2017 10:49:40 -0800 (PST) Received: from www.kot-begemot.co.uk (ivanoab5.miniserver.com [78.31.111.25]) (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 ADF5D1295EC for ; Fri, 17 Feb 2017 10:49:38 -0800 (PST) Received: from tun5.smaug.kot-begemot.co.uk ([192.168.18.6] helo=smaug.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cenat-0004KM-Vk; Fri, 17 Feb 2017 18:49:24 +0000 Received: from [185.69.145.185] (helo=[10.1.218.114]) by smaug.kot-begemot.co.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cenat-0001P5-H6; Fri, 17 Feb 2017 18:49:23 +0000 User-Agent: K-9 Mail for Android In-Reply-To: <76CD132C3ADEF848BD84D028D243C92793582685@NKGEML515-MBX.china.huawei.com> References: <20170207052610.GT12800@spectre> <20170207235031.GV12800@spectre> <46a48875-341f-8cb8-eeb9-46cdb52f7035@gmail.com> <5336C72F-FDDA-4303-876F-576C3F14F7C3@juniper.net> <9504631E-05C0-40A2-BBE2-BC678E349AE0@ucl.ac.uk> <75CB3375-DBF2-471A-BC74-5ACC7E5E480E@realsdn.org> <3678e77a-1f6a-b710-5830-722d3bde42f2@gmail.com> <37956fc6-5f3e-bc54-4411-63721d5a299a@gmail.com> <76CD132C3ADEF848BD84D028D243C9279357E254@NKGEML515-MBX.china.huawei.com> <25ffb53a-5522-e621-25ea-7c8655a8cb27@kot-begemot.co.uk> <76CD132C3ADEF848BD84D028D243C92793582685@NKGEML515-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----8WMHX9PYZSAQ203K3A66X56WWLBN5W" Content-Transfer-Encoding: 8bit From: Anton Ivanov Date: Fri, 17 Feb 2017 19:49:12 +0100 To: "Dongjie (Jimmy)" , Thomas Nadeau Message-ID: X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Cc: "netslices@ietf.org" Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 18:49:43 -0000 ------8WMHX9PYZSAQ203K3A66X56WWLBN5W Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 You have the wrong vertical example. If you cater for what dedicated is used today, the trading engineering will move the goalposts. Industries with active technological arms races do not make good standardisation material. You have to be past the arms race stage and into the common ground stage. On 17 February 2017 11:12:12 CET, "Dongjie (Jimmy)" wrote: >Hi Anton, > >Thanks a lot for your feedbacks. > >I may misunderstood your here, do you mean the trading scenarios which >currently require dedicated network will not be covered with a common >network infrastructure in future? But 5G aims to cover various vertical >industries which currently may use dedicated networks. It may be >beneficial to both the network operators and the vertical industry >users if such stringent service requirements can be met using a shared >infrastructure. > >We plan to write up a use case draft recently and it would be great to >get input from you and people on this mailing list. > >Best regards, >Jie > >From: Anton Ivanov [mailto:anton.ivanov@kot-begemot.co.uk] >Sent: Tuesday, February 14, 2017 3:41 AM >To: Thomas Nadeau ; Dongjie (Jimmy) > >Cc: netslices@ietf.org >Subject: Re: [Netslices] Network Slicing - Introductory Document and >Revised Problem Statement > > >+1 > >While there are trading scenarios which demand dedicated networks most >of them have been put in place to achieve very specific use cases. None >of these has any intention to share as far as I know as they are part >of what gives the company the special advantage. > >I would definitely like to see this written up so we can see how we can >work towards a SHARING solution - something we can drive towards a >standard within the concepts being discussed here. > >So I concur with Tom, I would like to see this use case written out so >it can be analyzed in context. > >As far as the other ones - surgery, etc - the ones that have known >working prototypes with known actual parameters can be dealt with using >existing solutions. I would be interested to see some numbers proving a >specific use case that they cannot. Similar - a draft describing a use >case would be needed as a part of forming the requirements. > >A. >On 13/02/17 17:04, Thomas Nadeau wrote: > >Perhaps you could write up a short draft explaining the details of that >use case? On the surface, I can see how existing >tech can work but you may have some requirements that I am missing from >your high level description. > >—Tom > > > >On Feb 13, 2017:3:42 AM, at 3:42 AM, Dongjie (Jimmy) >> wrote: > >Hi Anton, > >Yes, the use cases which cannot be fully met with existing solutions >are exactly what we would like to discuss on this mailing list. As you >said, quantifiable use cases would be quite useful, while since it is >just the beginning of the network slicing discussion in IETF, >qualitative use cases would also be helpful. I’d like to encourage >people who has specific use cases to briefly introduce them to the >list, so that we could have further discussion based on that. > >One use case discussed on the side meeting is the banking service which >has strict requirements on low latency and security, currently it is >still using a dedicated network which is not economical. If we aim to >migrate such kind of service onto the common network infrastructure in >5G, the latency, isolation and security must be guaranteed. And in 5G >more critical service such as industrial control, remote surgery, >automated-driving, etc. are emerging, they would need guaranteed >network performance and different levels of isolation if the >infrastructure is shared with other services. > >Best regards, >Jie > >From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Anton >Ivanov >Sent: Thursday, February 09, 2017 12:21 AM >To: netslices@ietf.org >Subject: Re: [Netslices] Network Slicing - Introductory Document and >Revised Problem Statement > >On 08/02/17 15:59, Stewart Bryant wrote: > > >On 08/02/2017 15:51, Thomas Nadeau wrote: >I don’t believe anyone is saying what we have is perfect by any means; >what you should ask is: is it good enough to achieve the goals and >requirements of network operators? > > —Tom > >Agreed, and assuming the delay jitter and isolation requirements hold >up, I think these need new work. > >People with experience on controller systems and models are better >placed to consider whether this is a good enough fit for the >requirements that have been expressed by the mobile operators. > >My exact point - as someone who works on various software aspects >related to this. I would like to see a negative test case proving that >what is currently available is insufficient. > >More importantly, I would like to see quantifiable negative test case - >the stuff which we presently have on offer is off by X us (or ms), Y >Gbit, Z size of address space of particular type, etc. > >We can generate the requirements based on the difference (if such >difference can be demonstrated) and work on the gap from that point >onwards. > >If there is no negative test case showing a clear quantifiable >deficiency in the standards and architectures presently available >across the IETF and the other standard bodies, then..., well..., we are >back to my original answer: "No". > >A. > > > > >- Stewart > > > > > >_______________________________________________ > >Netslices mailing list > >Netslices@ietf.org > >https://www.ietf.org/mailman/listinfo/netslices > >_______________________________________________ >Netslices mailing list >Netslices@ietf.org >https://www.ietf.org/mailman/listinfo/netslices -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ------8WMHX9PYZSAQ203K3A66X56WWLBN5W Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit You have the wrong vertical example. If you cater for what dedicated is used today, the trading engineering will move the goalposts.

Industries with active technological arms races do not make good standardisation material. You have to be past the arms race stage and into the common ground stage.

On 17 February 2017 11:12:12 CET, "Dongjie (Jimmy)" <jie.dong@huawei.com> wrote:

Hi Anton,

 

Thanks a lot for your feedbacks.

 

I may misunderstood your here, do you mean the trading scenarios which currently require dedicated network will not be covered with a common network infrastructure in future? But 5G aims to cover various vertical industries which currently may use dedicated networks. It may be beneficial to both the network operators and the vertical industry users if such stringent service requirements can be met using a shared infrastructure.

 

We plan to write up a use case draft recently and it would be great to get input from you and people on this mailing list.

 

Best regards,

Jie

 

From: Anton Ivanov [mailto:anton.ivanov@kot-begemot.co.uk]
Sent: Tuesday, February 14, 2017 3:41 AM
To: Thomas Nadeau <tnadeau@lucidvision.com>; Dongjie (Jimmy) <jie.dong@huawei.com>
Cc: netslices@ietf.org
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

 

+1

While there are trading scenarios which demand dedicated networks most of them have been put in place to achieve very specific use cases. None of these has any intention to share as far as I know as they are part of what gives the company the special advantage.

I would definitely like to see this written up so we can see how we can work towards a SHARING solution - something we can drive towards a standard within the concepts being discussed here.

So I concur with Tom, I would like to see this use case written out so it can be analyzed in context.

As far as the other ones - surgery, etc - the ones that have known working prototypes with known actual parameters can be dealt with using existing solutions. I would be interested to see some numbers proving a specific use case that they cannot. Similar - a draft describing a use case would be needed as a part of forming the requirements.

A.

On 13/02/17 17:04, Thomas Nadeau wrote:

 

Perhaps you could write up a short draft explaining the details of that use case? On the surface, I can see how existing 

tech can work but you may have some requirements that I am missing from your high level description.

 

—Tom

 

 

 

On Feb 13, 2017:3:42 AM, at 3:42 AM, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

 

Hi Anton,

 

Yes, the use cases which cannot be fully met with existing solutions are exactly what we would like to discuss on this mailing list. As you said, quantifiable use cases would be quite useful, while since it is just the beginning of the network slicing discussion in IETF,  qualitative use cases would also be helpful. I’d like to encourage people who has specific use cases to briefly introduce them to the list, so that we could have further discussion based on that.

 

One use case discussed on the side meeting is the banking service which has strict requirements on low latency and security, currently it is still using a dedicated network which is not economical. If we aim to migrate such kind of service onto the common network infrastructure in 5G, the latency, isolation and security must be guaranteed. And in 5G more critical service such as industrial control, remote surgery, automated-driving, etc. are emerging, they would need guaranteed network performance and different levels of isolation if the infrastructure is shared with other services.

 

Best regards,

Jie

 

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Anton Ivanov
Sent: Thursday, February 09, 2017 12:21 AM
To: netslices@ietf.org
Subject: Re: [Netslices] Network Slicing - Introductory Document and Revised Problem Statement

 

On 08/02/17 15:59, Stewart Bryant wrote:

 

 

On 08/02/2017 15:51, Thomas Nadeau wrote:

  I don’t believe anyone is saying what we have is perfect by any means; what you should ask is: is it good enough to achieve the goals and requirements of network operators?

 

  —Tom


Agreed, and assuming the delay jitter and isolation requirements hold up, I think these need new work.

People  with experience on controller systems and models are better placed to consider whether this is a good enough fit for the requirements that have been expressed by the mobile operators.


My exact point - as someone who works on various software aspects related to this. I would like to see a negative test case proving that what is currently available is insufficient.

More importantly, I would like to see quantifiable negative test case - the stuff which we presently have on offer is off by X us (or ms), Y Gbit, Z size of address space of  particular type, etc.

We can generate the requirements based on the difference (if such difference can be demonstrated) and work on the gap from that point onwards.

If there is no negative test case showing a clear quantifiable deficiency in the standards and architectures presently available across the IETF and the other standard bodies, then..., well..., we are back to my original answer: "No". 

A.




- Stewart




_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

 

_______________________________________________
Netslices mailing list
Netslices@ietf.org
https://www.ietf.org/mailman/listinfo/netslices

 

 


--
Sent from my Android device with K-9 Mail. Please excuse my brevity. ------8WMHX9PYZSAQ203K3A66X56WWLBN5W-- From nobody Mon Feb 20 07:04:02 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68371129506 for ; Mon, 20 Feb 2017 07:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2uoEwhm00Tnr for ; Mon, 20 Feb 2017 07:03:58 -0800 (PST) Received: from www.kot-begemot.co.uk (ivanoab5.miniserver.com [78.31.111.25]) (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 3246512947F for ; Mon, 20 Feb 2017 07:03:57 -0800 (PST) Received: from tun5.smaug.kot-begemot.co.uk ([192.168.18.6] helo=smaug.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cfpVJ-0005us-Az for netslices@ietf.org; Mon, 20 Feb 2017 15:03:53 +0000 Received: from monstrousnightmare.kot-begemot.co.uk ([192.168.11.207]) by smaug.kot-begemot.co.uk with esmtp (Exim 4.84_2) (envelope-from ) id 1cfpVJ-0002K6-4O for netslices@ietf.org; Mon, 20 Feb 2017 15:03:53 +0000 To: netslices@ietf.org References: <5B526793-E0F0-4842-9D22-5DEC416154D1@ucl.ac.uk> From: Anton Ivanov Message-ID: <27da3ef9-e145-39f0-c92f-252c83e61627@kot-begemot.co.uk> Date: Mon, 20 Feb 2017 15:03:50 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <5B526793-E0F0-4842-9D22-5DEC416154D1@ucl.ac.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Netslices] "Network Slicing - Introductory Document and Revised Problem Statement" draft 02 X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 15:04:00 -0000 Questions: 1. What do you mean under "four-dimensional"? 2. Operations - most of that sounds like defining a FSM and a matching model. Thus - the model for slices should not sit as a small sub-point of the last bullet point. It is where you start (along with the FSM). 3. Notes - half of that goes away once you define the FSM - they are just transitions along the FSM and relevant model changes. As a side effect of 2+3 once that is defined it becomes a simple manner of coding said FSM and orchestrating how it effects network and cloud resources unless we get bogged down in the end-to-end QoS swamp. That particular swamp probably needs some narrowing down in order to have a viable problem statement. Doing it to cover all possible arbitrary ideas of end-to-end QoS is just not feasible. That has been tried quite a few times and has been unsuccessful every time. So a narrowed down definition of supported end-to-end qos metrics and a matching model is needed as a part of defining the problem statement. A. On 14/02/17 20:45, Alex Galis wrote: > 14th February 2017 > > Dear All, > > Re: "Network Slicing - Introductory Document and Revised Problem Statement" draft 02 > > > Thank you for your contributions, reviews and discussions on the "Network Slicing - Introductory Document and Revised Problem Statement” draft 00. > > An update as draft 02 was produced and submitted to the IETF repository. > > This is a king request for you to consider this draft as input to : > > • further discussions on the mailing list. > • further updates and clarifications with the view of update it before the IETF98 In Chicago (26-31 March 2017). > • starting new drafts before IETF98 In Chicago on the following topics: > I) relevant use cases ; > II) reference model for network slices ; > III) Exposure Interface specification and Data model for Network Slicing ; > iV) detailed problem statements (i.e. based on already identified list of 20 problems) > > We are planning for a side meeting on Network Slicing at IETF 98. > > Best Regards > > Alex, Jimmy, Kiran, Stewart, Mod, Petro > > > > N.B. A new version of I-D, draft-gdmb-netslices-intro-and-ps-02.txt > has been successfully submitted by Alex Galis and posted to the > IETF repository. > > Name: draft-gdmb-netslices-intro-and-ps > Revision: 02 > Title: Network Slicing - Introductory Document and Revised Problem Statement > Document date: 2017-02-14 > Group: Individual Submission > Pages: 11 > URL: https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-and-ps-02.txt > Status: https://datatracker.ietf.org/doc/draft-gdmb-netslices-intro-and-ps/ > Htmlized: https://tools.ietf.org/html/draft-gdmb-netslices-intro-and-ps-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-gdmb-netslices-intro-and-ps-02 > > Abstract: > This document introduces Network Slicing problems and the motivation > for new work areas. It represents an initial revision of the Network > Slicing problem statement derived from the analysis of the technical > gaps in IETF protocols ecosystem. It complements and brings together > the silo efforts being carried out in several other IETF working groups > to achieve certain aspects of Network Slicing functions and operations. > > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices From nobody Mon Feb 20 22:57:28 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5444312986D for ; Mon, 20 Feb 2017 22:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 3wI2W-ZSdS3s for ; Mon, 20 Feb 2017 22:57:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83AD41289B0 for ; Mon, 20 Feb 2017 22:57:23 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHG05143; Tue, 21 Feb 2017 06:57:21 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 21 Feb 2017 06:57:20 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML703-CHM.china.huawei.com ([169.254.5.69]) with mapi id 14.03.0235.001; Mon, 20 Feb 2017 22:57:12 -0800 From: "Kiran.Makhijani" To: Anton Ivanov , "netslices@ietf.org" Thread-Topic: [Netslices] "Network Slicing - Introductory Document and Revised Problem Statement" draft 02 Thread-Index: AQHShwNAj/AeqtDQAE+1CWATvJ1iPKFyjSsAgACEPoA= Date: Tue, 21 Feb 2017 06:57:11 +0000 Message-ID: References: <5B526793-E0F0-4842-9D22-5DEC416154D1@ucl.ac.uk> <27da3ef9-e145-39f0-c92f-252c83e61627@kot-begemot.co.uk> In-Reply-To: <27da3ef9-e145-39f0-c92f-252c83e61627@kot-begemot.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.214] Content-Type: text/plain; charset="utf-8" Content-ID: <6F9F15E6565E2E4ABD64D0A1BE15F08A@huawei.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.58ABE4D1.0384, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c2b8a137d6e490cc85c4fda7a583354c Archived-At: Subject: Re: [Netslices] "Network Slicing - Introductory Document and Revised Problem Statement" draft 02 X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 06:57:26 -0000 QW50b24sDQpUaGFua3MgZm9yIGxvb2tpbmcgYXQgdGhlIGRvY3VtZW50Lg0KUGxlYXNlIHNlZSBp bmxpbmUNCg0KUmVnYXJkcw0KS2lyYW4gDQoNCk9uIDIvMjAvMTcsIDc6MDMgQU0sICJOZXRzbGlj ZXMgb24gYmVoYWxmIG9mIEFudG9uIEl2YW5vdiIgPG5ldHNsaWNlcy1ib3VuY2VzQGlldGYub3Jn IG9uIGJlaGFsZiBvZiBhbnRvbi5pdmFub3ZAa290LWJlZ2Vtb3QuY28udWs+IHdyb3RlOg0KDQog ICAgUXVlc3Rpb25zOg0KICAgIA0KICAgIDEuIFdoYXQgZG8geW91IG1lYW4gdW5kZXIgImZvdXIt ZGltZW5zaW9uYWwiPw0KICAgIFtLTV0gdGhlc2UgYXJlIChhKSBEYXRhIC8oYikgQ29udHJvbCAv KGMpIE1hbmFnZW1lbnQgLyhkKSBTZXJ2aWNlIHBsYW5lcy4gVGhlIGV4cGVjdGF0aW9uIGlzIHRv IGhhdmUgYW4gaW5kZXBlbmRlbnQgdmlldyBvZiBOUyBmcm9tIGVhY2ggb2YgdGhlc2UgcGVyc3Bl Y3RpdmVzLiANCg0KICAgIDIuIE9wZXJhdGlvbnMgLSBtb3N0IG9mIHRoYXQgc291bmRzIGxpa2Ug ZGVmaW5pbmcgYSBGU00gYW5kIGEgbWF0Y2hpbmcgDQogICAgbW9kZWwuIFRodXMgLSB0aGUgbW9k ZWwgZm9yIHNsaWNlcyBzaG91bGQgbm90IHNpdCBhcyBhIHNtYWxsIHN1Yi1wb2ludCANCiAgICBv ZiB0aGUgbGFzdCBidWxsZXQgcG9pbnQuIEl0IGlzIHdoZXJlIHlvdSBzdGFydCAoYWxvbmcgd2l0 aCB0aGUgRlNNKS4NCiBbS01dIGNhbiB5b3UgZWxhYm9yYXRlIGEgYml0IG1vcmUgd2hhdCBraW5k IG9mIEZTTSBhbmQgd2hhdOKAmXMgYSDigJhtYXRjaGluZyBtb2RlbOKAmT8gSGVyZSBTbGljZSBv cGVyYXRpb25zIG1heSBoYXZlIGRpZmZlcmVudCBnb2FscywgKGEpIHNvbWUgYmVpbmcgb3BlcmF0 b3IgZHJpdmVuIHNsaWNlIGNyZWF0ZS9kZWxldGUvbW9kaWZ5OyAoYikgb3RoZXJzIGJlaW5nIGFi b3V0IHJ1bnRpbWUgYWRqdXN0bWVudHMgb2YgY2FwYWJpbGl0aWVzLCAoYykgYXNwZWN0cyBsaWtl IGludGVsbGlnZW5jZSBpbiBzZWxmLW1vbml0b3JpbmcgYWN0aW9ucyBhbmQgc28gb24uIEkgYW0g bm90IGFibGUgdG8gcmVsYXRlIHRoZXNlIHRvIEZTTSBidXQgaWYgcG9zc2libGUsIHRoaXMgbWF5 IGJlIGFuIGludGVyZXN0aW5nIGFwcHJvYWNoIHRvIGV4cGxvcmUgZnVydGhlci4gDQoNCltLTV0g VGhhdCBzYWlkLCBpbnRyb2R1Y3RvcnkgZG9jdW1lbnQgYWltcyB0byDigJh3aGF04oCZIG5vdCDi gJhob3figJkuIA0KDQogICAgMy4gTm90ZXMgLSBoYWxmIG9mIHRoYXQgZ29lcyBhd2F5IG9uY2Ug eW91IGRlZmluZSB0aGUgRlNNIC0gdGhleSBhcmUgDQogICAganVzdCB0cmFuc2l0aW9ucyBhbG9u ZyB0aGUgRlNNIGFuZCByZWxldmFudCBtb2RlbCBjaGFuZ2VzLg0KICAgIA0KICAgIEFzIGEgc2lk ZSBlZmZlY3Qgb2YgMiszIG9uY2UgdGhhdCBpcyBkZWZpbmVkIGl0IGJlY29tZXMgYSBzaW1wbGUg bWFubmVyIA0KICAgIG9mIGNvZGluZyBzYWlkIEZTTSBhbmQgb3JjaGVzdHJhdGluZyBob3cgaXQg ZWZmZWN0cyBuZXR3b3JrIGFuZCBjbG91ZCANCiAgICByZXNvdXJjZXMgdW5sZXNzIHdlIGdldCBi b2dnZWQgZG93biBpbiB0aGUgZW5kLXRvLWVuZCBRb1Mgc3dhbXAuIFRoYXQgDQogICAgcGFydGlj dWxhciBzd2FtcCBwcm9iYWJseSBuZWVkcyBzb21lIG5hcnJvd2luZyBkb3duIGluIG9yZGVyIHRv IGhhdmUgYSANCiAgICB2aWFibGUgcHJvYmxlbSBzdGF0ZW1lbnQuIERvaW5nIGl0IHRvIGNvdmVy IGFsbCBwb3NzaWJsZSBhcmJpdHJhcnkgaWRlYXMgDQogICAgb2YgZW5kLXRvLWVuZCBRb1MgaXMg anVzdCBub3QgZmVhc2libGUuIFRoYXQgaGFzIGJlZW4gdHJpZWQgcXVpdGUgYSBmZXcgDQogICAg dGltZXMgYW5kIGhhcyBiZWVuIHVuc3VjY2Vzc2Z1bCBldmVyeSB0aW1lLiBTbyBhIG5hcnJvd2Vk IGRvd24gDQogICAgZGVmaW5pdGlvbiBvZiBzdXBwb3J0ZWQgZW5kLXRvLWVuZCBxb3MgbWV0cmlj cyBhbmQgYSBtYXRjaGluZyBtb2RlbCBpcyANCiAgICBuZWVkZWQgYXMgYSBwYXJ0IG9mIGRlZmlu aW5nIHRoZSBwcm9ibGVtIHN0YXRlbWVudC4NCiAgICANCltLTV0gbm90IHN1cmUgd2l0aCBxb3Mg bWV0cmljcyBwYXJ0IGVpdGhlciBiZWNhdXNlIGVhY2ggc2VydmljZSB2ZXJ0aWNhbCB3aWxsIGhh dmUgc3BlY2lmaWMgcmVxdWlyZW1lbnQ7IHdlIGRvbuKAmXQgd2FudCB0byBiZSBpbiBhIGtsdWRn eSBzaXR1YXRpb24gd2hlcmUgYW4gYXBwbGljYXRpb24gY2Fubm90IGJlIHNlcnZlZCBpbiB0aGUg Y29udGV4dCBvZiBhIHNsaWNlLiBTaW5jZSBJIGFtIHN0aWxsIG5vdCBjbGVhciBhYm91dCBtYXRj aGluZyBtb2RlbCwgY291bGQgeW91IHBsZWFzZSBzdWdnZXN0IHRoZSB0ZXh0IC0gdGhhdCB3aWxs IGJlIGhlbHBmdWwuDQpUaGFua3MgDQpLaXJhbg0KDQogICAgDQogICAgDQogICAgT24gMTQvMDIv MTcgMjA6NDUsIEFsZXggR2FsaXMgd3JvdGU6DQogICAgPiAxNHRoIEZlYnJ1YXJ5IDIwMTcNCiAg ICA+DQogICAgPiBEZWFyIEFsbCwNCiAgICA+DQogICAgPiBSZTogIk5ldHdvcmsgU2xpY2luZyAt IEludHJvZHVjdG9yeSBEb2N1bWVudCBhbmQgUmV2aXNlZCBQcm9ibGVtIFN0YXRlbWVudCIgZHJh ZnQgMDINCiAgICA+DQogICAgPg0KICAgID4gVGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlv bnMsIHJldmlld3MgIGFuZCBkaXNjdXNzaW9ucyBvbiB0aGUgICJOZXR3b3JrIFNsaWNpbmcgLSBJ bnRyb2R1Y3RvcnkgRG9jdW1lbnQgYW5kIFJldmlzZWQgUHJvYmxlbSBTdGF0ZW1lbnTigJ0gZHJh ZnQgMDAuDQogICAgPg0KICAgID4gQW4gdXBkYXRlIGFzIGRyYWZ0IDAyIHdhcyBwcm9kdWNlZCBh bmQgc3VibWl0dGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQogICAgPg0KICAgID4gVGhpcyBp cyBhIGtpbmcgcmVxdWVzdCBmb3IgeW91IHRvIGNvbnNpZGVyIHRoaXMgZHJhZnQgYXMgaW5wdXQg dG8gOg0KICAgID4NCiAgICA+IOKAoiBmdXJ0aGVyIGRpc2N1c3Npb25zIG9uIHRoZSBtYWlsaW5n IGxpc3QuDQogICAgPiDigKIgZnVydGhlciB1cGRhdGVzIGFuZCBjbGFyaWZpY2F0aW9ucyB3aXRo IHRoZSB2aWV3IG9mIHVwZGF0ZSBpdCBiZWZvcmUgdGhlIElFVEY5OCBJbiBDaGljYWdvICgyNi0z MSBNYXJjaCAyMDE3KS4NCiAgICA+IOKAoiBzdGFydGluZyBuZXcgZHJhZnRzIGJlZm9yZSBJRVRG OTggSW4gQ2hpY2FnbyBvbiB0aGUgZm9sbG93aW5nIHRvcGljczoNCiAgICA+IAkJSSkgcmVsZXZh bnQgdXNlIGNhc2VzIDsNCiAgICA+IAkJSUkpIHJlZmVyZW5jZSBtb2RlbCBmb3IgbmV0d29yayBz bGljZXMgOw0KICAgID4gCQlJSUkpIEV4cG9zdXJlIEludGVyZmFjZSBzcGVjaWZpY2F0aW9uIGFu ZCBEYXRhIG1vZGVsIGZvciBOZXR3b3JrIFNsaWNpbmcgOw0KICAgID4gCQlpVikgZGV0YWlsZWQg cHJvYmxlbSBzdGF0ZW1lbnRzIChpLmUuIGJhc2VkIG9uIGFscmVhZHkgaWRlbnRpZmllZCBsaXN0 IG9mIDIwIHByb2JsZW1zKQ0KICAgID4NCiAgICA+IFdlIGFyZSBwbGFubmluZyBmb3IgYSBzaWRl IG1lZXRpbmcgb24gTmV0d29yayBTbGljaW5nIGF0IElFVEYgOTguDQogICAgPg0KICAgID4gQmVz dCBSZWdhcmRzDQogICAgPg0KICAgID4gQWxleCwgSmltbXksIEtpcmFuLCBTdGV3YXJ0LCBNb2Qs IFBldHJvDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPiBOLkIuIEEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC1nZG1iLW5ldHNsaWNlcy1pbnRyby1hbmQtcHMtMDIudHh0DQogICAgPiBoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFsZXggR2FsaXMgYW5kIHBvc3RlZCB0byB0 aGUNCiAgICA+IElFVEYgcmVwb3NpdG9yeS4NCiAgICA+DQogICAgPiBOYW1lOgkJZHJhZnQtZ2Rt Yi1uZXRzbGljZXMtaW50cm8tYW5kLXBzDQogICAgPiBSZXZpc2lvbjoJMDINCiAgICA+IFRpdGxl OgkJTmV0d29yayBTbGljaW5nIC0gSW50cm9kdWN0b3J5IERvY3VtZW50IGFuZCBSZXZpc2VkIFBy b2JsZW0gU3RhdGVtZW50DQogICAgPiBEb2N1bWVudCBkYXRlOgkyMDE3LTAyLTE0DQogICAgPiBH cm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KICAgID4gUGFnZXM6CQkxMQ0KICAgID4gVVJM OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1n ZG1iLW5ldHNsaWNlcy1pbnRyby1hbmQtcHMtMDIudHh0DQogICAgPiBTdGF0dXM6ICAgICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2RtYi1uZXRzbGljZXMtaW50 cm8tYW5kLXBzLw0KICAgID4gSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1nZG1iLW5ldHNsaWNlcy1pbnRyby1hbmQtcHMtMDINCiAgICA+IERpZmY6ICAg ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtZ2RtYi1uZXRz bGljZXMtaW50cm8tYW5kLXBzLTAyDQogICAgPg0KICAgID4gQWJzdHJhY3Q6DQogICAgPiAgICBU aGlzIGRvY3VtZW50IGludHJvZHVjZXMgTmV0d29yayBTbGljaW5nIHByb2JsZW1zIGFuZCB0aGUg bW90aXZhdGlvbg0KICAgID4gICAgZm9yIG5ldyB3b3JrIGFyZWFzLiBJdCByZXByZXNlbnRzIGFu IGluaXRpYWwgcmV2aXNpb24gb2YgdGhlIE5ldHdvcmsNCiAgICA+ICAgIFNsaWNpbmcgcHJvYmxl bSBzdGF0ZW1lbnQgZGVyaXZlZCBmcm9tIHRoZSBhbmFseXNpcyBvZiB0aGUgdGVjaG5pY2FsDQog ICAgPiAgICBnYXBzIGluIElFVEYgcHJvdG9jb2xzIGVjb3N5c3RlbS4gIEl0IGNvbXBsZW1lbnRz IGFuZCBicmluZ3MgdG9nZXRoZXINCiAgICA+ICAgIHRoZSBzaWxvIGVmZm9ydHMgYmVpbmcgY2Fy cmllZCBvdXQgaW4gc2V2ZXJhbCBvdGhlciBJRVRGIHdvcmtpbmcgZ3JvdXBzDQogICAgPiAgICB0 byBhY2hpZXZlIGNlcnRhaW4gYXNwZWN0cyBvZiBOZXR3b3JrIFNsaWNpbmcgZnVuY3Rpb25zIGFu ZCBvcGVyYXRpb25zLg0KICAgID4NCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQogICAgPiBOZXRzbGljZXMgbWFpbGluZyBsaXN0DQogICAgPiBO ZXRzbGljZXNAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0c2xpY2VzDQogICAgDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCiAgICBOZXRzbGljZXMgbWFpbGluZyBsaXN0DQogICAg TmV0c2xpY2VzQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRzbGljZXMNCiAgICANCg0KDQoNCg== From nobody Tue Feb 21 00:00:43 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4CD129421 for ; Tue, 21 Feb 2017 00:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 Lz0LUwpiwqTv for ; Tue, 21 Feb 2017 00:00:39 -0800 (PST) Received: from www.kot-begemot.co.uk (ivanoab5.miniserver.com [78.31.111.25]) (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 B59D1129416 for ; Tue, 21 Feb 2017 00:00:38 -0800 (PST) Received: from tun5.smaug.kot-begemot.co.uk ([192.168.18.6] helo=smaug.kot-begemot.co.uk) by www.kot-begemot.co.uk with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cg5NA-0006Uk-2M; Tue, 21 Feb 2017 08:00:32 +0000 Received: from monstrousnightmare.kot-begemot.co.uk ([192.168.11.207]) by smaug.kot-begemot.co.uk with esmtp (Exim 4.84_2) (envelope-from ) id 1cg5N9-000557-RG; Tue, 21 Feb 2017 08:00:31 +0000 To: "Kiran.Makhijani" , "netslices@ietf.org" References: <5B526793-E0F0-4842-9D22-5DEC416154D1@ucl.ac.uk> <27da3ef9-e145-39f0-c92f-252c83e61627@kot-begemot.co.uk> From: Anton Ivanov Message-ID: <60f4dd43-e747-61eb-1db0-df144eead259@kot-begemot.co.uk> Date: Tue, 21 Feb 2017 08:00:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [Netslices] "Network Slicing - Introductory Document and Revised Problem Statement" draft 02 X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 08:00:42 -0000 On 21/02/17 06:57, Kiran.Makhijani wrote: > Anton, > Thanks for looking at the document. > Please see inline > > Regards > Kiran > > On 2/20/17, 7:03 AM, "Netslices on behalf of Anton Ivanov" wrote: > > Questions: > > 1. What do you mean under "four-dimensional"? > [KM] these are (a) Data /(b) Control /(c) Management /(d) Service planes. The expectation is to have an independent view of NS from each of these perspectives. Needs a definition. Otherwise it reads as a Star Trek fan fiction script not a draft. > > 2. Operations - most of that sounds like defining a FSM and a matching > model. Thus - the model for slices should not sit as a small sub-point > of the last bullet point. It is where you start (along with the FSM). > [KM] can you elaborate a bit more what kind of FSM and what’s a ‘matching model’? Here Slice operations may have different goals, (a) some being operator driven slice create/delete/modify; (b) others being about runtime adjustments of capabilities, (c) aspects like intelligence in self-monitoring actions and so on. I am not able to relate these to FSM but if possible, this may be an interesting approach to explore further. You are defining a standard which needs to be coded. I read the wishlist in the draft - it needs to be narrowed to a set of defined states, formed into an orderly FSM and expressed as data. Otherwise it is not standards material. This does not need to be done in the problem statement, the problem statement should however narrow the scope to make sure that this is the required end-product. > > [KM] That said, introductory document aims to ‘what’ not ‘how’. See above. > > 3. Notes - half of that goes away once you define the FSM - they are > just transitions along the FSM and relevant model changes. > > As a side effect of 2+3 once that is defined it becomes a simple manner > of coding said FSM and orchestrating how it effects network and cloud > resources unless we get bogged down in the end-to-end QoS swamp. That > particular swamp probably needs some narrowing down in order to have a > viable problem statement. Doing it to cover all possible arbitrary ideas > of end-to-end QoS is just not feasible. That has been tried quite a few > times and has been unsuccessful every time. So a narrowed down > definition of supported end-to-end qos metrics and a matching model is > needed as a part of defining the problem statement. > > [KM] not sure with qos metrics part either because each service vertical will have specific requirement; we don’t want to be in a kludgy situation where an application cannot be served in the context of a slice. You will always have at least one corner case like that. You cannot have a Santa wishlist where this does everything. It should be clear WHAT it it is intended to do and that WHAT should be expressible as numbers so that implementers can express it as code. A. > Since I am still not clear about matching model, could you please suggest the text - that will be helpful. > Thanks > Kiran > > > > On 14/02/17 20:45, Alex Galis wrote: > > 14th February 2017 > > > > Dear All, > > > > Re: "Network Slicing - Introductory Document and Revised Problem Statement" draft 02 > > > > > > Thank you for your contributions, reviews and discussions on the "Network Slicing - Introductory Document and Revised Problem Statement” draft 00. > > > > An update as draft 02 was produced and submitted to the IETF repository. > > > > This is a king request for you to consider this draft as input to : > > > > • further discussions on the mailing list. > > • further updates and clarifications with the view of update it before the IETF98 In Chicago (26-31 March 2017). > > • starting new drafts before IETF98 In Chicago on the following topics: > > I) relevant use cases ; > > II) reference model for network slices ; > > III) Exposure Interface specification and Data model for Network Slicing ; > > iV) detailed problem statements (i.e. based on already identified list of 20 problems) > > > > We are planning for a side meeting on Network Slicing at IETF 98. > > > > Best Regards > > > > Alex, Jimmy, Kiran, Stewart, Mod, Petro > > > > > > > > N.B. A new version of I-D, draft-gdmb-netslices-intro-and-ps-02.txt > > has been successfully submitted by Alex Galis and posted to the > > IETF repository. > > > > Name: draft-gdmb-netslices-intro-and-ps > > Revision: 02 > > Title: Network Slicing - Introductory Document and Revised Problem Statement > > Document date: 2017-02-14 > > Group: Individual Submission > > Pages: 11 > > URL: https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-and-ps-02.txt > > Status: https://datatracker.ietf.org/doc/draft-gdmb-netslices-intro-and-ps/ > > Htmlized: https://tools.ietf.org/html/draft-gdmb-netslices-intro-and-ps-02 > > Diff: https://www.ietf.org/rfcdiff?url2=draft-gdmb-netslices-intro-and-ps-02 > > > > Abstract: > > This document introduces Network Slicing problems and the motivation > > for new work areas. It represents an initial revision of the Network > > Slicing problem statement derived from the analysis of the technical > > gaps in IETF protocols ecosystem. It complements and brings together > > the silo efforts being carried out in several other IETF working groups > > to achieve certain aspects of Network Slicing functions and operations. > > > > _______________________________________________ > > Netslices mailing list > > Netslices@ietf.org > > https://www.ietf.org/mailman/listinfo/netslices > > > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices > > > > From nobody Tue Feb 21 08:57:26 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739BA1294FB for ; Tue, 21 Feb 2017 08:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.98 X-Spam-Level: X-Spam-Status: No, score=-0.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=realsdn.org 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 UsjvwmELPyii for ; Tue, 21 Feb 2017 08:57:24 -0800 (PST) Received: from ajmclachlan.com (pigmail.ajmclachlan.com [78.31.107.96]) (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 E274E129481 for ; Tue, 21 Feb 2017 08:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=realsdn.org; s=default; t=1487696244; bh=fMdT3RviSPLmJfuhMgk+zMySJ9U7CQxdRtSJqG4OlLg=; h=Subject:From:In-Reply-To:Date:Cc:References; b=iBKB+auXH6/rYCpq8N2BFmHEqSvkBO0TugX2vb2bn40RHKaRDSTOuuEVMnrU35YZ8 a9qEtqgAgw9OlfGsQiRe+75Q4RIAH72bLYalgwRSzSnwB5XQMVkCN4QvXVuNhnJfQs 3lRqc89JLTP+OxF/ryHJta8ARHXgMp7AG4a7BRz4= X-Default-Received-SPF: pass (skip=forwardok (res=PASS)); Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Andrew McLachlan In-Reply-To: <5B526793-E0F0-4842-9D22-5DEC416154D1@ucl.ac.uk> Date: Tue, 21 Feb 2017 16:57:20 +0000 Cc: Network Slices Content-Transfer-Encoding: quoted-printable Message-Id: References: <5B526793-E0F0-4842-9D22-5DEC416154D1@ucl.ac.uk> X-Mailer: Apple Mail (2.3124) X-To-Not-Matched: true X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted Archived-At: Subject: Re: [Netslices] "Network Slicing - Introductory Document and Revised Problem Statement" draft 02 X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 16:57:25 -0000 Hi Alex I think we are creating confusion by talking about 'slice control = planes', as this seems to imply something akin to the normal meaning of = control plane, as related to IETF work. I believe what we are really looking at here is the something more like = =E2=80=98 multi infrastructure tenant orchestration=E2=80=99. By way of = example what we do today already with services over and / or connected = to networks such as SFC connected to a VPN. Resources in any part of the chain for an E2E service will need to be = booked/allocated/managed by an overlord, with the control plane = functions essentially performing the same functions as today. For = examples attachments using vxlan, vNICs, VMs and all things beginning = with =E2=80=98v=E2=80=99. Different resources will need to be described and modelled, and we = already have drafts / standards aplenty for this. Outside of the IETF = scope, there is also an abundance for each infra type, NFV and so forth. I have read the document twice and understand that it is talking about a = potential problem space, but without providing details of issues which = need to be addressed by IETF.=20 It speaks of new protocols, but again there is no hint what they might = be or what problems have been identified so far, other that the need for = really good orchestration to bring the various functions together. So far I believe we are still covered by existing technologies, and = likely the biggest problem will be to pair down the list of which ones = to recommend, with the rest of the problem statement being outside of = the scope of the IETF. I might even go so far as to say that this is potentially more a TOSCA = type problem, with network modern SDN /programatic capabilities simply = making the job of turning up network service easier, which was kinda the = goal of SDN. cheers Andrew > On 14 Feb 2017, at 20:45, Alex Galis wrote: >=20 > 14th February 2017 >=20 > Dear All, >=20 > Re: "Network Slicing - Introductory Document and Revised Problem = Statement" draft 02 >=20 >=20 > Thank you for your contributions, reviews and discussions on the = "Network Slicing - Introductory Document and Revised Problem = Statement=E2=80=9D draft 00. >=20 > An update as draft 02 was produced and submitted to the IETF = repository. >=20 > This is a king request for you to consider this draft as input to : >=20 > =E2=80=A2 further discussions on the mailing list. > =E2=80=A2 further updates and clarifications with the view of update = it before the IETF98 In Chicago (26-31 March 2017). > =E2=80=A2 starting new drafts before IETF98 In Chicago on the = following topics:=20 > I) relevant use cases ;=20 > II) reference model for network slices ;=20 > III) Exposure Interface specification and Data model for = Network Slicing ;=20 > iV) detailed problem statements (i.e. based on already = identified list of 20 problems) >=20 > We are planning for a side meeting on Network Slicing at IETF 98. >=20 > Best Regards >=20 > Alex, Jimmy, Kiran, Stewart, Mod, Petro >=20 >=20 >=20 > N.B. A new version of I-D, draft-gdmb-netslices-intro-and-ps-02.txt > has been successfully submitted by Alex Galis and posted to the > IETF repository. >=20 > Name: draft-gdmb-netslices-intro-and-ps > Revision: 02 > Title: Network Slicing - Introductory Document and = Revised Problem Statement > Document date: 2017-02-14 > Group: Individual Submission > Pages: 11 > URL: = https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-and-ps-02.= txt > Status: = https://datatracker.ietf.org/doc/draft-gdmb-netslices-intro-and-ps/ > Htmlized: = https://tools.ietf.org/html/draft-gdmb-netslices-intro-and-ps-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-gdmb-netslices-intro-and-ps-02 >=20 > Abstract: > This document introduces Network Slicing problems and the motivation > for new work areas. It represents an initial revision of the Network > Slicing problem statement derived from the analysis of the technical > gaps in IETF protocols ecosystem. It complements and brings together > the silo efforts being carried out in several other IETF working = groups > to achieve certain aspects of Network Slicing functions and = operations. >=20 > _______________________________________________ > Netslices mailing list > Netslices@ietf.org > https://www.ietf.org/mailman/listinfo/netslices From nobody Mon Feb 27 11:35:26 2017 Return-Path: X-Original-To: netslices@ietfa.amsl.com Delivered-To: netslices@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE19B12A2F4 for ; Mon, 27 Feb 2017 11:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 4JD_S0rQi24e for ; Mon, 27 Feb 2017 11:35:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C82A1270B4 for ; Mon, 27 Feb 2017 11:35:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBU73251; Mon, 27 Feb 2017 19:35:21 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 27 Feb 2017 19:35:19 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.132]) by SJCEML703-CHM.china.huawei.com ([169.254.5.69]) with mapi id 14.03.0235.001; Mon, 27 Feb 2017 11:35:06 -0800 From: "Kiran.Makhijani" To: "netslices@ietf.org" Thread-Topic: NetSlices IETF 98: side meeting: Call for Contributions Thread-Index: AQHSkTCZFIbofckpiUyw4LbquFIK5Q== Date: Mon, 27 Feb 2017 19:35:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.49.234] Content-Type: multipart/alternative; boundary="_000_E56856143CEE41B2A6E928D7801FD0D6huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.58B47F79.0104, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.132, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0261a78b16573142815497a328bc2a1b Archived-At: Cc: Alex Galis , "Dongjie \(Jimmy\)" , "stewart.bryant" Subject: [Netslices] NetSlices IETF 98: side meeting: Call for Contributions X-BeenThere: netslices@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This list is intended for discussion and review of network slicing at IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 19:35:26 -0000 --_000_E56856143CEE41B2A6E928D7801FD0D6huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KDQpXZSBhcmUgcGxhbm5pbmcgYW5vdGhlciBzaWRlLW1lZXRpbmcgdG8gY29u dGludWUgZmFjZSB0byBmYWNlIGRpc2N1c3Npb25zIG9uIHRoZSB0b3BpYyBhbmQgYXJlIGluIHRo ZSBwcm9jZXNzIG9mIHNldHRpbmcgdXAgYWdlbmRhIGFuZCBpbnZpdGluZyBjb250cmlidXRpb25z IGZyb20gdGhlIGNvbW11bml0eS4NClBsZWFzZSBzZW5kIHlvdXIgY29udHJpYnV0aW9ucyAoc3Vj aCBhcyB1c2VjYXNlcykgYW5kIHN1Z2dlc3Rpb25zIGZvciBkaXNjdXNzaW9uIHRvcGljcy4NCg0K SW4gb3JkZXIgdG8gY29sbGFib3JhdGUsIHdlIGhhdmUgc2V0dXAgZ2l0aHViIHJlcG9zaXRvcnku IEZlZWwgZnJlZSB0byB1c2UgdGhpcyBmb3IgcmV2aWV3cywgZG9jdW1lbnQgdXBkYXRlIGFuZCB1 cGxvYWRpbmcgeW91ciBjb250cmlidXRpb25zLg0KDQotLSBNYWluIFJlcG9zaXRvcnkNCmh0dHBz Oi8vZ2l0aHViLmNvbS9uZXRzbGljZXMvSUVURi1OZXRTbGljZXMNCi0tIEZvbGRlciBmb3IgSUVU Rjk4IHNpZGUgbWVldGluZw0KaHR0cHM6Ly9naXRodWIuY29tL25ldHNsaWNlcy9JRVRGLU5ldFNs aWNlcy9JRVRGOThfU2lkZW1lZXRpbmcwMg0KDQpTdWdnZXN0aW9ucyB3ZWxjb21lDQpUaGFua3MN ClN0ZXdhcnQsIERvbmdqaWUsIEFsZXgsIEtpcmFuDQo= --_000_E56856143CEE41B2A6E928D7801FD0D6huaweicom_ Content-Type: text/html; charset="utf-8" Content-ID: <7DC835C26BAE194D817EED7E51CA7A8D@huawei.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IZWxsbyBh bGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5XZSBhcmUgcGxh bm5pbmcgYW5vdGhlciBzaWRlLW1lZXRpbmcgdG8gY29udGludWUgZmFjZSB0byBmYWNlIGRpc2N1 c3Npb25zIG9uIHRoZSB0b3BpYyBhbmQgYXJlIGluIHRoZSBwcm9jZXNzIG9mIHNldHRpbmcgdXAg YWdlbmRhIGFuZCBpbnZpdGluZyBjb250cmlidXRpb25zIGZyb20gdGhlIGNvbW11bml0eS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+UGxlYXNlIHNlbmQgeW91ciBjb250cmlidXRpb25zIChzdWNoIGFzIHVz ZWNhc2VzKSBhbmQgc3VnZ2VzdGlvbnMgZm9yIGRpc2N1c3Npb24gdG9waWNzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SW4gb3JkZXIgdG8gY29sbGFib3JhdGUs IHdlIGhhdmUgc2V0dXAgZ2l0aHViIHJlcG9zaXRvcnkuIEZlZWwgZnJlZSB0byB1c2UgdGhpcyBm b3IgcmV2aWV3cywgZG9jdW1lbnQgdXBkYXRlIGFuZCB1cGxvYWRpbmcgeW91ciBjb250cmlidXRp b25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LS0gTWFpbiBS ZXBvc2l0b3J5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRzbGljZXMv SUVURi1OZXRTbGljZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+LS0gRm9sZGVyIGZvciBJRVRGOTggc2lk ZSBtZWV0aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRzbGljZXMv SUVURi1OZXRTbGljZXMvSUVURjk4X1NpZGVtZWV0aW5nMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlN1Z2dlc3Rpb25zIHdlbGNvbWU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6 YmxhY2siPlN0ZXdhcnQsIERvbmdqaWUsIEFsZXgsIEtpcmFuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E56856143CEE41B2A6E928D7801FD0D6huaweicom_--