From nobody Fri Jan 13 10:21: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 7536C129533 for ; Fri, 13 Jan 2017 10:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, 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 SgmclLp-mSAm for ; Fri, 13 Jan 2017 10:21:07 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 1F2391294BD for ; Fri, 13 Jan 2017 10:21:04 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id r126so76500470wmr.0 for ; Fri, 13 Jan 2017 10:21:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to; bh=NPxS9joRnlY1ZYcPgSOzAV7P9/Vo/dZgAp380YvrDF0=; b=ma7pzKb8zQvZhv610H8iOajLMGy1KAhz85pFoMCCwKc/V8Ar56kyvtLIFfW1Uxs1wm +X3cCd2cz842NOgKnHxzd8cPpBBZZegfIhoTNGTgHI7liGAOTrVVD3mRP6uAPtzuhGv+ UBrhPy1uxoZt8gBZwbHBsyOiFbnWp6QyPQkKcRQE2YOfMshbRenaHdAn/QKPIiCCltYi GAZdRv6D0wPAPd1V5GDVb6thhJomC4L5vYff1fIT16HjRzMnyEjThPydAY4dZ11e+WQ2 DptCZOa2e1AOgDULgdZ1iHvghMngLwXJ3n/GNrfE9tzhYnQUEurf9DhNuYyiuJWPvhAI 7e/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to; bh=NPxS9joRnlY1ZYcPgSOzAV7P9/Vo/dZgAp380YvrDF0=; b=QeCUwTii1GfSzaSi7wv5AUvcdTbv4psbMrIXj1OnwkPbCwhB7eWpob9w95neWt9/W/ fKK+GtO4AzNVox6OtNHcAwPxiQo3QfAlRulExp7seU2+dK6+Jg9sjYwmzUJ3xD31jkQL 3dfQ9/Df6CJptwpP8eJ+piUKuUYK61f5+20l64kh4oicWb1jzfA/kIK+2rAsusywqhpz WOvX9P0piUuIXnvRZSm4gMTeTboS/08XGwMQH+Ri2Wm7jcwddbSbwsYuLIRwpC82Aifl +DfGen9u86pgoRt2iK5dNJp/vWLqUUD2isrUjoXGZEjNpQH5CGcvUlUDjzspHzZgZ+m2 C+5A== X-Gm-Message-State: AIkVDXK2S1Aa5evogMNvwEVl1B8+IF6zYlGLVHWg+hhfFekg0CsIcY1dzWrUWXuReGNy6w== X-Received: by 10.28.163.196 with SMTP id m187mr3195421wme.6.1484331662075; Fri, 13 Jan 2017 10:21:02 -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 c9sm5425554wmi.16.2017.01.13.10.21.00 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 10:21:01 -0800 (PST) References: <83714e3f-a292-c6de-4057-c2f8c039d0ff@gmail.com> To: netslices@ietf.org From: Stewart Bryant X-Forwarded-Message-Id: <83714e3f-a292-c6de-4057-c2f8c039d0ff@gmail.com> Message-ID: Date: Fri, 13 Jan 2017 18:20:59 +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: <83714e3f-a292-c6de-4057-c2f8c039d0ff@gmail.com> Content-Type: multipart/alternative; boundary="------------608E1F15AF04373460252463" Archived-At: Subject: [Netslices] Fwd: Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt 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, 13 Jan 2017 18:21:17 -0000 This is a multi-part message in MIME format. --------------608E1F15AF04373460252463 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sending to Netslices since it is more focal to the interests of this list S -------- Forwarded Message -------- Subject: Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt Date: Fri, 13 Jan 2017 18:16:59 +0000 From: Stewart Bryant To: teas@ietf.org Something that seems to be missing from this work are the concepts of isolation and latency which seem to be requirements for services of the type described in this document. We latency has two components, the physical latency of the path due to distance, and latency due to waiting for other packets. Clearly optimizing the paths traffic takes is the key to addressing the delay to physical path length, and considering congestion effects, bandwidth management and the choice of bearer technology impact the second. I did not see any mention of latency in the abstract interface to the SDN system and yet to address that emergent requirement it needs to be there. Secondly I understand that isolation is an emergent requirement. Isolation can take many forms. The most common is the need to avoid traffic leakage, but it can also include the need to avoid control plane interactions whereby the demands of one service impact another, and data plane interaction where a heavy demand by one virtual service spills over into latency effects in another, at least in classic network layer technologies such as MPLS-Tx. - Stewart --------------608E1F15AF04373460252463 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit

Sending to Netslices since it is more focal to the interests of this list

S



-------- Forwarded Message --------
Subject: Re: [Teas] I-D Action: draft-ietf-teas-actn-framework-02.txt
Date: Fri, 13 Jan 2017 18:16:59 +0000
From: Stewart Bryant <stewart.bryant@gmail.com>
To: teas@ietf.org <teas@ietf.org> 


Something that seems to be missing from this work are the concepts of 
isolation and latency
which seem to be requirements for services of the type described in this 
document.

We latency has two components, the physical latency of the path due to 
distance, and
latency due to waiting for other packets. Clearly optimizing the paths 
traffic takes
is the key to addressing the delay to physical path length, and 
considering congestion
effects, bandwidth management and the choice of bearer technology impact 
the second.

I did not see any mention of latency in the abstract interface to the 
SDN system and
yet to address that emergent requirement it needs to be there.

Secondly I understand that isolation is an emergent requirement. 
Isolation can
take many forms. The most common is the need to avoid traffic leakage, 
but it
can also include the need to avoid control plane interactions whereby 
the demands
of one service impact another, and data plane interaction where a heavy 
demand
by one virtual service spills over into latency effects in another, at 
least in
classic network layer technologies such as MPLS-Tx.

- Stewart
--------------608E1F15AF04373460252463-- From nobody Fri Jan 13 10:24: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 44437129D2E for ; Fri, 13 Jan 2017 10:24:41 -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 HgkEhL0oFJhG for ; Fri, 13 Jan 2017 10:24:39 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 C06A3129D2D for ; Fri, 13 Jan 2017 10:24:38 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id r144so82780065wme.1 for ; Fri, 13 Jan 2017 10:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=Gvwly5oE4TP2OgSSvCyYVJf6BhIUm9QwdFefLIyTDIM=; b=IzFU8fJ2as/WYr10zk94OzIk5DLMiSUp66Dle5iyGdq76rUge7MXlZonTXSpRNUdeA iC6M2wfD3xwz1YfN8QV1/K9IKH9QFyH4bDbexlQ8Q2cMexKWRcYxmTWiHv/F9L9kLfxn 3vuPfTyNm7av1mP9Xrb3GNQiBUdm4UjxQo7GlGV4/GnNh7WBCscvOziI98kWkhSgyBa2 +ffos0WHOn6atUg+Viya0BJxR3+K+mfbtJxcp5m4R5yX6Sfg8R97leP7esd9TL8QK3+T D3Y6jhyo1WRs7usJqOIkVR7NsfGbQGjTIMShTYNdWpThYImrz0xF37bnx/ADxbyT66RY C8gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=Gvwly5oE4TP2OgSSvCyYVJf6BhIUm9QwdFefLIyTDIM=; b=Qu3cdFHFDv00z1uqemqgDaP6DaVdtdavIgvzRYivUN0NFpAwfCwkQJPnSWnm8vgB7W Cs8GNYQdQ9IlbDYmBzyePuKnyRNT1ZR6P1x8VvDJlGOC8qjZbOv8u2inprvo14JDSQgT yDPvaWY4LlA49XdigUyuP9CXE6LJtnshao9wb8TS9NyfGXtkmRHPaRcQbr+B1LRrLVbN Y3Xl/AQxgpnEO7W276lTYhwt8WXf4c2CINFRnJmY++60DB3gnCF6tP+/OTW+fdPnH5ot uTztcNiVouwI+x4oa0Y3UIwrNDNEOQClevM7DixPS7Crh64JTWGSuc87D4p4Eoj/ho40 MDOQ== X-Gm-Message-State: AIkVDXJ3kwbGdaM8qZa6BDkx13QQyrd5n4q3QYXpvaqA4O/fyiLAOWvRQc+YM2Fvhzdkdg== X-Received: by 10.28.167.5 with SMTP id q5mr3642314wme.15.1484331877107; Fri, 13 Jan 2017 10:24:37 -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 197sm5936577wmy.16.2017.01.13.10.24.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Jan 2017 10:24:36 -0800 (PST) To: netslices@ietf.org From: Stewart Bryant Message-ID: <316705f3-6ac6-82f0-2a40-c017def88be0@gmail.com> Date: Fri, 13 Jan 2017 18:24:34 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Netslices] draft-dong-network-slicing-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, 13 Jan 2017 18:24:41 -0000 If you remember Jie and I worked on a problem statement draft https://tools.ietf.org/html/draft-dong-network-slicing-problem-statement-00 We would be interested peoples views on whether this is on track, what needs changing and what is missing. Thanks Stewart From nobody Fri Jan 13 23:45: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 C7779126FDC for ; Fri, 13 Jan 2017 23:45:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 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=-3.199, 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 pNzTVO3-AqR0 for ; Fri, 13 Jan 2017 23:45: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 01EA4129415 for ; Fri, 13 Jan 2017 23:45:54 -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 CYT64133; Sat, 14 Jan 2017 07:45:52 +0000 (GMT) Received: from SZXEMI413-HUB.china.huawei.com (10.86.210.41) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sat, 14 Jan 2017 07:45:51 +0000 Received: from SZXEMI507-MBS.china.huawei.com ([169.254.7.158]) by SZXEMI413-HUB.china.huawei.com ([10.86.210.41]) with mapi id 14.03.0235.001; Sat, 14 Jan 2017 15:44:55 +0800 From: "qiangli (D)" To: "netslices@ietf.org" Thread-Topic: Netslices Digest, Vol 1, Issue 1--Problem Statement Thread-Index: AQHSbjoZfWaochLlHE6Bsu5kgSVUig== Date: Sat, 14 Jan 2017 07:44:56 +0000 Message-ID: <06C389826B926F48A557D5DB5A54C4ED29B99218@SZXEMI507-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.163.138] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5879D731.001F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.158, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1d611bc78e26812925c8d3609948e2a2 Archived-At: Subject: Re: [Netslices] Netslices Digest, Vol 1, Issue 1--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: Sat, 14 Jan 2017 07:45:57 -0000 SGkgQWxsLCBJIGhhdmUgcmVhZCB0aGlzIGRyYWZ0IGFuZCBoYXZlIHRoZSBmb2xsb3dpbmcgc3Vn Z2VzdGlvbnM6DQoNCjEpIEkgYW0gbm90IHN1cmUgYWJvdXQgdGhlIHNjb3BlIG9mIG91ciB0ZWFt LCBidXQgc2luY2UgdGhlIHRoaXMgZHJhZnQgb25seSB0YWxrcyBhYm91dCB0aGUgbmV0d29yayBz bGljaW5nIGluIHRyYW5zcG9ydCBuZXR3b3JrLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0 byBmb2N1cyBvbiB0aGUgY29uY2VwdCBvZiB0cmFuc3BvcnQgbmV0d29yayBzbGljaW5nIHJhdGhl ciB0aGFuIEUyRSBuZXR3b3JrIHNsaWNpbmcgaW4gSW50cm9kdWN0aW9uLiANCg0KMikgRm9yIHRo ZSBzdHJ1Y3R1cmUgb2YgU3ViLVNlY3Rpb24gMi4xLiBJbiBteSB1bmRlcnN0YW5kaW5nLCB0aGlz IHBhcnQgdHJpZXMgdG8gY29udmV5IHN1Y2ggb3BpbmlvbiB0aGF0IHRoZXJlIGFyZSB0d28ga2lu ZHMgb2YgaXNvbGF0aW9ucyB3aGljaCBzaG91bGQgYmUgYWNoaWV2ZWQgYW1vbmcgbmV0d29yayBz bGljZXM6IGRhdGEgcGxhbmUgaXNvbGF0aW9uIGFuZCBjb250cm9sIHBsYW5lIGlzb2xhdGlvbi4g SWYgc28sIHRoZSBzZWN1cml0eSBpcyBqdXN0IG9uZSBvZiB0aGUgZGl2ZXJzZSBzZXJ2aWNlIHJl cXVpcmVtZW50cyAoZS5nLiwgbGF0ZW5jeSwgYmFuZHdpZHRoIGFuZCBzbyBvbikgdGhhdCBtb3Rp dmF0ZXMgdGhlIGlzb2xhdGlvbiwgc2hvdWxkIG5vdCBiZSBkaXNjdXNzZWQgcGFydGljdWxhcmx5 IGluIHRoZSBmaWZ0aCBwYXJhZ3JhcGggb2YgU3ViLVNlY3Rpb24gMi4xIG9uIHBhZ2UgNTogIlRo ZSBkaWZmZXJlbnQgc2VydmljZXMgd2lsbCBlYWNoIGhhdmUuLi4uLm9mIHRoZSBvdGhlciBuZXR3 b3JrIHNsaWNlcyIuICANCg0KMykgU3RpbGwgaW4gU3ViLVNlY3Rpb24gMi4xLCBjb3VsZCB3ZSBl eHRyYWN0IHRoZSBmb3VydGggcGFyYWdyYXBoIG9uIHBhZ2UgNCB0byBiZSBhbiBuZXcgaXNzdWUg KGkuZS4sIEF1dG9ub215LCB0aGUgdGhpcmQgcGFydGllcyBzaG91bGQgYmUgYWxsb3dlZCB0byBt YW5hZ2UgdGhlaXIgb3duIG5ldHdvcmsgc2xpY2VzKSBhbmQgZGlzY3VzcyBpdCBpbiBhIHNlcGFy YXRlIFN1Yi1TZWN0aW9uPw0KDQo0KSBBIHR5cG8gaW4gdGhlIHNlY29uZCBwYXJhZ3JhcGggb2Yg Mi4zIG9uIHBhZ2UgNzogIlRoZSByZXF1aXJlbWVudHMgaXMuLi4uIi0tPiJUaGUgcmVxdWlyZW1l bnRzIGFyZS4uLiINCg0KTGkgUWlhbmcNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IE5l dHNsaWNlcyBbbWFpbHRvOm5ldHNsaWNlcy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIG5ldHNsaWNl cy1yZXF1ZXN0QGlldGYub3JnDQq3osvNyrG85DogMjAxN8TqMdTCMTTI1SA0OjAwDQrK1bz+yMs6 IG5ldHNsaWNlc0BpZXRmLm9yZw0K1vfM4jogTmV0c2xpY2VzIERpZ2VzdCwgVm9sIDEsIElzc3Vl IDENCg0KU2VuZCBOZXRzbGljZXMgbWFpbGluZyBsaXN0IHN1Ym1pc3Npb25zIHRvDQoJbmV0c2xp Y2VzQGlldGYub3JnDQoNClRvIHN1YnNjcmliZSBvciB1bnN1YnNjcmliZSB2aWEgdGhlIFdvcmxk IFdpZGUgV2ViLCB2aXNpdA0KCWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0c2xpY2VzDQpvciwgdmlhIGVtYWlsLCBzZW5kIGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3Ig Ym9keSAnaGVscCcgdG8NCgluZXRzbGljZXMtcmVxdWVzdEBpZXRmLm9yZw0KDQpZb3UgY2FuIHJl YWNoIHRoZSBwZXJzb24gbWFuYWdpbmcgdGhlIGxpc3QgYXQNCgluZXRzbGljZXMtb3duZXJAaWV0 Zi5vcmcNCg0KV2hlbiByZXBseWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28g aXQgaXMgbW9yZSBzcGVjaWZpYyB0aGFuICJSZTogQ29udGVudHMgb2YgTmV0c2xpY2VzIGRpZ2Vz dC4uLiINCg== From nobody Sat Jan 14 03: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 580771299F6 for ; Sat, 14 Jan 2017 03:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, 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 hNtVXwv3-Z69 for ; Sat, 14 Jan 2017 03:24:23 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50104.outbound.protection.outlook.com [40.107.5.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311FA129A0B for ; Sat, 14 Jan 2017 03:24:19 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=a.galis@ucl.ac.uk; Received: from alex-galiss-mbp.connect (90.255.50.254) by DB6PR0101MB2341.eurprd01.prod.exchangelabs.com (10.169.220.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Sat, 14 Jan 2017 11:24:16 +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: <958AA6BD-320D-4060-9976-B1234D81524B@ucl.ac.uk> Date: Sat, 14 Jan 2017 11:24:14 +0000 To: Network Slices X-Mailer: Apple Mail (2.3259) X-Originating-IP: [90.255.50.254] X-ClientProxiedBy: AM4PR0101CA0054.eurprd01.prod.exchangelabs.com (10.165.22.150) To DB6PR0101MB2341.eurprd01.prod.exchangelabs.com (10.169.220.139) X-MS-Office365-Filtering-Correlation-Id: af066d85-bfc8-4f79-1b6d-08d43c6fe05c X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:DB6PR0101MB2341; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0101MB2341; 3:Tqcy7HG12NGfL5XxpwO86NqulKmZDQVS+yee8ZW5TLUj0fJ2PLVorYW3plyRplRsHol1am62Bebte8EzCANQhU+8F5Tc3hOw8pLQ0Cq58eEZ65Sy7Qo40SSRJaKfinD78+1Cl0i5E1ElRM1ftEjyJVHfaEx1WQgLpV6tYbLPOfEEO52ySkBpi3OLmWqKNFtuqumRmcMU7HksFHZ+iUMExZhtgBJjpdESIzdqYllpP4qaclCd2ZTsI/NgBABa0+XHi/rwFsxvPYW/h5u2AOmTiA==; 25:JHa1PcyKSAtC4o4+fgS+2Yuy/0fIuAlsusCdfTS/BlOu+OmsyZHZfKqSxWhC0Zr2tmfZBBxHAPwJ4HIX3ANDGy73OApEy8/XjTq9sCQ2jgvtrrmdORPub/HDeop769uNfRUlbyClBwa/73F16Pg3qcfJq4gYRnVrb68Qth9ZNgfinDwq2E/nZApB5q0XGNeZIgkho7iV9BvJvvem0CMZ8Ew6BUTD+8SRMbffo1E1EkBMWkJWjq8098fZTrSSAOC7EXnr2y412rqmCMLa4tag+eHDAXovqVrCurXAwpxFXup0MtRvNCrsgLFY7mdMmhPxFLXK0ZDWWb/TKU98poD5WmSdUUw9xXFStx8eyqzY4GhUuoV3WdDxssLhXGwG33tCGOybuvXpkXzjdPEkVkETQ2+kx+9QV+YtnU4Xw4dQbgkBJq5p6b+SgijGNMQ2I1fxsH8QmUe2j/mPDjzhj4wF+w== X-Microsoft-Exchange-Diagnostics: 1; DB6PR0101MB2341; 31:uTHxyampgAAO697ncKLQjztsfctMf2xyiVPaYQGnd64JwSdmxyZ3ZPYIi926eiu0uIvDMEqYUJ5OMNAyPCJNhCvmCccvHCmrplhEdKJMP6zwcZqEuOD+mEJc9744KoOeNAlZEH94yjjdpDejJzIjiiEkZuQXg5crBN9xHB2tXMQ/h/v5fNTrcrym44jNkn7/gSwvGS2VZnpZW6aFhZpvxLxxV9iqSDsanC5iae4mGSO0SlqzOHT0FOLZ0MSh7ahjCrRVEvIkVJDnR2DEe5u7CweYcUPCfGAP7Rm8hxS9Wtm2tb1Fm4PeN42kyfHBq6V9; 20:Qy2kshiBrB5Glul5I4YEORd+YwrcnuhJ3kJ5IqRjMXW0mkADVUGROxoG5VxtFsDFF6vvNmq1cWyt9MOFAFppbgRhPyMX1oekDRIjvOa16sC+Uy7gqlkw7P5EB4v0OEEBESMZPBuE2UGZHKGDiLXhhcd4UedMaE6qiYaY7OVbx0bAX7XrnOtKkzxy15aNRs12A5mxUPqSlX+ItwuLu0M/oudQ+qvt7mPfjxT1l4b2koeDDIRWJ7YWrTOb80gAmG7c+ryNGJLXfPxLXCe4wTMAyoDrdlqCzJGakv2G90ZZyMCDH7dWqPSUNC4orHrFv8tBX8+R2VJcrBtPb5oXdJRqHq9ltPIB91rvDsB6iRkm0GPn5ACxvL7ooPptQ5vTCltEqCf5JzJU0lM2y946cdpU8lukIQSlb1kqfyh4ghEnYRmWq9FAGfqafOcc8x8R6nujIqG70xrMPTiKFPuvI05z62AYXgKqpGTbjkw08TeZMQpJOf/njdrPBQzkcGJvy4Al X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(113884910453683)(278428928389397)(192374486261705)(60067363179207)(249562145798500); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:DB6PR0101MB2341; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0101MB2341; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0101MB2341; 4:krpQ5M1XuNguCiS801ZViJILytoxk8EEbbr3hxmovtYhQ2znXgrXO53Y20VN+GpO54AIHnSmvsdBE1+GiIDQMJsb6RPBjeeWV2K6rUgrhjMQZrAZRyGPDJm4Gk3U8SofsDTDpaud8bpVOuL1hJhv7Q1xwRKaKOQCPhISNd37Wcox/mDq1QUsEvgPHI8i3igba++k93Ek6EcEmEVasXVhAU+1Lo7FRlbexlW5eZeZzgVny9w14RXTohznIS1XPPRLybEIaZxw5VAFuxcRqHE7U2Lgec9+jqPtJM3X2ypUOUkGwd6+nDzGvnO2XROgtCsmK2tDWI5gclF23smgxA+wBvfFcCo3DLR62cFlfsQb5SL60ZHfl1Jyu26L1pvYHP4Wb+PLcouuHLkz3Jjk2sHN87Js66G1YpSjQ2E5679wuCjRLHDpl/k8pbrCH934SJDbzBNH9ZmOx7eOej6PFoL6Db8yd/MaQUXj81oNjEFYzC3eT1+Bq7qQodihDnV8mmWV9xyJYDLv8r+uMcmEWUOycHzqkP/jkY3PtOsKY+gJt1vv3ScX0U+eFZhu06qFWqYP7a/Hf45Gk0IHu0daKBBopiTDY2M2FW64Rx3/cy6duRYGVTbjY8vVjJ6AsKAjPKjMCsmwVAAU3ymoeZ5KdCuhHI3LmH3fvP5ZhBoqt6razOGMwVX5QwcASyD7LuSLXRux5bwIE3Jmj+ZfOdGZiUHQzHSHi1i8MSdmzi2QTSdOdDGQaZGzCGgJOIxDGuoC8CZ5 X-Forefront-PRVS: 0187F3EA14 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(39450400003)(189002)(57704003)(54164003)(199003)(6506006)(50226002)(25786008)(83716003)(42882006)(6916009)(39060400001)(6486002)(38730400001)(6306002)(82746002)(229853002)(54906002)(6512007)(97736004)(57306001)(27001)(74826001)(81156014)(6116002)(8746002)(2906002)(81166006)(74482002)(66066001)(4326007)(8676002)(47776003)(3846002)(92566002)(105586002)(5890100001)(64544003)(42186005)(23676002)(101416001)(50466002)(50986999)(86362001)(7736002)(575784001)(36756003)(305945005)(5660300001)(189998001)(110136003)(33656002)(106356001)(68736007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0101MB2341; H:alex-galiss-mbp.connect; 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: =?utf-8?B?MTtEQjZQUjAxMDFNQjIzNDE7MjM6bC9JczZxNjV1YWNFZEdZeERRNmdhbUJt?= =?utf-8?B?UWlwZDRsUWJHeWFqeFBrMVFGK0Jvb3JWTFZFRmpCbUwrcC9PSUVZcGNQNjhS?= =?utf-8?B?Sjk4QnlWWlZ6ZngxL01DaGtIWnp0dm4zeXBMT3dVdXFob0U0TDNRaEpNOWN2?= =?utf-8?B?WExhTlk3WFkyVXhycWc3d3pMMnhGalJOSXBMUFZIZGh3cEx3SHJIWEI2MkZF?= =?utf-8?B?Tyt2MXV6MkdKdzFuTFM3Q2FGMk92di83QUpYdVk2cWJkUTZ4ZzVPTW1yMlRJ?= =?utf-8?B?NkRRa0RFRUxaNUphSndmNUxWaE9EMGJicm8vWWxya2dJUFhoeDBlZmZ6bzYz?= =?utf-8?B?NllHQTQ0TjFXWDFXaG1ia2VSaGphZis5UnNwU01PTTV6ak5WMHUxRU5SeVl6?= =?utf-8?B?OUNCYXFRSlUyUUlDOWs2NU5YaUpIelpUTFZOV3c4VDNyQlRicGgyQkFsUEtW?= =?utf-8?B?TzhINTZDaXBaYXErMUpkMGE4bnFQZm1WQXRWWkJwa1RPZHdsdElUOVVoN1pu?= =?utf-8?B?dGFoREM3RUdleTIxWmZ2UHdsRGk5UEQ0RWdEbUVodmg2dmtBUGlFbHBYTjJm?= =?utf-8?B?WDNUK2JVcFJVeWcyTTJ5WndNOXR6Z2YrZzBPb2EvQWtzTUhDT0dmMlo1N29X?= =?utf-8?B?dGRIL0pnRWh0Mno5alN0NDZsNFFQUHpCdTBUN1dQSmhvVGo2QmQ4QXFVc2lJ?= =?utf-8?B?TTc2NmdVcHBCNENzODR5dng1c2xVUDZiU2NkRHc5OW1VbkpueEx2Qi9HcXNR?= =?utf-8?B?dWx2MjhZMnIyN0UwWTA4WVVBYUFFTUFyK1BOckJYampmVU1NQWdCMUtGek1D?= =?utf-8?B?Z2lrUDd4K3BJb2o1OGl0R1RVNFFlTWtmZi9ueStuTFJxeXZ6V09nSkI2ci9Z?= =?utf-8?B?Z0FTQ2FQWXRYcmZsVDI1S2pDbW8yU21rai8vOERwQU42RnBYUnM3U2hEL0J3?= =?utf-8?B?UEhxNlQxWHNrZ1VWc0dpOURCeVp1YUJseU9LUnFtd3NYVC8xcTZVc0sxeDU1?= =?utf-8?B?TVl6OUpnKzArNzAwS0RKMzJKQ1ROQ0k2Wmw2aTZmU0RKM1doMkkyZ3lsWGpn?= =?utf-8?B?SGQ1NUlXeUlnTGlMWjlkU0J0dDl1V3dTUlV6Z2RDem45ZC9MUzkzV0IwdlJJ?= =?utf-8?B?UnFrSWpiMENsTTR5QTc0dVhXTzZib1VBRG81Mkt0QjExakJqK3pTamhNME1y?= =?utf-8?B?cUpNbm90ZGh4dkpyNm1KV1lOcGcvQ2VUUHROQjZxYzRQZHRJQ3pIUC9BcG9O?= =?utf-8?B?OUZBaTBLcVNlY3ordGh6SzlwNlNHMnlQYzQyaFIySjdDMlhpMEpBV2tmVzdD?= =?utf-8?B?VS9XdEQ3aVpPL2ovcUo1UnI0MGg2c001MGRVc1BqUGs2K200eklBZUNGZUhI?= =?utf-8?B?WWRYNVVuVkM3STk2Uko4UHNMdTMwdXNwVFFlVjZMRmFYTzFIU2hhblBkVXBS?= =?utf-8?B?bHlTRHYyQmdLR1B3NkVFS1dQTndKSTZWMjBqSXVDMDhxVGJzZ0VibHRFanRr?= =?utf-8?B?aGU5eGlib0VEN2hrblRhWnZJTEhmMFhpdXJMZklPSWZ1cXE1QU9QMjgrT0pV?= =?utf-8?B?ck1mOTdlR09CbHd3UmRpSG5GaWxldnB0d2UzakZIbGFScU5FYlBUNmhIeVhB?= =?utf-8?B?T0R2a1VqbnlrVHFhSTB3YklQRmd4OTduYmZ3anJ4NFR1aGpJVVBsaEZZUDdN?= =?utf-8?B?MVRSdk1nT2pLMkU2TmgzS1hSVGIvWmxmODlmYTQxbThpcHMvcWNHdVd5VWVk?= =?utf-8?B?TWdqeldPdldRbGxZWWtLVWpraXdYMklEODFkbVl2NjRiWWZlNy9JcHFLVFlJ?= =?utf-8?B?dldxU3BlN2t0RHo1djFNaEVpU28wK2hELzZpWXlPakJYSm1teHEwd1JYTUVu?= =?utf-8?Q?acBewT2WWZrxs=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0101MB2341; 6:1hnTG1jjojr8874zF0QNMimGxAmOOaIPU2Mk9naDmLBzrZqPslx0pRK4eHfvavVMIE3P0uNqkL63CHuevoP69ESOl2xaUhHj9kYwEy4IXMEzvy7VEXFBCTLX2R1y20ffuOqT8mxp9/FjNnkDJK5BXODjmUlaKEvq6QBwLq9aAbkZbw/6xF1zhrZmxWBJi3dFvD4/x8wi9mWhdqkFdHYw5bC12fUESt68rP8hKf3HZwGE8YUW/3IBV1RFCs3TXgPKuJtCK+NkeEDK8b+/N46c10jEvkfwFg1fDbQeTw+Z0hQiSLJwGWvrP1vOBzzx1qPM5UUJTK7IDNormKHzi5sSuDIWl6KJnZMrCtGTQ32KNVVpDyP2sqgXZ8vFvB0zwEKl+td1VKH8Ntb744ylhheh/ze87DsiLsPrg8ya9hzS1sM=; 5:JRRSQ8geRqbXJd9R+/8MbVDuwTH+s86Ucx6jpkvj1BNTvdW23LiMT9WWNXq7fwIzgbCT3rwUS4P7BVeb5NVhdfyfd/W8dXdGxRQm70c6MzbYJKSfLCmkefT/K5r5X1Cd8elRv9IeGX5WuPkXehDdMWOSDT+iDUrXRe1RROhvuy0=; 24:m201RawcNnpMVy+SZaUxW3ZKKLcXJHnrz9TGErchDVGJAwhUahXtodzrT5g9USwM13NKvU+Q67hwdgYIk+3OuKNZ1JqM45zQ0qqL6iRXtV4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DB6PR0101MB2341; 7:Xv5jgeu1mgINhLx1JzAs3+pkkvAIZBwmlkN056rmkzvDHtqo7Cv8/8SOaXArjRpZReYrYxpE1kc0ZB1iwwADlyHsnOVy4vkTSA77eL3iRbnWC6sxERhp/HTMfovJrLi4czJyf2OXHIu6GmgkQbguHdFjIoH8ec3SfFRHwrXLjCxYH2uQ121+CydooyYXhSvpw7FmInafegn40W2e8kBPHZz1EMIN0ufGmsn4ceIque2QSujfrMwnxcNWX0vem7Sw+KaUepJZfdWAl/agdNfqoicEZSVGrDKpKpsTB1dWlfLzHLJBSVyKhS8bCAyPGBNkMCuTY3XyEgQgmiSIoSSVKgXS/WfiLD2BreiysR0NtG7kIymX89uU/gpB6piSYfxTlbaCIgcoF19D0t7h4aBl2xgOvdIgVrRDxSfZahcxMq9mqPmEwS9IghlsPe5H96IFXGyP7kE/FkmA9a297WNtTg== X-OriginatorOrg: ucl.ac.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2017 11:24:16.6369 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0101MB2341 Archived-At: Cc: Sheng Jiang , Stewart Bryant , "Kiran.Makhijani" , "Dongjie \(Jimmy\)" Subject: Re: [Netslices] Minutes of the Network Slicing meeting at IETF 97 of 15th November 2016 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: Sat, 14 Jan 2017 11:24:27 -0000 14th January 2017 Dear All Re: Minutes of the Network Slicing meeting at IETF 97 - 67 = participants signed the attendance sheet. =20 Please find for your reference the enclosed minutes of the Network = Slicing meeting at IETF 97 of 15th November 2016. This meeting included 4 presentations on Network Slicing problem = statement, 3 specific IETF drafts under progress and comments and = discussion. One of the action from this meeting that was based on unanimous interest = on working on slicing at IETF was to consolidate all suggestions and = comments into an unified problem statement and work plan which would be = the basis of a non-WG BoF at IETF 98 or IETF99. An initial draft is ready for your review and it will posted to the = mailing list < NetSlices@ietf.org> early next week. Best Regards Alex = =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2= =80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80= =A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6= =E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6=E2=80=A6 From: Stewart Bryant Date: Tue, Nov 22, 2016 at 03:07 Subject: Network Slicing meeting at IETF 97 Thanks to everyone that participated and thanks to those that took notes = of the meeting. Jie and I have merged the notes, which are included below. Corrections = welcome. I have put the slides on dropbox rather than attach them to the email. The slides can be found here: = https://www.dropbox.com/s/ax2ofdwygjema8z/0-Network%20Slicing%20Side%20Mee= ting%20Introduction_IETF97.pdf?dl=3D0 = https://www.dropbox.com/s/k2or6sd0ddzrc6c/1-Network%20Slicing%20Problem%20= Statement_IETF97.pdf?dl=3D0 = https://www.dropbox.com/s/g8zvfvbrtkysjs1/2-Autonomic%20Slice%20Networking= _IETF97.pdf?dl=3D0 = https://www.dropbox.com/s/d3rk4pjeg552ilv/3-Architecture%20for%20deliverin= g%20multicast%20mobility%20services%20using%20network%20slicing_IETF97.pdf= ?dl=3D0 = https://www.dropbox.com/s/e3isn1bxwwhaw8g/4-ACTN%20and%20network%20slicing= _IETF97.pdf?dl=3D0 If anyone has trouble with the links, please let me know and I will make = some other arrangement for depositing the files. To avoid span traps, I am sending this to a few people at a time, so = please do not reply to this email and expect the message to go to the = entire set of attendees. The last discussion I had with the Routing ADs = suggested that we continue the discussion on the IETF TEAS list. I am = not sure that this is necessarily the best long term home, but let=E2=80=99= s start there and if we generate to much noise outside their scope, I am = sure we will be asked to move and provided with a new home. Best Regards Stewart & jie =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Network Slicing Side Meeting Nov 14, 2016, 19:00-21:00, Studio 3 67 People signed the attendance sheet. 0. General Admin Jie Dong introduced the purpose of the meeting. Services have unique requirements, end-2-end slicing is required for 5G. = Among definitions we need to establish common definition. Purpose is to have a common view of what network slicing is in IETF. List request has been sent to Deborah (Routing Area AD). 1. Network slicing problem statement Stewart Bryant = https://tools.ietf.org/html/draft-dong-network-slicing-problem-statement-0= 0 Presentation: What is to be done in IETF, what existing and new work? Existing definition - NGMN - 3GPP - ITU-T (FG IMT-2020) - IETF? Requirements of Network Slicing - Isolation/separation - Customization of topology - Flexibility of topology - Guaranteed QoS - Management consideration What should be definition of network slicing in IETF ? What is needed beyond connectivity? What is the scope of network slicing in IETF? How much can existing/on-going tech meet the reqt? Discussion/Questions: Comment 1. IETF is protocol-oriented, how would slicing change the = semantics of existing protocols? Stewart: We typically have a set of tools designed for best-effort = fabrics and adding BW, these are not scalable and we need some = additional scheduling. Comment 2. We typically build separate networks for banking and other = low latency apps, this is not economical. Isolation and security are = weak points. Comment 3. What are the performance and isolation requirements? Does = this mean statistical sharing is out of scope? Fixed fraction of b/w = seems to be a must. Stewart: There will be a spectrum of requirements, different QoS for = different application, we may need some packet scheduling.Do we need = isolation using mechanisms like IEEE (time sensitive networking ? TSN) = or detnet. If its bit-level, we will go back to TDM. Andrew: isolation and security is the biggest challenge, figure out how = to provide banking applications in economic manner, such as a slice. = Packet scheduling at buffer and line speed level is not enough we need = to adapt to packet changes at micro-level (it was quietly mentioned, we are not thinking at bit-level but focus at = packet level). Comment 4. Look at 5G applications for machine critical, interface b/w = down to radio is key, we may adapt BW based on radio capacity, Internet = does not do this today, we need to figure this out. Stewart: It may be a packet level. factoring into a lower layer is an = issue Comment 5. Can we define slicing?? Stewart: We can also agree on an existing definition, which would be = useful. Comment 6. Generalised packet networks are not suitable for hard packet = tunnels. Comment 7. Dave Allen (Ericsson): slicing definition leave it open = disjoint resource like wavelength is considered in other forum as the = only way to achieve isolation. e.g. WDM-PON, wavelengths allocated per = slice. (Young Lee added that WSON controller is already doing this). = What does packet have to do if isolation cannot be guaranteed? 2. Autonomic slice networking Alex Galis Presentation: = https://tools.ietf.org/html/draft-galis-anima-autonomic-slice-networking-0= 0 Generation 1 - Resource partition of network resource is one definition. Generation 2 - Network function and services are another definition of = network slicing. Generation 3 - Grouping of partitioning of 5G slicing Generation 4 - Management and control and advertisement has to be added = to the Network slicing definition ANIMA - unified network slicing definition in the context of autonomic = networking - The service instance component - A network slice instance component - Resource component - Slice capability exposure component Suggested 15 work items and issues Discussion/Questions: Comment 1. Dino: asked difference between horizontal and vertical = slicing. Vertical slicing, can an application be a member of multiple = slices? Will Extranet be required? For horizontal slicing, would it be = stitching or something else? These would be for customers ill shared = services and isolation for specific VPN connectivity Alex: Yes, level of abstraction and level of isolation need to be = considered, and separate control may also be needed. Stewart: We may see both models Comment 2. This complicates the solution space. Alex: This is not an intent to recreate a VPN technology. Comment 3. Feels like IETF is lagging in industry work, upper service = layer which drives network resources. OpenSource is already ahead/doing = some of this, slicing is mainly multi-tenant, this is not rocket science = or new. They are trying to map existing technology like VXLAN and = mapping it into YANG. Is there a new architecture and protocol required? = what is the role of IETF? API ? application level TOSCA; policy; YANG; = already in place in industry. Question is where is the gap? Map to = protocol of new or existing protocols. Stewart: Those are the questions we are asking at the start of the = session. Comment 4. Slicing is a service definition, where is the gap? Categorise them and see if we need new protocols, or adapt existing. Alex: Yes, at least 15 problems, these are not supported by existing = protocols. Comment 5. We have a slicing architecture (as part of a H2020 project), = and service orchestrator, we then define flows which are application = specific: IoT, video, etc. Comment 6. Ravi: IMT-2020 challenge was that service context could be = only identified by flow tuple in cp, dp and mgmt. Also slicing is = interesting for ICN as it allows new architectures and new properites = per slice basis. 3. Architecture for delivering multicast mobility services using network = slicing Truong-Xuan Do https://tools.ietf.org/html/draft-xuan-dmm-multicast-mobility-slicing-00 Presentation: Multicast functionality is different for say broadcast, mobility etc = cases, so there is a need to function decomposition and function = chaining. Discussion/Questions: Comment 1. You are aware of DMM working group, DMM FTC draft defines a = model that covers this. I think the group does not have a good = definition of "slice", domain is similar with 5G slice. I think it=E2=80=99= s not clear what a slice is. Stewart: This is why we are here; do we need to define "slice"? 4. ACTN and network slicing - Daniele Ceccarelli https://tools.ietf.org/html/draft-ietf-teas-actn-framework-01 Presentation: Describe end to end L2VPN/L3VPN is not enough, so there are 3 different = level of controls (CNC, PNC and MDSC for customer, physical, = multi-domain network controls). Access points, per domain tunnels and = inter-domain links. Customer is able to provide constraints during = network provisioning. Discussion/Questions: Comment 1. Parviz: ACTN is a great piece of work, we have integrated = based on this framework. We shipped and integrate into ONOS. ACTN is = used for integrated packet optical SDN based solution. It is generalized = for L0-L3 layers and need to be perhaps extended for L1,L2 and NS. ACTN = seems to have a good starting point for network resource slicing and = Detnet may be implementing a protocol solution for time-sensitive = networking. Comment 2. Do you slice at the lower/physical lower and provide a slice = to the customer? So they can modify network resource, based on their = specific slice? Customer may just want the resource, not a solution, = they want to manage it by themselves. Daniele: Yes, they can manage their own resource. Young Lee: VNF connectivity is included in the solution. Alex: Maybe methods for slicing exist, the management methods for = specific applications and network functions are missing. Comment 3. ACTN has multiple topology descriptions (physical, virtual = and customer), can it support end to end slicing with applications? YoungLee: ACTN also support NFV-constraints as part of abstraction and = connectivity. Comment 4. Looking at ACTN it seems it can abstract multiple physical = domains and give us a logical view of TE/transport. Daniele: ACTN introduces virtual networking, between MDSC and CNC, = beneath PNC, its technology/vendor specific. Comment 5: Why ACTN for network slicing? Does it support hierarchy? YoungLee: Yes. It does via MDSC-MDSC recursion. Comment 6. ACTN is for multi-domain. How about for a single domain? YoungLee: Yes, multi-domain solution includes single-domain, which is = easier. Comment 7. For 5G transport, IETF has a role to play. Front-haul, = back-haul and cross haul need transport network abstraction which is = needed for 5G network. Orchestration federation takes each component to = give end-to-end solution. Georgios: Asked how does it do QoS besides partitioning of n/w = resources. Ans: Whatever TC can do is supported Pedro: There are 2 aspects of slices - an act of creating it, and second = customizing and managing it in isolation is second part of the problem. Comment: Service abstraction layer is missing and Information models. Seil: is there a gap to be discussed. Natasha from GSMA: not duplicate the work of other SDOs, if work needs = to evolve they will let IETF specific group know. Wim from Nokia: slicing includes all - management, applications, radio = etc beyond transport. Chris Seal: we need a stable platform first that doesnt exist. Loa: non WG BOF can be done, it is way too early to exclude from IETF Dave Allend: so many people are working on it. Problem space need to be = deconstructed, work needs to be done in totality of it. Jonas: can we invite 3GPP for next meeting? 5. Open Discussion 60 mins Stewart posed several questions 1. Does the IETF need to work on slicing? Yes 2. Does existing technologies solve the full set of slicing = requirements? No Comments: Already there are several slice definitions, educating and agreeing = definitions is useful - Suggest we allow implementations first using existing solutions, using = the tools which are already available. - Network slicing is important; it needs to be end-to-end and the IETF = has be involved. We also need to engage with other SDOs (3GPP, et = al.),including inviting the (SDOs) to participate in a BoF. - ACTN seems like a good starting point, maybe this needs to be extended = for additional technologies like Radio - A lot of this discussion needs to be relevant to the IETF, what's on = and in the wire - Process from here for the discussion, is non-WG BoF and then = WG-forming BoF. We should not exclude a potential WG on this topic, we = should prepare and investigate, then if we decide not to form that=E2=80=99= s better than not being able to form due to a lack of investigation = work. - One reason for lots of slicing definitions is the fact so many people = are working on this topic. Across different areas and functions = (controllers, orchestrations), and scheduling and APIs. We would need to = deconstruct the problem space to understand what is needed, and how the = IETF can help. - Of the questions asked through show of hands, people favored forming a = non-working group and agreed this is an area IETF can work into. - Identifying gaps from IETF perspective is the most important aspect. 3. Does the IETF need to focus discussion and develop tools for slicing? (no discussion captured) 4. Interests to work on slicing? A lot 5. Willing to contribute to drafts and discussions? Some = From nobody Tue Jan 17 03:56:15 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 1E68E1295E0 for ; Tue, 17 Jan 2017 03:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.055 X-Spam-Level: X-Spam-Status: No, score=-3.055 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, 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 1dduO-1M7M4m for ; Tue, 17 Jan 2017 03:41:20 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.146]) (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 EFEA2129418 for ; Tue, 17 Jan 2017 03:41:19 -0800 (PST) Received: from [85.158.136.83] by server-10.bemta-5.messagelabs.com id 0E/8D-04988-DD20E785; Tue, 17 Jan 2017 11:41:17 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRWlGSWpSXmKPExsWi75nTqXuHqS7 C4MMBaYvG/iWMDoweS5b8ZApgjGLNzEvKr0hgzbi2vZu54LxpxaSm9ywNjL/0uhi5OIQEtjNK fFzVxgbhHGaUWDCpgRXC2cwo8aL/EpDDycEm4CpxdNcddhBbREBX4ubVT4xdjBwcwgL6EqdOp UCETSRmLV/GBmHrSezct4ERxGYRUJU4em8bE4jNKxAqcXfuPbAxjAKyEl8aVzOD2MwC4hK3ns wHq5EQEJBYsuc8M4QtKvHy8T9WiJo8iYUrv7JAzBGUODnzCZgtBDT/xKE5bBMYBWchGTULScs sJC0QcR2JBbs/sUHY2hLLFr5mhrHPHHjMhCy+gJF9FaNGcWpRWWqRrpG5XlJRZnpGSW5iZo6u oYGpXm5qcXFiempOYlKxXnJ+7iZGYGTUMzAw7mC8usXvEKMkB5OSKG/H49oIIb6k/JTKjMTij Pii0pzU4kOMMhwcShK8jsBIExIsSk1PrUjLzAHGKExagoNHSYRXCyTNW1yQmFucmQ6ROsWoKC XO6wmSEABJZJTmwbXB0sIlRlkpYV5GBgYGIZ6C1KLczBJU+VeM4hyMSsK87xmBpvBk5pXATX8 FtJgJaPF1nWqQxSWJCCmpBkbdiFnb1rNnMV5l4bbXUJV5mJ2qmybMpKcwYevsaWblnc1Txbcd 0ux/I5rcuiVqjdI0yZWhLjUFLH58Jy4qzlDeHH97y3rHXflFpyqLOZV6z3adX2ayIm3b7cOL9 hn5Jij+mei/e07LXnVztjkt9tUK17ZdnNkdcnXWvEDzypUn8wIsvzNceKnEUpyRaKjFXFScCA DyraMfBgMAAA== X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-13.tower-36.messagelabs.com!1484653260!81107546!1 X-Originating-IP: [47.73.108.137] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29589 invoked from network); 17 Jan 2017 11:41:16 -0000 Received: from vgdpm11vr.vodafone.com (HELO voxe06hw.internal.vodafone.com) (47.73.108.137) by server-13.tower-36.messagelabs.com with AES256-SHA encrypted SMTP; 17 Jan 2017 11:41:16 -0000 Received: from VOEXH08W.internal.vodafone.com (47.73.211.206) by edge1.vodafone.com (195.232.244.51) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 17 Jan 2017 12:40:29 +0100 Received: from VOEXC04W.internal.vodafone.com (145.230.101.24) by VOEXH08W.internal.vodafone.com (47.73.211.206) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 17 Jan 2017 12:40:28 +0100 Received: from VOEXM17W.internal.vodafone.com ([169.254.1.118]) by VOEXC04W.internal.vodafone.com ([145.230.101.24]) with mapi id 14.03.0294.000; Tue, 17 Jan 2017 12:40:28 +0100 From: "Smith, Kevin, (R&D) Vodafone Group" To: "netslices@ietf.org" Thread-Topic: [Netslices] Problem statement comments Thread-Index: AdJwrt+TK/Jki/rzTuGK1rP2dLF4VA== Date: Tue, 17 Jan 2017 11:40:27 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A4BAAB326B17CE40B45830B745F70F10EE4A87AFVOEXM17Winterna_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 17 Jan 2017 03:56:14 -0800 Subject: [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: Tue, 17 Jan 2017 11:41:22 -0000 --_000_A4BAAB326B17CE40B45830B745F70F10EE4A87AFVOEXM17Winterna_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Jie and Stewart, Thanks for drafting the problem statement, it's good to see interest in net= work slicing outside of mobile standards. In fact, I think here is an oppor= tunity 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 c= ontention policy. Since many operators operate PLMN, fixed fibre broadband,= WiFi, Narrow Band IoT etc. networks then the benefits of slicing can inclu= de handoff between access networks according to resource contention or othe= r factors (such as mobility). So IMO the problem scope is broader than just= 3GPP mobile access and core. I'm not familiar with network slicing discuss= ions in non-mobile fora, so the problem statement may in fact stimulate tho= se discussions. Another comment is that the various service characteristics are mentioned t= hroughout the draft - and you make the point that different services requir= e different treatment - but I suggest that needs calling out in the introdu= ction as it's so important. I have heard the misconception that 5G can simp= ly be realised by building out capacity, to meet all service requirements i= n a 'one (bigger) size fits all' 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 di= ffer across service types and industries, is crucial upfront. 2.5. Management considerations: without opening a Net Neutrality can-o'-wor= ms, it may be worth noting that the intention of slicing is to tailor treat= ment 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 --_000_A4BAAB326B17CE40B45830B745F70F10EE4A87AFVOEXM17Winterna_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Jie and Stewart,

 

Thanks for drafting the problem statement, it’= s good to see interest in network slicing outside of mobile standards. In f= act, 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 techn= ology, allowing for the allocation and release of network resources accordi= ng 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 be= tween access networks according to resource contention or other factors (su= ch as mobility). So IMO the problem scope is broader than just 3GPP mobile = access and core. I’m not familiar with network slicing discussions in non-mobile fora, so the problem statem= ent may in fact stimulate those discussions.

 

Another comment is that the various service characte= ristics are mentioned throughout the draft - and you make the point that di= fferent services require different treatment - but I suggest that needs cal= ling out in the introduction as it’s so important. I have heard the misconception that 5G can simply be realise= d by building out capacity, to meet all service requirements in a  = 216;one (bigger) size fits all’ 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 c= rucial upfront.

 

2.5. Management considerations: without opening a Ne= t Neutrality can-o’-worms, it may be worth noting that the intention = of slicing is to tailor treatment towards the service type and delivery con= text, 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 consider= ation

 

All best,

Kevin

Vodafone R&D

 

--_000_A4BAAB326B17CE40B45830B745F70F10EE4A87AFVOEXM17Winterna_-- From nobody Thu Jan 19 17:28:17 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 4C6B8129410 for ; Thu, 19 Jan 2017 17:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 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=-3.199, 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 nzlse7Q6cPeb for ; Thu, 19 Jan 2017 17:28:14 -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 E4C541293F3 for ; Thu, 19 Jan 2017 17:28:13 -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 DEW08076; Fri, 20 Jan 2017 01:28:10 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 20 Jan 2017 01:28:02 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 20 Jan 2017 09:27:51 +0800 From: "Dongjie (Jimmy)" To: "qiangli (D)" , "netslices@ietf.org" Thread-Topic: Netslices Digest, Vol 1, Issue 1--Problem Statement Thread-Index: AQHSbjoZfWaochLlHE6Bsu5kgSVUiqFAmqwQ Date: Fri, 20 Jan 2017 01:28:26 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92793572CB2@NKGEML515-MBX.china.huawei.com> References: <06C389826B926F48A557D5DB5A54C4ED29B99218@SZXEMI507-MBS.china.huawei.com> In-Reply-To: <06C389826B926F48A557D5DB5A54C4ED29B99218@SZXEMI507-MBS.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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.588167AC.0029, 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: fd89ce9cc7811f414f7d80acd3d7e93b Archived-At: Subject: Re: [Netslices] Netslices Digest, Vol 1, Issue 1--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, 20 Jan 2017 01:28:16 -0000 SGkgTGkgUWlhbmcsIA0KDQpUaGFua3MgYSBsb3QgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZSBz ZWUgbXkgcmVwbGllcyBpbmxpbmU6DQoNCkJlc3QgcmVnYXJkcywNCkppZQ0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE5ldHNsaWNlcyBbbWFpbHRvOm5ldHNsaWNlcy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgcWlhbmdsaSAoRCkNCj4gU2VudDogU2F0dXJk YXksIEphbnVhcnkgMTQsIDIwMTcgMzo0NSBQTQ0KPiBUbzogbmV0c2xpY2VzQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbTmV0c2xpY2VzXSBOZXRzbGljZXMgRGlnZXN0LCBWb2wgMSwgSXNzdWUg MS0tUHJvYmxlbSBTdGF0ZW1lbnQNCj4gDQo+IEhpIEFsbCwgSSBoYXZlIHJlYWQgdGhpcyBkcmFm dCBhbmQgaGF2ZSB0aGUgZm9sbG93aW5nIHN1Z2dlc3Rpb25zOg0KPiANCj4gMSkgSSBhbSBub3Qg c3VyZSBhYm91dCB0aGUgc2NvcGUgb2Ygb3VyIHRlYW0sIGJ1dCBzaW5jZSB0aGUgdGhpcyBkcmFm dCBvbmx5IHRhbGtzDQo+IGFib3V0IHRoZSBuZXR3b3JrIHNsaWNpbmcgaW4gdHJhbnNwb3J0IG5l dHdvcmssIEkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIGZvY3VzDQo+IG9uIHRoZSBjb25j ZXB0IG9mIHRyYW5zcG9ydCBuZXR3b3JrIHNsaWNpbmcgcmF0aGVyIHRoYW4gRTJFIG5ldHdvcmsg c2xpY2luZyBpbg0KPiBJbnRyb2R1Y3Rpb24uDQoNClllcyB0aGUgc2NvcGUgb2YgdGhpcyBkcmFm dCBpcyBuZXR3b3JrIHNsaWNpbmcgaW4gbm9uLW1vYmlsZSBuZXR3b3Jrcywgd2Ugd2lsbCBtYWtl IHRoaXMgY2xlYXJlciBpbiBuZXh0IHJldmlzaW9uLg0KDQo+IDIpIEZvciB0aGUgc3RydWN0dXJl IG9mIFN1Yi1TZWN0aW9uIDIuMS4gSW4gbXkgdW5kZXJzdGFuZGluZywgdGhpcyBwYXJ0IHRyaWVz IHRvDQo+IGNvbnZleSBzdWNoIG9waW5pb24gdGhhdCB0aGVyZSBhcmUgdHdvIGtpbmRzIG9mIGlz b2xhdGlvbnMgd2hpY2ggc2hvdWxkIGJlDQo+IGFjaGlldmVkIGFtb25nIG5ldHdvcmsgc2xpY2Vz OiBkYXRhIHBsYW5lIGlzb2xhdGlvbiBhbmQgY29udHJvbCBwbGFuZSBpc29sYXRpb24uIElmDQo+ IHNvLCB0aGUgc2VjdXJpdHkgaXMganVzdCBvbmUgb2YgdGhlIGRpdmVyc2Ugc2VydmljZSByZXF1 aXJlbWVudHMgKGUuZy4sIGxhdGVuY3ksDQo+IGJhbmR3aWR0aCBhbmQgc28gb24pIHRoYXQgbW90 aXZhdGVzIHRoZSBpc29sYXRpb24sIHNob3VsZCBub3QgYmUgZGlzY3Vzc2VkDQo+IHBhcnRpY3Vs YXJseSBpbiB0aGUgZmlmdGggcGFyYWdyYXBoIG9mIFN1Yi1TZWN0aW9uIDIuMSBvbiBwYWdlIDU6 ICJUaGUgZGlmZmVyZW50DQo+IHNlcnZpY2VzIHdpbGwgZWFjaCBoYXZlLi4uLi5vZiB0aGUgb3Ro ZXIgbmV0d29yayBzbGljZXMiLg0KDQpSZWdhcmRpbmcgdGhlIGRpZmZlcmVudCByZXF1aXJlbWVu dHMgb24gc2VjdXJpdHksIG15IGZlZWxpbmcgaXMgaXQgaXMgY2xvc2VseSByZWxhdGVkIHRvIGlz b2xhdGlvbiwgYnV0IG1heSBub3QgYmUgdG90YWxseSBjb3ZlcmVkIGJ5IGVpdGhlciBkYXRhIHBs YW5lIG9yIGNvbnRyb2wgcGxhbmUgaXNvbGF0aW9uLiBCdXQgeW91IGFyZSByaWdodCB3ZSBuZWVk IHRvIGNvbnNpZGVyIHRvIHJldmlzZSB0aGUgc2VjdXJpdHkgcmVsYXRlZCBwcm9ibGVtIHN0YXRl bWVudCBpbiBuZXh0IHJldmlzaW9uLCBhbmQgaXQgd291bGQgYmUgZ3JlYXQgaWYgeW91IGNvdWxk IGNvbnRyaWJ1dGUgc29tZSB0ZXh0Lg0KDQo+IDMpIFN0aWxsIGluIFN1Yi1TZWN0aW9uIDIuMSwg Y291bGQgd2UgZXh0cmFjdCB0aGUgZm91cnRoIHBhcmFncmFwaCBvbiBwYWdlIDQgdG8gYmUNCj4g YW4gbmV3IGlzc3VlIChpLmUuLCBBdXRvbm9teSwgdGhlIHRoaXJkIHBhcnRpZXMgc2hvdWxkIGJl IGFsbG93ZWQgdG8gbWFuYWdlDQo+IHRoZWlyIG93biBuZXR3b3JrIHNsaWNlcykgYW5kIGRpc2N1 c3MgaXQgaW4gYSBzZXBhcmF0ZSBTdWItU2VjdGlvbj8NCg0KWWVzIGF1dG9ub215IG9mIHRoZSB0 aGlyZCBwYXJ0aWVzIGlzIGEgaG90IHRvcGljIG9mIDVHIG5ldHdvcmsgc2xpY2luZywgYW5kIGN1 cnJlbnRseSB3ZSBhcmUgd29ya2luZyB0b2dldGhlciB3aXRoIEFsZXggYW5kIEtpcmFuIHRvIGlt cHJvdmUgdGhlIHByb2JsZW0gc3RhdGVtZW50IG9mIHRoaXMgcGFydC4NCg0KPiA0KSBBIHR5cG8g aW4gdGhlIHNlY29uZCBwYXJhZ3JhcGggb2YgMi4zIG9uIHBhZ2UgNzogIlRoZSByZXF1aXJlbWVu dHMNCj4gaXMuLi4uIi0tPiJUaGUgcmVxdWlyZW1lbnRzIGFyZS4uLiINCg0KVGhhbmtzIGZvciBj YXRjaGluZyB0aGUgdHlwby9uaXQsIGl0IHdpbGwgYmUgY29ycmVjdGVkIGluIG5leHQgcmV2aXNp b24uDQoNCj4gDQo+IExpIFFpYW5nDQo+IA0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjL OiBOZXRzbGljZXMgW21haWx0bzpuZXRzbGljZXMtYm91bmNlc0BpZXRmLm9yZ10gtPqx7Q0KPiBu ZXRzbGljZXMtcmVxdWVzdEBpZXRmLm9yZw0KPiC3osvNyrG85DogMjAxN8TqMdTCMTTI1SA0OjAw DQo+IMrVvP7IyzogbmV0c2xpY2VzQGlldGYub3JnDQo+INb3zOI6IE5ldHNsaWNlcyBEaWdlc3Qs IFZvbCAxLCBJc3N1ZSAxDQo+IA0KPiBTZW5kIE5ldHNsaWNlcyBtYWlsaW5nIGxpc3Qgc3VibWlz c2lvbnMgdG8NCj4gCW5ldHNsaWNlc0BpZXRmLm9yZw0KPiANCj4gVG8gc3Vic2NyaWJlIG9yIHVu c3Vic2NyaWJlIHZpYSB0aGUgV29ybGQgV2lkZSBXZWIsIHZpc2l0DQo+IAlodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldHNsaWNlcw0KPiBvciwgdmlhIGVtYWlsLCBzZW5k IGEgbWVzc2FnZSB3aXRoIHN1YmplY3Qgb3IgYm9keSAnaGVscCcgdG8NCj4gCW5ldHNsaWNlcy1y ZXF1ZXN0QGlldGYub3JnDQo+IA0KPiBZb3UgY2FuIHJlYWNoIHRoZSBwZXJzb24gbWFuYWdpbmcg dGhlIGxpc3QgYXQNCj4gCW5ldHNsaWNlcy1vd25lckBpZXRmLm9yZw0KPiANCj4gV2hlbiByZXBs eWluZywgcGxlYXNlIGVkaXQgeW91ciBTdWJqZWN0IGxpbmUgc28gaXQgaXMgbW9yZSBzcGVjaWZp YyB0aGFuICJSZToNCj4gQ29udGVudHMgb2YgTmV0c2xpY2VzIGRpZ2VzdC4uLiINCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTmV0c2xpY2VzIG1h aWxpbmcgbGlzdA0KPiBOZXRzbGljZXNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRzbGljZXMNCg== From nobody Thu Jan 19 18:03:01 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 703D512944C for ; Thu, 19 Jan 2017 18:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 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=-3.199, 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 T3e3fA236dew for ; Thu, 19 Jan 2017 18:02:57 -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 12C161293E9 for ; Thu, 19 Jan 2017 18:02:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZD76897; Fri, 20 Jan 2017 02:02:54 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 20 Jan 2017 02:02:51 +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; Fri, 20 Jan 2017 10:02:43 +0800 From: "Dongjie (Jimmy)" To: "Smith, Kevin, (R&D) Vodafone Group" , "netslices@ietf.org" Thread-Topic: [Netslices] Problem statement comments Thread-Index: AdJwrt+TK/Jki/rzTuGK1rP2dLF4VACDY/eg Date: Fri, 20 Jan 2017 02:03:18 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92793572CEF@NKGEML515-MBX.china.huawei.com> References: 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_76CD132C3ADEF848BD84D028D243C92793572CEFNKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58816FCF.00A9, 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: 0e6eb9a34eca209de096445a18e81664 Archived-At: 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: Fri, 20 Jan 2017 02:03:00 -0000 --_000_76CD132C3ADEF848BD84D028D243C92793572CEFNKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kevin, Thanks a lot for your comments. I totally agree with you that network slicing is not only related to mobile= , but also the fixed network, as in 5G end-to-end network slicing is requir= ed to meet the diverse service requirements. The discussion about Network s= licing of non-mobile networks can be found in ITU-T FG IMT-2020 and BBF, an= d here we also want to identify the work needed in IETF. This draft was a p= reliminary attempt to describe the problem statement of network slicing in = the fixed networks part, and recently Stewart and I are working together wi= th Alex and Kiran to update this problem statement. You input would be quit= e helpful to the next revision of the problem statement document. As you suggested, in the introduction of next revision, we will emphasize t= hat different services require different treatment (bandwidth, latency, rel= iability, etc.) , and simply adding capacity would not meet all those requi= rements. And I think your suggestion about the management consideration is valid, we= will revise the statement to reflect the service type/context based slicin= g, while per customer or per content provider based treatment would be left= for further study. Also thanks a lot for catching the nits, they will be corrected in next rev= ision. Best regards, Jie From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Smith, Kev= in, (R&D) Vodafone Group Sent: Tuesday, January 17, 2017 7:40 PM To: netslices@ietf.org Subject: [Netslices] Problem statement comments Hello Jie and Stewart, Thanks for drafting the problem statement, it's good to see interest in net= work slicing outside of mobile standards. In fact, I think here is an oppor= tunity 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 c= ontention policy. Since many operators operate PLMN, fixed fibre broadband,= WiFi, Narrow Band IoT etc. networks then the benefits of slicing can inclu= de handoff between access networks according to resource contention or othe= r factors (such as mobility). So IMO the problem scope is broader than just= 3GPP mobile access and core. I'm not familiar with network slicing discuss= ions in non-mobile fora, so the problem statement may in fact stimulate tho= se discussions. Another comment is that the various service characteristics are mentioned t= hroughout the draft - and you make the point that different services requir= e different treatment - but I suggest that needs calling out in the introdu= ction as it's so important. I have heard the misconception that 5G can simp= ly be realised by building out capacity, to meet all service requirements i= n a 'one (bigger) size fits all' 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 di= ffer across service types and industries, is crucial upfront. 2.5. Management considerations: without opening a Net Neutrality can-o'-wor= ms, it may be worth noting that the intention of slicing is to tailor treat= ment 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 --_000_76CD132C3ADEF848BD84D028D243C92793572CEFNKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Kevin,

 

Thanks a lot for your comments.

 

I totally agree with you that network = slicing is not only related to mobile, but also the fixed network, as in 5G= end-to-end network slicing is required to meet the diverse service requirements. The discussion about Network sli= cing of non-mobile networks can be found in ITU-T FG IMT-2020 and BBF, and = here we also want to identify the work needed in IETF. This draft was a pre= liminary attempt to describe the problem statement of network slicing in the fixed networks part, and recen= tly Stewart and I are working together with Alex and Kiran to update this p= roblem statement. You input would be quite helpful to the next revision of = the problem statement document.

 

As you suggested, in the introduction = of next revision, we will emphasize that different services require differe= nt treatment (bandwidth, latency, reliability, etc.) , and simply adding capacity would not meet all those requirements.<= o:p>

 

And I think your suggestion about the = management consideration is valid, we will revise the statement to reflect = the service type/context based slicing, while per customer or per content provider based treatment would be left f= or further study.

 

Also thanks a lot for catching the nit= s, they will be corrected in next revision.

 

Best regards,

Jie

 

From: Netslices [mailto:netslices-bounces@ietf.org] On Behalf Of Smith, Kevin, (R&D) Vodafone Group
Sent: Tuesday, January 17, 2017 7:40 PM
To: netslices@ietf.org
Subject: [Netslices] Problem statement comments

 

Hello Jie and Stewart,

 

Thanks for drafting the problem= statement, it’s good to see interest in network slicing outside of m= obile standards. In fact, I think here is an opportunity to think of slicin= g as a network model, rather than purely a mobile model.

 

Network slicing should be consi= dered a network technology, allowing for the allocation and release of netw= ork resources according to the context and contention policy. Since many op= erators operate PLMN, fixed fibre broadband, WiFi, Narrow Band IoT etc. networks then the benefits of slicing can inclu= de handoff between access networks according to resource contention or othe= r factors (such as mobility). So IMO the problem scope is broader than just= 3GPP mobile access and core. I’m not familiar with network slicing discussions in non-mobile fora, so the p= roblem statement may in fact stimulate those discussions.=

 

Another comment is that the var= ious service characteristics are mentioned throughout the draft - and you m= ake the point that different services require different treatment - but I s= uggest that needs calling out in the introduction as it’s so important. I have heard the misconception th= at 5G can simply be realised by building out capacity, to meet all service = requirements in a  ‘one (bigger) size fits all’ approach. = So strengthening the point that requirements for latency, guaranteed delivery and pacing, durability (e.g. waking up an IoT node twi= ce 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’-worms, it may be worth notin= g 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/b= ears further consideration

 

All best,

Kevin

Vodafone R&D

 

--_000_76CD132C3ADEF848BD84D028D243C92793572CEFNKGEML515MBXchi_-- From nobody Fri Jan 20 00:53:45 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 5AE1F129AB2 for ; Fri, 20 Jan 2017 00:53:44 -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_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 Rmj8ptFWAFuM for ; Fri, 20 Jan 2017 00:53:40 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40097.outbound.protection.outlook.com [40.107.4.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B7D6129AB8 for ; Fri, 20 Jan 2017 00:53:39 -0800 (PST) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=a.galis@ucl.ac.uk; Received: from alex-galiss-mbp.connect (90.255.50.254) by HE1PR0101MB2347.eurprd01.prod.exchangelabs.com (10.168.143.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Fri, 20 Jan 2017 08:53:37 +0000 From: Alex Galis Content-Type: multipart/mixed; boundary="Apple-Mail=_B914A616-04B7-42C0-A349-6ACB21E81506" MIME-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Fri, 20 Jan 2017 08:53:35 +0000 To: Network Slices Message-ID: X-Mailer: Apple Mail (2.3259) X-Originating-IP: [90.255.50.254] X-ClientProxiedBy: HE1PR01CA0051.eurprd01.prod.exchangelabs.com (10.165.170.147) To HE1PR0101MB2347.eurprd01.prod.exchangelabs.com (10.168.143.141) X-MS-Office365-Filtering-Correlation-Id: 3ea062af-9f74-41ec-492e-08d44111d2f4 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0101MB2347; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0101MB2347; 3:gig8RTn6I66zy5hJEcMwk06VmCoOeX0cuvI+cI/IJySv2A0fJz9cQAqm9gOGFf13pfgs/gSRtlUBXLk6puK8A0BRd3pG/hdSboWRcLTKAyQMIPhh+75QsT6ok1gb1/6vw6iwtxbHT8VHmWS44rOqn5SQ6CD7BXWEDxZUprmp11VYQZ+pnD7eyJ/4otZujbt0QCUIV4DsgqDAZIx1FAJl2rdQxipW/r5oeGEj69XnvoiqpIIo0VGuR74LyYURbLrT6lZMetjlQAX3T36gYw8jjg== X-Microsoft-Exchange-Diagnostics: 1; HE1PR0101MB2347; 25:/cf2+uJRSMZ77fZ/l1ZTRJAJHDQfW3QIthXe9WKrwMCVMeI8pBmZYas3To8nwcvN8TRf2D7jtTz0u48RUWVMDYcvo1FLG7zPdJSRLcGqoEMZKyfpHzUe+Q1Qmj0Wh7KgMOJjfFSNLDfBnaA+eW9vDxm3y/OWkNc8OTDNNewX9w5+oNCyyLNCNQeJAw12BTrsAyhwXo7XorM+5lVKV4xkjIB4Ej39LUfW0qqEgMkdesSxfHE5dIf5Z9uf54mnVNQV7Hy0CeTC0A32+LIHFTkghiuY3kH+s6SPMHwnEHxn64U2nhmMGXha34BmTVoZeNJ/wdiYCi2oj1SHam8Myhcv3U2iOfsIds0Hb2M3G3tL7GGm3db4LWs/Pbxf1qm3xyx64cGCqGRHV0SzA7Caq7QgA+GMHEGiw6/1GRLblC1ubxfjrQmQCu0PQlSo50c0Jzee/mav2ABUOywxiX6iqYYofcUBH1MQKJL2FEnIVyZ4idYezO9U4bX++Fm/+CjDiTetP9JXI9OVFTMet21/TIcGS76vlyf/XAKiANK2SLiUmd7oGZVbAYrbu/uJEkP0jDy7HG1aTyP6Ny1AreTG3YiY/QqofvGza5E6iJGzUZlWoi20Z0O3J4hUbfOwagkd8KcHR55sF1RwwSE1Pzx5nmHSaq+C9eCxMA4hyw16uk/D9fc0kD5rgTSChL10+XXFxHV4cFYCIBhxbKvJhbsXddvCeg==; 31:b94F7jrCPOfKrwExNWantBd/+cBtePxzw7K0skZuOpyGmBssmeRORVJJuU5eVw99+EZlhx5LaOgbCQw5VJ6Gv0OzRtyAlaAkRYFoHrzZhvIlx4UGw37j7W638PT96XC+iBlAjHmgH0M/he4YIcqrlJknejwh+Y1/q5BWN/9jOIncDva3P60/kLK5YKwBXUI8 X-Microsoft-Exchange-Diagnostics: 1; HE1PR0101MB2347; 20:xCcu4c3QKSZ6TknmAdFHYWRcD3mxF/nSFXy3c9Clg1e6QYPcqIwmB+QBjutYT9JHRWSPBR+eLaLb/VXKff4zucmCFiqVGZPaVSkvOne7RoFLZknhB5TdDf4NQKOj27w6sMIXLj/xaSVDprIryeBSbV9HPcT+NMm0GTSsdj6vXN1Ji25NCB2XiLzeBhcIXUQHpIfSu7/DJeZoYLNkE1aZmS6U5dthRtljfu6qv+itSW3PjSwk5tfU8Wi3KQYK1iBw0vvw7sMfd/s5Ohy4lw81aKh7Rpe3proOxMJDBWh9ZZ0iSuxI8vcC8OwvX7rEkQA4DecRLjC354hfJtdHTI6khZkxuewCwBvRLPOp21QInziSULV7YvLtefOULgXuTVreCXm28P+T2IhNQ0g5t93mEVmFYG43V8Komw1IjaDKBLkd/J8eCFG6kLC30VnrSzb5MtSvd0n8bWsod/FIV9CglttAf18tQePz/g0eLzAFE2xFG5uXsfN92rCLYbANEvSb X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123558021)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:HE1PR0101MB2347; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0101MB2347; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0101MB2347; 4:I5iHwJaBLp1otFYNgIIZV/Ql/fJQ5qA9imf0SI7crn6sDHpS4/LlPgNh7fvaKC4etNgKSvf0M8dpWCk6bA3YcS4uRPh/VdMKHXy7E0Euv2JD+0FcBTjBpJK9w7JCcV/AvWIdkn+dFncQifzOPrT8xKbMm4kjyC3577M5N9nhj59vAwM+uRpgbJ4cXe3ldMyXxbR1xdcAoiXriHqzuLb37Y/RABh1WAr15RgSLEdybiSCAb/OKBls3zf7M+MEF8HYmhW3mXFysZokSWAGl0YiJvBLe12gqrwu+VfR5g2nwaaWVWbnH+omz9BhPLRfl36XU7hzZQcFvdOZD9vYcqD/hPjhf+ZoPtJLxOXhA3KEWeLh6lC0IyCdtX3qxcdeKYwRCwhHn1EPzRAsIZE+MJTrVaJrQR0qFFMnw4s75HuvKc2qym67j+wL48iDHUBSS5cCHSYJRFh/0A6Lj2fbnmDTDI6u5o00S2Y384lC7Px9+lPosA9JqGFgJSYYXwtCVzqZydWNGOrcdayxvkf08NQaJA== X-Forefront-PRVS: 01930B2BA8 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(7916002)(39830400002)(39410400002)(39450400003)(189002)(199003)(504964003)(74482002)(33656002)(3846002)(57306001)(86362001)(92566002)(6512007)(6916009)(6116002)(106356001)(50226002)(2906002)(42882006)(4326007)(42186005)(21480400002)(110136003)(105586002)(101416001)(2476003)(74826001)(305945005)(7736002)(50986999)(5890100001)(512954002)(68736007)(25786008)(229853002)(82746002)(270700001)(568964002)(54906002)(69556001)(5660300001)(84326002)(4610100001)(83716003)(6486002)(189998001)(39060400001)(38730400001)(345774005)(97736004)(6506006)(81166006)(8676002)(6306002)(36756003)(66066001)(81156014)(260700001)(53936002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0101MB2347; H:alex-galiss-mbp.connect; 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; HE1PR0101MB2347; 23:pCaE7m4YlD/lD8QMfa8/ujkH2iLnvIYSAKbQ4Xd?= =?us-ascii?Q?igSV03VXL+9wEy/u/+WmbgdZ7ZORhnNGB9hDsuP7dh8FzN/OfcfQRv95qh/f?= =?us-ascii?Q?JlOQKLSuplfjJ30A7hgXkvL/wHNYfE6e65kd2yW3Tg+fok+1SfzFbrGmIiVH?= =?us-ascii?Q?gGvcW+ztXSe5g9qddJFPHkADU9nzVXjqr92JfTjYu9bmtUEKNDWscAdzWIc6?= =?us-ascii?Q?QaYy3IsMLSa6rO8NaIOlsuwe45k6Jj+8SPy0gWbjRzqfphlRbZ7U0KFBFYat?= =?us-ascii?Q?yiX1uz9lBnfQ8leu2g4hacHjqTfc1Ou+pjSAL+Q2VzvgkobHNSIjBVRFeOKh?= =?us-ascii?Q?YTJawsRuApHxhgD8lXF0G6OsIcAwkfLgMOWelDD0GN9nEVcWQIc8GWGyPWBP?= =?us-ascii?Q?fCklygGwOr43K9UTAs5109sN1Zj5fIyzJdjuVunU82jRO5ikv4gb/rib3fic?= =?us-ascii?Q?ldf3gu1XnjwfR9tJ6f+5w+izEZiIYXamdBKbAk/vo1ToaNNnqXpjH5ygOyGP?= =?us-ascii?Q?Gj9P19f143Q0zSehmJsvSOlISDNFk2J0ZLEI+YCC6hXx2JfFHCtHmMJiAAoB?= =?us-ascii?Q?1imH90LuZDtdhpkhLPcnyd3Simw4JeE0Y69mtp44L8H3YmB7IztnUpmsIG0u?= =?us-ascii?Q?GR7vfWFYPde32IQHQJPnDKjevp0PLMT3exxc2a9R0LF+JHnxssqnbW2OdRKI?= =?us-ascii?Q?WG6fneyrHWidhYtPuXD4Asq6EfrgNgdauAInNaJUm2EBuFSbvM1cDEoIkLJk?= =?us-ascii?Q?e/JBIHyP9kBy16F9uMye2zC+Dtz/qnhi3s4BTDEjj7rKb9PkZx98fz7ZsDsW?= =?us-ascii?Q?U45jpAMXkgrP1qBdipnQPtttA3Rz25fm5PVbHQfcP4hakV+/BBayDPY8/5Dn?= =?us-ascii?Q?ZiV0G0Gymz5pxboucgYABAGfyj1uMkbdWBLYxIBnoeCAksl3PaTP2lanZsrn?= =?us-ascii?Q?5Ri67fUeJD2Bv0+msChXB+aAWlNMVefamTcJUcqreU1O939p2dT6k4p3JIfv?= =?us-ascii?Q?h18bwnWUUcnyI1W7Yeum+iE/DH0ajELQOW2hlBMC3on+WEQzqWVWlex8Az/N?= =?us-ascii?Q?qwI1ioBhPJcBC6KlBsaW8XAD84MTcWyC3quePPyX4Kyl98muqulHQrb8d1qY?= =?us-ascii?Q?+joRNx0DzVCQpCgEOiqNna2yVRrHMBK3/qRi36aKPlgAnzCZRlkCj20Ac7TQ?= =?us-ascii?Q?72TQUloeuw5KTs2MEbbVplj38KwM9WhUjtnYtY4Rv57wlzHs5g4pVBUeDPX5?= =?us-ascii?Q?rt6UcQOFhay8SrzUyo7C5Jl40/XzxlnFa2Ot3ulLVQpsiIGvyKMwJqR1UWE4?= =?us-ascii?Q?6JUQeoLZMek1zBGi/919CkyaB7Gpqg/Tdlh3RhKzpHNHffVKw7QqE0ekyzS8?= =?us-ascii?Q?eNeFCh6wy8emBu3WrLDIzKjzmBW1QqZwm7DAmSEaTZSh0YqPIrJNDsykJvrF?= =?us-ascii?Q?5DNs2y2hu2g2ESUKfFO82mMS87ufSo1iLFUw6vTKvgwgtQjMhIMmNvEeyx42?= =?us-ascii?Q?ly4jHlo1nPRmv15tw47UfrzcCr8gjeyLPbe8=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0101MB2347; 6:QhhRo2w8EvY8/nQwV2kyx6wl2gFB+LNa+ZAM6S9pvVK672PbSZC1TPcgtDme7bDPPI5uTbdmcxrV1m+yaz6ke2QemYaMYk1HcawopLqXu+mdSV5WL/JMsU1XV3duEV7pdSx8V9vFbn54T4JkZGZ5wUdvxLCfUQnpiT8XAz2S0GRZPtRNW61rQAu+niBrHuQCVfRu/T41b8Bb63abU6dTVcf607Kv0G0fwKVGkl2EdoBZG7UN7Eqn7O74Ug8hCsuuLXXaXFAKKFgF9zbgz8hZrV7SG2zCC+xSFFhVUjNCA1TCwd2ohbC0XmlpQJwCEGav; 5:r541kANJxq8m++NoJvU+sKUs1nDPE1t2X6uT/mWq0MCQWPxTTYCUz8RsMKqUlR0fpEkYqWv0c84SSeR76MssU+qH/inD5Ub8dknvSoYy3pU3fcBF5C1bZLy9u4UqAkH/4aX67aJTcBdjFZ1gKChfrQ==; 24:vCkGFAU3VuLXA2cbLVhLO3831207rlsuw/DIVbMnM/fUcxhTr166WOX7Rbe1s0mQXBIC+h4plhA6CitSQaQRNyDPIpzlV/HzXVQ+rNoYg8o= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; HE1PR0101MB2347; 7:wJiIg07tlwHmMI+f1QgcXoz+BeWszpkKTXeJHAlewiSLLVnVryA4gBsUVhKz8U97cp4pskI+1XbaxrQW1SFfzv1W45BDpbNjL2FlPXKeOQSLTt3smBSvjMe87TxUGXM5EGatfiwKSnLtwDu9tdeYoSd+xxB0+Rgee0A9RqltLlolrp+oUl0ENA2hTYsDn9eXsRgyv2mV+pf9BudbLoUuG6TOjBbFmLMvtuIzQXBszKU9zdlXpBFcstOUVLbBI3et4a94jqSbK2H+v54ySTSFQWu3ihJWskFQ173CDzOYMZ4OkWXTfY1aNcjGCSC3bp3N6aMdQ9AEDbxHzZzYJt4HC0IiaXK79zITgTcZeySZ1nco545RrssJ5qUcBWFHGzwpsbkK3YHQ1ynQAm6LTT1dolFPKjaW8HRCN1A92uz2UmqGmd7SKe5apcbbiTAPls4QLhpJJhORKmvH9dJVIZiI7g== X-OriginatorOrg: ucl.ac.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jan 2017 08:53:37.0893 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0101MB2347 Archived-At: Cc: "Dongjie \(Jimmy\)" , Stewart Bryant , Alex Galis , "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: Fri, 20 Jan 2017 08:53:44 -0000 --Apple-Mail=_B914A616-04B7-42C0-A349-6ACB21E81506 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" --Apple-Mail=_B914A616-04B7-42C0-A349-6ACB21E81506 Content-Disposition: attachment; filename="draft-gdmb-netslices-intro-and-ps-00.txt" Content-Type: text/plain; x-unix-mode=0644; name="draft-gdmb-netslices-intro-and-ps-00.txt" Content-Transfer-Encoding: quoted-printable No Working Group A. Galis Internet-Draft University College London Intended status: Informational J. Dong Expires: July 23, 2017 K. Makhijani S. Bryant Huawei Technologies January 19, 2017 Network Slicing - Introductory Document and Revised Problem Statement draft-gdmb-netslices-intro-and-ps-00 Abstract This documents 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 23, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Galis, et al. Expires July 23, 2017 [Page 1] =0C Internet-Draft NS Intro and PS January 2017 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Suggested Problems and Work Areas . . . . . . . . . . . . . . 4 2.1. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Network slicing (NS) refers to the managed partitions of physical and/or virtual network resources, network physical/virtual and service functions that can act as an independent instance of a network and/or as a network cloud. Network resources include connectivity, compute and storage resources. Slices considerably transform the networking perspective by abstracting, isolating, orchestrating, softwarizing and separating logical network components from the underlying physical network resources and as such they enhance Internet architecture. For slice creation, the management plane creates the grouping of physical and virtual network resources, connects with the physical and virtual network and service functions as appropriate and it instantiates all the network and service functions assigned to the slice. On the other hand for slice operations the slice control takes over the control and governing of all the network resources, network functions and service functions assigned to the slice, and (re-) configure them as appropriate and as per elasticity needs in order to provide an end-to-end service. Network operators can exploit NS to significantly reduce operations expenditures, and enable softwarization, programmability and the innovation necessary to enrich the offered services. Network softwarization techniques [IMT2020-2015], [IMT2020-2016] may be used Galis, et al. Expires July 23, 2017 [Page 2] =0C Internet-Draft NS Intro and PS January 2017 to realised and manage [MANO-2014] network slicing. NS provides the means for the network operators to provide network programmable capabilities to OTT providers and other market players without changing their physical infrastructure. NS enables the concurrent deployment of multiple logical, self-contained and independent, shared or partitioned networks on a common infrastructure. Slices support also dynamic multi-services, multi-tenancy and the integration means for vertical market players. The purpose of NS work in IETF is to develop a set of protocols and/ or protocol extensions that enable efficient slice creation, activation / deactivation, composition, elasticity, orchestration, management, isolation, guaranteed SLA and safe operations within a network or network cloud / data centre environment that assumes an IP and/or MPLS-based underlay. While there are, isolated efforts being carried out in several IETF working groups DETNET, [I-D.leeking-actn-problem-statement], [I-D.dong-network-slicing-problem-statement], [I-D.galis-anima-autonomic-slice-networking], [IETF-Slicing1], [IETF-Slicing2], [IETF-Slicing3], [IETF-Slicing4], [IETF-Slicing5] to achieve certain aspects of network slice functions and operations, there is a clear need to look at complete life-cycle management characteristics of network Slicing solutions though the discussions based on the following architectural tenets: o Underlay tenet: support for an IP/MPLS-based underlay data plane the transport network used to carry that underlay. o Governance tenet: a logically centralized authority for network slices in a domain. o Separation tenet: slices are independent and have appropriate degree of isolation (1) from each other. o Capability exposure tenet: each slice allows third parties to access via APIs information regarding services provided by the slice (e.g. connectivity information, QoS, mobility, autonomicity, etc.) within the limits set by the operator. NS approaches that do not adhere to these tenets are explicitly outside of the scope of the proposed work at IETF. In pursuit of the solutions described above, there is a need to document an architecture for network slicing within both wide area network and a data center environments. Galis, et al. Expires July 23, 2017 [Page 3] =0C Internet-Draft NS Intro and PS January 2017 Elicitation of requirements ([RFC2119], [RFC4364]) for a network slice control and management planes and will be needed facilitating the selection, extension, and/or development of the protocol for each of the functional interfaces identified to support the architecture. Additionally, documentation on the common use-cases for slice validation for 5G is needed (e.g. mission-critical ultra-low latency communication services; massive-connectivity machine communication services - smart metering, smart grid and sensor networks; extreme QoS; Independent operations and management; Independent cost and/or energy optimisation; Independent multi-topology routing; multi-tenant operations, etc.). The proposed NS work would be co-ordinated with other IETF WGs (e.g. TEAS WG, DETNET WG, ANIMA WG, NETCONF WG, SUPA WG, NVO3 WG, Routing Area WG (RTGWG), Network Management Research Group (NMRG) and NFV Research Group (NFVRG)) to ensure that the commonalities and differences in solutions are properly considered. Where suitable protocols, models or methods exist, they will be preferred over creating new ones. 1.1. Notes (1) This issue require efficient interaction between an upper layer in the hierarchy and a lower layer for QoS guaranties and most of the operations on slicing. 2. Suggested Problems and Work Areas The goal of this work is to develop one or more protocol specifications (or extensions to existing protocols) to address the following problem areas. These problems were selected according to the analysis of the technical gaps in IETF protocols ecosystem. o Uniform Reference Model for Network Slicing; Describe all elements and instances of a network slice. Describe shared non-sliced network parts. o Slice Templates: Design the slices to different scenarios ([ChinaCom-2009], [GENI-2009], [IMT2020-2016bis], [NGMN-2016], [NGS-3GPP-2016], [ONF-2016]); an appropriate slice template definition that may include capability exposure of managed partitions of physical and/or virtual network resources (i.e. connectivity, compute and storage resources), physical and/or virtual network and service functions that can act as an independent network and/or as a network cloud. Galis, et al. Expires July 23, 2017 [Page 4] =0C Internet-Draft NS Intro and PS January 2017 o Network slice expected capabilities (i.e. prioritization may be needed): * Four-dimensional efficient slice isolation with guarantees for isolation in Data / Control / Management / Service planes. Enablers for safe and efficient multi-tenancy in slices. * Methods to guarantee the end-to-end QoS of a slice. * Recursion - methods for NS segmentation allowing a slicing hierarchy with parent child relationships. * Efficiency in slicing: realize diverse requirements without re-engineering the infrastructure. * Customized security mechanisms per slice. * Enablers to manage the trade-offs between flexibility and efficiency in slicing. * Optimisation - methods for network resources automatic acquisition, global resource view formed; global energy view formed; Network Slice deployed based on global resource and energy efficiency; Mapping algorithms. * Monitoring status and behaviour of NS in a single and/or muti-domain environment. * Capability exposure for slices; APIs for slices. * Programmability and openness of network slices. o Network slice operations (i.e. prioritization may be needed): Galis, et al. Expires July 23, 2017 [Page 5] =0C Internet-Draft NS Intro and PS January 2017 * Slice creation: slices in access, core and transport networks; slices in data centres, slices in edge clouds. * Slice life cycle management including creation, activation/ deactivation, protection (2) , elasticity (3), extensibility (4) , safety (5) , Sizing and scalability of the slicing model per network and per network cloud. * Autonomic slice management and operation (i.e. self-configuration, self-composition, self-monitoring, self-optimisation, self-elasticity are carried as part of the slice protocols). * Slice stitching / composition: Enablers for efficient stitching / composition/ decomposition of slices: - vertically (service + management + control planes) and/or - horizontally (between different domains part of access, core, edge segments) and /or - vertically + horizontally. * E2E wireline network segments and network clouds orchestration of slices ([GUERZONI-2016], [KARL-2016]). * Service Mapping: Dynamic Mapping of Services to slices; YANG models for slices. o Efficient enablers for Integration of above capabilities and operations. 2.1. Notes (2) Protection refers to the related mechanisms so that events within one slice, such as congestion, do not have a negative impact on another slice. (3) Elasticity refers to the mechanisms and triggers for the growth /shrinking of network resources, network and service functions. (4) Extensibility refers to the ability to expand a NS with additional functionality and/or characteristics or through modification of existing functionality/characteristics, while minimizing impact to existing functions. (5) Safety refers to the conditions of being protected against different types and the consequences of failure, error harm or any other event, which could be considered non-desirable. Galis, et al. Expires July 23, 2017 [Page 6] =0C Internet-Draft NS Intro and PS January 2017 [GUERZONI-2016] [KARL-2016] 3. Documents The following are the proposed / expected / resulting documents with priority (I) or (II) (i.e. revised prioritization may be needed): o Agreed work plan o Slice template and reference model to IESG (Informational) o Slice life-cycle management model to IESG (Informational) o Requirements for a network slice control and management planes. o Common use-cases for slice validation for 5G o (I) Slice template and reference model. o (I) Four dimensional efficient slice isolation with guarantees for isolation in Data/ Control/ Management/ Service planes. o (II) Methods to guarantee the end-to-end QoS of a slice. o (I) YANG data model for slicing. o (I) E2E orchestration of slices. o (II) Customized security mechanisms per slice. o (I) Slice stitching / composition: enablers for efficient stitch / composition / decomposition of slices vertically, horizontally and vertically + horizontally 4. Security Considerations Security will be a major part of the design of network slicing. 5. IANA Considerations This document requests no IANA actions. 6. Acknowledgements Thanks to Sheng Jiang (Huawei Technologies) for reviewing this draft. Galis, et al. Expires July 23, 2017 [Page 7] =0C Internet-Draft NS Intro and PS January 2017 7. References 7.1. Normative References [I-D.dong-network-slicing-problem-statement] Dong, J. and S. Bryant, "Problem Statement of Network Slicing in IP/MPLS Networks", draft-dong-network-slicing- problem-statement-00 (work in progress), October 2016. [I-D.galis-anima-autonomic-slice-networking] Galis, A., Makhijani, K., and D. Yu, "Autonomic Slice Networking-Requirements and Reference Model", draft-galis- anima-autonomic-slice-networking-01 (work in progress), October 2016. [I-D.leeking-actn-problem-statement] Lee, Y., King, D., Boucadair, M., Jing, R., and L. Contreras, "Problem Statement for Abstraction and Control of Transport Networks", draft-leeking-actn-problem- statement-03 (work in progress), September 2014. [IETF-Slicing1] "Presentations - Network Slicing meeting at IETF 97 of 15th November 2016", n.d., . [IETF-Slicing2] "Presentations - Network Slicing meeting at IETF 97 of 15th November 2016", n.d., . [IETF-Slicing3] "Presentations - Network Slicing meeting at IETF 97 of 15th November 2016", n.d., . [IETF-Slicing4] "Presentations - Network Slicing meeting at IETF 97 of 15th November 2016", n.d., . Galis, et al. Expires July 23, 2017 [Page 8] =0C Internet-Draft NS Intro and PS January 2017 [IETF-Slicing5] "Presentations - Network Slicing meeting at IETF 97 of 15th November 2016", n.d., . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, . 7.2. Informative References [ChinaCom-2009] "A. Galis et al - Management and Service-aware Networking Architectures (MANA) for Future Internet - Invited paper IEEE 2009 Fourth International Conference on Communications and Networking in China (ChinaCom09) 26-28 August 2009, Xi'an, China", n.d., . [GENI-2009] "GENI Key Concepts - Global Environment for Network Innovations (GENI)", n.d., . [GUERZONI-2016] "Guerzoni, R., Vaishnavi,I.,Perez-Caparros, D., Galis, A., et al Analysis of End-to-End Multi Domain Management and Orchestration Frameworks for Software Defined Infrastructures - an Architectural Survey", June 2016, . [IMT2020-2015] "Report on Gap Analysis", ITU-T FG IMT2020 , December 2015, . [IMT2020-2016] "Draft Technical Report Application of network softwarization to IMT-2020 (O-041)", ITU-T FG IMT2020 , December 2016, . Galis, et al. Expires July 23, 2017 [Page 9] =0C Internet-Draft NS Intro and PS January 2017 [IMT2020-2016bis] "Draft Terms and definitions for IMT-2020 in ITU-T (O-040)", ITU-T FG IMT2020 , December 2016, . [KARL-2016] "Karl, H., Peuster, M, Galis, A., et al DevOps for Network Function Virtualization - An Architectural Approach", July 2016, . [MANO-2014] "Network Functions Virtualisation (NFV); Management and Orchestration v1.1.1.", ETSI European Telecommunications Standards Institute. , December 2014, . [NGMN-2016] "Hedmar,P., Mschner, K., et al - Description of Network Slicing Concept", NGMN Alliance NGS-3GPP-2016 , January 2016, . [NGS-3GPP-2016] "Study on Architecture for Next Generation System - latest version v1.0.2", September 2016, . [ONF-2016] "Paul, M, Schallen, S., Betts, M., Hood, D., Shirazipor, M., Lopes, D., Kaippallimalit, J., - Open Network Fundation document "Applying SDN Architecture to 5G Slicing", Open Network Fundation , April 2016, . Authors' Addresses Alex Galis University College London Email: a.galis@ucl.ac.uk Galis, et al. Expires July 23, 2017 [Page 10] =0C Internet-Draft NS Intro and PS January 2017 Jie Dong Huawei Technologies Email: jie.dong@huawei.com Kiran Makhijani Huawei Technologies Email: kiran.makhijani@huawei.com Stewart Bryant Huawei Technologies Email: stewart.bryant@gmail.com Galis, et al. Expires July 23, 2017 [Page 11] --Apple-Mail=_B914A616-04B7-42C0-A349-6ACB21E81506 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" 20th January 2017 Dear All =20 Re: Network Slicing - Introductory Document and Revised Problem = Statement = https://www.ietf.org/internet-drafts/draft-gdmb-netslices-intro-and-ps-00.= txt =20 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. =20 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. =20 Thank you in advance, Best Regards Alex, Jie, Kiran and Stewart =20 =20 =20 Network Slicing - Introductory Document and Revised Problem Statement =20 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.= --Apple-Mail=_B914A616-04B7-42C0-A349-6ACB21E81506-- From nobody Fri Jan 20 03:48: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 6614F129B3B for ; Fri, 20 Jan 2017 03:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 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_H5=-1, 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=nokia.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 mMxscrgS3dIc for ; Fri, 20 Jan 2017 03:48:31 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0117.outbound.protection.outlook.com [104.47.1.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE93129B39 for ; Fri, 20 Jan 2017 03:48:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NaagWl3JKkbzBd5wRcwpXj+gQGjNMYx+ImuNL7Drc4A=; b=i55zG63cw0MHP0Mv8JHmlLsY821YiGQ959GFFV0RLbqypSpSRM19V/Mqq5ayuLtNK4Kke0uV6hb8zMd7cMpiZk702sSsC2bURyBDHmjKKZL44LEtJR0m99CyJpUuBFGqNvDGLgY+6lk99UyCYPVjvWT71CtwhLrJMPeDCFzmHO0= Received: from DB5PR07MB1399.eurprd07.prod.outlook.com (10.166.4.9) by DB5PR07MB1399.eurprd07.prod.outlook.com (10.166.4.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Fri, 20 Jan 2017 11:48:27 +0000 Received: from DB5PR07MB1399.eurprd07.prod.outlook.com ([10.166.4.9]) by DB5PR07MB1399.eurprd07.prod.outlook.com ([10.166.4.9]) with mapi id 15.01.0860.012; Fri, 20 Jan 2017 11:48:27 +0000 From: "Flinck, Hannu (Nokia - FI/Espoo)" To: "netslices@ietf.org" Thread-Topic: RE: Problem statement comments Thread-Index: AdJzECF4kQxiFEw3QfOLp1tyh1uxSQ== Date: Fri, 20 Jan 2017 11:48:27 +0000 Message-ID: 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=hannu.flinck@nokia-bell-labs.com; x-originating-ip: [131.228.2.1] x-ms-office365-filtering-correlation-id: 357bf599-8cb8-413c-9125-08d4412a3f57 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB5PR07MB1399; x-microsoft-exchange-diagnostics: 1; DB5PR07MB1399; 7:A9Hd1d0kQ8SpZXAuUBKZjZnaVJuai4ne/fDuH4qoeqnSdshKMnHlgwDOzcHgvvmxdVobFv/blfg/X/gaCmr7189FHtKNV+HdKRP+ajPJ7TeeYHy6eVRYS2JEmAmpKWHrCuzBej50sq34c6PhSQi59zkWBqw7yPnek7J3N6w316A/z9CmKAIeDe6POXq718FxPk7A1m8PxSudkbYVGd6Ba7ASFV5AxEV85pmYpHy4Dwe6qgqjWV1FQ+qcFpXo5DtO6r5Ehtp6FUeVXlZWKfjGM0qusMBHgAviNbTFwdA9+mrJgdw0bECohmZ6Qh49bwF/Ga2G9xtvTONrMbdSSXmqNT9T2SVOUceDfYnK48UyjRsBFhSBqpMvokjblhMpbpZxzM60hKN4yAEyI+gGe1mVJqNSM3Snzrtv7ed5g0k1i2jRJolMHJmty4dSg4SI1Vp5sI9kkd8scuo8wL0wH1o6UA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148); SRVR:DB5PR07MB1399; BCL:0; PCL:0; RULEID:; SRVR:DB5PR07MB1399; x-forefront-prvs: 01930B2BA8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39450400003)(39860400002)(39410400002)(39850400002)(199003)(189002)(102836003)(6116002)(53936002)(3846002)(6916009)(5660300001)(7116003)(2501003)(450100001)(74316002)(7696004)(110136003)(305945005)(92566002)(68736007)(97736004)(345774005)(122556002)(2351001)(81166006)(55016002)(38730400001)(66066001)(6506006)(2906002)(5640700003)(25786008)(1730700003)(81156014)(107886002)(105586002)(50986999)(8676002)(3280700002)(54356999)(189998001)(33656002)(101416001)(77096006)(3480700004)(6436002)(7736002)(6306002)(2900100001)(106356001)(9686003)(86362001)(229853002)(8936002)(3660700001)(99286003)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB1399; H:DB5PR07MB1399.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB5PR07MB139934BCA372E686A446D7709B710DB5PR07MB1399eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2017 11:48:27.1596 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB1399 Archived-At: 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: Fri, 20 Jan 2017 11:48:33 -0000 --_000_DB5PR07MB139934BCA372E686A446D7709B710DB5PR07MB1399eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 i= n transport networks. It looks to me that the use cases are very close if n= ot 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 us= e cases are then left? It seems that the slicing is more of a service provi= sioning and management notion that transport. Regarding the related and relevant IETF WGs you may also consider SFC WG. O= ne could claim that the SFC protocol defined there has most of what is need= ed 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 sco= pe of the problem? What makes this as transport issue? Isn't this more of s= ervice problem than transport resource issue. This would need more motivati= on. What is exactly "four-dimensional isolation"? What are the dimensions you a= re referring to? Best regards Hannu Flinck --_000_DB5PR07MB139934BCA372E686A446D7709B710DB5PR07MB1399eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello
 
Thank you for taking the initiative in consolidating the problem state= ment 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 slic= ing 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 f= ocus only those use cases that are of relevance to transport? And how much to use cases are then left? It seem= s 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, co= mpute and storage seems to demonstrate that slicing and service chaining wi= ll go hand-in-hand. Equally, it shows similarly to the use case section tha= t 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’t this more of service problem than tran= sport resource issue. This would need more motivation.
 
What is exactly “four-dimensional isolation”? What are the= dimensions you are referring to?
 
Best regards
Hannu Flinck
 
 --_000_DB5PR07MB139934BCA372E686A446D7709B710DB5PR07MB1399eurp_--