From nobody Fri Jul 3 05:32:17 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78FD91B2EC0 for ; Fri, 3 Jul 2015 05:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gEiGEaV3o6N for ; Fri, 3 Jul 2015 05:32:13 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 56AF91B2EC1 for ; Fri, 3 Jul 2015 05:32:13 -0700 (PDT) Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t63CWCRs006025 for ; Fri, 3 Jul 2015 21:32:12 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id B16205F611 for ; Fri, 3 Jul 2015 21:32:12 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id A3B4B5F592 for ; Fri, 3 Jul 2015 21:32:12 +0900 (JST) Received: from [IPv6:::1] ([129.60.13.28]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t63CW4kK016650 for ; Fri, 3 Jul 2015 21:32:12 +0900 Message-ID: <55968103.8000706@lab.ntt.co.jp> Date: Fri, 03 Jul 2015 21:33:07 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 References: <20150703122853.2904.73515.idtracker@ietfa.amsl.com> In-Reply-To: <20150703122853.2904.73515.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150703122853.2904.73515.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To: sfc@ietf.org X-TM-AS-MML: disable Archived-At: Subject: [sfc] Fwd: New Version Notification for draft-homma-sfc-forwarding-methods-analysis-03.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 12:32:15 -0000 Hi all, I modified editorial issues in this updating. Best regards, Shunsuke -------- Forwarded Message -------- Subject: New Version Notification for draft-homma-sfc-forwarding-methods-analysis-03.txt Date: Fri, 03 Jul 2015 05:28:53 -0700 From: internet-drafts@ietf.org To: Alexey Gorbunov , Kengo , Shunsuke Homma , Alexey Gorbunov , Nicolai Leymann , Diego R. Lopez , David Dolson , Diego Lopez , Kengo Naito , David Dolson , Nicolai Leymann , Shunsuke Homma A new version of I-D, draft-homma-sfc-forwarding-methods-analysis-03.txt has been successfully submitted by Shunsuke Homma and posted to the IETF repository. Name: draft-homma-sfc-forwarding-methods-analysis Revision: 03 Title: Analysis on Forwarding Methods for Service Chaining Document date: 2015-07-03 Group: Individual Submission Pages: 32 URL: https://www.ietf.org/internet-drafts/draft-homma-sfc-forwarding-methods-analysis-03.txt Status: https://datatracker.ietf.org/doc/draft-homma-sfc-forwarding-methods-analysis/ Htmlized: https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-analysis-03 Diff: https://www.ietf.org/rfcdiff?url2=draft-homma-sfc-forwarding-methods-analysis-03 Abstract: This document presents the results of analyzing packet forwarding methods and path selection patterns for achieving Service Chaining. In Service Chaining, data packets need to be forwarded to the appropriate service functions deployed in networks based on service provided for the packets, and distribution of the service-oriented route information and steering data packets following the route information would be required. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Jul 6 01:14:12 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761FA1A904F for ; Mon, 6 Jul 2015 01:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.35 X-Spam-Level: X-Spam-Status: No, score=-1.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cSUC9yk3HSG for ; Mon, 6 Jul 2015 01:14:10 -0700 (PDT) Received: from SNT004-OMC2S38.hotmail.com (snt004-omc2s38.hotmail.com [65.55.90.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D85281A9054 for ; Mon, 6 Jul 2015 01:14:09 -0700 (PDT) Received: from SNT146-DS12 ([65.55.90.71]) by SNT004-OMC2S38.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 6 Jul 2015 01:14:08 -0700 X-TMN: [UA68xyLLO675gRqgoFrY2NHgH9mBrE1t] X-Originating-Email: [fuqiao1@outlook.com] Message-ID: From: Fu Qiao To: Date: Mon, 6 Jul 2015 16:14:07 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdC3kmt5jrs993AFR4KTq8lI4LSNxQAMPU0w Content-Language: zh-cn X-OriginalArrivalTime: 06 Jul 2015 08:14:08.0197 (UTC) FILETIME=[BB42D750:01D0B7C3] Archived-At: Cc: "'Joel M. Halpern'" , 'Hui Deng' Subject: [sfc] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-fu-sfc-topology-00=2Etxt?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 08:14:11 -0000 Hi, all. I have just submitted a draft about the deployment topology of = sfc. Comparing with the architecture work, this work includes more details = about how to deploy SFC in the network. A usecase of VCPE deployment, = which is an example of usecase of SFC in the access network is also = proposed in order to explain the topology and related technologies in = depth. Your comments are more than welcome. Thank you! -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- =E5=8F=91=E4=BB=B6=E4=BA=BA: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]=20 =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2015=E5=B9=B47=E6=9C=886=E6=97=A5 = 10:21 =E6=94=B6=E4=BB=B6=E4=BA=BA: Qiao Fu; Joel M. Halpern; Qiao Fu; Joel. = Halpern; Hui Deng; Hui Deng =E4=B8=BB=E9=A2=98: New Version Notification for = draft-fu-sfc-topology-00.txt A new version of I-D, draft-fu-sfc-topology-00.txt has been successfully submitted by Qiao Fu and posted to the IETF repository. Name: draft-fu-sfc-topology Revision: 00 Title: The topology of service function chaining Document date: 2015-07-05 Group: Individual Submission Pages: 10 URL: = https://www.ietf.org/internet-drafts/draft-fu-sfc-topology-00.txt Status: https://datatracker.ietf.org/doc/draft-fu-sfc-topology/ Htmlized: https://tools.ietf.org/html/draft-fu-sfc-topology-00 Abstract: This document proposes a deployment topology of Service Function Chaining(SFC). The topology is in accordance with the SFC architecture in [I-D.ietf-sfc-architecture]. Currently, such architecture only includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, without any instruction for the field deployment. It is still difficult to map from the architecture to a real deployment of SFC. In this document, we propose this topology which will give instructions for the field deployments. We further propose a VCPE usecase of SFC in the transport network, which explains the details of the deployment topology. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Jul 6 02:24:42 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DFDC1A9233 for ; Mon, 6 Jul 2015 02:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svGA4eGCaOEU for ; Mon, 6 Jul 2015 02:24:38 -0700 (PDT) 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 5AC2D1A9245 for ; Mon, 6 Jul 2015 02:24:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUT31088; Mon, 06 Jul 2015 09:24:37 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jul 2015 10:24:36 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.233]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 6 Jul 2015 17:24:28 +0800 From: "Songhaibin (A)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: SFC WG agenda slots - Prague Thread-Index: AQHQsOmuFIw1+/NXJ0OcpkbP+ocVYp3OOASg Date: Mon, 6 Jul 2015 09:24:27 +0000 Message-ID: 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.138.41.34] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F652CC327nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [sfc] SFC WG agenda slots - Prague X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 09:24:41 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F652CC327nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, I would like to request a very short slot presentation for draft-song-sfc-l= egacy-sf-mapping-05. This document serves the purpose how legacy service fu= nctions can participate in the service function chaining. There are some up= dates. We make it informational and remove RFC 2119 language, and add a lit= tle more deployment considerations, and also clarify on the meta data probl= em. Best Regards! -Haibin From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Saturday, June 27, 2015 10:58 PM To: sfc@ietf.org Subject: [sfc] SFC WG agenda slots - Prague Greetings WG: Our meeting in Prague is fast approaching. As always the goal of the meetin= g will be to make the best use of our limited face-to-face time. With that = in mind we welcome requests for agenda time. As we build the meeting agenda our goal will be to select presentations tha= t best further the work of the WG, and that generally means focusing on key= charter deliverables and topics with important open issues to resolve. Whe= n making a request please consider what you think the WG should do with its= content - for example: * Does the document have useful content that should be moved into anoth= er WG document or progress on its own merit * Does the content have a good basis for one of the WG documents per th= e charter * Should the document content be merged with one or more other document= s, so that a combined document could become a WG document Jim & Thomas --_000_E33E01DFD5BEA24B9F3F18671078951F652CC327nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 = ;

I would like to request a ver= y short slot presentation for draft-song-sfc-legacy-sf-mapping-05. This doc= ument serves the purpose how legacy service functions can participate in the service function chaining. There are some updates. We m= ake it informational and remove RFC 2119 language, and add a little more de= ployment considerations, and also clarify on the meta data problem.

 = ;

Best Regards!

-Haibin

 = ;

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, June 27, 2015 10:58 PM
To: sfc@ietf.org
Subject: [sfc] SFC WG agenda slots - Prague

 

Greetings WG= :

 <= /o:p>

Our meeting = in Prague is fast approaching. As always the goal of the meeting will be to= make the best use of our limited face-to-face time. With that in mind we welcome requests for agenda time. <= /p>

 <= /o:p>

As we build = the meeting agenda our goal will be to select presentations that best furth= er the work of the WG, and that generally means focusing on key charter deliverables and topics with important open issues to resolve.= When making a request please consider what you think the WG should do with= its content – for example:

  • Does the document have useful content that shou= ld be moved into another WG document or progress on its own merit
  • Does the content have a good basis for one of t= he WG documents per the charter
  • Should the document content be merged with one = or more other documents, so that a combined document could become a WG docu= ment

Jim & Th= omas

--_000_E33E01DFD5BEA24B9F3F18671078951F652CC327nkgeml501mbschi_-- From nobody Mon Jul 6 06:02:52 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C3C1A1A70 for ; Mon, 6 Jul 2015 06:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsVOw0OAquf8 for ; Mon, 6 Jul 2015 06:02:47 -0700 (PDT) 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 352291A1A73 for ; Mon, 6 Jul 2015 05:57:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BYJ92433; Mon, 06 Jul 2015 12:57:20 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 6 Jul 2015 13:57:18 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.156]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Mon, 6 Jul 2015 20:57:13 +0800 From: "Zhulei (MBB Research)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: SFC WG agenda slots - Prague Thread-Index: AQHQsOmuFIw1+/NXJ0OcpkbP+ocVYp3OcbYA Date: Mon, 6 Jul 2015 12:57:13 +0000 Message-ID: <470F27D1263A1B4EB73491ED995DE62525A63368@NKGEML512-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.111.65.38] Content-Type: multipart/alternative; boundary="_000_470F27D1263A1B4EB73491ED995DE62525A63368NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [sfc] SFC WG agenda slots - Prague X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 13:02:50 -0000 --_000_470F27D1263A1B4EB73491ED995DE62525A63368NKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgSmltIGFuZCBhbGwsDQoNClRvIHJlcGx5IHlvdXIgY2FsbCwgSSB3b3VsZCBuZWVkIHRvIGFz ayBhIHNsb3Qgd2l0aCB0aW1lIHRvIHByZXNlbnQgT0FNIGlzc3VlcyBmb3IgU0ZDIGZyb20gYXJj aGl0ZWN0dXJlIHBlcnNwZWN0aXZlLg0KDQpJbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtemh1LXNmYy1vYW0tYXJjaGl0ZWN0dWFsLWlzc3Vlcy0wMCwgaXQgd2FzIG5vdCB0byBh ZGRyZXNzIGV2ZXJ5IHRvcGljcyBpbiBkZXRhaWwgYnV0IHdpbGwgbWVudGlvbiBhIGxvdCByZWxl dmFuY2UgZm9yIE9BTSBhbmQgU0ZDIGNvbXBvbmVudHMsIGFuZCwgZm9yIFNGQyBhbmQgU0YgbWFu YWdlbWVudC4gVGhlc2UgYXNzdW1wdGlvbnMgYW5kIGNvbnNpZGVyYXRpb25zIGFyZSBhbHNvIGFw cGxpY2FibGUgZm9yIHZpcnR1YWxpemVkIFNGcywgdGhlbiB3aWxsIG1lbnRpb24gaXQgYXMgd2hp bGUuDQoNClRoZXJlIHdhcyBhbm90aGVyIHByZXNlbnRhdGlvbiBhIGNvdXBsZSBvZiBtZWV0aW5n IGFnbyBmb3IgT0FNLCBJIHdvdWxkIGhvcGUgdGhhdCB0aGlzIGRpc2N1c3Npb24gaXMgbW92aW5n IG9uIHRpbWVseSBpbiB0aGlzIG1lZXRpbmcuIFRoYW5rIHlvdS4NCg0KQmVzdCByZWdhcmRzLA0K Wmh1IExlaQ0KDQq3orz+yMs6IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSC0+rHt IEppbSBHdWljaGFyZCAoamd1aWNoYXIpDQq3osvNyrG85DogMjAxNcTqNtTCMjfI1SAyMjo1OA0K ytW8/sjLOiBzZmNAaWV0Zi5vcmcNCtb3zOI6IFtzZmNdIFNGQyBXRyBhZ2VuZGEgc2xvdHMgLSBQ cmFndWUNCg0KR3JlZXRpbmdzIFdHOg0KDQpPdXIgbWVldGluZyBpbiBQcmFndWUgaXMgZmFzdCBh cHByb2FjaGluZy4gQXMgYWx3YXlzIHRoZSBnb2FsIG9mIHRoZSBtZWV0aW5nIHdpbGwgYmUgdG8g bWFrZSB0aGUgYmVzdCB1c2Ugb2Ygb3VyIGxpbWl0ZWQgZmFjZS10by1mYWNlIHRpbWUuIFdpdGgg dGhhdCBpbiBtaW5kIHdlIHdlbGNvbWUgcmVxdWVzdHMgZm9yIGFnZW5kYSB0aW1lLg0KDQpBcyB3 ZSBidWlsZCB0aGUgbWVldGluZyBhZ2VuZGEgb3VyIGdvYWwgd2lsbCBiZSB0byBzZWxlY3QgcHJl c2VudGF0aW9ucyB0aGF0IGJlc3QgZnVydGhlciB0aGUgd29yayBvZiB0aGUgV0csIGFuZCB0aGF0 IGdlbmVyYWxseSBtZWFucyBmb2N1c2luZyBvbiBrZXkgY2hhcnRlciBkZWxpdmVyYWJsZXMgYW5k IHRvcGljcyB3aXRoIGltcG9ydGFudCBvcGVuIGlzc3VlcyB0byByZXNvbHZlLiBXaGVuIG1ha2lu ZyBhIHJlcXVlc3QgcGxlYXNlIGNvbnNpZGVyIHdoYXQgeW91IHRoaW5rIHRoZSBXRyBzaG91bGQg ZG8gd2l0aCBpdHMgY29udGVudCCoQyBmb3IgZXhhbXBsZToNCg0KICAqICAgRG9lcyB0aGUgZG9j dW1lbnQgaGF2ZSB1c2VmdWwgY29udGVudCB0aGF0IHNob3VsZCBiZSBtb3ZlZCBpbnRvIGFub3Ro ZXIgV0cgZG9jdW1lbnQgb3IgcHJvZ3Jlc3Mgb24gaXRzIG93biBtZXJpdA0KICAqICAgRG9lcyB0 aGUgY29udGVudCBoYXZlIGEgZ29vZCBiYXNpcyBmb3Igb25lIG9mIHRoZSBXRyBkb2N1bWVudHMg cGVyIHRoZSBjaGFydGVyDQogICogICBTaG91bGQgdGhlIGRvY3VtZW50IGNvbnRlbnQgYmUgbWVy Z2VkIHdpdGggb25lIG9yIG1vcmUgb3RoZXIgZG9jdW1lbnRzLCBzbyB0aGF0IGEgY29tYmluZWQg ZG9jdW1lbnQgY291bGQgYmVjb21lIGEgV0cgZG9jdW1lbnQNCkppbSAmIFRob21hcw0K --_000_470F27D1263A1B4EB73491ED995DE62525A63368NKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Jim and= all,

 = ;

To reply y= our call, I would need to ask a slot with time to present OAM issues for SF= C from architecture perspective.

 = ;

In https://tools.ietf.org/html/draft-zhu-sfc-oam-architectual-issues-00<= /a>, it was not to address every topics in detail but will mention a lot re= levance for OAM and SFC components, and, for SFC and SF management. These assumptions and considerations are a= lso applicable for virtualized SFs, then will mention it as while.

 = ;

There was = another presentation a couple of meeting ago for OAM, I would hope that thi= s discussion is moving on timely in this meeting. Thank you.

 = ;

Best regar= ds,

Zhu Lei

 = ;

=B7=A2=BC=FE=C8=CB: sfc [ma= ilto:sfc-bounces@ietf.org] =B4=FA= =B1=ED Jim Guichard (jguichar)
=B7=A2= =CB=CD=CA=B1=BC=E4: 2015=C4=EA6=D4=C227=C8=D5 22:58
=CA=D5=BC=FE=C8=CB: sfc@ietf.org
=D6=F7=CC=E2: [sfc] SFC WG agenda slots - Prague

 

Greetings WG= :

 <= /o:p>

Our meeting = in Prague is fast approaching. As always the goal of the meeting will be to= make the best use of our limited face-to-face time. With that in mind we welcome requests for agenda time. <= /p>

 <= /o:p>

As we build = the meeting agenda our goal will be to select presentations that best furth= er the work of the WG, and that generally means focusing on key charter deliverables and topics with important open issues to resolve.= When making a request please consider what you think the WG should do with= its content =A8C for example:

  • Does the document have useful content that shou= ld be moved into another WG document or progress on its own merit
  • Does the content have a good basis for one of t= he WG documents per the charter
  • Should the document content be merged with one = or more other documents, so that a combined document could become a WG docu= ment

Jim & Th= omas

--_000_470F27D1263A1B4EB73491ED995DE62525A63368NKGEML512MBSchi_-- From nobody Mon Jul 6 11:15:53 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DBC1A6F13 for ; Mon, 6 Jul 2015 11:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdG8UxiuPC2R for ; Mon, 6 Jul 2015 11:15:47 -0700 (PDT) Received: from smfilter3.kt.com (smfilter3.kt.com [14.63.245.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2291A1B6E for ; Mon, 6 Jul 2015 11:15:43 -0700 (PDT) Received: from external ([147.6.42.86]) by smfilter3.kt.com (1.0) id t66IFE5007D2; Tue, 07 Jul 2015 03:15:14 +0900 Received: by KTEX1.localdomain (Postfix, from userid 0) id 3mQFS2076QzPyP5; Tue, 7 Jul 2015 03:15:14 +0900 (KST) Received: from MAIL-FRT-02.corp.ktad.kt.com (unknown [147.6.42.85]) by KTEX1.localdomain (Postfix) with ESMTP id 3mQFS174pRzPyLN for ; Tue, 7 Jul 2015 03:15:13 +0900 (KST) Received: from MAIL-MBX-02.corp.ktad.kt.com ([10.215.33.72]) by MAIL-FRT-02.corp.ktad.kt.com ([10.215.33.52]) with mapi id 14.02.0318.004; Tue, 7 Jul 2015 03:15:13 +0900 From: =?utf-8?B?6rCV7YOc7Zi4KFNETiBQcm9qZWN0KQ==?= To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-kang-sfc-dynamic-path-selection-00.txt Thread-Index: AQHQuBXg1GlJtVQ3d0SJvGe/h/u2TZ3OvY8g Date: Mon, 6 Jul 2015 18:15:12 +0000 Message-ID: References: <20150706180035.13017.75321.idtracker@ietfa.amsl.com> In-Reply-To: <20150706180035.13017.75321.idtracker@ietfa.amsl.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-dispnameaddress: th.kang@kt.com x-originating-ip: [10.214.72.214] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [sfc] FW: New Version Notification for draft-kang-sfc-dynamic-path-selection-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:15:52 -0000 SGksDQpXZSB1cGxvYWRlZCBhIGRyYWZ0IGRlc2NyaWJpbmcgZHluYW1pYyBwYXRoIHNlbGVjdGlv biBiZXR3ZWVuIFNGRiAmIFNGLCBhbmQgZmFpbG92ZXIuDQpJdCB3b3VsZCBoZWxwIG92ZXJhbGwg c3RhYmlsaXR5IG9mIHNlcnZpY2UgY2hhaW4uDQoNCldlIGFwcHJlY2lhdGUgeW91ciBjb21tZW50 cyBhbmQvb3Igc3VnZ2VzdGlvbnMuDQpUaGFua3MuDQoNCkJlc3QgcmVnYXJkcywNClRhZWhvDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQpTZW50OiBUdWVzZGF5LCBKdWx5 IDA3LCAyMDE1IDM6MDEgQU0NClRvOiDrsLHsnYDqsr0oU0RORlYgVEYpOyDrsLHsnYDqsr0oU0RO RlYgVEYpOyDqsJXtg5ztmLgoU0ROIFByb2plY3QpOyDquYDshLHsiJgoU0ROIFByb2plY3QpOyDq sJXtg5ztmLgoU0ROIFByb2plY3QpOyDquYDshLHsiJgoU0ROIFByb2plY3QpOyDquYDrgqjqs6Qo TkZWIFByb2plY3QpOyDquYDrgqjqs6QoTkZWIFByb2plY3QpOyDtlZzsmIHtg5woU0ROIFByb2pl Y3QpOyDtlZzsmIHtg5woU0ROIFByb2plY3QpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LWthbmctc2ZjLWR5bmFtaWMtcGF0aC1zZWxlY3Rpb24tMDAudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWthbmctc2ZjLWR5bmFtaWMtcGF0aC1zZWxl Y3Rpb24tMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRhZWhvIEth bmcgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAg ZHJhZnQta2FuZy1zZmMtZHluYW1pYy1wYXRoLXNlbGVjdGlvbg0KUmV2aXNpb246ICAgICAgIDAw DQpUaXRsZTogICAgICAgICAgRHluYW1pYyBTZXJ2aWNlIFBhdGggU2VsZWN0aW9uIG92ZXIgTXVs dGlwbGUgTGlua3MgYmV0d2VlbiBTRkYgYW5kIFNGIGZvciBFbmhhbmNpbmcgU2VydmljZSBTdGFi aWxpdHkNCkRvY3VtZW50IGRhdGU6ICAyMDE1LTA3LTA2DQpHcm91cDogICAgICAgICAgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAgOQ0KVVJMOiAgICAgICAgICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rYW5nLXNmYy1keW5hbWljLXBh dGgtc2VsZWN0aW9uLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWthbmctc2ZjLWR5bmFtaWMtcGF0aC1zZWxlY3Rpb24vDQpIdG1s aXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWthbmctc2ZjLWR5 bmFtaWMtcGF0aC1zZWxlY3Rpb24tMDANCg0KDQpBYnN0cmFjdDoNCiAgIEluIHRoaXMgZG9jdW1l bnQsIHdlIHVzZSBTRiBjbGFzc2lmaWNhdGlvbiBvZiAxKWluZGlzcGVuc2libGUgU0YgZm9yDQog ICBwYWNrZXQgZGVsaXZlcnksIGFsbGVnZWRseSBtYW5kYXRvcnkgU0ZzLCBzdWNoIGFzIE5BVCBh bmQgMilvcHRpb25hbA0KICAgU0ZzIHRoYXQgYSBwYWNrZXQgY2FuIGJlIGRlbGl2ZXJlZCB3aXRo b3V0IHRoZW0sIHN1Y2ggYXMgRmlyZXdhbGwgYW5kDQogICBJRFMuDQoNCiAgIFRoZSBub2RlcyBv ZiBTRkMtZW5hYmxlZCBkb21haW4gY2FuIGJlIHZhcmlvdXMuICBEaWZmZXJlbnQgdmVuZG9ycw0K ICAgbWFrZSBkaWZmZXJlbnQgdHlwZXMgb2YgZXF1aXBtZW50cywgYW5kIHRoaXMgY2F1c2VzIHBl cmZvcm1hbmNlDQogICBpc3N1ZXMuICBDb25zaWRlcmluZyB0aGlzIGRpdmVyc2l0eSwgdGhlIGtp bmQgb2YgU0ZzIGNhbiBiZSBpbiBteXJpYWQNCiAgIGZvcm0uICBUaHVzLCB3ZSBzaG91bGQgZGlz dGluZ3Vpc2ggc29tZSBtYW5kYXRvcnkgU0ZzIGZyb20gbm90DQogICBtYW5kYXRvcnkgU0ZzIGFu ZCB0cmVhdCBkaXN0aW5jdGl2ZWx5LiAgTWFuZGF0b3J5IFNGcyBzaG91bGQgYmUNCiAgIG1hdGNo ZWQgd2l0aCBoaWdoZXItcGVyZm9ybWFuY2UgU0ZGIHRvIGFjaGlldmUgaGlnaCBhdmFpbGFiaWxp dHkgYXMNCiAgIHdlbGwgYXMgbG93ZXIgdGhlIHByb2JhYmlsaXR5IG9mIGZhaWx1cmUuICBBYm92 ZSBhbGwsIHdoZXRoZXIgZWFjaCBTRg0KICAgaXMgbWFuZGF0b3J5IG9yIG9wdGlvbmFsIHNob3Vs ZCBiZSByZWdpc3RlcmVkIGluIGFkdmFuY2UuICBNYW5kYXRvcnkNCiAgIFNGcyBhcmUgdG8gYWxs b2NhdGVkIHRvIHJlbGF0aXZlbHkgaGlnaGVyLXBlcmZvcm1hbmNlLCBsYXJnZXINCiAgIGNhcGFj aXR5LCBtb3JlIHN0YWJsZSBTRkZzLiAgU0ZDIGNvbnN0cnVjdGVkIHVzaW5nIHRoaXMgd2F5IG9m DQogICBhbGxvY2F0aW9uIGJlY29tZXMgdGhlIHBhdGggZm9yIHBhY2tldHMgYW5kIHBhY2tldHMg YXJlIHRyYW5zZmVycmVkDQogICB0byBjbGFzc2lmaWVyIHRocm91Z2ggQzEgaW50ZXJmYWNlLCBh bmQgdG8gU0ZGIHRocm91Z2ggQzIgaW50ZXJmYWNlLA0KICAgcmVzcGVjdGl2ZWx5Lg0KDQoNCg0K DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg0KDQrsnbQg66mU7J287J2AIOyngOygleuQnCDsiJjst6jsnbjrp4zsnYQg7JyE7ZW0IOye keyEseuQmOyXiOycvOupsCwg7KSR7JqU7ZWcIOygleuztOuCmCDsoIDsnpHqtozsnYQg7Y+s7ZWo 7ZWY6rOgIOyeiOydhCDsiJgg7J6I7Iq164uI64ukLiDslrTrlqDtlZwg6raM7ZWcIOyXhuydtCwg 67O4IOusuOyEnOyXkCDtj6ztlajrkJwg7KCV67O07J2YIOyghOu2gCDrmJDripQg7J2867aA66W8 IOustOuLqOycvOuhnCDsoJwz7J6Q7JeQ6rKMIOqzteqwnCwg67Cw7Y+sLCDrs7Xsgqwg65iQ64qU IOyCrOyaqe2VmOuKlCDqsoPsnYQg7JeE6rKp7Z6IIOq4iOyngO2VqeuLiOuLpC4g66eM7JW9LCDr s7gg66mU7J287J20IOyemOuquyDsoITshqHrkJwg6rK97JqwLCDrsJzsi6Dsnbgg65iQ64qUIOuL ueyCrOyXkCDslYzroKTso7zsi5zqs6AsIOuzuCDrqZTsnbzsnYQg7KaJ7IucIOyCreygnO2VmOyX rCDso7zsi5zquLAg67CU656N64uI64ukLg0KVGhpcyBFLW1haWwgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIGluZm9ybWF0aW9uIGFuZC9vciBjb3B5cmlnaHQgbWF0ZXJpYWwuIFRoaXMgZW1haWwg aXMgaW50ZW5kZWQgZm9yIHRoZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZSBvbmx5LiBJZiB5b3UgcmVj ZWl2ZSB0aGlzIGVtYWlsIGJ5IG1pc3Rha2UsIHBsZWFzZSBlaXRoZXIgZGVsZXRlIGl0IHdpdGhv dXQgcmVwcm9kdWNpbmcsIGRpc3RyaWJ1dGluZyBvciByZXRhaW5pbmcgY29waWVzIHRoZXJlb2Yg b3Igbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkuDQo= From nobody Mon Jul 6 11:42:17 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFAF1B3001 for ; Mon, 6 Jul 2015 11:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AuqO-D1T1H9W for ; Mon, 6 Jul 2015 11:42:14 -0700 (PDT) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4251B2FEB for ; Mon, 6 Jul 2015 11:42:14 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0224.002; Mon, 6 Jul 2015 11:42:13 -0700 From: Ron Parker To: =?utf-8?B?6rCV7YOc7Zi4KFNETiBQcm9qZWN0KQ==?= , "sfc@ietf.org" Thread-Topic: New Version Notification for draft-kang-sfc-dynamic-path-selection-00.txt Thread-Index: AQHQuBXg1GlJtVQ3d0SJvGe/h/u2TZ3OvY8ggAAFQQA= Date: Mon, 6 Jul 2015 18:42:13 +0000 Message-ID: References: <20150706180035.13017.75321.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.205.79.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] New Version Notification for draft-kang-sfc-dynamic-path-selection-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:42:16 -0000 VGFlaG8sDQoNClRoYW5rIHlvdSBmb3IgcHV0dGluZyB0aGlzIGRyYWZ0IHRvZ2V0aGVyLiAgICBJ IGFtIGZ1bGx5IHN1cHBvcnRpdmUgb2YgZHluYW1pYyBwYXRoIHNlbGVjdGlvbiBmb3IgaW5jcmVh c2VkIHJlc2lsaWVuY3kuICAgSSB0aGluayB0aGUgY29uY2VwdCBjYW4gYmUgZnVydGhlciBleHRl bmRlZCB0byBzaW11bHRhbmVvdXNseSBzdXBwb3J0IFNGQy1sZXZlbCBsb2FkIGJhbGFuY2luZyBh bmQgcmVzaWxpZW5jeS4gICBGb3IgZXhhbXBsZSwgaW4geW91ciBmaWd1cmUgMSwgaWYgeW91IGV4 dGVuZGVkIHlvdXIgaW5zdGFuY2Ugb2YgU0YyIHRvIGluY2x1ZGUgbXVsdGlwbGUgZW50aXRpZXMg Y2FwYWJsZSBvZiBwcm92aWRpbmcgZXF1aXZhbGVudCBmdW5jdGlvbmFsaXR5IChlZyBTRjItYSwg U0YyLWIsIFNGMi1jLCAuLi4pIHlvdSBjb3VsZCB0aGVuIGhhdmUgZGlmZmVyZW50IFNGMiBpbnN0 YW5jZXMgaGF2aW5nIGRpZmZlcmVudCBjb25uZWN0aXZpdHkuICAgRm9yIGV4YW1wbGUsIHBlcmhh cHMgU0YyLWEgY29ubmV0cyB0byBhbGwgMyBTRkYncyBhcyB5b3VyIGRpYWdyYW0gaW5kaWNhdGVz IGZvciB0aGUgY3VycmVudCAiU0YyIi4gICBGdXJ0aGVyLCBTRjItYiBjb3VsZCBjb25uZWN0IG9u bHkgdG8gU0ZGMiBhbmQgU0ZGNCBhbmQgU0YyLWMgY291bGQgY29ubmVjdCBvbmx5IHRvIFNGRjEu ICAgIEFkZGl0aW9uYWxseSwgeW91IGNvdWxkIGNoYXJhY3Rlcml6ZSB0aGUgY2FwYWNpdHkgYW5k L29yIGN1cnJlbnQgbG9hZCBvZiBlYWNoIGluc3RhbmNlIHNlcGFyYXRlbHkuICAgIE5vdywgdGhl IHNhbWUgZHluYW1pYyBwYXRoIHNlbGVjdGlvbiBsb2dpYyB5b3UgZW52aXNpb24gY291bGQgYWNj b3VudCBmb3IgcG9saWN5LWJhc2VkIGxvYWQgYmFsYW5jaW5nIGFuZCByZXNpbGllbmN5Lg0KDQpU aGlzIGFsc28gcHJvdmlkZXMgYSBnb29kIGV4YW1wbGUgdG8gcmVtaW5kIG9mIHRoZSBwcmV2aW91 cyB0ZXJtaW5vbG9neSBkaXNjdXNzaW9ucyB0aGF0IHdlIGhhZCBvbiB0aGlzIHRocmVhZCByZWdh cmRpbmcgU0ZDLCBTRlAsIGFuZCBSU1AuICAgV2hlbiB3ZSBsYXN0IGxlZnQgaXQsIGFuZCBwZXIg bXkgaW50ZXJwcmV0YXRpb24sIHRoZSBTRkMgd2FzIHRoZSBhYnN0cmFjdCBzZXF1ZW5jZSBvZiBs b2dpY2FsIHNlcnZpY2UgZnVuY3Rpb25zIGV4YWN0bHkgYXMgeW91IGRlc2NyaWJlIGluIHlvdXIg ZHJhZnQgKGkuZS4sIFNGMS0tPlNGMi0tPlNGMykuICAgIFRoZSBTRlAsIGhvd2V2ZXIsIHdhcyBu b3QgbmVjZXNzYXJpbHkgYSBmdWxseSBjb25zdHJhaW5lZCBzZXF1ZW5jZSBvZiBhY3R1YWwgaG9w cyBhcyB5b3UgZGVzY3JpYmUgaW4geW91ciBkcmFmdCAoaS5lLiwgU0ZQMTogU0ZGMSAtPiBTRjEg LT4gU0ZGMSAtPiBTRkYyIC0+IFNGMiAtPiBTRkYyIC0+IFNGMyAtPiBTRkYyIC0+IFNGRjQpLiAg IFRoYXQgd2FzIGRlc2NyaWJlZCBhcyB0aGUgUlNQIChSZW5kZXJlZCBTZXJ2aWNlIFBhdGgpLiAg IFRoZSAiU0ZQIiB0ZXJtIHdhcyBkZXNjcmliZWQgYXMgYW4gaW50ZXJtZWRpYXRlIGxldmVsIGJl dHdlZW4gU0ZDIGFuZCBSU1AsIHdoaWNoIGFkbWl0dGVkbHkgc2VlbXMgaGFyZCB0byB1bmRlcnN0 YW5kIGF0IGZpcnN0IGdsYW5jZS4gICAgV2hhdCB3YXMgaW50ZW5kZWQgaGVyZSB3YXMgdGhlIGFi aWxpdHkgdG8gZGVzY3JpYmUgY2VydGFpbiBjb25zdHJhaW5pbmcgcG9saWN5IGJ1dCB0byBzdGls bCBhbGxvdyBzb21lIGR5bmFtaWMgc2VsZWN0aW9uLiAgIEZvciBleGFtcGxlLCBTRkMxLCBoYXZp bmcgU0ZQMSBhbmQgU0ZQMiwgbWlnaHQgZGVzY3JpYmUgU0ZQMSBhcyB7IFNGRjEvU0YxLCB7IFNG RjIvU0YyIG9yIFNGRjQvU0YyIH0sIHtTRkYyL1NGMyBvciBTRkY0L1NGM30gfSAoaS5lLiwgcG9s aWN5IHN0YXRlcyB0aGF0IHRoZSBTRkYxL1NGMiBwYXRoIGlzIG5vdCBhbGxvd2VkIGZvciB0aGlz IHBhcnRpY3VsYXIgU0ZQLCBhcyByZWxhdGVkIHRvIHlvdXIgZmlndXJlIDEpLg0KDQpUaGFua3Mu DQoNCiAgIFJvbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mID8/PyhTRE4gUHJvamVjdCkN ClNlbnQ6IE1vbmRheSwgSnVseSA2LCAyMDE1IDI6MTUgUE0NClRvOiBzZmNAaWV0Zi5vcmcNClN1 YmplY3Q6IFtHUkFZTUFJTF0gW3NmY10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQta2FuZy1zZmMtZHluYW1pYy1wYXRoLXNlbGVjdGlvbi0wMC50eHQNCg0KSGksDQpXZSB1 cGxvYWRlZCBhIGRyYWZ0IGRlc2NyaWJpbmcgZHluYW1pYyBwYXRoIHNlbGVjdGlvbiBiZXR3ZWVu IFNGRiAmIFNGLCBhbmQgZmFpbG92ZXIuDQpJdCB3b3VsZCBoZWxwIG92ZXJhbGwgc3RhYmlsaXR5 IG9mIHNlcnZpY2UgY2hhaW4uDQoNCldlIGFwcHJlY2lhdGUgeW91ciBjb21tZW50cyBhbmQvb3Ig c3VnZ2VzdGlvbnMuDQpUaGFua3MuDQoNCkJlc3QgcmVnYXJkcywNClRhZWhvDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQpTZW50OiBUdWVzZGF5LCBKdWx5IDA3LCAyMDE1 IDM6MDEgQU0NClRvOiDrsLHsnYDqsr0oU0RORlYgVEYpOyDrsLHsnYDqsr0oU0RORlYgVEYpOyDq sJXtg5ztmLgoU0ROIFByb2plY3QpOyDquYDshLHsiJgoU0ROIFByb2plY3QpOyDqsJXtg5ztmLgo U0ROIFByb2plY3QpOyDquYDshLHsiJgoU0ROIFByb2plY3QpOyDquYDrgqjqs6QoTkZWIFByb2pl Y3QpOyDquYDrgqjqs6QoTkZWIFByb2plY3QpOyDtlZzsmIHtg5woU0ROIFByb2plY3QpOyDtlZzs mIHtg5woU0ROIFByb2plY3QpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWthbmctc2ZjLWR5bmFtaWMtcGF0aC1zZWxlY3Rpb24tMDAudHh0DQoNCg0KQSBuZXcg dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWthbmctc2ZjLWR5bmFtaWMtcGF0aC1zZWxlY3Rpb24tMDAu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFRhZWhvIEthbmcgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQta2Fu Zy1zZmMtZHluYW1pYy1wYXRoLXNlbGVjdGlvbg0KUmV2aXNpb246ICAgICAgIDAwDQpUaXRsZTog ICAgICAgICAgRHluYW1pYyBTZXJ2aWNlIFBhdGggU2VsZWN0aW9uIG92ZXIgTXVsdGlwbGUgTGlu a3MgYmV0d2VlbiBTRkYgYW5kIFNGIGZvciBFbmhhbmNpbmcgU2VydmljZSBTdGFiaWxpdHkNCkRv Y3VtZW50IGRhdGU6ICAyMDE1LTA3LTA2DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpQYWdlczogICAgICAgICAgOQ0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rYW5nLXNmYy1keW5hbWljLXBhdGgtc2VsZWN0 aW9uLTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWthbmctc2ZjLWR5bmFtaWMtcGF0aC1zZWxlY3Rpb24vDQpIdG1saXplZDogICAg ICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWthbmctc2ZjLWR5bmFtaWMtcGF0 aC1zZWxlY3Rpb24tMDANCg0KDQpBYnN0cmFjdDoNCiAgIEluIHRoaXMgZG9jdW1lbnQsIHdlIHVz ZSBTRiBjbGFzc2lmaWNhdGlvbiBvZiAxKWluZGlzcGVuc2libGUgU0YgZm9yDQogICBwYWNrZXQg ZGVsaXZlcnksIGFsbGVnZWRseSBtYW5kYXRvcnkgU0ZzLCBzdWNoIGFzIE5BVCBhbmQgMilvcHRp b25hbA0KICAgU0ZzIHRoYXQgYSBwYWNrZXQgY2FuIGJlIGRlbGl2ZXJlZCB3aXRob3V0IHRoZW0s IHN1Y2ggYXMgRmlyZXdhbGwgYW5kDQogICBJRFMuDQoNCiAgIFRoZSBub2RlcyBvZiBTRkMtZW5h YmxlZCBkb21haW4gY2FuIGJlIHZhcmlvdXMuICBEaWZmZXJlbnQgdmVuZG9ycw0KICAgbWFrZSBk aWZmZXJlbnQgdHlwZXMgb2YgZXF1aXBtZW50cywgYW5kIHRoaXMgY2F1c2VzIHBlcmZvcm1hbmNl DQogICBpc3N1ZXMuICBDb25zaWRlcmluZyB0aGlzIGRpdmVyc2l0eSwgdGhlIGtpbmQgb2YgU0Zz IGNhbiBiZSBpbiBteXJpYWQNCiAgIGZvcm0uICBUaHVzLCB3ZSBzaG91bGQgZGlzdGluZ3Vpc2gg c29tZSBtYW5kYXRvcnkgU0ZzIGZyb20gbm90DQogICBtYW5kYXRvcnkgU0ZzIGFuZCB0cmVhdCBk aXN0aW5jdGl2ZWx5LiAgTWFuZGF0b3J5IFNGcyBzaG91bGQgYmUNCiAgIG1hdGNoZWQgd2l0aCBo aWdoZXItcGVyZm9ybWFuY2UgU0ZGIHRvIGFjaGlldmUgaGlnaCBhdmFpbGFiaWxpdHkgYXMNCiAg IHdlbGwgYXMgbG93ZXIgdGhlIHByb2JhYmlsaXR5IG9mIGZhaWx1cmUuICBBYm92ZSBhbGwsIHdo ZXRoZXIgZWFjaCBTRg0KICAgaXMgbWFuZGF0b3J5IG9yIG9wdGlvbmFsIHNob3VsZCBiZSByZWdp c3RlcmVkIGluIGFkdmFuY2UuICBNYW5kYXRvcnkNCiAgIFNGcyBhcmUgdG8gYWxsb2NhdGVkIHRv IHJlbGF0aXZlbHkgaGlnaGVyLXBlcmZvcm1hbmNlLCBsYXJnZXINCiAgIGNhcGFjaXR5LCBtb3Jl IHN0YWJsZSBTRkZzLiAgU0ZDIGNvbnN0cnVjdGVkIHVzaW5nIHRoaXMgd2F5IG9mDQogICBhbGxv Y2F0aW9uIGJlY29tZXMgdGhlIHBhdGggZm9yIHBhY2tldHMgYW5kIHBhY2tldHMgYXJlIHRyYW5z ZmVycmVkDQogICB0byBjbGFzc2lmaWVyIHRocm91Z2ggQzEgaW50ZXJmYWNlLCBhbmQgdG8gU0ZG IHRocm91Z2ggQzIgaW50ZXJmYWNlLA0KICAgcmVzcGVjdGl2ZWx5Lg0KDQoNCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv ZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFp bGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0KDQrs nbQg66mU7J287J2AIOyngOygleuQnCDsiJjst6jsnbjrp4zsnYQg7JyE7ZW0IOyekeyEseuQmOyX iOycvOupsCwg7KSR7JqU7ZWcIOygleuztOuCmCDsoIDsnpHqtozsnYQg7Y+s7ZWo7ZWY6rOgIOye iOydhCDsiJgg7J6I7Iq164uI64ukLiDslrTrlqDtlZwg6raM7ZWcIOyXhuydtCwg67O4IOusuOyE nOyXkCDtj6ztlajrkJwg7KCV67O07J2YIOyghOu2gCDrmJDripQg7J2867aA66W8IOustOuLqOyc vOuhnCDsoJwz7J6Q7JeQ6rKMIOqzteqwnCwg67Cw7Y+sLCDrs7Xsgqwg65iQ64qUIOyCrOyaqe2V mOuKlCDqsoPsnYQg7JeE6rKp7Z6IIOq4iOyngO2VqeuLiOuLpC4g66eM7JW9LCDrs7gg66mU7J28 7J20IOyemOuquyDsoITshqHrkJwg6rK97JqwLCDrsJzsi6Dsnbgg65iQ64qUIOuLueyCrOyXkCDs lYzroKTso7zsi5zqs6AsIOuzuCDrqZTsnbzsnYQg7KaJ7IucIOyCreygnO2VmOyXrCDso7zsi5zq uLAg67CU656N64uI64ukLg0KVGhpcyBFLW1haWwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGlu Zm9ybWF0aW9uIGFuZC9vciBjb3B5cmlnaHQgbWF0ZXJpYWwuIFRoaXMgZW1haWwgaXMgaW50ZW5k ZWQgZm9yIHRoZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZSBvbmx5LiBJZiB5b3UgcmVjZWl2ZSB0aGlz IGVtYWlsIGJ5IG1pc3Rha2UsIHBsZWFzZSBlaXRoZXIgZGVsZXRlIGl0IHdpdGhvdXQgcmVwcm9k dWNpbmcsIGRpc3RyaWJ1dGluZyBvciByZXRhaW5pbmcgY29waWVzIHRoZXJlb2Ygb3Igbm90aWZ5 IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkuDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K From nobody Mon Jul 6 13:40:23 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD981B31FE for ; Mon, 6 Jul 2015 13:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUx_3b7bKenK for ; Mon, 6 Jul 2015 13:40:20 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id C6A971B31EE for ; Mon, 6 Jul 2015 13:40:19 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Mon, 6 Jul 2015 16:40:18 -0400 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-dolson-sfc-hierarchical-02.txt Thread-Index: AQHQuCuKm8pFhljN5EyuyivmmX9AnJ3O5wHw Date: Mon, 6 Jul 2015 20:40:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [sfc] FW: New Version Notification for draft-dolson-sfc-hierarchical-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 20:40:21 -0000 V2UgaGF2ZSBwb3N0ZWQgYW4gdXBkYXRlIHRvIHRoZSBIaWVyYXJjaGljYWwgU2VydmljZSBDaGFp bmluZyAoaFNGQykgZG9jdW1lbnQuDQpUaGlzIHZlcnNpb24gYWRkcyBhbiBhcHBlbmRpeCBzaG93 aW5nIGFuIGV4YW1wbGUgdG8gaGVscCByZWFkZXJzIHZpc3VhbGl6ZSB0aGUgcmVkdWNlZCBjb21w bGV4aXR5IG9mIHVzaW5nIGhTRkMuDQoNCi1EYXZlDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEp1bHkgMDYsIDIwMTUgNDozNyBQTQ0KVG86 IFNodW5zdWtlIEhvbW1hOyBEaWVnbyBSLiBMb3BlejsgTW9oYW1lZCBCb3VjYWRhaXI7IERhdmUg RG9sc29uOyBEaWVnbyBMb3BlejsgRGF2ZSBEb2xzb247IE1vaGFtZWQgQm91Y2FkYWlyOyBTaHVu c3VrZSBIb21tYQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1k b2xzb24tc2ZjLWhpZXJhcmNoaWNhbC0wMi50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwg ZHJhZnQtZG9sc29uLXNmYy1oaWVyYXJjaGljYWwtMDIudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVs bHkgc3VibWl0dGVkIGJ5IERhdmlkIERvbHNvbiBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBv c2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtZG9sc29uLXNmYy1oaWVyYXJjaGljYWwNClJldmlzaW9u OgkwMg0KVGl0bGU6CQlIaWVyYXJjaGljYWwgU2VydmljZSBDaGFpbmluZw0KRG9jdW1lbnQgZGF0 ZToJMjAxNS0wNy0wNg0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTYN ClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtZG9sc29uLXNmYy1oaWVyYXJjaGljYWwtMDIudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZG9sc29uLXNmYy1oaWVyYXJjaGljYWwv DQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWRvbHNv bi1zZmMtaGllcmFyY2hpY2FsLTAyDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWRvbHNvbi1zZmMtaGllcmFyY2hpY2FsLTAyDQoNCkFic3Ry YWN0Og0KICAgSGllcmFyY2hpY2FsIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKGhTRkMpIGlz IGEgbmV0d29yaw0KICAgYXJjaGl0ZWN0dXJlIGFsbG93aW5nIGFuIG9yZ2FuaXphdGlvbiB0byBj b21wYXJ0bWVudGFsaXplIGEgbGFyZ2UtDQogICBzY2FsZSBuZXR3b3JrIGludG8gbXVsdGlwbGUg ZG9tYWlucyBvZiBhZG1pbmlzdHJhdGlvbi4NCg0KICAgVGhlIGdvYWxzIG9mIGhTRkMgYXJlIHRv IG1ha2UgYSBsYXJnZS1zY2FsZSBuZXR3b3JrIGVhc2llciB0byByZWFzb24NCiAgIGFib3V0LCBz aW1wbGVyIHRvIGNvbnRyb2wgYW5kIHRvIHN1cHBvcnQgaW5kZXBlbmRlbnQgZnVuY3Rpb25hbA0K ICAgZ3JvdXBzIHdpdGhpbiBsYXJnZSBvcGVyYXRvcnMuDQoNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0KDQo= From nobody Tue Jul 7 00:59:17 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 304451A1A99 for ; Tue, 7 Jul 2015 00:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBYYJd7PIAjt for ; Tue, 7 Jul 2015 00:59:13 -0700 (PDT) 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 4BB811A1B24 for ; Tue, 7 Jul 2015 00:59:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUU30408; Tue, 07 Jul 2015 07:59:11 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 7 Jul 2015 08:59:05 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.117]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Tue, 7 Jul 2015 15:58:58 +0800 From: Jiangyuanlong To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: SFC WG agenda slots - Prague Thread-Index: AQHQsOmuFIw1+/NXJ0OcpkbP+ocVYp3Psxeg Date: Tue, 7 Jul 2015 07:58:58 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A940C9E@szxema506-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.66.76.118] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A940C9Eszxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "Xuweiping \(A\)" , Zhuhengjun Subject: Re: [sfc] SFC WG agenda slots - Prague X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 07:59:15 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A940C9Eszxema506mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, I would like to request a 10 minutes slot for draft-jx-sfc-oam-02. Thanks, Yuanlong From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Saturday, June 27, 2015 10:58 PM To: sfc@ietf.org Subject: [sfc] SFC WG agenda slots - Prague Greetings WG: Our meeting in Prague is fast approaching. As always the goal of the meetin= g will be to make the best use of our limited face-to-face time. With that = in mind we welcome requests for agenda time. As we build the meeting agenda our goal will be to select presentations tha= t best further the work of the WG, and that generally means focusing on key= charter deliverables and topics with important open issues to resolve. Whe= n making a request please consider what you think the WG should do with its= content - for example: * Does the document have useful content that should be moved into a= nother WG document or progress on its own merit * Does the content have a good basis for one of the WG documents pe= r the charter * Should the document content be merged with one or more other docu= ments, so that a combined document could become a WG document Jim & Thomas --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A940C9Eszxema506mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 = ;

I would li= ke to request a 10 minutes slot for draft-jx-sfc-oam-02.<= /p>

 = ;

Thanks,

Yuanlong

 = ;

 = ;

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguich= ar)
Sent: Saturday, June 27, 2015 10:58 PM
To: sfc@ietf.org
Subject: [sfc] SFC WG agenda slots - Prague

 

Greetings WG:

 

Our meeting in Prague is fast approaching. As always the goal of the meeting will be to make the best use of our limited face-t= o-face time. With that in mind we welcome requests for agenda time. 

 

As we build the meeting agenda our goal will be to select presentations that best further the work of the WG, and that gen= erally means focusing on key charter deliverables and topics with important= open issues to resolve. When making a request please consider what you thi= nk the WG should do with its content – for example:

·=    &n= bsp;     Does the document have usef= ul content that should be moved into another WG document or progress on its own merit

·=    &n= bsp;     Does the content have a goo= d basis for one of the WG documents per the charter

·=    &n= bsp;     Should the document content= be merged with one or more other documents, so that a combined document could become a WG document

Jim & Thomas

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A940C9Eszxema506mbschi_-- From nobody Thu Jul 9 10:28:02 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2D31A19F2 for ; Thu, 9 Jul 2015 10:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaek3SygBWj3 for ; Thu, 9 Jul 2015 10:27:54 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA4F1A0AF8 for ; Thu, 9 Jul 2015 10:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63833; q=dns/txt; s=iport; t=1436462874; x=1437672474; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=18EXt7BeVQhNQWbuYhbFwLqOlmMd0XOXQXb2bz11K5E=; b=egk9b3SW/OREbEy+SXTcZsOcPoYCK9UXgeZ7t43ue/Pj9Qbd9BHsW8lz PB7JLpH3UF9Cq6JbYkqWUw0e4fiHi9h/3TYKnKg1ySkX+qY2vK6K66PIc QHYk+YUpEPCPpf4VTCk+gZAXHSVBgo8FWuVABrDSL3j+wEEq0+c4SLlYF E=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CrBQADrp5V/40NJK1YA4JFTVRgBoMauAuBThkBCYV3AoFeOhIBAQEBAQEBgQqEIwEBAQMBAQEBFwkERwsFBwQCAQgRAQMBAQEgAQYDAgInCxQDBggCBA4FDogYCA25ApYnAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLS4QtAUgQBwYLglcvgRQFhR+Baoo8gmgBgiyBVIVagiWBPYQYgw+Hd4gMJmOBKRyBU2+BBAEfI4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,441,1432598400"; d="asc'?scan'208,217";a="167007658" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-7.cisco.com with ESMTP; 09 Jul 2015 17:27:53 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t69HRq4k031229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jul 2015 17:27:52 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.220]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 9 Jul 2015 12:27:52 -0500 From: "Carlos Pignataro (cpignata)" To: "Elzur, Uri" Thread-Topic: [sfc] clarification on SFC and Overlay interaction Thread-Index: AQHQSjCk/CO92w19PkOCqp0Z1D8ImZzz3I0wgACUXQD//3x9gIAAiO2AgMOJl6CADQlKAIAArLQAgACTMACAAApagIAORSgA Date: Thu, 9 Jul 2015 17:27:51 +0000 Message-ID: References: <7E05C330D7FD6D4FAD0728C46B89958581B7E39A@ORSMSX114.amr.corp.intel.com> <54E262B8.2010605@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E414@ORSMSX114.amr.corp.intel.com> <54E27BFA.2010608@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E4A5@ORSMSX114.amr.corp.intel.com> <54E28085.8070803@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581C98149@ORSMSX114.amr.corp.intel.com> <5EC6B28A-0F3C-4E28-B596-394DDB9EB89D@cisco.com> <7E05C330D7FD6D4FAD0728C46B89958581CA902C@ORSMSX114.amr.corp.intel.com> <2B8D89D3-C772-4ED7-A3FE-AC923019E7F4@cisco.com> <7E05C330D7FD6D4FAD0728C46B89958581CAA072@ORSMSX114.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B89958581CAA072@ORSMSX114.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.54.204] Content-Type: multipart/signed; boundary="Apple-Mail=_03DFB0FC-40EE-40B2-8035-926CCFF6851D"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Joel Halpern Direct , "sfc@ietf.org" Subject: Re: [sfc] clarification on SFC and Overlay interaction X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 17:27:59 -0000 --Apple-Mail=_03DFB0FC-40EE-40B2-8035-926CCFF6851D Content-Type: multipart/alternative; boundary="Apple-Mail=_4A328CE6-70A9-4C94-AD8D-10BAAA36B85B" --Apple-Mail=_4A328CE6-70A9-4C94-AD8D-10BAAA36B85B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Uri, (WG,) I was re-reading these set of comments from you, and realized that we = could add some more clarity as you mentioned. What do you think of these set of proposed diffs? =E2=80=94>8=E2=80=94 @@ -511,38 +511,43 @@ 7. Heterogeneous control/policy points: The architecture allows SFs to use independent mechanisms (out of scope for this document) = to populate and resolve local policy and (if needed) local classification criteria. 4. Core SFC Architecture Components The SFC Architecture is built out of architectural building blocks which are logical components; these logical components are classifiers, service function forwarders (SFF), the service = functions - themselves (SF), and SFC-proxies. They are interconnected using the - SFC Encapsulation. This results in a high level logical = architecture - of an SFC-enabled Domain which comprises: + themselves (SF), and SFC-proxies. While this architecture describes + functionally distinct logical components and promotes transport + indepencence, they could be realized and combined in various ways in + deployed products, and could be combined with an overlay. + + They are interconnected using the SFC Encapsulation. This results = in + a high level logical architecture of an SFC-enabled Domain which + comprises: o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . +--------------+ +------------------~~~ . | Service | SFC | Service +---+ +---+ . |Classification| Encapsulation | Function |sf1|...|sfn| +---->| Function |+---------------->| Path +---+ +---+ . +--------------+ +------------------~~~ . SFC-enabled Domain o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2: Service Function Chain Architecture The following sub-sections provide details on each logical component that form the basis of the SFC architecture. A detailed overview of - how each of these architectural components interact is provided in + how some of these architectural components interact is provided in Figure 3: +----------------+ +----------------+ | SFC-aware | | SFC-unaware | |Service Function| |Service Function| +-------+--------+ +-------+--------+ | | SFC Encapsulation No SFC Encapsulation | SFC | +---------+ +----------------+ Encapsulation +---------+ @@ -561,21 +566,26 @@ Network Overlay Transport | _,....._ ,-' `-. / `. | Network | `. / `.__ __,-' `'''' - Figure 3: Service Function Chain Architecture Components + Figure 3: SFC Architecture Components Post Initial Classification + + Please note that the depiction in Figure 3 shows packets post = initial + classification, and therefore including the SFC encapsulation. + Although not included in Figure 3, the classifier is an SFC + architectural component. 4.1. SFC Encapsulation =E2=80=94>8=E2=80=94 Thanks! =E2=80=94 Carlos. > On Jun 30, 2015, at 11:32 AM, Elzur, Uri wrote: >=20 > Hi Carlos >=20 > Pls see below [UE] >=20 > Thx >=20 > Uri (=E2=80=9COo-Ree=E2=80=9D) > C: 949-378-7568 >=20 > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com = ] > Sent: Tuesday, June 30, 2015 7:56 AM > To: Elzur, Uri > Cc: Joel Halpern Direct; sfc@ietf.org > Subject: Re: [sfc] clarification on SFC and Overlay interaction >=20 > Hi, Uri, >=20 > Thanks for the comments, please see inline. >=20 >> On Jun 30, 2015, at 2:08 AM, Elzur, Uri wrote: >>=20 >> Hi Carlos >>=20 >> Thanks for following up. Few comments >>=20 >> 1) There is an impression (by some) that SFC REQUIRES an independent >> layer EVEN if one has an overlay deployed. Without pointing out ANY >> technology, a sentence like =E2=80=9CWhile this architecture = describes >> functionally distinct logical components and promotes transport >> independence, the service chaining layer can be combined in various >> ways with an overlay=E2=80=9D can explain that point. BTW: In the NSH = draft, >> we do make the assumption that there is an Overlay on top of which = SFC >> (NSH) is deployed. This Overlay can be dedicated to NSH or shared >> with an overlay for network virtualization=E2=80=A6 >>=20 >=20 > If I read this correctly, you are proposing to add =E2=80=9Cpromotes = transport independence=E2=80=9D. I think that the document already = covers this point in detail. Also, it is not the service layer that is = combined, but rather the components, so part of this re-write could be a = bit confusing. >=20 > I am happy to try to rewrite and sharpen this sentence, but I really = think that nothing you say is precluded. > [UE] the point is about building SFC into an existing NetVirt Overlay. = To sharpen that point, I'm adding albeit that SFC = promotes/assumes/mandates Transport independence, merging SFC into an = exisiting overlay is possible. I think it takes clear statement for = folks to see as it comes across to me and others as if this is not = possible >=20 >> 2) Classifier vs SFF =E2=80=93 have looked into rev 9 of the arch = draft, assume the Classifier is the entity that inserts the NSH header = i.e. encapsulates (see figure 2), we may want to update the = architectural diagram (fig 3) to clearly show the Service Classifier as = part of the architecture. >=20 > Figure 2 already shows the classifier as part of the architecture. I = am not sure how to update Figure 3 without making it unreadable. = Remember fig 3 is not showing and end-to-end view of the SFP. > [UE] without a classifier Fig 3 is incomplete IMHO, it is the = Classifier that is located at the boundary of the non encapsulated and = SFC-encapsulated world. And this is also why I was proposing to update = the definition. The suggestion is to make it clear it is not theSFF that = is encapsulating the first SFC packet >=20 >> Also may want to update the Classifier definition to that end (like = in >> the above, a classifier can be integrated into the SFF, then we may >> want to mention that. In any case, the SFF performs the NSH >> decapsulation) >=20 > I am hesitant to add a very specific example to the general sentence = above. Otherwise, we might end up implying that other combinations are = not possible. Since the role of classification and use of the SFC = encapsulation is covered in detail in full sections of the doc, I=E2=80=99= d recommend we do not try to summarize here. > [UE] not suggesting to limit the generality of the architecture and = for me there is no need to include the example of a classifier = integrated into SFF. On the contrary I much prefer to see the above = clarification of the Classifier independent role >=20 > We welcome other comments on this of course, >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >>=20 >> Thx >>=20 >> Uri (=E2=80=9COo-Ree=E2=80=9D) >> C: 949-378-7568 >>=20 >> -----Original Message----- >> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >> Sent: Monday, June 29, 2015 12:51 PM >> To: Elzur, Uri >> Cc: Joel Halpern Direct; sfc@ietf.org >> Subject: Re: [sfc] clarification on SFC and Overlay interaction >>=20 >> Hi, Uri, >>=20 >> I added the following text at the beginning of Section 4: =E2=80=9CWhil= e this architecture describes functionally distinct logical components, = they could combined in various ways in deployed products.=E2=80=9D >>=20 >> I think this covers all potential cases, instead of singling out one = example. >>=20 >> The Section now starts like this: >>=20 >> --->8--- >> The SFC Architecture is built out of architectural building blocks >> which are logical components; these logical components are >> classifiers, service function forwarders (SFF), the service = functions >> themselves (SF), and SFC-proxies. While this architecture describes >> functionally distinct logical components, they could combined in >> various ways in deployed products. >>=20 >> They are interconnected using the SFC Encapsulation. This results = in >> a high level logical architecture of an SFC-enabled Domain which >> comprises: >> --->8--- >>=20 >> Does this help? >>=20 >> Thanks, >>=20 >> =E2=80=94 Carlos. >>=20 >>> On Jun 22, 2015, at 10:20 AM, Elzur, Uri = wrote: >>>=20 >>> Hi Joel >>>=20 >>> I've recently reviewed the latest draft v 09. I still miss such a = clarification. Pls point me in the right direction if it does exist = somewhere in chapter 4. >>>=20 >>> I'd like to suggest we add language referring to the specific = example >>> outlined below of SFF integrated with an overlay manager as a way to >>> show how the logical elements can be implemented as part of an >>> overlay and to clarify we are not talking ONLY about a completely >>> independent new Service overlay >>>=20 >>> Thx >>>=20 >>> Uri ("Oo-Ree") >>> C: 949-378-7568 >>>=20 >>> -----Original Message----- >>> From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com] >>> Sent: Monday, February 16, 2015 3:43 PM >>> To: Elzur, Uri; sfc@ietf.org >>> Subject: Re: [sfc] clarification on SFC and Overlay interaction >>>=20 >>> It seems like we can (and unless I am very confused, should) add = such a statement in the base portion of section 4. Carlos and I will = work on this. Thank you for calling our attention to the omission. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 2/16/15 6:36 PM, Elzur, Uri wrote: >>>> Agree. I do not recall however any such statement. I do recall many >>>> statement like section 4.5, indicating the separation and referring >>>> to topological and transport independence. Pls point me to the >>>> paragraph or we may want to add such clarification in the next rev >>>>=20 >>>> Thx >>>>=20 >>>> Uri ("Oo-Ree") >>>> C: 949-378-7568 >>>>=20 >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Monday, February 16, 2015 3:24 PM >>>> To: Elzur, Uri; sfc@ietf.org >>>> Subject: Re: [sfc] clarification on SFC and Overlay interaction >>>>=20 >>>> If we do not have text in there that says that these logical = components may be combined in real world implementations or deployments = with each other or with components from outside the architecture, I = could see adding that. I thought we already said it. >>>>=20 >>>> I would prefer not to add comments on any specific deployments, = because there are so many ways to do so, and as far as I can tell, most = of us think the one in our head is the most likely / common / useful. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 2/16/15 5:36 PM, Elzur, Uri wrote: >>>>> Joel >>>>>=20 >>>>> Sounds good to me. However a clarification, maybe in the format of >>>>> a comment or example (as I suspect this may be a very common case, >>>>> for >>>>> some) in the draft will be of value >>>>>=20 >>>>> Thx >>>>>=20 >>>>> Uri ("Oo-Ree") >>>>> C: 949-378-7568 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>> Sent: Monday, February 16, 2015 1:36 PM >>>>> To: Elzur, Uri; sfc@ietf.org >>>>> Subject: Re: [sfc] clarification on SFC and Overlay interaction >>>>>=20 >>>>> One of the key reasons for identifying the logical components is = that there are a broad range of ways that they can be composed. That = does sound like one possible composition. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 2/16/15 4:32 PM, Elzur, Uri wrote: >>>>>> While section 4.5 of draft-ietf-sfc-architecture-04, states >>>>>> "underneath the SFF there are components responsible for >>>>>> performing the transport >>>>>> (overlay) forwarding. They do not consults the SFC encapsulation >>>>>> or inner payload for performing these forwarding.", there is no >>>>>> reason to exclude the following private case, I'd assume. This is >>>>>> the case where the SFF is effectively integrated with the Overlay >>>>>> manager, or instantiated in other overlay network elements (e.g. >>>>>> vSwitch), enabling in essence SFC within an Overlay network, with >>>>>> no need for a separate SFC domain. >>>>>>=20 >>>>>> To be clear (or clearer), this is not to suggest that transport = or >>>>>> topological independence can be or should be bend, but simply to >>>>>> suggest a deployment scenario that may be popular for limited >>>>>> scale SFC >>>>>>=20 >>>>>> Thx >>>>>>=20 >>>>>> Uri ("Oo-Ree") >>>>>>=20 >>>>>> C: 949-378-7568 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>=20 >>>>>=20 >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_4A328CE6-70A9-4C94-AD8D-10BAAA36B85B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Uri, (WG,)

I was re-reading these set of comments from you, and realized = that we could add some more clarity as you mentioned.

What do you think of = these set of proposed diffs?

=E2=80=94>8=E2=80=94 
@@ -511,38 +511,43 @@
    7. =  Heterogeneous control/policy points: The architecture allows = SFs
        to use independent = mechanisms (out of scope for this document) to
  =       populate and resolve local policy and (if needed) = local
        classification = criteria.
 
 4.  Core SFC = Architecture Components
 
    = The SFC Architecture is built out of architectural building blocks
    which are logical components; these logical = components are
    classifiers, service function = forwarders (SFF), the service functions
-   = themselves (SF), and SFC-proxies.  They are interconnected using = the
-   SFC Encapsulation.  This results in a = high level logical architecture
-   of an SFC-enabled = Domain which comprises:
+   themselves (SF), and = SFC-proxies.  While this architecture describes
+ =   functionally distinct logical components and promotes = transport
+   indepencence, they could be realized = and combined in various ways in
+   deployed = products, and could be combined with an overlay.
+
+   They are interconnected using the SFC Encapsulation. =  This results in
+   a high level logical = architecture of an SFC-enabled Domain which
+   = comprises:
 
      =  o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . = .
       .  +--------------+ =                 =  +------------------~~~
       . =  |   Service    |       SFC   =      |  Service  +---+   +---+
       .  |Classification| =  Encapsulation   | Function  |sf1|...|sfn|
    +---->|   Function   = |+---------------->|   Path    +---+   +---+
       .  +--------------+   =               =  +------------------~~~
       . = SFC-enabled Domain
       o . . . . . = . . . . . . . . . . . . . . . . . . . . . . . . . . .
 
          =       Figure 2: Service Function Chain Architecture
 
    The following sub-sections = provide details on each logical component
    = that form the basis of the SFC architecture.  A detailed overview = of
-   how each of these architectural components = interact is provided in
+   how some of these = architectural components interact is provided in
  =   Figure 3:
 
      =     +----------------+           =              +----------------+
          |   SFC-aware   =  |                   =      |  SFC-unaware   |
  =         |Service Function|       =                  |Service = Function|
          = +-------+--------+               =          +-------+--------+
  =                 |     =                     =                 |
            SFC Encapsulation =                     =   No SFC Encapsulation
        =           |           =        SFC             =        |
    =  +---------+  +----------------+ Encapsulation     = +---------+
@@ -561,21 +566,26 @@
  =                     =      Network Overlay Transport
  =                     =                  |
                =                   =  _,....._
            =                     = ,-'        `-.
      =                     =      /             =  `.
              =                 |     = Network    |
          =                     `. =              /
  =                     =           `.__     __,-'
                =                     = `''''
 
-         = Figure 3: Service Function Chain Architecture Components
+ =     Figure 3: SFC Architecture Components Post Initial = Classification
+
+   Please note that = the depiction in Figure 3 shows packets post initial
+ =   classification, and therefore including the SFC encapsulation.
+   Although not included in Figure 3, the classifier is = an SFC
+   architectural component.
 
 4.1.  SFC Encapsulation
 =E2=80=94>8=E2=80=94 


Thanks!

=E2=80=94 Carlos.


On Jun 30, 2015, at 11:32 AM, = Elzur, Uri <uri.elzur@intel.com> wrote:

Hi Carlos

Pls see below [UE]

Thx

Uri = (=E2=80=9COo-Ree=E2=80=9D)
C: 949-378-7568

-----Original Message-----
From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] 
Sent: Tuesday, June 30, 2015 7:56 AM
To: Elzur, Uri
Cc: Joel Halpern Direct; sfc@ietf.org
Subject: Re: [sfc] = clarification on SFC and Overlay interaction

Hi, Uri,

Thanks for the comments, please see = inline.

On Jun 30, 2015, at 2:08 AM, Elzur, Uri <uri.elzur@intel.com>= wrote:

Hi Carlos

Thanks for following up. Few comments

1) There is an impression (by some) that SFC REQUIRES an = independent 
layer EVEN if one has an overlay deployed. Without pointing = out ANY 
technology, a sentence like =E2=80=9CWhile this architecture = describes 
functionally distinct logical components and promotes = transport 
independence, the service chaining layer can be combined in = various 
ways with an overlay=E2=80=9D can explain that point. BTW: In = the NSH draft, 
we do make the assumption that there is an Overlay on top of = which SFC 
(NSH) is deployed. This Overlay can be dedicated to NSH =  or shared 
with an overlay for network virtualization=E2=80=A6


If I read this correctly, you are proposing to = add =E2=80=9Cpromotes transport independence=E2=80=9D. I think that the = document already covers this point in detail. Also, it is not the = service layer that is combined, but rather the components, so part of = this re-write could be a bit confusing.

I am happy to try to rewrite and sharpen this = sentence, but I really think that nothing you say is = precluded.
[UE] the point is about = building SFC into an existing NetVirt Overlay. To sharpen that point, = I'm adding albeit that SFC promotes/assumes/mandates Transport = independence, merging SFC into an exisiting overlay is possible. I think = it takes clear statement for folks to see as it comes across to me and = others as if this is not possible

2) Classifier vs SFF = =E2=80=93 have looked into rev 9 of the arch draft, assume the = Classifier is the entity that inserts the NSH header i.e. encapsulates = (see figure 2), we may want to update the architectural diagram (fig 3) = to clearly show the Service Classifier as part of the architecture.

Figure 2 already shows the = classifier as part of the architecture. I am not sure how to update = Figure 3 without making it unreadable. Remember fig 3 is not showing and = end-to-end view of the SFP.
[UE] without a classifier = Fig 3 is incomplete IMHO, it is the Classifier that is located at the = boundary of the non encapsulated and SFC-encapsulated world. And this is = also why I was proposing to update the definition. The suggestion is to = make it clear it is not theSFF that is encapsulating the first SFC = packet

Also may want to update the Classifier definition to = that end (like in 
the above, a classifier can be integrated into the SFF, then = we may 
want to mention that. In any case, the SFF performs the = NSH 
decapsulation)

I am hesitant to add a very specific example to = the general sentence above. Otherwise, we might end up implying that = other combinations are not possible. Since the role of classification = and use of the SFC encapsulation is covered in detail in full sections = of the doc, I=E2=80=99d recommend we do not try to summarize = here.
[UE] not suggesting to = limit the generality of the architecture and for me there is no need to = include the example of a classifier integrated into SFF. On the contrary = I much prefer to see the above clarification of the Classifier = independent role

We welcome other comments = on this of course,

Thanks,

=E2=80=94 Carlos.


Thx

Uri (=E2=80=9COo-Ree=E2=80=9D)
C: = 949-378-7568

-----Original Message-----
From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Monday, = June 29, 2015 12:51 PM
To: Elzur, Uri
Cc: = Joel Halpern Direct; sfc@ietf.org
Subject: Re: [sfc] = clarification on SFC and Overlay interaction

Hi, Uri,

I added the following = text at the beginning of Section 4: =E2=80=9CWhile this architecture = describes functionally distinct logical components, they could combined = in various ways in deployed products.=E2=80=9D

I think this covers all potential cases, instead of singling = out one example.

The Section now starts = like this:

--->8---
 The SFC Architecture is built out of architectural = building blocks
 which are logical components; these = logical components are
 classifiers, service function = forwarders (SFF), the service functions
 themselves = (SF), and SFC-proxies.  While this architecture describes
 functionally distinct logical components, they could = combined in
 various ways in deployed products.

 They are interconnected using the SFC = Encapsulation.  This results in
 a high level = logical architecture of an SFC-enabled Domain which
 comprises:
--->8---

Does this help?

Thanks,

=E2=80=94 Carlos.

On Jun 22, 2015, at = 10:20 AM, Elzur, Uri <uri.elzur@intel.com> wrote:

Hi Joel

I've recently reviewed = the latest draft v 09. I still miss such a clarification. Pls point me = in the right direction if it does exist somewhere in chapter 4.

I'd like to suggest we add language referring = to the specific example 
outlined = below of SFF integrated with an overlay manager as a way to 
show how the = logical elements can be implemented as part of an 
overlay and = to clarify we are not talking ONLY about  a completely 
independent = new Service overlay

Thx

Uri ("Oo-Ree")
C: 949-378-7568

-----Original Message-----
From: Joel Halpern = Direct [mailto:jmh.direct@joelhalpern.com]
Sent: = Monday, February 16, 2015 3:43 PM
To: Elzur, Uri; sfc@ietf.org
Subject: Re: [sfc] clarification on SFC and Overlay = interaction

It seems like we can (and = unless I am very confused, should) add such a statement in the base = portion of section 4.  Carlos and I will work on this.  Thank = you for calling our attention to the omission.

Yours,
Joel

On = 2/16/15 6:36 PM, Elzur, Uri wrote:
Agree. I do not recall however any such statement. I do = recall many 
statement like section 4.5, indicating the separation and = referring 
to topological and transport independence. Pls point me to = the 
paragraph or we may want to add such clarification in the = next rev

Thx

Uri= ("Oo-Ree")
C: 949-378-7568

-----Original Message-----
From: Joel M. = Halpern [mailto:jmh@joelhalpern.com]
Sent: Monday, = February 16, 2015 3:24 PM
To: Elzur, Uri; sfc@ietf.org
Subject: Re: [sfc] clarification on SFC and Overlay = interaction

If we do not have text in there = that says that these logical components may be combined in real world = implementations or deployments with each other or with components from = outside the architecture, I could see adding that.  I thought we = already said it.

I would prefer not to add = comments on any specific deployments, because there are so many ways to = do so, and as far as I can tell, most of us think the one in our head is = the most likely / common / useful.

Yours,
Joel

On 2/16/15 5:36 PM, Elzur, = Uri wrote:
Joel

Sounds good to me. However a clarification, = maybe in the format of 
a comment or = example (as I suspect this may be a very common case, 
for
some) in the draft will be of value

Thx

Uri ("Oo-Ree")
C: 949-378-7568

-----Original = Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Monday, = February 16, 2015 1:36 PM
To: Elzur, Uri; sfc@ietf.org
Subject: Re: [sfc] clarification on SFC and Overlay = interaction

One of the key reasons for = identifying the logical components is that there are a broad range of = ways that they can be composed.  That does sound like one possible = composition.

Yours,
Joel

On 2/16/15 4:32 PM, Elzur, Uri wrote:
While section 4.5 of = draft-ietf-sfc-architecture-04, states 
"underneath = the SFF there are components responsible for 
performing = the transport
(overlay) forwarding. They do not consults = the SFC encapsulation 
or inner = payload for performing these forwarding.", there is no 
reason to = exclude the following private case, I'd assume. This is 
the case = where the SFF is effectively integrated with the Overlay 
manager, or = instantiated in other overlay network elements (e.g. 
vSwitch), = enabling in essence SFC within an Overlay network, with 
no need for = a separate SFC domain.

To be clear (or = clearer), this is not to suggest that transport or 
topological = independence can be or should be bend, but simply to 
suggest a = deployment scenario that may be popular for limited 
scale SFC

Thx

Uri = ("Oo-Ree")

C: 949-378-7568



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



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

= --Apple-Mail=_4A328CE6-70A9-4C94-AD8D-10BAAA36B85B-- --Apple-Mail=_03DFB0FC-40EE-40B2-8035-926CCFF6851D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVnq8YAAoJEIXgpQGOZny9iQ8P/2ae9HlyRQhjxssOjszt6Eib UhxePcxv7KfcSufG5rZ8Cqk9dRBOu/YsTicMZWuTPFCI0FNpFviC/QJgV6KFm5/Z RB7t6XpuBsYsMKFIWKLqmwlVeipNO2x43XdpDkUmTYVP3X/kDphdD7Ot8kI5z/nF d2sdUtQ4BqMKKzrVDXMUTQcJesWHoJx/wGIWXjZbfuID4s1TvwRN6zpwQP++wfGq SRC3TcZMOsj4Ky6tOOmYrE2FhSugsbg2NLww763SsJLNXDptcJxTC0THjVVUoT2f uU3oZGIdkw8kLH4F++DwkKaPkg/BlGxNicWgLf7jg9ascP8TlhFzMLTzTMBuHlxs xU9/qYvF2ZWKP1hcVU+Jf+Hnuu4q7UkMuFT6LNKviZjtuQdOBXGFGOREFoDoUGf8 vCnrykm5dS1LPfXFdIY/kqFEsaOtUOfQp1MbEIHqiXXiSCoiISwHceoWgQ1Z2lgh lRjmTFO6XTLuIUmA0K0JPQscqVMNpM/D1fMcuj7p+MCzbmdMRji0TdgrD51YrwzS Jj63hjHf1cvkKI+9i7L9Vna7WdfA4deAhhzmGn1uIiiAAJlQ/mYH0ZEJ9MEIorDQ j8Y/h68axnR7U3AJCAzwq0rOMPlbA8vGVJskqE/CUeuo77/3riJNEA2J/jqI4XBu //6T6Pg4abjZzqaHaj9p =UBC8 -----END PGP SIGNATURE----- --Apple-Mail=_03DFB0FC-40EE-40B2-8035-926CCFF6851D-- From nobody Sat Jul 11 09:17:18 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D571A8ADD for ; Sat, 11 Jul 2015 09:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.81 X-Spam-Level: X-Spam-Status: No, score=-11.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuCLJGEMXu5f for ; Sat, 11 Jul 2015 09:17:14 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB011A8AD9 for ; Sat, 11 Jul 2015 09:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4653; q=dns/txt; s=iport; t=1436631434; x=1437841034; h=from:to:cc:subject:date:message-id:mime-version; bh=DFcaseU2VXStwXgQfRDFPs6924mxu36W8BI9SSA/4ys=; b=gVSkn398pSXlFiCymwQI3NPwEai1vZ/NILqcjblVY3TvUm+RJbT7GXPk eE1L8BOSSVEkIj3azMeOqLDLp6o4W/ORqil5ctsMpcDc6TGA0dyikeh+B ZaNSJ0OA+gMdl5OXfLvFYBnyzBZnO6XGkAvhT539bDyohucbMcwJcXJWs c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BMBQAKQaFV/5tdJa1bgkdNgT0GuzeHaoEnORMBAQEBAQEBgQqEIwECBHkSAQgEDQMBAig5FAkKBAENBYguznoBAQEBAQEBAwEBAQEBAQEBGotMhC1IEYQyBZQxAYwDgT+EGJMUJmODGG+BBEOBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,454,1432598400"; d="scan'208,217";a="167741826" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP; 11 Jul 2015 16:17:14 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t6BGHDBZ011546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 Jul 2015 16:17:13 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.210]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Sat, 11 Jul 2015 11:17:13 -0500 From: "Jeffrey Napper (jenapper)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] SFC WG agenda slots - Prague Thread-Index: AQHQu/ULiklMubU44029w6MVU48i/g== Date: Sat, 11 Jul 2015 16:17:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.203.45] Content-Type: multipart/alternative; boundary="_000_D1C68ECA2DCFDjenapperciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Muley, Praveen V \(Praveen\)" , "Surendra Kumar \(smkumar\)" Subject: Re: [sfc] SFC WG agenda slots - Prague X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jul 2015 16:17:16 -0000 --_000_D1C68ECA2DCFDjenapperciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Howdy, Jim. Could we also have a short time slot to present the NSH mobility allocation= informational: draft-napper-sfc-nsh-mobility-allocation-01? Cheers, Jeff From: sfc > on behalf of = "Jim Guichard (jguichar)" > Date: Saturday, June 27, 2015 at 7:58 AM To: "sfc@ietf.org" > Subject: [sfc] SFC WG agenda slots - Prague Greetings WG: Our meeting in Prague is fast approaching. As always the goal of the meetin= g will be to make the best use of our limited face-to-face time. With that = in mind we welcome requests for agenda time. As we build the meeting agenda our goal will be to select presentations tha= t best further the work of the WG, and that generally means focusing on key= charter deliverables and topics with important open issues to resolve. Whe= n making a request please consider what you think the WG should do with its= content =96 for example: * Does the document have useful content that should be moved into anoth= er WG document or progress on its own merit * Does the content have a good basis for one of the WG documents per th= e charter * Should the document content be merged with one or more other document= s, so that a combined document could become a WG document Jim & Thomas --_000_D1C68ECA2DCFDjenapperciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7E31EF74874EEF448504CFB9608AE02F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Howdy, Jim.

Could we also have a short time slot to present the NSH mobility alloc= ation informational: draft-napper-sfc-nsh-mobility-allocation-01? 

Cheers,
Jeff


From: sfc <sfc-bounces@ietf.org> on behalf of "Jim Guic= hard (jguichar)" <jguichar@ci= sco.com>
Date: Saturday, June 27, 2015 at 7:= 58 AM
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] SFC WG agenda slots = - Prague

Greetings WG:

Our meeting in Prague is fast approaching. As always the goal of the m= eeting will be to make the best use of our limited face-to-face time. With = that in mind we welcome requests for agenda time. 

As we build the meeting agenda our goal will be to select presentation= s that best further the work of the WG, and that generally means focusing o= n key charter deliverables and topics with important open issues to resolve= . When making a request please consider what you think the WG should do with its content =96 for example:
  • Does the document have useful content that should be moved into another= WG document or progress on its own merit
  • Does the content have a g= ood basis for one of the WG documents per the charter
  • Should the do= cument content be merged with one or more other documents, so that a combin= ed document could become a WG document
Jim & Thomas
 --_000_D1C68ECA2DCFDjenapperciscocom_-- From nobody Mon Jul 13 07:12:26 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B271B2B10 for ; Mon, 13 Jul 2015 07:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhCvX9tAfcwt for ; Mon, 13 Jul 2015 07:12:23 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39C6B1B2B0D for ; Mon, 13 Jul 2015 07:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2163; q=dns/txt; s=iport; t=1436796743; x=1438006343; h=from:to:subject:date:message-id:mime-version; bh=BoKIvcrjp2uPg0KsWgzCg4ebEFkCbNxfHubF15LsFoQ=; b=cc8fDGc1UYBgn5knsuVYNzc+jC6ZD7LaV3raXcWCJvCDnU48XFThYt1l NcDFd889C4e40M04G8pBgXG1zoCCvzCflXojnoAZmeYpxjZXYjVXEZtLD 5ZUl/BRLbniXeSZxsWGTNmefheHEC9FuKyur/rYkycGH0aROpSLUVEYzZ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BoAwBSxqNV/4MNJK1bgkdNVG+7OwmBc4V3gTQ4FAEBAQEBAQGBCoQqgQsBDAFzJwSIQQ2kUaU/AQEBBwEBAQEaBJBOhDYFlDEBjAOBP4QYkxQmY4MYgjaBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,462,1432598400"; d="scan'208,217";a="167786289" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP; 13 Jul 2015 14:12:23 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6DECMu4000443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 13 Jul 2015 14:12:22 GMT Received: from xmb-aln-x01.cisco.com ([169.254.2.142]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Mon, 13 Jul 2015 09:12:22 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: IETF93 SFC WG Agenda Thread-Index: AQHQvXXv5bzQMgdeckC7+BE2vi0eQQ== Date: Mon, 13 Jul 2015 14:12:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.98.43.179] Content-Type: multipart/alternative; boundary="_000_D1C93FB617EF1jguicharciscocom_" MIME-Version: 1.0 Archived-At: Subject: [sfc] IETF93 SFC WG Agenda X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 14:12:24 -0000 --_000_D1C93FB617EF1jguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks: I have posted a preliminary agenda for our upcoming WG meeting in Prague he= re: https://www.ietf.org/proceedings/93/agenda/agenda-93-sfc If you are a presenter please plan to send Thomas & I slides no later than = 7/21 so that we have time to review prior to the meeting. Jim & Thomas --_000_D1C93FB617EF1jguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <37C78DEFFECB5541BE8F3D3FD345F8AA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Folks:

I have posted a preliminary agenda for our upcoming WG meeting in Prague he= re:


If you are a presenter please plan t= o send Thomas & I slides no later than 7/21 so that we have time t= o review prior to the meeting.

Jim & Thomas

--_000_D1C93FB617EF1jguicharciscocom_-- From nobody Mon Jul 13 19:15:33 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FCA1A8946 for ; Mon, 13 Jul 2015 19:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIIjxUOT_pKo for ; Mon, 13 Jul 2015 19:15:29 -0700 (PDT) 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 0D7531A8944 for ; Mon, 13 Jul 2015 19:15:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVD20869; Tue, 14 Jul 2015 02:15:27 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 14 Jul 2015 03:15:24 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.10]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Tue, 14 Jul 2015 10:15:16 +0800 From: "Songhaibin (A)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: IETF93 SFC WG Agenda Thread-Index: AQHQvXXv5bzQMgdeckC7+BE2vi0eQZ3aOkIA Date: Tue, 14 Jul 2015 02:15:15 +0000 Message-ID: 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.138.41.33] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F65301258nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [sfc] IETF93 SFC WG Agenda X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 02:15:31 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F65301258nkgeml501mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, I also sent the request for a slot on legacy service function support. And = there were interests from the working group at Dallas meeting. Best Regards! -Haibin From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, July 13, 2015 10:12 PM To: sfc@ietf.org Subject: [sfc] IETF93 SFC WG Agenda Folks: I have posted a preliminary agenda for our upcoming WG meeting in Prague he= re: https://www.ietf.org/proceedings/93/agenda/agenda-93-sfc If you are a presenter please plan to send Thomas & I slides no later than = 7/21 so that we have time to review prior to the meeting. Jim & Thomas --_000_E33E01DFD5BEA24B9F3F18671078951F65301258nkgeml501mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 = ;

I also sen= t the request for a slot on legacy service function support. And there were= interests from the working group at Dallas meeting.

 = ;

Best Regards!

-Haibin

 = ;

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, July 13, 2015 10:12 PM
To: sfc@ietf.org
Subject: [sfc] IETF93 SFC WG Agenda

 

Folks:<= /o:p>

 <= /o:p>

I have poste= d a preliminary agenda for our upcoming WG meeting in Prague here:

 <= /o:p>

 <= /o:p>

If you are a= presenter please plan to send Thomas & I slides no later than 7/2= 1 so that we have time to review prior to the meeting.

 <= /o:p>

Jim & Th= omas

 <= /o:p>

--_000_E33E01DFD5BEA24B9F3F18671078951F65301258nkgeml501mbschi_-- From nobody Thu Jul 16 20:21:18 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07C81A87E2 for ; Thu, 16 Jul 2015 20:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.421 X-Spam-Level: X-Spam-Status: No, score=-101.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLPfA5-Yeurc for ; Thu, 16 Jul 2015 20:21:13 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id DF82D1A877F for ; Thu, 16 Jul 2015 20:21:12 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id F1CD3DBD10B98 for ; Fri, 17 Jul 2015 11:16:41 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 5D1BF2F122CFD; Fri, 17 Jul 2015 11:21:06 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t6H3KlZU062366; Fri, 17 Jul 2015 11:20:48 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) In-Reply-To: References: To: Fu Qiao MIME-Version: 1.0 X-KeepSent: 3B4158CA:42E63295-48257E85:0011296E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: wang.cui1@zte.com.cn Date: Fri, 17 Jul 2015 11:20:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-07-17 11:20:48, Serialize complete at 2015-07-17 11:20:48 Content-Type: multipart/alternative; boundary="=_alternative 001262A548257E85_=" X-MAIL: mse01.zte.com.cn t6H3KlZU062366 Archived-At: Cc: "'Joel M. Halpern'" , sfc@ietf.org, 'Hui Deng' Subject: Re: [sfc] New Version Notification for draft-fu-sfc-topology-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 03:21:16 -0000 This is a multipart message in MIME format. --=_alternative 001262A548257E85_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 R29vZCBzdGFmZi4gSXQgaGVscHMgbWUgdW5kZXJzdGFuZCBob3cgdG8gZGVwbG95IFNGQyBzb2x1 dGlvbiBpbiBjdXJyZW50IA0KYWNjZXNzIG5ldHdvcmssIHdoaWxlIG90aGVyIHVzZWNhc2VzIG1h aW5seSBmb2N1cyBvbiBEQyBzY2VuYXJpb2VzLg0KDQpIZXJlIGFyZSBzb21lIHF1ZXN0aW9ucyB3 aGVuIEkgc2F3IHRoaXMgZHJhZnQsIHdvdWxkIHlvdSBwbGVhc2UgZXhwbGFpbiANCnRoZW0gZm9y IG1lIG1vcmUgY2xlYXJseT8NCg0KMS4gVGhlIFZDUEUgeW91IG1lbnRpb25lZCBpbiB0aGlzIGRy YWZ0IGlzIG5vdCB0aGUgdHJhZGl0aW9uYWwgQ3VzdG9tZXJzIA0KUHJlbWlzZSBFcXVpcG1lbnQg aW4gY3VzdG9tZXJzJyBob21lLCBpcyB0aGF0IHJpZ2h0Pw0KMi4gWW91ciBtYWluIHB1cnBvc2Ug b2YgdGhpcyBkcmFmdCBpcyB0byB0YWtlIGFkdmFudGFnZSBvZiB0aGUgVkNQRSANCnNvbHV0aW9u IHRvIGltcHJvdmUgdGhlIGZsZXhpYmlsaXR5IG9mIGN1cnJlbnQgUFROIG5ldHdvcmssIGlzIHRo YXQgcmlnaHQ/IA0KDQpBbmQgd291bGQgeW91IHBsZWFzZSBnaXZlIHNvbWUgbW9yZSBzcGVjaWZp YyB1c2UgY2FzZXMgdG8gaWxsdXN0cmF0ZSBob3cgDQp0aGUgVkNQRSBzb2x1dGlvbiBpbXByb3Zl IHRoZSBjdXJyZW50IFBUTiBuZXR3b3JrPyANCg0KVGhhbmtzIHZlcnkgbXVjaC4NCg0KQlJzLA0K TGluZGEgV2FuZyANCg0KDQoNCg0KDQoic2ZjIiA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+INC009og MjAxNS0wNy0wNiAxNjoxNDowNzoNCg0KPiBGdSBRaWFvIDxmdXFpYW8xQG91dGxvb2suY29tPiAN Cj4gt6K8/sjLOiAgInNmYyIgPHNmYy1ib3VuY2VzQGlldGYub3JnPg0KPiANCj4gMjAxNS0wNy0w NiAxNjoxNA0KPiANCj4gytW8/sjLDQo+IA0KPiA8c2ZjQGlldGYub3JnPiwgDQo+IA0KPiCzrcvN DQo+IA0KPiAiJ0pvZWwgTS4gSGFscGVybiciIDxqbWhAam9lbGhhbHBlcm4uY29tPiwgJ0h1aSBE ZW5nJyANCj4gPGRlbmdodWlAY2hpbmFtb2JpbGUuY29tPg0KPiANCj4g1vfM4g0KPiANCj4gW3Nm Y10g16q3ojogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1mdS1zZmMtdG9wb2xv Z3ktMDAudHh0DQo+IA0KPiBIaSwgYWxsLiBJIGhhdmUganVzdCBzdWJtaXR0ZWQgYSBkcmFmdCBh Ym91dCB0aGUgZGVwbG95bWVudCB0b3BvbG9neSBvZiANCnNmYy4NCj4gQ29tcGFyaW5nIHdpdGgg dGhlIGFyY2hpdGVjdHVyZSB3b3JrLCB0aGlzIHdvcmsgaW5jbHVkZXMgbW9yZSANCj4gZGV0YWls cyBhYm91dCBob3cgdG8gZGVwbG95IFNGQyBpbiB0aGUgbmV0d29yay4gQSB1c2VjYXNlIG9mIFZD UEUgDQo+IGRlcGxveW1lbnQsIHdoaWNoIGlzIGFuIGV4YW1wbGUgb2YgdXNlY2FzZSBvZiBTRkMg aW4gdGhlIGFjY2VzcyANCj4gbmV0d29yayBpcyBhbHNvIHByb3Bvc2VkIGluIG9yZGVyIHRvIGV4 cGxhaW4gdGhlIHRvcG9sb2d5IGFuZCANCj4gcmVsYXRlZCB0ZWNobm9sb2dpZXMgaW4gZGVwdGgu DQo+IFlvdXIgY29tbWVudHMgYXJlIG1vcmUgdGhhbiB3ZWxjb21lLiBUaGFuayB5b3UhDQo+IA0K PiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg W21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KPiC3osvNyrG85DogMjAxNcTqN9TC NsjVIDEwOjIxDQo+IMrVvP7IyzogUWlhbyBGdTsgSm9lbCBNLiBIYWxwZXJuOyBRaWFvIEZ1OyBK b2VsLiBIYWxwZXJuOyBIdWkgRGVuZzsgSHVpIA0KRGVuZw0KPiDW98ziOiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWZ1LXNmYy10b3BvbG9neS0wMC50eHQNCj4gDQo+IA0KPiBB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZnUtc2ZjLXRvcG9sb2d5LTAwLnR4dA0KPiBoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFFpYW8gRnUgYW5kIHBvc3RlZCB0byB0aGUN Cj4gSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZTogICAgICBkcmFmdC1mdS1zZmMtdG9wb2xv Z3kNCj4gUmV2aXNpb246ICAgMDANCj4gVGl0bGU6ICAgICAgVGhlIHRvcG9sb2d5IG9mIHNlcnZp Y2UgZnVuY3Rpb24gY2hhaW5pbmcNCj4gRG9jdW1lbnQgZGF0ZTogICAyMDE1LTA3LTA1DQo+IEdy b3VwOiAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQYWdlczogICAgICAxMA0KPiBVUkw6 ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWZ1 LXNmYy0NCj4gdG9wb2xvZ3ktMDAudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mdS1zZmMtdG9wb2xvZ3kvDQo+IEh0bWxpemVkOiAg ICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZnUtc2ZjLXRvcG9sb2d5LTAw DQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBkZXBs b3ltZW50IHRvcG9sb2d5IG9mIFNlcnZpY2UgRnVuY3Rpb24NCj4gICAgQ2hhaW5pbmcoU0ZDKS4g IFRoZSB0b3BvbG9neSBpcyBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIFNGQw0KPiAgICBhcmNoaXRl Y3R1cmUgaW4gW0ktRC5pZXRmLXNmYy1hcmNoaXRlY3R1cmVdLiAgQ3VycmVudGx5LCBzdWNoDQo+ ICAgIGFyY2hpdGVjdHVyZSBvbmx5IGluY2x1ZGVzIGFyY2hpdGVjdHVyYWwgY29uY2VwdHMsIHBy aW5jaXBsZXMsIGFuZA0KPiAgICBjb21wb25lbnRzIHVzZWQgaW4gdGhlIGNvbnN0cnVjdGlvbiBv ZiBjb21wb3NpdGUgc2VydmljZXMgdGhyb3VnaA0KPiAgICBkZXBsb3ltZW50IG9mIFNGQ3MsIHdp dGhvdXQgYW55IGluc3RydWN0aW9uIGZvciB0aGUgZmllbGQgZGVwbG95bWVudC4NCj4gICAgSXQg aXMgc3RpbGwgZGlmZmljdWx0IHRvIG1hcCBmcm9tIHRoZSBhcmNoaXRlY3R1cmUgdG8gYSByZWFs DQo+ICAgIGRlcGxveW1lbnQgb2YgU0ZDLiAgSW4gdGhpcyBkb2N1bWVudCwgd2UgcHJvcG9zZSB0 aGlzIHRvcG9sb2d5IHdoaWNoDQo+ICAgIHdpbGwgZ2l2ZSBpbnN0cnVjdGlvbnMgZm9yIHRoZSBm aWVsZCBkZXBsb3ltZW50cy4gIFdlIGZ1cnRoZXIgcHJvcG9zZQ0KPiAgICBhIFZDUEUgdXNlY2Fz ZSBvZiBTRkMgaW4gdGhlIHRyYW5zcG9ydCBuZXR3b3JrLCB3aGljaCBleHBsYWlucyB0aGUNCj4g ICAgZGV0YWlscyBvZiB0aGUgZGVwbG95bWVudCB0b3BvbG9neS4NCj4gDQo+ICANCj4gDQo+IA0K PiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZiANCnN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNl Y3JldGFyaWF0DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K --=_alternative 001262A548257E85_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdvb2Qgc3RhZmYuIEl0IGhlbHBzIG1lIHVu ZGVyc3RhbmQgaG93DQp0byBkZXBsb3kgU0ZDIHNvbHV0aW9uIGluIGN1cnJlbnQgYWNjZXNzIG5l dHdvcmssIHdoaWxlIG90aGVyIHVzZWNhc2VzDQptYWlubHkgZm9jdXMgb24gREMgc2NlbmFyaW9l cy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlcmUg YXJlIHNvbWUgcXVlc3Rpb25zIHdoZW4gSSBzYXcgdGhpcw0KZHJhZnQsIHdvdWxkIHlvdSBwbGVh c2UgZXhwbGFpbiB0aGVtIGZvciBtZSBtb3JlIGNsZWFybHk/PC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4xLiBUaGUgVkNQRSB5b3UgbWVudGlvbmVkIGlu IHRoaXMgZHJhZnQNCmlzIG5vdCB0aGUgdHJhZGl0aW9uYWwgQ3VzdG9tZXJzIFByZW1pc2UgRXF1 aXBtZW50IGluIGN1c3RvbWVycycgaG9tZSwNCmlzIHRoYXQgcmlnaHQ/PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4yLiBZb3VyIG1haW4gcHVycG9zZSBvZiB0aGlz IGRyYWZ0IGlzDQp0byB0YWtlIGFkdmFudGFnZSBvZiB0aGUgVkNQRSBzb2x1dGlvbiB0byBpbXBy b3ZlIHRoZSBmbGV4aWJpbGl0eSBvZiBjdXJyZW50DQpQVE4gbmV0d29yaywgaXMgdGhhdCByaWdo dD8gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BbmQgd291bGQg eW91IHBsZWFzZSBnaXZlIHNvbWUgbW9yZQ0Kc3BlY2lmaWMgdXNlIGNhc2VzIHRvIGlsbHVzdHJh dGUgaG93IHRoZSBWQ1BFIHNvbHV0aW9uIGltcHJvdmUgdGhlIGN1cnJlbnQNClBUTiBuZXR3b3Jr PyA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5r cyB2ZXJ5IG11Y2guPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5CUnMsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5MaW5k YSBXYW5nIDwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZxdW90O3NmYyZxdW90OyAmbHQ7c2ZjLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7INC0 09oNCjIwMTUtMDctMDYgMTY6MTQ6MDc6PGJyPg0KPGJyPg0KJmd0OyBGdSBRaWFvICZsdDtmdXFp YW8xQG91dGxvb2suY29tJmd0OyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgt6K8/sjLOiAmbmJzcDsmcXVvdDtzZmMmcXVvdDsgJmx0O3NmYy1ib3VuY2VzQGlldGYub3Jn Jmd0Ozxicj4NCiZndDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDIw MTUtMDctMDYgMTY6MTQ8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJy Pg0KJmd0OyDK1bz+yMs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJy Pg0KJmd0OyAmbHQ7c2ZjQGlldGYub3JnJmd0OywgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgs63LzTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZxdW90OydKb2VsIE0uIEhhbHBlcm4nJnF1b3Q7ICZsdDtq bWhAam9lbGhhbHBlcm4uY29tJmd0OywgJ0h1aSBEZW5nJw0KPGJyPg0KJmd0OyAmbHQ7ZGVuZ2h1 aUBjaGluYW1vYmlsZS5jb20mZ3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IDxicj4NCiZndDsg1vfM4jwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyA8YnI+DQomZ3Q7IFtzZmNdINeqt6I6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtZnUtc2ZjLXRvcG9sb2d5LTAwLnR4dDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyA8YnI+DQomZ3Q7IEhpLCBhbGwuIEkgaGF2ZSBqdXN0IHN1Ym1pdHRlZCBhIGRyYWZ0 IGFib3V0IHRoZSBkZXBsb3ltZW50IHRvcG9sb2d5DQpvZiBzZmMuPGJyPg0KJmd0OyBDb21wYXJp bmcgd2l0aCB0aGUgYXJjaGl0ZWN0dXJlIHdvcmssIHRoaXMgd29yayBpbmNsdWRlcyBtb3JlIDxi cj4NCiZndDsgZGV0YWlscyBhYm91dCBob3cgdG8gZGVwbG95IFNGQyBpbiB0aGUgbmV0d29yay4g QSB1c2VjYXNlIG9mIFZDUEUNCjxicj4NCiZndDsgZGVwbG95bWVudCwgd2hpY2ggaXMgYW4gZXhh bXBsZSBvZiB1c2VjYXNlIG9mIFNGQyBpbiB0aGUgYWNjZXNzIDxicj4NCiZndDsgbmV0d29yayBp cyBhbHNvIHByb3Bvc2VkIGluIG9yZGVyIHRvIGV4cGxhaW4gdGhlIHRvcG9sb2d5IGFuZCA8YnI+ DQomZ3Q7IHJlbGF0ZWQgdGVjaG5vbG9naWVzIGluIGRlcHRoLjxicj4NCiZndDsgWW91ciBjb21t ZW50cyBhcmUgbW9yZSB0aGFuIHdlbGNvbWUuIFRoYW5rIHlvdSE8YnI+DQomZ3Q7IDxicj4NCiZn dDsgLS0tLS3Tyrz+1K28/i0tLS0tPGJyPg0KJmd0OyC3orz+yMs6IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbPC9mb250PjwvdHQ+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyI+PHR0Pjxmb250IHNpemU9Mj5tYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9m b250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+XQ0KPGJyPg0KJmd0OyC3osvNyrG85DogMjAx NcTqN9TCNsjVIDEwOjIxPGJyPg0KJmd0OyDK1bz+yMs6IFFpYW8gRnU7IEpvZWwgTS4gSGFscGVy bjsgUWlhbyBGdTsgSm9lbC4gSGFscGVybjsgSHVpIERlbmc7DQpIdWkgRGVuZzxicj4NCiZndDsg 1vfM4jogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1mdS1zZmMtdG9wb2xvZ3kt MDAudHh0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWZ1LXNmYy10b3BvbG9neS0wMC50eHQ8YnI+DQomZ3Q7IGhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgUWlhbyBGdSBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCiZndDsg SUVURiByZXBvc2l0b3J5Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBOYW1lOiAmbmJzcDsgJm5ic3A7 ICZuYnNwO2RyYWZ0LWZ1LXNmYy10b3BvbG9neTxicj4NCiZndDsgUmV2aXNpb246ICZuYnNwOyAw MDxicj4NCiZndDsgVGl0bGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhlIHRvcG9sb2d5IG9mIHNl cnZpY2UgZnVuY3Rpb24gY2hhaW5pbmc8YnI+DQomZ3Q7IERvY3VtZW50IGRhdGU6ICZuYnNwOyAy MDE1LTA3LTA1PGJyPg0KJmd0OyBHcm91cDogJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRpdmlkdWFs IFN1Ym1pc3Npb248YnI+DQomZ3Q7IFBhZ2VzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOzEwPGJyPg0K Jmd0OyBVUkw6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250 PjwvdHQ+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LWZ1LXNmYy0iPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWZ1LXNmYy08L2ZvbnQ+PC90dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+ DQomZ3Q7IHRvcG9sb2d5LTAwLnR4dDxicj4NCiZndDsgU3RhdHVzOiAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgPC9mb250PjwvdHQ+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtZnUtc2ZjLXRvcG9sb2d5LyI+PHR0Pjxmb250IHNpemU9Mj5odHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mdS1zZmMtdG9wb2xvZ3kvPC9mb250Pjwv dHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyBIdG1saXplZDogJm5ic3A7ICZuYnNw OyAmbmJzcDsgPC9mb250PjwvdHQ+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWZ1LXNmYy10b3BvbG9neS0wMCI+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtZnUtc2ZjLXRvcG9sb2d5LTAwPC9mb250PjwvdHQ+PC9hPjx0 dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQWJzdHJhY3Q6 PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBwcm9wb3NlcyBhIGRlcGxveW1l bnQgdG9wb2xvZ3kgb2YgU2VydmljZQ0KRnVuY3Rpb248YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtD aGFpbmluZyhTRkMpLiAmbmJzcDtUaGUgdG9wb2xvZ3kgaXMgaW4gYWNjb3JkYW5jZSB3aXRoDQp0 aGUgU0ZDPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7YXJjaGl0ZWN0dXJlIGluIFtJLUQuaWV0Zi1z ZmMtYXJjaGl0ZWN0dXJlXS4gJm5ic3A7Q3VycmVudGx5LA0Kc3VjaDxicj4NCiZndDsgJm5ic3A7 ICZuYnNwO2FyY2hpdGVjdHVyZSBvbmx5IGluY2x1ZGVzIGFyY2hpdGVjdHVyYWwgY29uY2VwdHMs IHByaW5jaXBsZXMsDQphbmQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtjb21wb25lbnRzIHVzZWQg aW4gdGhlIGNvbnN0cnVjdGlvbiBvZiBjb21wb3NpdGUgc2VydmljZXMNCnRocm91Z2g8YnI+DQom Z3Q7ICZuYnNwOyAmbmJzcDtkZXBsb3ltZW50IG9mIFNGQ3MsIHdpdGhvdXQgYW55IGluc3RydWN0 aW9uIGZvciB0aGUgZmllbGQNCmRlcGxveW1lbnQuPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7SXQg aXMgc3RpbGwgZGlmZmljdWx0IHRvIG1hcCBmcm9tIHRoZSBhcmNoaXRlY3R1cmUgdG8NCmEgcmVh bDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2RlcGxveW1lbnQgb2YgU0ZDLiAmbmJzcDtJbiB0aGlz IGRvY3VtZW50LCB3ZSBwcm9wb3NlDQp0aGlzIHRvcG9sb2d5IHdoaWNoPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7d2lsbCBnaXZlIGluc3RydWN0aW9ucyBmb3IgdGhlIGZpZWxkIGRlcGxveW1lbnRz LiAmbmJzcDtXZQ0KZnVydGhlciBwcm9wb3NlPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7YSBWQ1BF IHVzZWNhc2Ugb2YgU0ZDIGluIHRoZSB0cmFuc3BvcnQgbmV0d29yaywgd2hpY2gNCmV4cGxhaW5z IHRoZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2RldGFpbHMgb2YgdGhlIGRlcGxveW1lbnQgdG9w b2xvZ3kuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgUGxlYXNl IG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUg b2YNCnN1Ym1pc3Npb248YnI+DQomZ3Q7IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFRoZSBJRVRGIFNlY3JldGFyaWF0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHNm YyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IHNmY0BpZXRmLm9yZzxicj4NCiZndDsgPC9mb250Pjwv dHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYz48dHQ+ PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9m b250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250PjwvdHQ+DQo= --=_alternative 001262A548257E85_=-- From nobody Sat Jul 18 03:45:19 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3431B2AB9 for ; Sat, 18 Jul 2015 03:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.94 X-Spam-Level: *** X-Spam-Status: No, score=3.94 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wssLTLhuHvls for ; Sat, 18 Jul 2015 03:45:15 -0700 (PDT) Received: from SNT004-OMC2S4.hotmail.com (snt004-omc2s4.hotmail.com [65.55.90.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB65E1B2ABA for ; Sat, 18 Jul 2015 03:45:14 -0700 (PDT) Received: from SNT146-DS19 ([65.55.90.73]) by SNT004-OMC2S4.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sat, 18 Jul 2015 03:45:13 -0700 X-TMN: [gXn25jNgDongwDz9cd9xnzGYE+GE0VpF] X-Originating-Email: [fuqiao1@outlook.com] Message-ID: From: Fu Qiao To: References: In-Reply-To: Date: Sat, 18 Jul 2015 18:45:08 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_018B_01D0C189.DEAACC00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdDAP5/J0MX0RdfsTLuiiC/O1OFC5wBBe9Yw Content-Language: zh-cn X-OriginalArrivalTime: 18 Jul 2015 10:45:13.0923 (UTC) FILETIME=[D3CFD930:01D0C146] Archived-At: Cc: "'Joel M. Halpern'" , sfc@ietf.org, 'Hui Deng' Subject: [sfc] =?gb2312?b?tPC4tDogIFJlOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g?= =?gb2312?b?Zm9yIGRyYWZ0LWZ1LXNmYy10b3BvbG9neS0wMC50eHQ=?= X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 10:45:18 -0000 ------=_NextPart_000_018B_01D0C189.DEAACC00 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi, Wang Cui. Thank you for your comments and questions. I try to answer them as follows. =20 =B7=A2=BC=FE=C8=CB: wang.cui1@zte.com.cn [mailto:wang.cui1@zte.com.cn]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA7=D4=C217=C8=D5 11:21 =CA=D5=BC=FE=C8=CB: Fu Qiao =B3=AD=CB=CD: 'Joel M. Halpern'; 'Hui Deng'; sfc@ietf.org =D6=F7=CC=E2: Re: [sfc] Re: New Version Notification for draft-fu-sfc-topology-00.txt =20 Good staff. It helps me understand how to deploy SFC solution in current access network, while other usecases mainly focus on DC scenarioes.=20 Here are some questions when I saw this draft, would you please explain = them for me more clearly?=20 1. The VCPE you mentioned in this draft is not the traditional Customers Premise Equipment in customers' home, is that right?=20 [fq] Yes, the concept of VCPE is to shift most of the complex functions = from the traditional CPE side to the network side. And since it is a usecase = of SFC in the access and mobile core network, I put it in this draft as an example for the deployment. 2. Your main purpose of this draft is to take advantage of the VCPE = solution to improve the flexibility of current PTN network, is that right?=20 [fq] The main purpose of the draft is to illustrate a deployable = topology of the SFC. I use VCPE as a usecase. Of cause details of the solution do = have the advantage of improving the flexibility of current PTN network as you concludeJ And would you please give some more specific use cases to illustrate how = the VCPE solution improve the current PTN network?=20 [fq] Since this draft is not intended to focus on VCPE topic, rather = than using it as an example for the deployment of SFC, so I do not put too = much contend and explanation about VCPE in it. I have another draft = specifically talking about the VCPE. https://datatracker.ietf.org/doc/draft-fu-dmm-vcpe-models/ You can look into this draft for more details about VCPE. Thanks very much.=20 BRs,=20 Linda Wang=20 "sfc" =D0=B4=D3=DA 2015-07-06 16:14:07: > Fu Qiao =20 > =B7=A2=BC=FE=C8=CB: "sfc" >=20 > 2015-07-06 16:14=20 >=20 > =CA=D5=BC=FE=C8=CB=20 >=20 > ,=20 >=20 > =B3=AD=CB=CD=20 >=20 > "'Joel M. Halpern'" , 'Hui Deng'=20 > =20 >=20 > =D6=F7=CC=E2=20 >=20 > [sfc] =D7=AA=B7=A2: New Version Notification for = draft-fu-sfc-topology-00.txt=20 >=20 > Hi, all. I have just submitted a draft about the deployment topology = of sfc. > Comparing with the architecture work, this work includes more=20 > details about how to deploy SFC in the network. A usecase of VCPE=20 > deployment, which is an example of usecase of SFC in the access=20 > network is also proposed in order to explain the topology and=20 > related technologies in depth. > Your comments are more than welcome. Thank you! >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: internet-drafts@ietf.org [ = mailto:internet-drafts@ietf.org]=20 > =B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA7=D4=C26=C8=D5 10:21 > =CA=D5=BC=FE=C8=CB: Qiao Fu; Joel M. Halpern; Qiao Fu; Joel. Halpern; = Hui Deng; Hui Deng > =D6=F7=CC=E2: New Version Notification for = draft-fu-sfc-topology-00.txt >=20 >=20 > A new version of I-D, draft-fu-sfc-topology-00.txt > has been successfully submitted by Qiao Fu and posted to the > IETF repository. >=20 > Name: draft-fu-sfc-topology > Revision: 00 > Title: The topology of service function chaining > Document date: 2015-07-05 > Group: Individual Submission > Pages: 10 > URL: https://www.ietf.org/internet-drafts/draft-fu-sfc- > topology-00.txt > Status: = https://datatracker.ietf.org/doc/draft-fu-sfc-topology/ > Htmlized: = https://tools.ietf.org/html/draft-fu-sfc-topology-00 >=20 >=20 > Abstract: > This document proposes a deployment topology of Service Function > Chaining(SFC). The topology is in accordance with the SFC > architecture in [I-D.ietf-sfc-architecture]. Currently, such > architecture only includes architectural concepts, principles, and > components used in the construction of composite services through > deployment of SFCs, without any instruction for the field = deployment. > It is still difficult to map from the architecture to a real > deployment of SFC. In this document, we propose this topology = which > will give instructions for the field deployments. We further = propose > a VCPE usecase of SFC in the transport network, which explains the > details of the deployment topology. >=20 > >=20 >=20 > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc ------=_NextPart_000_018B_01D0C189.DEAACC00 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi, Wang Cui. Thank you for your comments and questions. I try to = answer them as follows.

 

=B7=A2=BC=FE=C8=CB: wang.cui1@zte.com.cn = [mailto:wang.cui1@zte.com.cn]
=B7=A2=CB=CD=CA=B1=BC=E4: 2015=C4=EA7=D4=C217=C8=D5 = 11:21
=CA=D5=BC=FE=C8=CB: Fu = Qiao
=B3=AD=CB=CD: 'Joel M. Halpern'; 'Hui Deng'; = sfc@ietf.org
=D6=F7=CC=E2: Re: [sfc] Re: New Version = Notification for = draft-fu-sfc-topology-00.txt

 

Good staff. = It helps me understand how to deploy SFC solution in current access = network, while other usecases mainly focus on DC scenarioes.

Here are = some questions when I saw this draft, would you please explain them for = me more clearly?

1. The VCPE = you mentioned in this draft is not the traditional Customers Premise = Equipment in customers' home, is that right? =

[fq] Yes, the concept of VCPE is to shift most of the complex = functions from the traditional CPE side to the network side. And since = it is a usecase of SFC in the access and mobile core network, I put it = in this draft as an example for the deployment.


2. Your main = purpose of this draft is to take advantage of the VCPE solution to = improve the flexibility of current PTN network, is that right?

[fq] The main purpose of the draft is to illustrate a deployable = topology of the SFC. I use VCPE as a usecase. Of cause details of the = solution do have the advantage of improving the flexibility of current = PTN network as you concludeJ


And would = you please give some more specific use cases to illustrate how the VCPE = solution improve the current PTN network?

[fq] Since this draft is not intended to focus on VCPE topic, rather = than using it as an example for the deployment of SFC, so I do not put = too much contend and explanation about VCPE in it. I have another draft = specifically talking about the VCPE. = https= ://datatracker.ietf.org/doc/draft-fu-dmm-vcpe-models/

You can look into this draft for more details about = VCPE.



Thanks very = much.

BRs,
Linda Wang =





"sfc" = <sfc-bounces@ietf.org> =D0=B4=D3=DA 2015-07-06 = 16:14:07:

> Fu Qiao = <fuqiao1@outlook.com>
> =B7=A2=BC=FE=C8=CB: =  "sfc" = <sfc-bounces@ietf.org>
>
> 2015-07-06 16:14
>
> =CA=D5=BC=FE=C8=CB
>
> <sfc@ietf.org>, =
>
> =B3=AD=CB=CD =
> =
> = "'Joel M. Halpern'" <jmh@joelhalpern.com>, 'Hui Deng' =
> <denghui@chinamobile.com>
>
> =D6=F7=CC=E2 =
> =
> = [sfc] =D7=AA=B7=A2: New Version Notification for = draft-fu-sfc-topology-00.txt =
> =
> = Hi, all. I have just submitted a draft about the deployment topology of = sfc.
> Comparing with the architecture work, this work = includes more
> details about how to deploy SFC in the = network. A usecase of VCPE
> deployment, which is an = example of usecase of SFC in the access
> network is = also proposed in order to explain the topology and
> = related technologies in depth.
> Your comments are more = than welcome. Thank you!
>
> = -----=D3=CA=BC=FE=D4=AD=BC=FE-----
> =B7=A2=BC=FE=C8=CB: = internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] =
> = =B7=A2=CB=CD=CA=B1=BC=E4: = 2015=C4=EA7=D4=C26=C8=D5 = 10:21
> =CA=D5=BC=FE=C8=CB: Qiao = Fu; Joel M. Halpern; Qiao Fu; Joel. Halpern; Hui Deng; Hui = Deng
> =D6=F7=CC=E2: New Version = Notification for draft-fu-sfc-topology-00.txt
>
> =
> A new version of I-D, = draft-fu-sfc-topology-00.txt
> has been successfully = submitted by Qiao Fu and posted to the
> IETF = repository.
>
> Name:     =  draft-fu-sfc-topology
> Revision:   = 00
> Title:      The topology of service = function chaining
> Document date:   = 2015-07-05
> Group:      Individual = Submission
> Pages:     =  10
> URL:           =  https://www.ietf.org/internet-drafts/draft-fu-= sfc-
> topology-00.txt
> = Status:         https://datatracker.ietf.org/doc/draft-fu-sfc-= topology/
> Htmlized:       = https://tools.ietf.org/html/draft-fu-sfc-topol= ogy-00
>
> =
> Abstract:
>    This document = proposes a deployment topology of Service Function
> =    Chaining(SFC).  The topology is in accordance with the = SFC
>    architecture in = [I-D.ietf-sfc-architecture].  Currently, such
> =    architecture only includes architectural concepts, = principles, and
>    components used in the = construction of composite services through
>   =  deployment of SFCs, without any instruction for the field = deployment.
>    It is still difficult to map = from the architecture to a real
>    deployment = of SFC.  In this document, we propose this topology = which
>    will give instructions for the field = deployments.  We further propose
>    a = VCPE usecase of SFC in the transport network, which explains = the
>    details of the deployment = topology.
>
>         =                     =                     =                     =          
>
> =
> Please note that it may take a couple of minutes from = the time of submission
> until the htmlized version and = diff are available at tools.ietf.org.
>
> = The IETF Secretariat
>
> =
> = _______________________________________________
> sfc = mailing list
> sfc@ietf.org
> = https://www.ietf.org/mailman/listinfo/sfc

------=_NextPart_000_018B_01D0C189.DEAACC00-- From nobody Mon Jul 20 13:48:53 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B5F1B31C2; Mon, 20 Jul 2015 13:48:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OW2SfufSpsa; Mon, 20 Jul 2015 13:48:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA131B31BD; Mon, 20 Jul 2015 13:48:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150720204850.31438.50016.idtracker@ietfa.amsl.com> Date: Mon, 20 Jul 2015 13:48:50 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 20:48:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining Use Cases in Mobile Networks Authors : Walter Haeffner Jeffrey Napper Martin Stiemerling Diego R. Lopez Jim Uttaro Filename : draft-ietf-sfc-use-case-mobility-04.txt Pages : 26 Date : 2015-07-20 Abstract: This document provides some exemplary use cases for service function chaining in mobile service provider networks. The objective of this draft is not to cover all conceivable service chains in detail. Rather, the intention is to localize and explain the application domain of service chaining within mobile networks as far as it is required to complement the problem statement [RFC7498] and architecture framework [ietf-sfc-arch] of the working group. Service function chains typically reside in a LAN segment which links the mobile access network to the actual application platforms located in the carrier's datacenters or somewhere else in the Internet. Service function chains (SFC) ensure a fair distribution of network resources according to agreed service policies, enhance the performance of service delivery or take care of security and privacy. SFCs may also include Value Added Services (VAS). Commonly, SFCs are typical middle box based services. General considerations and specific use cases are presented in this document to demonstrate the different technical requirements of these goals for service function chaining in mobile service provider networks. The specification of service function chaining for mobile networks must take into account an interaction between service function chains and the 3GPP Policy and Charging Control (PCC) environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-use-case-mobility-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 20 13:51:50 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31EBD1B31C0 for ; Mon, 20 Jul 2015 13:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyRd10ba-684 for ; Mon, 20 Jul 2015 13:51:47 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6671B31BD for ; Mon, 20 Jul 2015 13:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3614; q=dns/txt; s=iport; t=1437425507; x=1438635107; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YP72WpM3XzCIq/2bgig9ICpb7cI/UyCxIJ/HGIjvyNo=; b=TPVp8G4mGVUB3el7gHTApUg7voRC9rmoRb9lOhburb2YbB/856Ht2S6+ KgyNzfQGb7RMv2DV6/i4FN6bzM+79Qn8dPHjSWb9hw+tdnjypq+FsJubI MOLCcSQFVPY6O8oHvjyytAj7y9jJpUeaUJ4TxPhtY2TUF3Btt4OZVZ7ST g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeAwDUXq1V/5RdJa1cgxNUaQa7aAmBawqGAQKBMDgUAQEBAQEBAYEKhCMBAQEEAQEBNy0HFwQCAQgRAQIBAhYJECcLFwYIAgQTiC4NyRUBAQEBAQEBAQIBAQEBAQEBARqLTIUNBgSEIQWUUgGEbocygUNGg1STKiaDfG+BR4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,510,1432598400"; d="scan'208";a="170615345" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP; 20 Jul 2015 20:51:46 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6KKpkH1008117 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 20 Jul 2015 20:51:46 GMT Received: from xmb-rcd-x12.cisco.com ([169.254.2.210]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 15:51:45 -0500 From: "Jeffrey Napper (jenapper)" To: "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt Thread-Index: AQHQwy2C/2vsJNVcNkiupisDzpkFOZ3lSsAA Date: Mon, 20 Jul 2015 20:51:45 +0000 Message-ID: References: <20150720204850.31438.50016.idtracker@ietfa.amsl.com> In-Reply-To: <20150720204850.31438.50016.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.212.151] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 20:51:49 -0000 The version 4 of the use case mobility draft (draft-ietf-sfc-use-case-mobility-04) differs from version 03 by a short note on recently discussed security issues with http header enrichment and a possible way out by using one-time, session-based keys. Also included a remark on the recent 3GPP work on service classifiers. The authors believe this revision is ready for WG last call. Cheers, Jeff -----Original Message----- From: sfc on behalf of "internet-drafts@ietf.org" Date: Monday, July 20, 2015 at 10:48 PM To: "i-d-announce@ietf.org" Cc: "sfc@ietf.org" Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Service Function Chaining Working Group >of the IETF. > > Title : Service Function Chaining Use Cases in Mobile >Networks > Authors : Walter Haeffner > Jeffrey Napper > Martin Stiemerling > Diego R. Lopez > Jim Uttaro > Filename : draft-ietf-sfc-use-case-mobility-04.txt > Pages : 26 > Date : 2015-07-20 > >Abstract: > This document provides some exemplary use cases for service function > chaining in mobile service provider networks. The objective of this > draft is not to cover all conceivable service chains in detail. > Rather, the intention is to localize and explain the application > domain of service chaining within mobile networks as far as it is > required to complement the problem statement [RFC7498] and > architecture framework [ietf-sfc-arch] of the working group. > > Service function chains typically reside in a LAN segment which links > the mobile access network to the actual application platforms located > in the carrier's datacenters or somewhere else in the Internet. > Service function chains (SFC) ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery or take care of security and privacy. > SFCs may also include Value Added Services (VAS). Commonly, SFCs are > typical middle box based services. > > General considerations and specific use cases are presented in this > document to demonstrate the different technical requirements of these > goals for service function chaining in mobile service provider > networks. > > The specification of service function chaining for mobile networks > must take into account an interaction between service function chains > and the 3GPP Policy and Charging Control (PCC) environment. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-04 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-use-case-mobility-04 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Jul 21 00:45:36 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B36C1AD289 for ; Tue, 21 Jul 2015 00:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEn4UsYMff3V for ; Tue, 21 Jul 2015 00:45:32 -0700 (PDT) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4E91AD277 for ; Tue, 21 Jul 2015 00:45:24 -0700 (PDT) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 3, 6978) id ; Tue, 21 Jul 2015 10:47:15 +0300 Received: from LION.ALLOT.LOCAL ([169.254.1.29]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Tue, 21 Jul 2015 10:47:15 +0300 From: Alla Goldner To: "Jeffrey Napper (jenapper)" , "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt Thread-Index: AQHQwy3C2BI+DdOLnEmdGdZdPdDMNp3koyCAgADoHxA= Date: Tue, 21 Jul 2015 07:47:14 +0000 Message-ID: References: <20150720204850.31438.50016.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.17.62] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 07:45:35 -0000 Dear Jeffrey, I reviewed the latest version of the document. Unfortunately, it includes many incorrect claims with regards to 3GPP rel= ated functionality, as well as recent work done by 3GPP is referenced inc= orrectly (as study has reached its conclusions and normative specificatio= n already in 3GPP, while this document discusses some of the solutions br= ought during the study phase). I can provide a more detailed comments, if I get editable document's vers= ion from you. Best Regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel =A0=A0 +972 9 761 9251 Cell =A0 +972 54 249 3985=20 agoldner@allot.com=20 www.allot.com=20 =A0 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jeffrey Napper (jena= pper) Sent: Monday, July 20, 2015 11:52 PM To: sfc@ietf.org Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt The version 4 of the use case mobility draft (draft-ietf-sfc-use-case-mobility-04) differs from version 03 by a short = note on recently discussed security issues with http header enrichment an= d a possible way out by using one-time, session-based keys. Also included= =20a remark on the recent 3GPP work on service classifiers. The authors believe this revision is ready for WG last call. Cheers, Jeff -----Original Message----- From: sfc on behalf of "internet-drafts@ietf.org" Date: Monday, July 20, 2015 at 10:48 PM To: "i-d-announce@ietf.org" Cc: "sfc@ietf.org" Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt > >A New Internet-Draft is available from the on-line Internet-Drafts=20 >directories. > This draft is a work item of the Service Function Chaining Working=20 >Group of the IETF. > > Title : Service Function Chaining Use Cases in Mobile >Networks > Authors : Walter Haeffner > Jeffrey Napper > Martin Stiemerling > Diego R. Lopez > Jim Uttaro > Filename : draft-ietf-sfc-use-case-mobility-04.txt > Pages : 26 > Date : 2015-07-20 > >Abstract: > This document provides some exemplary use cases for service function > chaining in mobile service provider networks. The objective of this > draft is not to cover all conceivable service chains in detail. > Rather, the intention is to localize and explain the application > domain of service chaining within mobile networks as far as it is > required to complement the problem statement [RFC7498] and > architecture framework [ietf-sfc-arch] of the working group. > > Service function chains typically reside in a LAN segment which links= > the mobile access network to the actual application platforms located= > in the carrier's datacenters or somewhere else in the Internet. > Service function chains (SFC) ensure a fair distribution of network > resources according to agreed service policies, enhance the > performance of service delivery or take care of security and privacy.= > SFCs may also include Value Added Services (VAS). Commonly, SFCs are= > typical middle box based services. > > General considerations and specific use cases are presented in this > document to demonstrate the different technical requirements of these= > goals for service function chaining in mobile service provider > networks. > > The specification of service function chaining for mobile networks > must take into account an interaction between service function chains= > and the 3GPP Policy and Charging Control (PCC) environment. > > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ > >There's also a htmlized version available at: >https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-04 > >A diff from the previous version is available at: >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-use-case-mobility-04 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### From nobody Tue Jul 21 01:22:35 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7931B2A15 for ; Tue, 21 Jul 2015 01:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2mkmpr4vgMi for ; Tue, 21 Jul 2015 01:22:23 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 777821B2A20 for ; Tue, 21 Jul 2015 01:22:22 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 0D0B61748120; Tue, 21 Jul 2015 17:22:22 +0900 (JST) X-Virus-Scanned: amavisd-new at kddilabs.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Z1VVlqW_WR4; Tue, 21 Jul 2015 17:22:20 +0900 (JST) Received: from fruits.mip.kddilabs.jp (unknown [IPv6:2001:200:601:401:2e0:81ff:fe28:594a]) by mandala.kddilabs.jp (Postfix) with ESMTP id EFE5C1748100; Tue, 21 Jul 2015 17:22:19 +0900 (JST) Received: from tea.mip.kddilabs.jp (tea.mip.kddilabs.jp [IPv6:2001:200:601:400::5]) by fruits.mip.kddilabs.jp (Postfix) with ESMTP id EC657EF471; Tue, 21 Jul 2015 17:22:19 +0900 (JST) Received: from [172.19.113.4] (ovb004.vpn.kddilabs.jp [172.19.113.4]) by tea.mip.kddilabs.jp (Postfix) with SMTP id CE3E595835; Tue, 21 Jul 2015 17:22:19 +0900 (JST) Date: Tue, 21 Jul 2015 17:22:21 +0900 From: Takeshi Usui To: Alla Goldner , "Jeffrey Napper (jenapper)" , "sfc@ietf.org" In-Reply-To: References: Message-Id: <20150721172221.2E10.972D78D2@kddilabs.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.68 [ja] (Unregistered) Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 08:22:30 -0000 Dear All, I agree with updating the usecase draft in order to fit the conclusion of 3GPP SA2. As Alla told, FMSS (Flexible Mobile Service Steering) in 3GPP SA2 concluded the architecture to report the policy information from PCRF. The architecture in 3GPP SA2 accepts the three solutions. The first assumes that PCEF executes the classification, and Gx is used as the interface from PCRF. The second assumes that TDF executes the classification and Sd is used. The third assumes that the new entity out of 3GPP scope receives the policy from the PCRF, and uses the interface which semantecs is the same with the Sd interface. The current draft describes only the first and second solutions. best regards, takeshi > Dear Jeffrey, > > I reviewed the latest version of the document. > > Unfortunately, it includes many incorrect claims with regards to 3GPP related functionality, as well as recent work done by 3GPP is referenced incorrectly (as study has reached its conclusions and normative specification already in 3GPP, while this document discusses some of the solutions brought during the study phase). > > I can provide a more detailed comments, if I get editable document's version from you. > > Best Regards, > > Alla Goldner > Director of Mobile Technologies and Standards > Allot Communications > Tel ?? +972 9 761 9251 > Cell ? +972 54 249 3985 > agoldner@allot.com > www.allot.com > > > > > > > > ? > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jeffrey Napper (jenapper) > Sent: Monday, July 20, 2015 11:52 PM > To: sfc@ietf.org > Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt > > > The version 4 of the use case mobility draft > (draft-ietf-sfc-use-case-mobility-04) differs from version 03 by a short note on recently discussed security issues with http header enrichment and a possible way out by using one-time, session-based keys. Also included a remark on the recent 3GPP work on service classifiers. > > > The authors believe this revision is ready for WG last call. > > Cheers, > Jeff > > > > -----Original Message----- > From: sfc on behalf of "internet-drafts@ietf.org" > > Date: Monday, July 20, 2015 at 10:48 PM > To: "i-d-announce@ietf.org" > Cc: "sfc@ietf.org" > Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > This draft is a work item of the Service Function Chaining Working > >Group of the IETF. > > > > Title : Service Function Chaining Use Cases in Mobile > >Networks > > Authors : Walter Haeffner > > Jeffrey Napper > > Martin Stiemerling > > Diego R. Lopez > > Jim Uttaro > > Filename : draft-ietf-sfc-use-case-mobility-04.txt > > Pages : 26 > > Date : 2015-07-20 > > > >Abstract: > > This document provides some exemplary use cases for service function > > chaining in mobile service provider networks. The objective of this > > draft is not to cover all conceivable service chains in detail. > > Rather, the intention is to localize and explain the application > > domain of service chaining within mobile networks as far as it is > > required to complement the problem statement [RFC7498] and > > architecture framework [ietf-sfc-arch] of the working group. > > > > Service function chains typically reside in a LAN segment which links > > the mobile access network to the actual application platforms located > > in the carrier's datacenters or somewhere else in the Internet. > > Service function chains (SFC) ensure a fair distribution of network > > resources according to agreed service policies, enhance the > > performance of service delivery or take care of security and privacy. > > SFCs may also include Value Added Services (VAS). Commonly, SFCs are > > typical middle box based services. > > > > General considerations and specific use cases are presented in this > > document to demonstrate the different technical requirements of these > > goals for service function chaining in mobile service provider > > networks. > > > > The specification of service function chaining for mobile networks > > must take into account an interaction between service function chains > > and the 3GPP Policy and Charging Control (PCC) environment. > > > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ > > > >There's also a htmlized version available at: > >https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-04 > > > >A diff from the previous version is available at: > >https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-use-case-mobility-04 > > > > > >Please note that it may take a couple of minutes from the time of > >submission until the htmlized version and diff are available at > >tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >sfc mailing list > >sfc@ietf.org > >https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > ############################################################################################## > This message is intended only for the designated recipient(s).It may contain confidential or proprietary information. > If you are not the designated recipient, you may not review, copy or distribute this message. > If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. > Thank you. > ############################################################################################## > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc -- Takeshi Usui From nobody Tue Jul 21 01:29:55 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9804C1B29EE for ; Tue, 21 Jul 2015 01:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gLA3yj1406X for ; Tue, 21 Jul 2015 01:29:49 -0700 (PDT) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id AD35A1B2AAB for ; Tue, 21 Jul 2015 01:29:46 -0700 (PDT) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 3, 6978) id ; Tue, 21 Jul 2015 11:31:37 +0300 Received: from LION.ALLOT.LOCAL ([169.254.1.29]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Tue, 21 Jul 2015 11:31:37 +0300 From: Alla Goldner To: Takeshi Usui , "Jeffrey Napper (jenapper)" , "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt Thread-Index: AQHQwy3C2BI+DdOLnEmdGdZdPdDMNp3koyCAgADoHxD//9WyAIAANyLw Date: Tue, 21 Jul 2015 08:31:37 +0000 Message-ID: References: <20150721171108.2E05.C088274E@kddi.com> In-Reply-To: <20150721171108.2E05.C088274E@kddi.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.17.62] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 08:29:52 -0000 Dear Takeshi, all, This is only one of inconsistencies and incorrect statements in this revi= sion. There are also others. I can volunteer to correct those, but I need edita= ble version of the document for this reason. Best Regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel =A0=A0 +972 9 761 9251 Cell =A0 +972 54 249 3985=20 agoldner@allot.com=20 www.allot.com=20 =A0 -----Original Message----- From: Takeshi Usui [mailto:ta-usui@kddi.com]=20 Sent: Tuesday, July 21, 2015 11:11 AM To: Alla Goldner; Jeffrey Napper (jenapper); sfc@ietf.org Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt Dear All, As Alla told, FMSS (Flexible Mobile Service Steering) in 3GPP SA2 conclud= ed the architecture to report the policy information from PCRF. I agree with updating the usecase draft in order to fit the conclusion of= =203GPP SA2. The architecture in 3GPP SA2 accepts the three solutions. The first assumes that PCEF executes the classification, and Gx is used a= s the interface from PCRF. The second assumes that TDF executes the classification and Sd is used. The third assumes that the new entity out of 3GPP scope receives the poli= cy from the PCRF, and uses the interface which semantecs is the same with= =20the Sd interface.=20 The current draft describes only the first and second solutions. > Dear Jeffrey, >=20 > I reviewed the latest version of the document. >=20 > Unfortunately, it includes many incorrect claims with regards to 3GPP r= elated functionality, as well as recent work done by 3GPP is referenced i= ncorrectly (as study has reached its conclusions and normative specificat= ion already in 3GPP, while this document discusses some of the solutions = brought during the study phase). >=20 > I can provide a more detailed comments, if I get editable document's ve= rsion from you. >=20 > Best Regards, >=20 > Alla Goldner > Director of Mobile Technologies and Standards Allot Communications Tel = > ?? +972 9 761 9251 Cell ? +972 54 249 3985 agoldner@allot.com=20 > www.allot.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ? >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jeffrey Napper=20 > (jenapper) > Sent: Monday, July 20, 2015 11:52 PM > To: sfc@ietf.org > Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt >=20 >=20 > The version 4 of the use case mobility draft > (draft-ietf-sfc-use-case-mobility-04) differs from version 03 by a shor= t note on recently discussed security issues with http header enrichment = and a possible way out by using one-time, session-based keys. Also includ= ed a remark on the recent 3GPP work on service classifiers. >=20 >=20 > The authors believe this revision is ready for WG last call. >=20 > Cheers, > Jeff >=20 >=20 >=20 > -----Original Message----- > From: sfc on behalf of "internet-drafts@ietf.org= " > > Date: Monday, July 20, 2015 at 10:48 PM > To: "i-d-announce@ietf.org" > Cc: "sfc@ietf.org" > Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt >=20 > > > >A New Internet-Draft is available from the on-line Internet-Drafts=20 > >directories. > > This draft is a work item of the Service Function Chaining Working=20 > >Group of the IETF. > > > > Title : Service Function Chaining Use Cases in Mobil= e > >Networks > > Authors : Walter Haeffner > > Jeffrey Napper > > Martin Stiemerling > > Diego R. Lopez > > Jim Uttaro > > Filename : draft-ietf-sfc-use-case-mobility-04.txt > > Pages : 26 > > Date : 2015-07-20 > > > >Abstract: > > This document provides some exemplary use cases for service functio= n > > chaining in mobile service provider networks. The objective of thi= s > > draft is not to cover all conceivable service chains in detail. > > Rather, the intention is to localize and explain the application > > domain of service chaining within mobile networks as far as it is > > required to complement the problem statement [RFC7498] and > > architecture framework [ietf-sfc-arch] of the working group. > > > > Service function chains typically reside in a LAN segment which lin= ks > > the mobile access network to the actual application platforms locat= ed > > in the carrier's datacenters or somewhere else in the Internet. > > Service function chains (SFC) ensure a fair distribution of network= > > resources according to agreed service policies, enhance the > > performance of service delivery or take care of security and privac= y. > > SFCs may also include Value Added Services (VAS). Commonly, SFCs a= re > > typical middle box based services. > > > > General considerations and specific use cases are presented in this= > > document to demonstrate the different technical requirements of the= se > > goals for service function chaining in mobile service provider > > networks. > > > > The specification of service function chaining for mobile networks > > must take into account an interaction between service function chai= ns > > and the 3GPP Policy and Charging Control (PCC) environment. > > > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ > > > >There's also a htmlized version available at: > >https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-04 > > > >A diff from the previous version is available at: > >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-use-case-mobility-0= 4 > > > > > >Please note that it may take a couple of minutes from the time of=20 > >submission until the htmlized version and diff are available at=20 > >tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >sfc mailing list > >sfc@ietf.org > >https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > ###################################################################### > ######################## This message is intended only for the=20 > designated recipient(s).It may contain confidential or proprietary info= rmation. > If you are not the designated recipient, you may not review, copy or di= stribute this message. > If you have mistakenly received this message, please notify the sender = by a reply e-mail and delete this message.=20 > Thank you. > ###################################################################### > ######################## >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc -- Takeshi Usui #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### From nobody Tue Jul 21 05:55:20 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FBB1A8831 for ; Tue, 21 Jul 2015 05:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUHTnaUHyL-P for ; Tue, 21 Jul 2015 05:55:11 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.119]) (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 D31F81A87F1 for ; Tue, 21 Jul 2015 05:55:09 -0700 (PDT) Received: from [193.109.255.99] by server-15.bemta-14.messagelabs.com id C5/3E-18947-B214EA55; Tue, 21 Jul 2015 12:55:07 +0000 X-Env-Sender: walter.haeffner@vodafone.com X-Msg-Ref: server-13.tower-48.messagelabs.com!1437483306!16486120!1 X-Originating-IP: [195.232.244.133] X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8437 invoked from network); 21 Jul 2015 12:55:07 -0000 Received: from mailout01.vodafone.com (HELO mailout01.vodafone.com) (195.232.244.133) by server-13.tower-48.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Jul 2015 12:55:07 -0000 Received: from mailint04.vodafone.com (mailint04.vodafone.com [195.232.244.201]) by mailout01.vodafone.com (Postfix) with ESMTP id 3mbKdk3L3kz1yG2; Tue, 21 Jul 2015 14:55:06 +0200 (CEST) Received: from mailint04.vodafone.com (localhost [127.0.0.1]) by mailint04.vodafone.com (Postfix) with ESMTP id 3mbKdk2LdrzfZGr; Tue, 21 Jul 2015 14:55:06 +0200 (CEST) Received: from VOEXC05W.internal.vodafone.com (voexc05w.dc-ratingen.de [145.230.101.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint04.vodafone.com (Postfix) with ESMTPS id 3mbKdk1wspzfZCZ; Tue, 21 Jul 2015 14:55:06 +0200 (CEST) Received: from VOEXC24W.internal.vodafone.com (145.230.103.196) by VOEXC05W.internal.vodafone.com (145.230.101.25) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 21 Jul 2015 14:55:05 +0200 Received: from VOEXM19W.internal.vodafone.com ([169.254.3.63]) by voexc24w ([145.230.103.196]) with mapi id 14.03.0224.002; Tue, 21 Jul 2015 14:55:05 +0200 From: "Haeffner, Walter, Vodafone DE" To: Alla Goldner , Takeshi Usui , "Jeff Napper" , "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt Thread-Index: AQHQwy2A0qCSS9dYSEatH4xGJRTqO53koyCAgADoHxD//9WyAIAANyLwgABKf4g= Date: Tue, 21 Jul 2015 12:55:05 +0000 Message-ID: References: <20150721171108.2E05.C088274E@kddi.com>, In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C8C844F84E550E43865561FAE104718570F6EAD6VOEXM19Winterna_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 12:55:16 -0000 --_000_C8C844F84E550E43865561FAE104718570F6EAD6VOEXM19Winterna_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi Alla, Which document you are asking for? Thanks for support and best regards, Walter Gesendet mit meinem HTC ----- Reply message ----- Von: "Alla Goldner" An: "Takeshi Usui" , "Jeffrey Napper (jenapper)" , "sfc@ietf.org" Betreff: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt Datum: Di., Jul 21, 2015 10:30 Dear Takeshi, all, This is only one of inconsistencies and incorrect statements in this revisi= on. There are also others. I can volunteer to correct those, but I need editabl= e version of the document for this reason. Best Regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 761 9251 Cell +972 54 249 3985 agoldner@allot.com www.allot.com -----Original Message----- From: Takeshi Usui [mailto:ta-usui@kddi.com] Sent: Tuesday, July 21, 2015 11:11 AM To: Alla Goldner; Jeffrey Napper (jenapper); sfc@ietf.org Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt Dear All, As Alla told, FMSS (Flexible Mobile Service Steering) in 3GPP SA2 concluded= the architecture to report the policy information from PCRF. I agree with updating the usecase draft in order to fit the conclusion of 3= GPP SA2. The architecture in 3GPP SA2 accepts the three solutions. The first assumes that PCEF executes the classification, and Gx is used as = the interface from PCRF. The second assumes that TDF executes the classification and Sd is used. The third assumes that the new entity out of 3GPP scope receives the policy= from the PCRF, and uses the interface which semantecs is the same with the= Sd interface. The current draft describes only the first and second solutions. > Dear Jeffrey, > > I reviewed the latest version of the document. > > Unfortunately, it includes many incorrect claims with regards to 3GPP rel= ated functionality, as well as recent work done by 3GPP is referenced incor= rectly (as study has reached its conclusions and normative specification al= ready in 3GPP, while this document discusses some of the solutions brought = during the study phase). > > I can provide a more detailed comments, if I get editable document's vers= ion from you. > > Best Regards, > > Alla Goldner > Director of Mobile Technologies and Standards Allot Communications Tel > ?? +972 9 761 9251 Cell ? +972 54 249 3985 agoldner@allot.com > www.allot.com > > > > > > > > ? > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jeffrey Napper > (jenapper) > Sent: Monday, July 20, 2015 11:52 PM > To: sfc@ietf.org > Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt > > > The version 4 of the use case mobility draft > (draft-ietf-sfc-use-case-mobility-04) differs from version 03 by a short = note on recently discussed security issues with http header enrichment and = a possible way out by using one-time, session-based keys. Also included a r= emark on the recent 3GPP work on service classifiers. > > > The authors believe this revision is ready for WG last call. > > Cheers, > Jeff > > > > -----Original Message----- > From: sfc on behalf of "internet-drafts@ietf.org" > > Date: Monday, July 20, 2015 at 10:48 PM > To: "i-d-announce@ietf.org" > Cc: "sfc@ietf.org" > Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > This draft is a work item of the Service Function Chaining Working > >Group of the IETF. > > > > Title : Service Function Chaining Use Cases in Mobile > >Networks > > Authors : Walter Haeffner > > Jeffrey Napper > > Martin Stiemerling > > Diego R. Lopez > > Jim Uttaro > > Filename : draft-ietf-sfc-use-case-mobility-04.txt > > Pages : 26 > > Date : 2015-07-20 > > > >Abstract: > > This document provides some exemplary use cases for service function > > chaining in mobile service provider networks. The objective of this > > draft is not to cover all conceivable service chains in detail. > > Rather, the intention is to localize and explain the application > > domain of service chaining within mobile networks as far as it is > > required to complement the problem statement [RFC7498] and > > architecture framework [ietf-sfc-arch] of the working group. > > > > Service function chains typically reside in a LAN segment which links > > the mobile access network to the actual application platforms located > > in the carrier's datacenters or somewhere else in the Internet. > > Service function chains (SFC) ensure a fair distribution of network > > resources according to agreed service policies, enhance the > > performance of service delivery or take care of security and privacy. > > SFCs may also include Value Added Services (VAS). Commonly, SFCs are > > typical middle box based services. > > > > General considerations and specific use cases are presented in this > > document to demonstrate the different technical requirements of these > > goals for service function chaining in mobile service provider > > networks. > > > > The specification of service function chaining for mobile networks > > must take into account an interaction between service function chains > > and the 3GPP Policy and Charging Control (PCC) environment. > > > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ > > > >There's also a htmlized version available at: > >https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-04 > > > >A diff from the previous version is available at: > >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-use-case-mobility-04 > > > > > >Please note that it may take a couple of minutes from the time of > >submission until the htmlized version and diff are available at > >tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >sfc mailing list > >sfc@ietf.org > >https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > ###################################################################### > ######################## This message is intended only for the > designated recipient(s).It may contain confidential or proprietary inform= ation. > If you are not the designated recipient, you may not review, copy or dist= ribute this message. > If you have mistakenly received this message, please notify the sender by= a reply e-mail and delete this message. > Thank you. > ###################################################################### > ######################## > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc -- Takeshi Usui ###########################################################################= ################### This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information. If you are not the designated recipient, you may not review, copy or distri= bute this message. If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message. Thank you. ###########################################################################= ################### _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_C8C844F84E550E43865561FAE104718570F6EAD6VOEXM19Winterna_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
Hi Alla,
Which document you are asking for?
Thanks for support and best regards,
Walter

Gesendet mit meinem HTC

----- Reply message -----
Von: "Alla Goldner" <agoldner@allot.com>
An: "Takeshi Usui" <ta-usui@kddi.com>, "Jeffrey Napper= (jenapper)" <jenapper@cisco.com>, "sfc@ietf.org" <= sfc@ietf.org>
Betreff: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt
Datum: Di., Jul 21, 2015 10:30

Dear Takeshi, all,

This is only one of inconsistencies and incorrect statements in this revisi= on.

There are also others. I can volunteer to correct those, but I need editabl= e version of the document for this reason.

Best Regards,

Alla Goldner
Director of Mobile Technologies and Standards
Allot Communications
Tel    +972 9 761 9251
Cell   +972 54 249 3985
agoldner@allot.com
www.allot.com







 



-----Original Message-----
From: Takeshi Usui [mailto:ta-usui@kddi= .com]
Sent: Tuesday, July 21, 2015 11:11 AM
To: Alla Goldner; Jeffrey Napper (jenapper); sfc@ietf.org
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt

Dear All,

As Alla told, FMSS (Flexible Mobile Service Steering) in 3GPP SA2 concluded= the architecture to report the policy information from PCRF.

I agree with updating the usecase draft in order to fit the conclusion of 3= GPP SA2.

The architecture in 3GPP SA2 accepts the three solutions.
The first assumes that PCEF executes the classification, and Gx is used as = the interface from PCRF.
The second assumes that TDF executes the classification and Sd is used.
The third assumes that the new entity out of 3GPP scope receives the policy= from the PCRF, and uses the interface which semantecs is the same with the= Sd interface.

The current draft describes only the first and second solutions.

> Dear Jeffrey,
>
> I reviewed the latest version of the document.
>
> Unfortunately, it includes many incorrect claims with regards to 3GPP = related functionality, as well as recent work done by 3GPP is referenced in= correctly (as study has reached its conclusions and normative specification= already in 3GPP, while this document discusses some of the solutions brought during the study phase).
>
> I can provide a more detailed comments, if I get editable document's v= ersion from you.
>
> Best Regards,
>
> Alla Goldner
> Director of Mobile Technologies and Standards Allot Communications Tel=
> ?? +972 9 761 9251 Cell ? +972 54 249 3985 agoldner@allot.com =
> www.allot.com
>
>
>
>
>
>
>
> ?
>
>
> -----Original Message-----
> From: sfc [mailto:sfc-bounces@= ietf.org] On Behalf Of Jeffrey Napper
> (jenapper)
> Sent: Monday, July 20, 2015 11:52 PM
> To: sfc@ietf.org
> Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt=
>
>
> The version 4 of the use case mobility draft
> (draft-ietf-sfc-use-case-mobility-04) differs from version 03 by a sho= rt note on recently discussed security issues with http header enrichment a= nd a possible way out by using one-time, session-based keys. Also included = a remark on the recent 3GPP work on service classifiers.
>
>
> The authors believe this revision is ready for WG last call.
>
> Cheers,
> Jeff
>
>
>
> -----Original Message-----
> From: sfc <sfc-bounces@ietf.org> on behalf of "internet-dra= fts@ietf.org"
> <internet-drafts@ietf.org>
> Date: Monday, July 20, 2015 at 10:48 PM
> To: "i-d-announce@ietf.org" <i-d-announce@ietf.org> > Cc: "sfc@ietf.org" <sfc@ietf.org>
> Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt
>
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts=
> >directories.
> > This draft is a work item of the Service Function Chaining Workin= g
> >Group of the IETF.
> >
> >        Title   =         : Service Function Chaining Use = Cases in Mobile
> >Networks
> >        Authors  &nbs= p;      : Walter Haeffner
> >           =             &nb= sp;  Jeffrey Napper
> >           =             &nb= sp;  Martin Stiemerling
> >           =             &nb= sp;  Diego R. Lopez
> >           =             &nb= sp;  Jim Uttaro
> >     Filename     &nb= sp;  : draft-ietf-sfc-use-case-mobility-04.txt
> >     Pages      =      : 26
> >     Date      &= nbsp;     : 2015-07-20
> >
> >Abstract:
> >   This document provides some exemplary use cases for s= ervice function
> >   chaining in mobile service provider networks.  T= he objective of this
> >   draft is not to cover all conceivable service chains = in detail.
> >   Rather, the intention is to localize and explain the = application
> >   domain of service chaining within mobile networks as = far as it is
> >   required to complement the problem statement [RFC7498= ] and
> >   architecture framework [ietf-sfc-arch] of the working= group.
> >
> >   Service function chains typically reside in a LAN seg= ment which links
> >   the mobile access network to the actual application p= latforms located
> >   in the carrier's datacenters or somewhere else in the= Internet.
> >   Service function chains (SFC) ensure a fair distribut= ion of network
> >   resources according to agreed service policies, enhan= ce the
> >   performance of service delivery or take care of secur= ity and privacy.
> >   SFCs may also include Value Added Services (VAS).&nbs= p; Commonly, SFCs are
> >   typical middle box based services.
> >
> >   General considerations and specific use cases are pre= sented in this
> >   document to demonstrate the different technical requi= rements of these
> >   goals for service function chaining in mobile service= provider
> >   networks.
> >
> >   The specification of service function chaining for mo= bile networks
> >   must take into account an interaction between service= function chains
> >   and the 3GPP Policy and Charging Control (PCC) enviro= nment.
> >
> >
> >
> >The IETF datatracker status page for this draft is:
> >https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobil= ity/
> >
> >There's also a htmlized version available at:
> >https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-04
> >
> >A diff from the previous version is available at:
> >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-use-ca= se-mobility-04
> >
> >
> >Please note that it may take a couple of minutes from the time of =
> >submission until the htmlized version and diff are available at > >tools.ietf.org.
> >
> >Internet-Drafts are also available by anonymous FTP at:
> >ftp://ftp.ietf.org= /internet-drafts/
> >
> >_______________________________________________
> >sfc mailing list
> >sfc@ietf.org
> >https://www.= ietf.org/mailman/listinfo/sfc
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf= .org/mailman/listinfo/sfc
> ######################################################################=
> ######################## This message is intended only for the
> designated recipient(s).It may contain confidential or proprietary inf= ormation.
> If you are not the designated recipient, you may not review, copy or d= istribute this message.
> If you have mistakenly received this message, please notify the sender= by a reply e-mail and delete this message.
> Thank you.
> ######################################################################=
> ########################
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf= .org/mailman/listinfo/sfc

--
Takeshi Usui <ta-usui@kddilabs.jp>

###########################################################################= ###################
This message is intended only for the designated recipient(s).It may contai= n confidential or proprietary information.
If you are not the designated recipient, you may not review, copy or distri= bute this message.
If you have mistakenly received this message, please notify the sender by a= reply e-mail and delete this message.
Thank you.
###########################################################################= ###################

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/= mailman/listinfo/sfc
 --_000_C8C844F84E550E43865561FAE104718570F6EAD6VOEXM19Winterna_-- From nobody Tue Jul 21 06:42:32 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358BB1B2DE5 for ; Tue, 21 Jul 2015 06:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxsESi-Bv3hm for ; Tue, 21 Jul 2015 06:42:16 -0700 (PDT) Received: from mailgw.allot.com (mailgw.allot.com [199.203.223.210]) by ietfa.amsl.com (Postfix) with ESMTP id 4611F1B2DDB for ; Tue, 21 Jul 2015 06:41:52 -0700 (PDT) Received: from PUMA.ALLOT.LOCAL (Not Verified[199.203.223.202]) by mailgw.allot.com with MailMarshal (v7, 2, 3, 6978) id ; Tue, 21 Jul 2015 16:43:38 +0300 Received: from LION.ALLOT.LOCAL ([169.254.1.29]) by PUMA.ALLOT.LOCAL ([199.203.223.202]) with mapi id 14.03.0123.003; Tue, 21 Jul 2015 16:43:37 +0300 From: Alla Goldner To: "Haeffner, Walter, Vodafone DE" , "Takeshi Usui" , Jeff Napper , "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt Thread-Index: AQHQwy3C2BI+DdOLnEmdGdZdPdDMNp3koyCAgADoHxD//9WyAIAANyLwgAAYNICAAD82YA== Date: Tue, 21 Jul 2015 13:43:37 +0000 Message-ID: References: <20150721171108.2E05.C088274E@kddi.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [5.29.252.71] Content-Type: multipart/related; boundary="_009_A6B8F2A767638641889989BC1BA704795F96544ALIONALLOTLOCAL_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 13:42:21 -0000 --_009_A6B8F2A767638641889989BC1BA704795F96544ALIONALLOTLOCAL_ Content-Type: multipart/alternative; boundary="_000_A6B8F2A767638641889989BC1BA704795F96544ALIONALLOTLOCAL_" --_000_A6B8F2A767638641889989BC1BA704795F96544ALIONALLOTLOCAL_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am talking about the latest revision. Best regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 761 9251 Cell +972 54 249 3985 agoldner@allot.com www.allot.com [http://idudi.co.il/projects/allot/signature/images/linkedin.png] [http://idudi.co.il/projects/allot/signature/images/facebook.png] [http://idudi.co.il/projects/allot/signature/images/youtube.png] [http://idudi.co.il/projects/allot/signature/images/twitter.png] [http://idudi.co.il/projects/allot/signature/images/blog.png] [http://idudi.co.il/projects/allot/signature/images/gplus.png] From: Haeffner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com]= Sent: Tuesday, July 21, 2015 3:55 PM To: Alla Goldner; Takeshi Usui; Jeff Napper; sfc@ietf.org Subject: AW: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt Hi Alla, Which document you are asking for? Thanks for support and best regards, Walter Gesendet mit meinem HTC ----- Reply message ----- Von: "Alla Goldner" > An: "Takeshi Usui" >, "Jeffrey = Napper (jenapper)" >, "sfc@= ietf.org" > Betreff: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt Datum: Di., Jul 21, 2015 10:30 Dear Takeshi, all, This is only one of inconsistencies and incorrect statements in this revi= sion. There are also others. I can volunteer to correct those, but I need edita= ble version of the document for this reason. Best Regards, Alla Goldner Director of Mobile Technologies and Standards Allot Communications Tel +972 9 761 9251 Cell +972 54 249 3985 agoldner@allot.com www.allot.com -----Original Message----- From: Takeshi Usui [mailto:ta-usui@kddi.com] Sent: Tuesday, July 21, 2015 11:11 AM To: Alla Goldner; Jeffrey Napper (jenapper); sfc@ietf.org Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt Dear All, As Alla told, FMSS (Flexible Mobile Service Steering) in 3GPP SA2 conclud= ed the architecture to report the policy information from PCRF. I agree with updating the usecase draft in order to fit the conclusion of= =203GPP SA2. The architecture in 3GPP SA2 accepts the three solutions. The first assumes that PCEF executes the classification, and Gx is used a= s the interface from PCRF. The second assumes that TDF executes the classification and Sd is used. The third assumes that the new entity out of 3GPP scope receives the poli= cy from the PCRF, and uses the interface which semantecs is the same with= =20the Sd interface. The current draft describes only the first and second solutions. > Dear Jeffrey, > > I reviewed the latest version of the document. > > Unfortunately, it includes many incorrect claims with regards to 3GPP r= elated functionality, as well as recent work done by 3GPP is referenced i= ncorrectly (as study has reached its conclusions and normative specificat= ion already in 3GPP, while this document discusses some of the solutions = brought during the study phase). > > I can provide a more detailed comments, if I get editable document's ve= rsion from you. > > Best Regards, > > Alla Goldner > Director of Mobile Technologies and Standards Allot Communications Tel > ?? +972 9 761 9251 Cell ? +972 54 249 3985 agoldner@allot.com > www.allot.com > > > > > > > > ? > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jeffrey Napper > (jenapper) > Sent: Monday, July 20, 2015 11:52 PM > To: sfc@ietf.org > Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt > > > The version 4 of the use case mobility draft > (draft-ietf-sfc-use-case-mobility-04) differs from version 03 by a shor= t note on recently discussed security issues with http header enrichment = and a possible way out by using one-time, session-based keys. Also includ= ed a remark on the recent 3GPP work on service classifiers. > > > The authors believe this revision is ready for WG last call. > > Cheers, > Jeff > > > > -----Original Message----- > From: sfc > on behalf= =20of "internet-drafts@ietf.org" > > > Date: Monday, July 20, 2015 at 10:48 PM > To: "i-d-announce@ietf.org" > > Cc: "sfc@ietf.org" > > Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt > > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > This draft is a work item of the Service Function Chaining Working > >Group of the IETF. > > > > Title : Service Function Chaining Use Cases in Mobil= e > >Networks > > Authors : Walter Haeffner > > Jeffrey Napper > > Martin Stiemerling > > Diego R. Lopez > > Jim Uttaro > > Filename : draft-ietf-sfc-use-case-mobility-04.txt > > Pages : 26 > > Date : 2015-07-20 > > > >Abstract: > > This document provides some exemplary use cases for service functio= n > > chaining in mobile service provider networks. The objective of thi= s > > draft is not to cover all conceivable service chains in detail. > > Rather, the intention is to localize and explain the application > > domain of service chaining within mobile networks as far as it is > > required to complement the problem statement [RFC7498] and > > architecture framework [ietf-sfc-arch] of the working group. > > > > Service function chains typically reside in a LAN segment which lin= ks > > the mobile access network to the actual application platforms locat= ed > > in the carrier's datacenters or somewhere else in the Internet. > > Service function chains (SFC) ensure a fair distribution of network= > > resources according to agreed service policies, enhance the > > performance of service delivery or take care of security and privac= y. > > SFCs may also include Value Added Services (VAS). Commonly, SFCs a= re > > typical middle box based services. > > > > General considerations and specific use cases are presented in this= > > document to demonstrate the different technical requirements of the= se > > goals for service function chaining in mobile service provider > > networks. > > > > The specification of service function chaining for mobile networks > > must take into account an interaction between service function chai= ns > > and the 3GPP Policy and Charging Control (PCC) environment. > > > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/ > > > >There's also a htmlized version available at: > >https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-04 > > > >A diff from the previous version is available at: > >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-use-case-mobility-0= 4 > > > > > >Please note that it may take a couple of minutes from the time of > >submission until the htmlized version and diff are available at > >tools.ietf.org. > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > >_______________________________________________ > >sfc mailing list > >sfc@ietf.org > >https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > ###################################################################### > ######################## This message is intended only for the > designated recipient(s).It may contain confidential or proprietary info= rmation. > If you are not the designated recipient, you may not review, copy or di= stribute this message. > If you have mistakenly received this message, please notify the sender = by a reply e-mail and delete this message. > Thank you. > ###################################################################### > ######################## > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc -- Takeshi Usui > #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message. Thank you. #########################################################################= ##################### _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc #########################################################################= ##################### This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information. If you are not the designated recipient, you may not review, copy or dist= ribute this message. If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.=20 Thank you. #########################################################################= ##################### --_000_A6B8F2A767638641889989BC1BA704795F96544ALIONALLOTLOCAL_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =

Hi,=

 

I am talking about th= e latest revision.

 

Best regards,

 

Alla Goldner

 

Director of Mobile Technologies and Standards=

Allot Communications

 

Tel    +972 9 761 9251<= /span>

 

Cell   +972 54 249 3985=

 

agoldner@allot.com <= /span>

 

www.allot.com

 

3D"http://idudi.co.il/=

=3D"http://idudi.co.il/projects/allot/signature/images/facebook.png"

3D"http:=

3D"http://idud=

3D"http://idudi.co.il/=

3D"http://idudi.co.il/projects/allot/signature/images/gplus.pn=

 

 

 

 

From: Ha= effner, Walter, Vodafone DE [mailto:walter.haeffner@vodafone.com]
Sent: Tuesday, July 21, 2015 3:55 PM
To: Alla Goldner; Takeshi Usui; Jeff Napper; sfc@ietf.org
Subject: AW: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04= .txt

 

Hi Alla,

Which document you are asking for?=

Thanks for support and best regards,

Walter

 

Gesendet mit meinem HTC

 

----- Reply message -----
Von: "Alla Goldner" <a= goldner@allot.com>
An: "Takeshi Usui" <ta-u= sui@kddi.com>, "Jeffrey Napper (jenapper)" <jenapper@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>
Betreff: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt
Datum: Di., Jul 21, 2015 10:30

 

Dear Takeshi, all= ,

This is only one of inconsistencies and incorrect statements in this revi= sion.

There are also others. I can volunteer to correct those, but I need edita= ble version of the document for this reason.

Best Regards,

Alla Goldner
Director of Mobile Technologies and Standards
Allot Communications
Tel    +972 9 761 9251
Cell   +972 54 249 3985
agoldner@allot.com
www.allot.com







 



-----Original Message-----
From: Takeshi Usui [mailto:ta-usui@kd= di.com]
Sent: Tuesday, July 21, 2015 11:11 AM
To: Alla Goldner; Jeffrey Napper (jenapper); sfc@ietf.org
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt
Dear All,

As Alla told, FMSS (Flexible Mobile Service Steering) in 3GPP SA2 conclud= ed the architecture to report the policy information from PCRF.

I agree with updating the usecase draft in order to fit the conclusion of= =203GPP SA2.

The architecture in 3GPP SA2 accepts the three solutions.
The first assumes that PCEF executes the classification, and Gx is used a= s the interface from PCRF.
The second assumes that TDF executes the classification and Sd is used. The third assumes that the new entity out of 3GPP scope receives the poli= cy from the PCRF, and uses the interface which semantecs is the same with= =20the Sd interface.

The current draft describes only the first and second solutions.

> Dear Jeffrey,
>
> I reviewed the latest version of the document.
>
> Unfortunately, it includes many incorrect claims with regards to 3GP= P related functionality, as well as recent work done by 3GPP is reference= d incorrectly (as study has reached its conclusions and normative specifi= cation already in 3GPP, while this document =20discusses some of the solutions brought during the study phase).
>
> I can provide a more detailed comments, if I get editable document's= =20version from you.
>
> Best Regards,
>
> Alla Goldner
> Director of Mobile Technologies and Standards Allot Communications T= el
> ?? +972 9 761 9251 Cell ? +972 54 249 3985 agoldner@allot.com
> www.allot.com
>
>
>
>
>
>
>
> ?
>
>
> -----Original Message-----
> From: sfc [mailto:sfc-bounce= s@ietf.org] On Behalf Of Jeffrey Napper
> (jenapper)
> Sent: Monday, July 20, 2015 11:52 PM
> To: sfc@ietf.org
> Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.t= xt
>
>
> The version 4 of the use case mobility draft
> (draft-ietf-sfc-use-case-mobility-04) differs from version 03 by a s= hort note on recently discussed security issues with http header enrichme= nt and a possible way out by using one-time, session-based keys. Also inc= luded a remark on the recent 3GPP work on =20service classifiers.
>
>
> The authors believe this revision is ready for WG last call.
>
> Cheers,
> Jeff
>
>
>
> -----Original Message-----
> From: sfc <sfc-bounces@ie= tf.org> on behalf of "internet-drafts@ietf.org"
> <internet-drafts@ietf= .org>
> Date: Monday, July 20, 2015 at 10:48 PM
> To: "i-d-announce@ietf= .org" <i-d-announce@= ietf.org>
> Cc: "sfc@ietf.org" <= ;sfc@ietf.org>
> Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt >
> >
> >A New Internet-Draft is available from the on-line Internet-Draf= ts
> >directories.
> > This draft is a work item of the Service Function Chaining Work= ing
> >Group of the IETF.
> >
> >        Title  &nbs= p;        : Service Function Chaining = Use Cases in Mobile
> >Networks
> >        Authors  &n= bsp;      : Walter Haeffner
> >          &nbs= p;            = ;   Jeffrey Napper
> >          &nbs= p;            = ;   Martin Stiemerling
> >          &nbs= p;            = ;   Diego R. Lopez
> >          &nbs= p;            = ;   Jim Uttaro
> >     Filename     &= nbsp;  : draft-ietf-sfc-use-case-mobility-04.txt
> >     Pages     &nbs= p;     : 26
> >     Date      = ;      : 2015-07-20
> >
> >Abstract:
> >   This document provides some exemplary use cases for= =20service function
> >   chaining in mobile service provider networks. = =20The objective of this
> >   draft is not to cover all conceivable service chain= s in detail.
> >   Rather, the intention is to localize and explain th= e application
> >   domain of service chaining within mobile networks a= s far as it is
> >   required to complement the problem statement [RFC74= 98] and
> >   architecture framework [ietf-sfc-arch] of the worki= ng group.
> >
> >   Service function chains typically reside in a LAN s= egment which links
> >   the mobile access network to the actual application= =20platforms located
> >   in the carrier's datacenters or somewhere else in t= he Internet.
> >   Service function chains (SFC) ensure a fair distrib= ution of network
> >   resources according to agreed service policies, enh= ance the
> >   performance of service delivery or take care of sec= urity and privacy.
> >   SFCs may also include Value Added Services (VAS).&n= bsp; Commonly, SFCs are
> >   typical middle box based services.
> >
> >   General considerations and specific use cases are p= resented in this
> >   document to demonstrate the different technical req= uirements of these
> >   goals for service function chaining in mobile servi= ce provider
> >   networks.
> >
> >   The specification of service function chaining for = mobile networks
> >   must take into account an interaction between servi= ce function chains
> >   and the 3GPP Policy and Charging Control (PCC) envi= ronment.
> >
> >
> >
> >The IETF datatracker status page for this draft is:
> >https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-m= obility/
> >
> >There's also a htmlized version available at:
> >https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-= 04
> >
> >A diff from the previous version is available at:
> >https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-us= e-case-mobility-04
> >
> >
> >Please note that it may take a couple of minutes from the time o= f
> >submission until the htmlized version and diff are available at =
> >tools.ietf.org.
> >
> >Internet-Drafts are also available by anonymous FTP at:
> >ftp://ftp.ietf.o= rg/internet-drafts/
> >
> >_______________________________________________
> >sfc mailing list
> >sfc@ietf.org
> >https://ww= w.ietf.org/mailman/listinfo/sfc
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ie= tf.org/mailman/listinfo/sfc
> ####################################################################= ##
> ######################## This message is intended only for the
> designated recipient(s).It may contain confidential or proprietary i= nformation.
> If you are not the designated recipient, you may not review, copy or= =20distribute this message.
> If you have mistakenly received this message, please notify the send= er by a reply e-mail and delete this message.
> Thank you.
> ####################################################################= ##
> ########################
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ie= tf.org/mailman/listinfo/sfc

--
Takeshi Usui <ta-usui@kddilabs.= jp>

#########################################################################= #####################
This message is intended only for the designated recipient(s).It may cont= ain confidential or proprietary information.
If you are not the designated recipient, you may not review, copy or dist= ribute this message.
If you have mistakenly received this message, please notify the sender by= =20a reply e-mail and delete this message.
Thank you.
#########################################################################= #####################

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.or= g/mailman/listinfo/sfc

This message is intended only for the designated recipient(s). It may con= tain=20 confidential or proprietary information. If you are not the designated=20 recipient, you may not review, copy or distribute this message. If you ha= ve=20 mistakenly received this message, please notify the sender by a reply e-m= ail and=20 delete this message. Thank you.

--_000_A6B8F2A767638641889989BC1BA704795F96544ALIONALLOTLOCAL_-- --_009_A6B8F2A767638641889989BC1BA704795F96544ALIONALLOTLOCAL_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=1543; creation-date="Tue, 21 Jul 2015 13:43:37 GMT"; modification-date="Tue, 21 Jul 2015 13:43:37 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAB8AAAAaCAIAAADAARDdAAAFzklEQVRIDY1VW2xURRiembPdttRt d0urdGPZ0ipyEWgTqgShAROpjQ8iiQmRRKP4QEANPhj1zSgmPhCNCYkxapTgC5rYAqY+CA2SqARs wYi92PS22lKg0LOldNvdMzN+35wlvGDidHM6Z+a/ft///0daq4VVWgpPGCGUwNMqK8X03Hzn4I32 PydH/IWR6zN+zqyqKisr9p54oHr7qurmZAXEhIRKqOAJia17o5HCRhprpRW448MK2L2ZzR84M3jo 18tZnZPaWgUrnrCBcCIUFbYxGfuodfWWhoS1eDdWKjxdcILhQggqeNK682SUVtY7NXJ959GLU3M5 ZY2RLgoLNYTGFCFg1IIQEWGUVPrZh2u+2rGupAhWmK4hAHcWnEjnSoWBf3Iuva+zz2q84cclZeiF WTG0QlwKkMAWtJtrEh0vNCYXlTiUwmhCTT5DjIjJ8YFre0/0lkdV1+5H7IHWD59ajZylMQ40Zxzh SZhEKBbLRWDOT/jPHOmeB1mOMwYFz0CExgEHpKwenJ7ddfQCdF9sWrJ1WSVAeH3D0nU1FS5ZCfQB jjKAq4A+JKXzBOXz47OvHPud8AqiDzf4hTQooA0G3vxhYDafs0YN+XkhAsYrxUw2jw3wJrEKNHig j8VhAkO+aI9oGX34wuTFiUz4DhjwC1FR0gt+SfvtfVfBGM5O9F3e3zl8rP/Kjq97RjK3hMEhMrVC W4Ito+RKgUfERGwUspMqEObtkwPOegGZcB+BwOe/pXFGWWmeb0qinK3Nv/bY0tHM/NrkPbsbazVC tqZ7MhNfVJwoUT2Tt450Xx71b8KEYZxSGXFycPr6vKksASZIB6mzbyJGqPbeScoBAxlpqCjfUpfA NVaiZKi+orQlFQeMgbAtDeWsRSu2rxTvbk299N2lL3ugCC0kYADat3+k96yvgyJMI1L6+efGnJ/V Eq6Qrw2M5wzzmkGhH0ESHEfYFSwwYsRn5IsdaxkHFvoBqEpxdnSGqQAqQoGHAI1ZoSLsGJBnPQ8b LsDqrtFhgk3kfNI6OoZ94973b0yhlryw6aQAT244gG9whKLVKhsgStQGbaEq0F0uGEZuROAamvWL +47eK/UHuxLvnxqeXuCJUC0Ni6GlZU4BH2NnF1BfSJCmWLBoxajrU3DPI5GHINiwYSeCS5EL0QFH H58dS/s5fz4/7s9BBnAlokUoUpBhOCpEabTYWWZmBBJJpyoWMV2D9Gk+hACXcMA/HvMCc8Q1KKIz GiOGleEZqTUqFpaQsbF1FWAO2wL01FpWVVZZChFWEHhGXnRMoAg9asWBFoIDGcRI9N24pgPn2mkr uzkVhyOC6AKl9SJpNtVX0TkMWnIBmw4Zg7pFbeEFFGj2jS7S8A6iOT+w3ASkGuygbJ58aDEi89zn wanwVO1Zn0QhOPw9oTxqUl8FLCK2BpBFsBFt8x4giaDXIIdzTlxWAWAyzffHlsZjLESOdA4/gEyG 2x6s3lxbjoKhqEF4REdZGNIqQB8AMw53wO104ZQzIwBO/GHLuvlg2wp8AviGLnJfHLjFJOA62LZm w6c/4+b0aMZ2DQIO0JjOZH8a8985PczyE2JsOgc3ykYOd6fPDE0ZVaRcIwGMp1dUP75sMZyFiUCY ZpFI+PUATIfOpl/9vpfHRJqlwA5Ed4UqNlCoPBzzFWFgOBiWpVB1VcUX9myKlUTDLzOZK5SG63RK C7Xv0dQbm+qhBtJAL6yzcjRy53/wwf7BFMAeGWiYBqyiJl7W+dzGeHHU5cFyonT4B4wQe6FMoGXV Z+f+3tvZp2EdHCAINCGN3F7kjzXHZWxzbbxjV9OSWBFkwpwJqUMFr7CB4UZh7hRyxpXuvzr31o/9 xwemnBj7yMFOdWTMeShFotR7r3X5y02pYg4m5572YIAMOXjdg611t9Uz4bf3Xvvm0vhfU1migWUl sN1WX7lzTbJt+b1x9uBt03ezgDP2939c3TnOLAQTfnblfbE7R/9v9y8mlQiUNPljIwAAAABJRU5E rkJggg== --_009_A6B8F2A767638641889989BC1BA704795F96544ALIONALLOTLOCAL_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=1543; creation-date="Tue, 21 Jul 2015 13:43:37 GMT"; modification-date="Tue, 21 Jul 2015 13:43:37 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAB8AAAAaCAIAAADAARDdAAAFzklEQVRIDXWWW4hWVRiG11p7/zrm JKMzHkYdz1oz4yE1K8XIE1IZRtCVUF5EBGJhN9kJooiCCAxF7EoJwQrC7EKDLKUUG6xRozyV5Vhq M86Yo46j88/ea/W8a095kW1+5t//2t96v/d7v/dbe6z3mbWJCSZY/uQuJMZ6E1xnd0/zkT92Hzzd 0XHlXOvlru7yuFFVtw3oP3N63YI5Y+8cO9QQH3L2BsOtD8Fay60LxhutOGO8ZVk/fDDOcsN19Xr5 gx3f7fjiRE85s8F5k7NHu7i8tSYzIZ04vnrVitn3TB2nxcisb7NitCZwYANXTM5CbvwPP51/bcOe zss91vkMTOC8NYnx3pPABm9DGlgKyrfk3slrn7m/on8JCNJyCSrSQAkWbMhhTTrHkx1fHVu3ZX+w rjdkKY8ycH1uTeqdsZmxJfJnKsLGOj1LDXXV77ywtHrI7ZDsU6YQQ9nY5iQKafc3n3538zdInmc+ DSktsAlILiUDJYSKPGR5SiEeaIKQOvXm5NnWl9d9We6hRuBEkRvdqwJXKOPPt3U/+eLHvT0ZDGID 1KXc+hIqEOhs7ZBBtcMqQWXhz/YbrRevIk7Igklh3PvwwoaXnl4AXrxuCp+yFz6bth24Ue5BA9SC HZ0kSeLxQxhYWfH2miUzG0chqNT0ZvOnh7Z8cpAmuZTicjqxc+/Pyxc1NE4cFjWPDVUvoyYnfrm4 9/vfEt8PpVS2t/EeLLls4yvLgJYVgJbmrHtVKOvmTrplUH5/W1N8qBh9Yodpl9++5yh99WqXT/Co ybkvImbU104aV8O6/FvsVvGq3dEN1kJuQoknh4+3tnVc40bAUU6+U8Kamn9VwyFuCecPcuUUYE3v XY3DjMH1cuHXh1q2f36c7Wc7LlOTF66TT9gc8GvSdOTMo0saotSFqYxrbb/S2YUeWFqJ4RUdZWbV 185srKutqYoMYOt+PNZGWde6yhcudFJMMIl1mhZtcwnfR47/CV8lE39d6bm2K0wGwyIpIn70k9vw 6iMBjxPJZTM6/OwTc0ndfPLsmjd24nhNANLI+0UGc779ktSjHsgAan16I0NBZh0clalAxOGGgfQ0 ThJKdGhGpEQupS0ZT+ERDCZWfq7rPYUXxadg70qJYXawtJyAQkikS1OjaYgcwMfdkKEQqhAml6U3 uEVzhH+50qQfoJFgYUqX1tZU4lzWYoMIzq1EtKvf3IXbHnpg0oPzp8iK1qzf+u2plvburjIkvGOU ycZElehu4nSeDK+uUFJW+yYjpKOGVw0clF7r6iUnYpKI1tHkw8dasfOs+hEgR/v6Uy0XsZ0irHMB CpwPGb7xaZZybhvbOGWoSuhThQaoXjOzfrQ8EIvSzFC+tPYmSXOKpqoIL1wZS3PBiEZZpICOIXKY fMHsMcJWejWASJ1iyxffwQ/NBmldgnkrkIdjl2o4ztRw78kBv6CDjSM+MaViXT/jZ+qE4aNHFtzB iVD6Cu6+aWOn1Y+QXmyPJ3ivy73pjb0r6owuk82gLCZwJT19DuoRLUhXPnZ3bC1Boh0LJU5vB7N6 xTy1igw4jD3qWAlxGBkiCSAzcFJJwhTV8LoRmcT72dNHzp1Vp3AB9hGSNNrlQ8OkmudXztehgT9N OQmJjmCe4WuB6eDlW57kBMMpgsh9wmlhhg2ven3VQr07C7cU1BUMJyEiE5vdxq0HPtx1lF84IaFP ogUCPe7HWykHSroRSGtIoBkcPLhi/dplE8YMjiAiwHNMpjeM+N1Elx8+233yva37csaDAcZnai1R klzva049vf2UgNwNE6vfem5pdU1lJCp+MhWRgta/C/+ix6Qq350517npo6b9zS1IWDa+pLNKjLG/ DnVSJX7wgNJTj89dvnhymur9I60jZU1zlKhYAZ2Ht7hOtLTvO9iyp+n0721/IXQR0b+Uzpk+etHc CfNm1FUOxJTFesH6FiD/i67YglQwV2+UOy51jx85SHD/ML0F2H+W/gbZ6SfL/JJX/AAAAABJRU5E rkJggg== --_009_A6B8F2A767638641889989BC1BA704795F96544ALIONALLOTLOCAL_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=1516; creation-date="Tue, 21 Jul 2015 13:43:37 GMT"; modification-date="Tue, 21 Jul 2015 13:43:37 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAB8AAAAaCAIAAADAARDdAAAFs0lEQVRIDZWVS2yUVRiGzzkz05aW Cm2gBUaaQIAQoEUpEECQhMglFJLGRIhxARjdmGgMauIKkUQ3uDEmKi6MCyVEIohEgtCNkWCVS0vF QtTYu9zKrbeZTmf+4/Oen5oY4sIz7X855/ve7/2uv/VhWeuNMd44a6LwYEwmc6vp9O0jxwYut430 9UXX+otnziiqqp60ckVlw6apmxpQsIiaKDw4Hozh+q9lPafWYMIaG5/73Fj3xwc69+0p3LkXGe2z vI8iwDwsfMKYopqZs/e+nd65S7qxmahgHCdAFZCPLaEWsw5EvBn5/UrL1q0jv/2JYAE1OSVvnG7i Cj4/Zzyv5atX1H95JDVtmoizB1EXgvDAHpK+wB5qbN9uamprfDqfHU5EUSEwZZ8DoGETISY/MZaI bIFNeJWk07XHjk+qf1yS8iLy3ok6YjzE6EAPtF+6uHRVlM3ktc2BKEOflQTOFIgRDuVlyCe8GdO+ IQpl6XT9j83Fj6aFyVIsYvKiI+LRUKa1YWsuNwJcEnqeKGqhLzD5zA1iujlv8czJZAJa2d7eX7Y/ 4/OxRlAbvzjEsdnx7t5cV4/zDmtjXtkJ3qGbAIcYKLkiYnnRUnoLCVmRSwNnm28eOhSnUHAPvAhx Grv+19k5cwvDGVCIyay39lSsXeMmV5Q/VmvFXiEyVIwyFpGFoa7ufOcf2c6e9ldfiQYHVBbeTkjP WNXd6RzyDxYxVwF17N9/ytiTxpyypq2x0Ue50APUaiF+UG58Qa+EjC1dc/zfOHoExSZjUeSv/9Tp ICaZKMojqLjf/vo4N7zB67K6Jd6myDc/aJLMQiajUKuu4jBGEjUpGFc1bmEX13Tszc2jx2LaVERk Sbxxkc/fv/gzTwSaKFauXRXiFrIR8Hr2vfPT8mX3z/wgTeR0VdQRyxt4oBnMGTPYfIYTmQ7VxYMb vXbDZ0Y5RzFJMSTIqPR1laDJD94dPn/h3Jq1bQ2bs1d+VWrUYoJPcrHKc95SPzbX0aMjdOWrVjLK ZrlRaipeEifbyiD1BYbT5EkUpOL6T5wc6u1d2dKqbpAGPaUsqKIVH58ZuCujsh0TMy5VPAFbqSBB kREpLPOWMJFj8ITZA5PSivL5H7z/xKU2S9Eq1HIxESSJZ0oNapKlRTFqJFsKYzI1o8oVlfp/+sjS jGrRBKysIErqFzOwZr3xmi8t056cI9vCATfwoG8jGEysmRMwGXNklbljk9Yly+oWDJ0/Tx7xc6il vfLJp2ghY3WBZnrXDt1jZ4PTQIRoRDF3RTUQKlu6NKiQw6T8ZtjRIFM3bkJBYTZmpKtbGdOCH39h VNBDyrR6PTRU3PRusLVFA1NHCnb1tu2xpiEAIkBsvavaucMmk6Qa+tc++/Tu9xQflh06kkbbWRKO N+NVL8jhjq7253dQNgwyWKSmTKlctxqFQB/SLBxg2Btz9aWX+z76kCSmmDMiY5OTpj6yZD5CSaat ZpYWKKxsZ2e2sytyjkGdp6Rw1rp57+2v2b1bbks9/EJ5ys3RvhvNC+blBocQ1LSyVKQSxcLJhAZy mMihVsgYHw/oMywZ+syyCXPnLbvclkgVizjZCxMeXDjpryg9vfbwUYtkqAlVcYBGAmiwYJ1Uj+Ep wBGSoeEoyYItn7zwq8NAc05W1DNiRc41HmSN98oN6xYe+ESFA5wWvOBM9ImlihxL6KFD3zH/5QAm S0oWHfz8kUV1IIQ2EgXRD/Wqb5PaJ5gD8tZ3p9qf2zZ65z6Jkzon9EY4BZcoxb0IHU5La2Yu/ubb iXW1IiAZXFSZj7dFHJkYOngxZeOGlZev1rzwonP6loh/4KjvEUWjrwdIPllSNvvN15e3tpfV1QIa ZFRmD6DHycoORh9emY6O6we/6D9x4t7ZZgU+5JCQVKxfP2XzlunPbk9VV6OF8rjbD2Nw/B9L80n/ 4VuRG7134Vx4+X+XvwEne2djo/hMbwAAAABJRU5ErkJggg== --_009_A6B8F2A767638641889989BC1BA704795F96544ALIONALLOTLOCAL_ Content-Type: image/png; name="image004.png" Content-Description: image004.png Content-Disposition: inline; filename="image004.png"; size=1547; creation-date="Tue, 21 Jul 2015 13:43:37 GMT"; modification-date="Tue, 21 Jul 2015 13:43:37 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAB8AAAAaCAIAAADAARDdAAAF0klEQVRIDX1WW4hVVRhel33OmXPG OeeM0ziTZo6MPkQ3QwcLxbHMBwVLLIKCMAh6CQ2kh/AlIegxCh8qyLR3M2SgHqScGNAk9YxBktQ4 XtJCHefS7HPZl/X3fWsf7QK1xtmz9lr/9fv+/99qEVFYopwW45Qy2U7PRO7LG83Pr8jVpvo5bM1G 8kDZlq3d3G+fXZxfUw2opajgtZX2736PQ7zyXIukogzuaJVHbjbS715o7f+l0XDw5RwljXaRMnkR Z0RDblXVvvdwceOiHBSdSo1YSGVx3fGiKCguSnXOQkYM7kdvt57/LpxqZaEgChjnOVPin/a5lgKU X1isPhuqduBe+9jb5ilDc6JhXfwdc/xwsvl6re7fIREr8elr7FOlLJ4wwluuVGmL19UVfXR9+d4C hNooIQYuLwVpLngZuR4/c3JeYzntYFrnvBTsxYK9GKsl1aLEQQR4KpUnbloN9ZixDZUCcablzHm2 MSAVIVyou5dOzWuVA7LO4igznVABe+BiklQS0g4ZPGkjcQY0uO9vxbvP1vHeXjCchU/GyYbsHW+E Aqux1gHZBQdIQHIwCxkD4mHQmEe69fYlqjsPpAMPNoRSZYJPLoe12Zgy/AVVMMEFmpJTt9WR3xMh uEgFgCbKAnQUSkyQECOJNS/fX6htqh5ZWx5eRA6AOh4oJCUJimvvD42/Ir5TpkAr+HiywZQ1dLAQ lBldVz2wuriqArizulYDneqDR0u4BvIHV5dWVYPUGWUihYoF4VoduxlNISQADSf0wwtW2shvDQfL DnAkSkda2/cnWjsHOk5v6vp2eMHSUoBMd68oVlHc0DUOm+MbqssWkBMaYD/aVOzhX0MQDk+oLcCL wM2l0ExFRqVEzSFwgiOX6vF8BF23odde2VLZubTj1eUFCOCERaAMWvWNlSXlAs3AUzoQc/Kmx0ZY vICcchfrManTOZQZNxQwk3UnGoGxcsDEoaFiF8PmFXqEYSj1yvJgdGPnrkEERPS0SSda8M18KMjl DNqdYLEyU88hcJDZltpzLmRxE2iLuLTlCIBGpoxntzXLi7mrdd/HGCeS1uMMpaxg6AmUg/CA9YJI ARpMJrE17tyMm0b5MGOGjXtggs5G5PSg1MUwfvun5je3YuhaHYCtTgNmIAAFMspEB4o5X4vQIXxY 1hZQD2fn4qdHZzCHYAlcscP4w44kdSL7J6JDl+f/wEQy0OQovK+E7iPmZBXyOFrRZbph38ChDBbz CwNwFPtKMBN1NXYLLiEPk/jhFjWG59VQDl5uwRZzQWfwQoZ7i5kQSpUwigQI5slec+QayZ9oxJ+u KV+ZT45PAUfZvsQO94AGGs2GVPbErN9xKsSgho6optZ5gIuq3dZnOY0JQuCJ1jqW5NgNt3VsjvE5 XemwB9YUdvTnYQ89btEB7C9CjSixpmK3eSysTUd+MmPYgTjO8bX35E8Mlz1yWTTIxkHfbunNreux nHxGz7WS506EO8+Ek00vKQGKAcZB02zi9p1vrPxqpjbDXrBsRjQzElNig3ceKmK6etiYKFKHe05g pHN6Rq37ejphB0AW/xCqxgdooFM/Vs7V5uJLYTw+a4xj/7OMsIgs/mBS2W19uaPrix5A3iAg1AFu +fVgzk7tn6zvroHPiMXE8YSpAExoANdW5ZyLxGqbmhTwuoBmHbrcDnapk09VenImm4KEMAMRteI7 hNHsGiy9uRLNCVagEnEEInf4oAMHlllsTqfQQIqYoxIra/qLZuTxBTCNEHCfzZksINJIgAgTNfDz 0US0Z3y+wa8w/eLjgBzhRRgZ9vi8oNjAEAMdWhiMPFHqK3BGeiqBQ/vL61Ei2wDJh8UDNub5OXnr xwY+hL4qgA80UWDZhh7hpiev9j1Yem1ZEd/7rExx8e+PNu21kfXZ/O1xZjr+4npy+FpygdOS7YXG KVm7qS94cWlua3+hQiDuKiBRT/XdA7/5T+v+tq2D9rnWxP+W2ln/08L/vf0JxHMW/IHyPq0AAAAA SUVORK5CYII= --_009_A6B8F2A767638641889989BC1BA704795F96544ALIONALLOTLOCAL_ Content-Type: image/png; name="image005.png" Content-Description: image005.png Content-Disposition: inline; filename="image005.png"; size=1530; creation-date="Tue, 21 Jul 2015 13:43:37 GMT"; modification-date="Tue, 21 Jul 2015 13:43:37 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAB8AAAAaCAIAAADAARDdAAAFwUlEQVRIDYVVW2xUVRQ9j3tnpg8p lA+hYkOnJqZgKIXE+IBWTDRKlUcwfvlG/gQTMRqjH5L4oWgETU1MagyKHyYNiTXij4IltCZGKKYU foRWkRSMcdpSy3TmnrO3a587Q+uXN+2d81x77bUfV3smo7SSh1QYsiatDCvlx3+YuzCoNPH4CW5a G2cXqVs6ci0bVa5RMWud3lKMi8pUJoDBTTxhrpkY97ENdA6Hksnx0tBH7vTndP0vNlmtExZzVnGi ldXMdvW22nv32HxnQAicTIoQcBe8QIw1Ky9sPejMDX1Y/O4tVbxG1isVMSdimNgYwwxWhjVoOdKm pm1b7vFPo2x9YBYoa7hU8SkdCHdIAf7QZ6ZvZ2n4MxiDDzq4Ysh7E2tOGJa0wxmcjvAm7Q1FTesa tvfSinYr4qSPWaAMVbiDz7UjzyWnDimOlU6UTlHgjhBPJWaGTUwghUiCRfG5ZmnDq79ahES0DU9q KMyAwrB2/ft9xeP7lAZN8pojwhuBIpttNLe2M5Ni68dOkBK5jPakYigpAScdL+tY9OLPUAxPeKVG xAegJzx5eeqd2whpAlKaLMeOXa61K7PlYLxszYILNDfYUzz2pitOWwNcW4ExNrvpjfoHXq/Snycv 3KePPO9PHWZwkbwCTY5XPXbTk19qFvckjOyUjoSLUu7qmemPH9KlAkmoQN1BTCiz6LULVX1uoJPx pYI7fRguVwSVDDV1j+4XIsgBAYfWUUoTBuyyjtydTwA6OO7FVehTmnajX+GiHAOnlJYyxp/r176s 2ZKxEksTZfOdZvFKuU088+3emd4H/+m9f6Z3k/vzLBZhLG7bAumNSqA+8h/wCFVyvh9bwdcQeXGU omTiLFvkNUNJyQGP86HwtANlP/o1Tf6GEoYj8aXh+ObVIJhZ3MyEtEyw6iTBDRK3dPHH+sAdlZM6 Cu8jmhglckgvZIrUP6xAeLEcQeUlL1/AYWQ6dkNZCCO1pGXp26XS2EDxm5fc1XPIC6sMlQtV0Plf cBJoKUuBgFmCXHACA/m3MAREZBNK2uCvKq7K5O/TNY0xOeRCGsd51OrIIAktZEFxCDD8lAzBCweQ cTLQRMqiA8BAaknuyj688mAE1YUfskEeYISugAEoW2XLwlYqHJljNeyJJbnLavbYPhobwIJn2CJ0 G7t8be3m/dAx6AvbsBl6GI5Lp0KM5bL0LfaRbd5gxo4jWdBxI2U9OStWBRq9xA8fclMTEnPgM9Je qctn6rrfDZkqIqJjwm9WiV3cCuiAi5c8mEameY1ETEopJk5ilSldGamTPVjQDa9cTC6eFDZQAUis 7Yo75CbmitzELwKDgTbZ/MYgCy6FNbDVFGVv3z7b2MyFcUsJUj7hsilNlgZ7cne/AFqSs61dOI/D KFapuOAWbuIMlQoxxx5nNGfWPw2JwknxXZQRwbXKrX0KFuEmysCYCMLPHt0z+9NBxT5cQFNE/0d5 CnTKrDj8xezRvUghp+E0Z1d2ZVo2plt4zw+gppqbnPpgvZ/+A6fLxmfkEwQwn13eHrftgHn0aYNc FPmRpYbO9SdXRuSi+CaftoZdA1G+MygiQoWB1BQ6LjqUdRNnpnvukhQHF53BTWwAN/iEtBCvkDjI f2W8tF5r0DoQTGdM7YbdtZsPoNlUHataARHECbOoqaNuxyeIMlpH+H5KjcBE+KaHIjCJ/IAqKh/9 V+obXd7k1j9b9/ABqe6KZiFEiFJ4AJGKK6v+fP+1vp1qruBBK7DFJeiiwZdCj4M32AupDbjcPbvr ut+XjyCklCQJkCl0GAu6NMzgmAg2NX69b1d5bFArDwHQpuSDhWYlnRbfVYuTKO+oIV/T/V5m9dYA ItEOwDcGYSbtA05JaG44Jhv+ykhx6KAbO+kmx2FZ2g6iKoWp47atmVWP5NY9I1MEMGUmn96UeYpb eafo/1laMCE/dYn+/h0rKFaTbYia2hfs/v/wXy9kHK2ZogLVAAAAAElFTkSuQmCC --_009_A6B8F2A767638641889989BC1BA704795F96544ALIONALLOTLOCAL_ Content-Type: image/png; name="image006.png" Content-Description: image006.png Content-Disposition: inline; filename="image006.png"; size=1274; creation-date="Tue, 21 Jul 2015 13:43:37 GMT"; modification-date="Tue, 21 Jul 2015 13:43:37 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAB8AAAAaCAIAAADAARDdAAAEwUlEQVRIDZWVWSjvWxTHr3k4Ms/z PGQocvDAeaCkiBQvlDx6EF6UIgnhQSTlQXlQHDIUyUk88CBzylDKEMeU6Tjmebif3136nf/Ffbj7 Ybf22t/9Xd+91vrtn9br6+tfn43Hx8eFhYXJycmVlZWjo6Pr6+svX77Y2toGBARERUWFhobq6upy juNaWlpCoGmLRwvXO+/z8/Pw8HBbW9vp6Slb2tra/0D+GNCZm5unp6cnJyfr6OiwBACdGkaoFc/L y4tsy7y/v19ZWbm5uSlQZgASAPS7YB4eHkVFRc7OzgJWSVXjLaysV1dXS0pKrq6uRIsKUg1RoC6B mZqalpeX+/v742QpYVTjLTPs7e3tFRQUkF/BceXb21siGRgY3N/fc0xfXx/b0NCQ25C9y8tL8gOR iYlJXV2di4uLGlWN9KYddG5u7tbWFiwchvr3799WVlaxsbGOjo7e3t4UFrqzs7OBgQFCwpuSktLV 1SVE7u7ujY2N7+pMYG3Z7uvrg5o1Q6i9vLyam5vPz8+/f//OVkJCAmE6Ozuhvrm5QU10dDR3kiMA +vv7RbskBxtDYaf5enp6ZA366ekJFdSWMrS3txOgtLR0fHw8IiLCzc2NvqSYVBKkq6srl7C0tOS6 MMAjAdRZ6dnp6WmuLC7agwz4+flxcmJiwtjY2MLC4uLigh6NiYmxt7cPCgqiEQETgIYBv7S0VFtb izE1NQVGpcZQ2Ofm5hAiN0KFnp4eellGRkZyCVLBbQCAPDw8HBsb6+7utrGxqa6uzsvLo/IokPLO zs6q7EKoZIYMCDUzg97Y3t7u7e319PQsLi4mEp7U1NSmpqbl5WUzMzMKgwIjIyNmBgok9tramhhw wqPMrNPS0tRGFC9iEYU/MTHx169f1tbWZAZ2eoN6MqAOCwubmZkh1wSDiEFJpH6yZFa0q9TkTjYQ C7S1tZXG2N3dpSNheXh4gJfwiL27u/vx44ekUfQy00tyXL2BkncSh1IM0ATgPFzU2cnJiT4hElv5 +fmUt6GhgXsgFhgGeOJhQ8fMhYRdEoCtiKVEbOOSgUYqmZOTA1d8fDydU1hYeHBwkJWVlZGRcXJy whGQ8AqpKCUSPGzJUgxFu6+v78+fP8WLahJVU1MTEhKSnZ2NnxQRbHFxsaWlhQCDg4OEp5gE0ORi CQ8e8YuhaP/69Sszgw1SREK+ffs2Pz/Py25nZ0dC6P2dnR2+Z94sko5MwWvOiFN5xI9H0U5fQ0Gi OUZOkcYIDAykQygpVSEJ+IODg6kkmXFwcACJFJmFCwaKpBkPgE5ZWZm0FGJZU8Pj42Mo4uLikpKS 0M7/iCxRBkJWVVXx4UgZIQLPQCOezMxMYJrsCkDSjTreSMk+UF5EksgDGR4eDoDlyMjI6OgoAgmv mRmh5v35+Eb+YcciCbzv9CwHUMRrg821sPm4eNZRDUyoRTJLBmWvr6/nfZeDeDCYwbxplw0+ZZ5D Pn3Z/ohWyP49uA255aIqWHP/jV11kYSKioqNjQ0JoPoxPp7nG+ZPSW1U2DvMe3Zw1GBoaKijo4MX Rj2maUDBb4sy8q3RoOqWUGsG+IRd0HQIjxRjfX2dh5ca0Jr0j4+PD53HkBdCpf7U+E/2T9H/1/k3 /RRAl7l89aQAAAAASUVORK5CYII= --_009_A6B8F2A767638641889989BC1BA704795F96544ALIONALLOTLOCAL_-- From nobody Wed Jul 22 01:50:23 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722AB1ACEAC for ; Wed, 22 Jul 2015 01:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZaz9_sPG8Ey for ; Wed, 22 Jul 2015 01:50:16 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545531ACEAA for ; Wed, 22 Jul 2015 01:50:16 -0700 (PDT) Received: by obnw1 with SMTP id w1so130120630obn.3 for ; Wed, 22 Jul 2015 01:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=l67xBZNl0NIdvK6KJs6Qy9i8dv0fZTD0HWKP8FpQDIQ=; b=H+SHupVaKefrSPA3EzhG/gMcaPFUnDeq9vZUdVAFKYfWYtoYxIc3yHuzTlgxx4fmLJ HdEQv3jcb7575M2R1kvmnL8FqbFkXhzrQ54a3hJiTHKkg9OF7RP4xobhKi27eGJCJq6C 5pcppXkWJk4na1Ee+uRcfDnDCaOZWyHuLq1MAWGDaRl9VpNKBtKfXAxNJhZMIO6D1KCU VJmEzZogcbQD5wyLG29iOwui9mLLOCAliHL+QT2B/mu4mDzaPfz541M7KcNfOeQUS8dq TQs3U8slAE2c+yBgIPulnBtAGxPhICkZSozp8wbNUqChqIZdxehs8dT8D1lh/2w7EB7W yMjA== MIME-Version: 1.0 X-Received: by 10.182.29.68 with SMTP id i4mr1204717obh.57.1437555015565; Wed, 22 Jul 2015 01:50:15 -0700 (PDT) Received: by 10.60.41.99 with HTTP; Wed, 22 Jul 2015 01:50:15 -0700 (PDT) Date: Wed, 22 Jul 2015 04:50:15 -0400 Message-ID: From: Alia Atlas To: "sfc@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2993a0c47b9051b72dc22 Archived-At: Subject: [sfc] NSH and UDP transport X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 08:50:19 -0000 --001a11c2993a0c47b9051b72dc22 Content-Type: text/plain; charset=UTF-8 Hi, draft-kumar-sfc-nsh-udp-transport has received some discussion on the mailing list and is identified as being out of charter. However, on reading the draft, the complexities of carrying NSH over UDP do not appear, largely, to be details of the encoding but rather the issues around security and congestion control that are directly tied to understanding SFC and NSH. Assuming that there is interest in describing NSH over UDP, I see two approaches that are possible. First, draft-kumar-sfc-nsh-upd-transport could be improved to describe the security and congestion control assumptions and requirements that would make it safe and acceptable to use for SFC. Second, a more general draft could be written to describe the different requirements for how a transport needs to handle those concerns. Then an NSH over UDP draft could simply connect up to the general draft. In either case, it seems that a "transport considerations" type of draft for SFC is needed to provide some requirements on the transports. I agree that this work is not yet in the scope of the charter. I am interested in considered opinions. Thanks, Alia --001a11c2993a0c47b9051b72dc22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
Hi,
draft-kumar-sfc-nsh-udp-transport has received some=
 discussion on the mailing list and is identified as being out of charter.<=
/pre>
However, on reading the draft, the complexities of carrying NSH over UD=
P do not appear, largely, to be details of the encoding but rather the issu=
es around security and congestion control that are directly tied to underst=
anding SFC and NSH.
Assuming that there is interest in describing NSH o=
ver UDP, I see two approaches that are possible.
First, draft-kumar-sfc=
-nsh-upd-transport could be improved to describe the security and congestio=
n control assumptions and requirements that would make it safe and acceptab=
le to use for SFC.
Second, a more general draft could be written to des=
cribe the different requirements for how a transport needs to handle those =
concerns.  Then an NSH over UDP draft could simply connect up to the genera=
l draft.
In either case, it seems that a "transport considerations=
" type of draft for SFC is needed to provide some requirements on the =
transports.
I agree that this work is not yet in the scope of the chart=
er.  I am interested in considered opinions.
Thanks,
Alia


--001a11c2993a0c47b9051b72dc22--


From nobody Wed Jul 22 11:53:55 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F90E1A8974; Wed, 22 Jul 2015 11:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7fXNoJIYcNK; Wed, 22 Jul 2015 11:53:53 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9811A8A66; Wed, 22 Jul 2015 11:53:17 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.1.0.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150722185317.5559.72565.idtracker@ietfa.amsl.com>
Date: Wed, 22 Jul 2015 11:53:17 -0700
Archived-At: 
Cc: sfc@ietf.org
Subject: [sfc] I-D Action: draft-ietf-sfc-dc-use-cases-03.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jul 2015 18:53:54 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Service Function Chaining Working Group of the IETF.

        Title           : Service Function Chaining Use Cases In Data Centers
        Authors         : Surendra Kumar
                          Mudassir Tufail
                          Sumandra Majee
                          Claudiu Captari
                          Shunsuke Homma
	Filename        : draft-ietf-sfc-dc-use-cases-03.txt
	Pages           : 23
	Date            : 2015-07-22

Abstract:
   Data center operators deploy a variety of layer 4 through layer 7
   service functions in both physical and virtual form factors.  Most
   traffic originating, transiting, or terminating in the data center is
   subject to treatment by multiple service functions.

   This document describes use cases that demonstrate the applicability
   of Service Function Chaining (SFC) within a data center environment
   and provides SFC requirements for data center centric use cases, with
   primary focus on Enterprise data centers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sfc-dc-use-cases-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-dc-use-cases-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Jul 22 18:54:19 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BE21A1BE0 for ; Wed, 22 Jul 2015 18:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXiDbSPUfi9F for ; Wed, 22 Jul 2015 18:54:16 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29F21A1BDC for ; Wed, 22 Jul 2015 18:54:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2153; q=dns/txt; s=iport; t=1437616456; x=1438826056; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=G1/qg+cnz6vfw+aCDCRdPHdmyrK36FEeMN9lEEnCI18=; b=ALRBZ3xqyw89t/fEyDDgTe4LzbAsyQ4+Zj/Fngu/ciVC2fMxWAMGERpa 4457xlaURmL49Yns0rC+xLDk3PUD4W3qCY1iBfVduoAf6DtV470FU4Hsx 3zP+jkW85lVF/E2NpjDePtDB81yCk/kf1YuxCDmJtdVlFle9En91AXsvv o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AeAwDsR7BV/4YNJK1bgxVUaQa7QwmBawqGAQKBWDgUAQEBAQEBAX8LhCQBAQQBAQE3NBsCAQg2ECcLJQIEE4guDc0NAQEBAQEBAQECAQEBAQEBAQEai0yFDYQrBZRcAYR0h0CBQ0aDV5M4JoN8b4FHgQQBAQE
X-IronPort-AV: E=Sophos;i="5.15,527,1432598400"; d="scan'208";a="171401020"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP; 23 Jul 2015 01:54:15 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6N1sFxl001971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 23 Jul 2015 01:54:15 GMT
Received: from xmb-aln-x09.cisco.com ([169.254.4.112]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 20:54:14 -0500
From: "Surendra Kumar (smkumar)" 
To: "sfc@ietf.org" 
Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-dc-use-cases-03.txt
Thread-Index: AQHQxK/JBfs/De2v/k6XyFoXSmoKW53oKgmA
Date: Thu, 23 Jul 2015 01:54:14 +0000
Message-ID: 
References: <20150722185317.5559.72565.idtracker@ietfa.amsl.com>
In-Reply-To: <20150722185317.5559.72565.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.9.150325
x-originating-ip: [10.24.113.95]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2A9399F9F1616848889C28190531B129@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-dc-use-cases-03.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jul 2015 01:54:17 -0000

This is a revision without any changes, just to avoid the impending
expiration.
The authors of this draft believe it is ready for LC.

Regards,
Surendra.

On 7/22/15, 11:53 AM, "internet-drafts@ietf.org"
 wrote:

>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the Service Function Chaining Working Group
>of the IETF.
>
>        Title           : Service Function Chaining Use Cases In Data
>Centers
>        Authors         : Surendra Kumar
>                          Mudassir Tufail
>                          Sumandra Majee
>                          Claudiu Captari
>                          Shunsuke Homma
>	Filename        : draft-ietf-sfc-dc-use-cases-03.txt
>	Pages           : 23
>	Date            : 2015-07-22
>
>Abstract:
>   Data center operators deploy a variety of layer 4 through layer 7
>   service functions in both physical and virtual form factors.  Most
>   traffic originating, transiting, or terminating in the data center is
>   subject to treatment by multiple service functions.
>
>   This document describes use cases that demonstrate the applicability
>   of Service Function Chaining (SFC) within a data center environment
>   and provides SFC requirements for data center centric use cases, with
>   primary focus on Enterprise data centers.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/
>
>There's also a htmlized version available at:
>https://tools.ietf.org/html/draft-ietf-sfc-dc-use-cases-03
>
>A diff from the previous version is available at:
>https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-dc-use-cases-03
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>sfc mailing list
>sfc@ietf.org
>https://www.ietf.org/mailman/listinfo/sfc


From nobody Thu Jul 23 11:51:59 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1E51A1B20; Thu, 23 Jul 2015 11:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PI9W9_Q4ho8z; Thu, 23 Jul 2015 11:51:55 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 922001A1B4C; Thu, 23 Jul 2015 11:51:50 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.1.0.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150723185150.17399.69708.idtracker@ietfa.amsl.com>
Date: Thu, 23 Jul 2015 11:51:50 -0700
Archived-At: 
Cc: sfc@ietf.org
Subject: [sfc] I-D Action: draft-ietf-sfc-nsh-01.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jul 2015 18:51:56 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Service Function Chaining Working Group of the IETF.

        Title           : Network Service Header
        Authors         : Paul Quinn
                          Uri Elzur
	Filename        : draft-ietf-sfc-nsh-01.txt
	Pages           : 43
	Date            : 2015-07-23

Abstract:
   This draft describes a Network Service Header (NSH) inserted onto
   encapsulated packets or frames to realize service function paths.
   NSH also provides a mechanism for metadata exchange along the
   instantiated service path.  NSH is the SFC encapsulation as per SFC
   Architecture [SFC-arch]


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sfc-nsh-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-nsh-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Jul 23 15:54:53 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876B11B2A3E for ; Thu, 23 Jul 2015 15:54:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level: 
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Q-IAr2VyRtW for ; Thu, 23 Jul 2015 15:54:51 -0700 (PDT)
Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 593081B2A3C for ; Thu, 23 Jul 2015 15:54:51 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so4443247wib.0 for ; Thu, 23 Jul 2015 15:54:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:date:message-id:subject:from:to:content-type;  bh=SIftq/TVgkARVPAAUbZv/I2DSIyXw2bqGWq9F3VhuoY=; b=lnbTzEJ4bRU2idaAdFRw5rlAqSTIT1xk//47Q7HQBj2Hj4Z1poCvKNuTTMwyhNz6Kk 9Oz8CWf/pBLWBiRyor8KXCEhs0oTM4WbGyFWiHOkstxsaoKTe4/RqGjR3ZFbRUuRyM1A dQEUYu6y9KLXCuKUYT+hToKIZ/9FU32NL+b9Dz5bnM5tClECBlTDDwtkVZ/C5u2f9sTV b+DxMVWWGafMHyjP40otmJR8k8SfJcvB2zoVTT6nQKcTudKVqPZ2wSA8JALayjCpigNk 2JZW/mWrPxIYYuYhLvZwRt1lQWEu1Le+jlYjN0uCzQP/Dm8OU0Dflpoqb4VcbtrA9nJ8 LJ2w==
MIME-Version: 1.0
X-Received: by 10.194.238.193 with SMTP id vm1mr20185072wjc.57.1437692090159;  Thu, 23 Jul 2015 15:54:50 -0700 (PDT)
Sender: ghanwani@gmail.com
Received: by 10.27.12.74 with HTTP; Thu, 23 Jul 2015 15:54:50 -0700 (PDT)
Date: Thu, 23 Jul 2015 15:54:50 -0700
X-Google-Sender-Auth: gX1qMGOe7uaDsG9syHxS7zvn-JQ
Message-ID: 
From: Anoop Ghanwani 
To: "sfc@ietf.org" 
Content-Type: multipart/alternative; boundary=089e01493cec549932051b92c694
Archived-At: 
Subject: [sfc] update to SFC OAM requirements draft
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 23 Jul 2015 22:54:52 -0000

--089e01493cec549932051b92c694
Content-Type: text/plain; charset=UTF-8

All,

A new version of the SFC OAM requirements draft has been published.  We
have tried to address the comments received since the last time it was
presented (Nov 2014).  Would appreciate review/comments from the WG.

https://tools.ietf.org/html/draft-aldrin-sfc-oam-framework-02

Thanks,
Anoop

--089e01493cec549932051b92c694
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


All,

A new version of the SFC OAM requi=
rements draft has been published.=C2=A0 We have tried to address the commen=
ts received since the last time it was presented (Nov 2014).=C2=A0 Would ap=
preciate review/comments from the WG.


Thanks,
Anoop


--089e01493cec549932051b92c694--


From nobody Fri Jul 24 00:07:24 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22751B2A3D; Fri, 24 Jul 2015 00:07:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nqy_qAjLxza1; Fri, 24 Jul 2015 00:07:19 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E9C1B2F8D; Fri, 24 Jul 2015 00:07:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.1.0.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150724070718.9586.29770.idtracker@ietfa.amsl.com>
Date: Fri, 24 Jul 2015 00:07:18 -0700
Archived-At: 
Cc: sfc@ietf.org
Subject: [sfc] I-D Action: draft-ietf-sfc-architecture-10.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jul 2015 07:07:21 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Service Function Chaining Working Group of the IETF.

        Title           : Service Function Chaining (SFC) Architecture
        Authors         : Joel Halpern
                          Carlos Pignataro
	Filename        : draft-ietf-sfc-architecture-10.txt
	Pages           : 30
	Date            : 2015-07-24

Abstract:
   This document describes an architecture for the specification,
   creation, and ongoing maintenance of Service Function Chains (SFC) in
   a network.  It includes architectural concepts, principles, and
   components used in the construction of composite services through
   deployment of SFCs, with a focus on those to be standardized in the
   IETF.  This document does not propose solutions, protocols, or
   extensions to existing protocols.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sfc-architecture-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-10


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Jul 24 00:24:48 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4281B2FAC; Fri, 24 Jul 2015 00:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.761
X-Spam-Level: 
X-Spam-Status: No, score=-1.761 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fh-wXU9ASL8a; Fri, 24 Jul 2015 00:24:45 -0700 (PDT)
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 2D13C1B2FAA; Fri, 24 Jul 2015 00:24:45 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BZC59397; Fri, 24 Jul 2015 07:24:43 +0000 (GMT)
Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 24 Jul 2015 08:24:09 +0100
Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.210]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 24 Jul 2015 15:24:05 +0800
From: Xuxiaohu 
To: "sfc@ietf.org" 
Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-nsh-01.txt
Thread-Index: AQHQxXi9Tgyhos48PEq9TRyTCNQEgp3qNSbA
Date: Fri, 24 Jul 2015 07:24:04 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB016CC@NKGEML512-MBS.china.huawei.com>
References: <20150723185150.17399.69708.idtracker@ietfa.amsl.com>
In-Reply-To: <20150723185150.17399.69708.idtracker@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.66.180]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "mpls@ietf.org" 
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-nsh-01.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jul 2015 07:24:47 -0000

SGkgY28tYXV0aG9ycywNCg0KSSB3b25kZXIgd2hldGhlciB0aGUgTlNIIGVuY2Fwc3VsYXRpb24g
d291bGQgc3RyaWN0bHkgZm9sbG93IHRoZSB0cmFuc3BvcnQtaW5kZXBlbmRhbmNlIHByaW5jaXBs
ZSBhcyBkZWZpbmVkIGluIHRoZSBTRkMgYXJjaGl0ZWN0dXJlIGRyYWZ0LiBJZiBzbywgaXQncyBw
b3NzaWJsZSB0aGF0IHRoZSBOU0ggd291bGQgYmUgdHJhbnNwb3J0ZWQgb3ZlciBNUExTIG5ldHdv
cmtzIHNvbWVkYXkuIEFzIHN1Y2gsIGl0J3MgYmV0dGVyIHRvIGNvbnNpZGVyIHRoZSBmaXJzdCBu
aWJibGUgaXNzdWUgYXNzb2NpYXRlZCB3aXRoIHRoZSBjdXJyZW50IE1QTFMgYXJjaGl0ZWN0dXJl
IGZyb20gdGhlIGJlZ2lubmluZy4gSSBoYXZlIG5vdCBzZWVuIGFueSB0ZXh0IGluIHRoaXMgcmVn
YXJkIGluIHRoaXMgbmV3IHZlcnNpb24uDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQpfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IHNmYyBbc2ZjLWJv
dW5jZXNAaWV0Zi5vcmddILT6se0gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFtpbnRlcm5ldC1k
cmFmdHNAaWV0Zi5vcmddDQq3osvNyrG85DogMjAxNcTqN9TCMjTI1SAyOjUxDQrK1bz+yMs6IGkt
ZC1hbm5vdW5jZUBpZXRmLm9yZw0Ks63LzTogc2ZjQGlldGYub3JnDQrW98ziOiBbc2ZjXSBJLUQg
QWN0aW9uOiBkcmFmdC1pZXRmLXNmYy1uc2gtMDEudHh0DQoNCkEgTmV3IEludGVybmV0LURyYWZ0
IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmll
cy4NCiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBTZXJ2aWNlIEZ1bmN0aW9uIENo
YWluaW5nIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoNCiAgICAgICAgVGl0bGUgICAgICAg
ICAgIDogTmV0d29yayBTZXJ2aWNlIEhlYWRlcg0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBQ
YXVsIFF1aW5uDQogICAgICAgICAgICAgICAgICAgICAgICAgIFVyaSBFbHp1cg0KICAgICAgICBG
aWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXNmYy1uc2gtMDEudHh0DQogICAgICAgIFBhZ2Vz
ICAgICAgICAgICA6IDQzDQogICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTUtMDctMjMNCg0K
QWJzdHJhY3Q6DQogICBUaGlzIGRyYWZ0IGRlc2NyaWJlcyBhIE5ldHdvcmsgU2VydmljZSBIZWFk
ZXIgKE5TSCkgaW5zZXJ0ZWQgb250bw0KICAgZW5jYXBzdWxhdGVkIHBhY2tldHMgb3IgZnJhbWVz
IHRvIHJlYWxpemUgc2VydmljZSBmdW5jdGlvbiBwYXRocy4NCiAgIE5TSCBhbHNvIHByb3ZpZGVz
IGEgbWVjaGFuaXNtIGZvciBtZXRhZGF0YSBleGNoYW5nZSBhbG9uZyB0aGUNCiAgIGluc3RhbnRp
YXRlZCBzZXJ2aWNlIHBhdGguICBOU0ggaXMgdGhlIFNGQyBlbmNhcHN1bGF0aW9uIGFzIHBlciBT
RkMNCiAgIEFyY2hpdGVjdHVyZSBbU0ZDLWFyY2hdDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIg
c3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu
b3JnL2RvYy9kcmFmdC1pZXRmLXNmYy1uc2gvDQoNClRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZl
cnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll
dGYtc2ZjLW5zaC0wMQ0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFp
bGFibGUgYXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1z
ZmMtbnNoLTAxDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt
aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZl
cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJu
ZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8v
ZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0K
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM=


From nobody Fri Jul 24 02:13:39 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BD81A870B for ; Fri, 24 Jul 2015 02:13:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzuIbYI0kr8g for ; Fri, 24 Jul 2015 02:13:33 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECFAF1A8797 for ; Fri, 24 Jul 2015 02:13:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3754; q=dns/txt; s=iport; t=1437729212; x=1438938812; h=from:to:subject:date:message-id:mime-version; bh=2rPSsMJCE4oW4blpZFufdiEe/Luz3YF8sF/0qtOL0lc=; b=A8CsjzTYXoPd46AyRJwuGGsfGrHxCw6uiVcNkyMMEfZ4aTYcz/yJvRyi p0Fwe3HTtyq1nQAJdyXX9rPdarcXCpQAb3QfqEBeVJqXt/DV/w5daR2yC SE2i4He+eJKIDu6TVJ6WapQfb/RpMw3czRdUGarec8d+dVGvGhxKw/dhy 8=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A9AwC9ALJV/4wNJK1cgxVUb4MduF0JgXWGAYFFOBQBAQEBAQEBfwuEKiNEJAEMATYHAjQnBCGIIA2kQ49flg0BAQEBAQEEAQEBAQEBARcEkFCCdC+BFAWUYwGCNoFXaIdGmSQmZIFbgT6CNoEEAQEB
X-IronPort-AV: E=Sophos;i="5.15,537,1432598400";  d="asc'?scan'208,217";a="171889295"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP; 24 Jul 2015 09:13:32 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t6O9DWZ0013048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 24 Jul 2015 09:13:32 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.220]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Fri, 24 Jul 2015 04:13:31 -0500
From: "Carlos Pignataro (cpignata)" 
To: "sfc@ietf.org" 
Thread-Topic: draft-ww-sfc-control-plane-06 - Service Function Chaining (SFC) Control Plane Components & Requirements
Thread-Index: AQHQxfECYEnx0enbP0ySs9Yt2iKz8Q==
Date: Fri, 24 Jul 2015 09:13:31 +0000
Message-ID: <9D14F8BA-3AF6-41D7-9A87-5FF58392EEA3@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.61.95.167]
Content-Type: multipart/signed; boundary="Apple-Mail=_D05A990C-4D11-4D54-80CD-E91AC981057A"; protocol="application/pgp-signature"; micalg=pgp-sha256
MIME-Version: 1.0
Archived-At: 
Subject: [sfc] draft-ww-sfc-control-plane-06 - Service Function Chaining (SFC) Control Plane Components & Requirements
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jul 2015 09:13:37 -0000

--Apple-Mail=_D05A990C-4D11-4D54-80CD-E91AC981057A
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_7248B3F0-4304-4065-8EC9-87DFC88CF9B2"


--Apple-Mail=_7248B3F0-4304-4065-8EC9-87DFC88CF9B2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

Thank you Ron for presenting today this very nice work!

Looking through the document, there is one meta-comment that I wanted to =
make: it seems to me that in many/most places where this document says =
=E2=80=9CSFC=E2=80=9D, it really means =E2=80=9CSFP=E2=80=9D.

For example, the document says:
	=E2=80=9CSFC Identifier carried in the packet header=E2=80=9D
Yes, I am only aware of an SFP ID carried in the packet.

This should align to draft-ietf-sfc-nsh

https://tools.ietf.org/html/draft-ww-sfc-control-plane-06 =


Thanks,

=E2=80=94 Carlos.

--Apple-Mail=_7248B3F0-4304-4065-8EC9-87DFC88CF9B2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Hi,

Thank you Ron for presenting today this =
very nice work!

Looking through the document, there is one meta-comment that =
I wanted to make: it seems to me that in many/most places where this =
document says =E2=80=9CSFC=E2=80=9D, it really means =
=E2=80=9CSFP=E2=80=9D. 

For example, the document =
says:
	=E2=80=9CSFC Identifier carried =
in the packet header=E2=80=9D
Yes, I am only aware =
of an SFP ID carried in the packet.

This should align to =
draft-ietf-sfc-nsh


https://tools.ietf.org/html/draft-ww-sfc-control-plane-06



Thanks,

=E2=80=94 =
Carlos.
=

--Apple-Mail=_7248B3F0-4304-4065-8EC9-87DFC88CF9B2--

--Apple-Mail=_D05A990C-4D11-4D54-80CD-E91AC981057A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVsgHFAAoJEIXgpQGOZny9oFAQAJT+G8yTN01uYgBwE22/CiAz
oSX36pNtLMbby6qok0zDkMEm+X9Y4uLKrJkt6Ug8rGarP27CI/UWiuopHNqqDlFd
PyY3SmPqVkNPMF3B8zyYEB6YlRT7jZbjQYN4lduRLZlVrc0DCnxCtRxPiCtW++H8
p0HDPeVggys074541I6WafxSR2D3HifOo9wfy8M0E2Wp/Jj9BoQcDJI7KnYGT9vW
bGhoT6PAZXYoY8+AM+koQzRRFd3iPpWLRqah1TpmFp7Zh2hqViQ3SpL5YmTXZaLs
TLyzQTcJTl2Ssr1FTePXtjE4hwZ2kURIWneE7z3EW0dDMlHmkma73n3eF5+T4nzT
bNacUQZLTG0BqrZ7hs3irBTf765Ashm0JhkesYJSn9I9Lp8pxyIHMRL29dS+2k9d
LkiZnMJy+f8g5FoW6O/hkagLBDwUASFCRHCH0Vrl0Tefmm/fGoKOxCd3sEAzsDvQ
KkZ6lZJth4zkOuwQX4w01HcabDsHNYJzdKEVQxpYGgma3v+mvwvcUfgZhmIlBn2E
QcpRmjdhqvXuagtb47WjSJpMKOMq/UPpJUz3HnOf4BQAbPk3uw68BLLRxaRbsPOG
Bf08rC5U6ti7Az6SCiwo++H3LvYIii55lICu6iQiLJKvmyGjgtBvnN3NgV50EN30
YpnDO/GPShY+cfsFNCqW
=2SrU
-----END PGP SIGNATURE-----

--Apple-Mail=_D05A990C-4D11-4D54-80CD-E91AC981057A--


From nobody Fri Jul 24 02:16:43 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A91D1A87E9 for ; Fri, 24 Jul 2015 02:16:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aK7W2Umvv8Nb for ; Fri, 24 Jul 2015 02:16:39 -0700 (PDT)
Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58EC61A8856 for ; Fri, 24 Jul 2015 02:16:39 -0700 (PDT)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0224.002;  Fri, 24 Jul 2015 02:16:38 -0700
From: Ron Parker 
To: "Carlos Pignataro (cpignata)" , "sfc@ietf.org" 
Thread-Topic: draft-ww-sfc-control-plane-06 - Service Function Chaining (SFC) Control Plane Components & Requirements
Thread-Index: AQHQxfECYEnx0enbP0ySs9Yt2iKz8Z3qVqnA
Date: Fri, 24 Jul 2015 09:16:38 +0000
Message-ID: 
References: <9D14F8BA-3AF6-41D7-9A87-5FF58392EEA3@cisco.com>
In-Reply-To: <9D14F8BA-3AF6-41D7-9A87-5FF58392EEA3@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [31.133.161.195]
Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B2E8EB09EMBX021W3CA2exch_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [sfc] draft-ww-sfc-control-plane-06 - Service Function Chaining (SFC) Control Plane Components & Requirements
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jul 2015 09:16:42 -0000

--_000_CDF2F015F4429F458815ED2A6C2B6B0B2E8EB09EMBX021W3CA2exch_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhhbmsgeW91LCBDYXJsb3MuICAgV2Ugd2lsbCByZWZpbmUgdGhlIHRleHQgaW4gb3VyIG5leHQg
dmVyc2lvbiB0byBiZSBtb3JlIGNvbmZvcm1hbnQgdG8gdGhlIGFyY2hpdGVjdHVyZSB0ZXJtaW5v
bG9neS4NCg0KICAgUm9uDQoNCg0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v
cmddIE9uIEJlaGFsZiBPZiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNClNlbnQ6IEZyaWRh
eSwgSnVseSAyNCwgMjAxNSA1OjE0IEFNDQpUbzogc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBbc2Zj
XSBkcmFmdC13dy1zZmMtY29udHJvbC1wbGFuZS0wNiAtIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5p
bmcgKFNGQykgQ29udHJvbCBQbGFuZSBDb21wb25lbnRzICYgUmVxdWlyZW1lbnRzDQoNCkhpLA0K
DQpUaGFuayB5b3UgUm9uIGZvciBwcmVzZW50aW5nIHRvZGF5IHRoaXMgdmVyeSBuaWNlIHdvcmsh
DQoNCkxvb2tpbmcgdGhyb3VnaCB0aGUgZG9jdW1lbnQsIHRoZXJlIGlzIG9uZSBtZXRhLWNvbW1l
bnQgdGhhdCBJIHdhbnRlZCB0byBtYWtlOiBpdCBzZWVtcyB0byBtZSB0aGF0IGluIG1hbnkvbW9z
dCBwbGFjZXMgd2hlcmUgdGhpcyBkb2N1bWVudCBzYXlzIOKAnFNGQ+KAnSwgaXQgcmVhbGx5IG1l
YW5zIOKAnFNGUOKAnS4NCg0KRm9yIGV4YW1wbGUsIHRoZSBkb2N1bWVudCBzYXlzOg0KICAgICAg
ICAgICAg4oCcU0ZDIElkZW50aWZpZXIgY2FycmllZCBpbiB0aGUgcGFja2V0IGhlYWRlcuKAnQ0K
WWVzLCBJIGFtIG9ubHkgYXdhcmUgb2YgYW4gU0ZQIElEIGNhcnJpZWQgaW4gdGhlIHBhY2tldC4N
Cg0KVGhpcyBzaG91bGQgYWxpZ24gdG8gZHJhZnQtaWV0Zi1zZmMtbnNoDQoNCmh0dHBzOi8vdG9v
bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13dy1zZmMtY29udHJvbC1wbGFuZS0wNg0KDQpUaGFua3Ms
DQoNCuKAlCBDYXJsb3MuDQo=

--_000_CDF2F015F4429F458815ED2A6C2B6B0B2E8EB09EMBX021W3CA2exch_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws
IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ
Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9
DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj
b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu
Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw
dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLXRhYi1zcGFu
DQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ
e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz
YW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl
LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv
bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu
O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48
IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw
aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht
bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk
YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K
PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz
cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjojMUY0OTdEIj5UaGFuayB5b3UsIENhcmxvcy4mbmJzcDsmbmJzcDsgV2Ugd2lsbCByZWZp
bmUgdGhlIHRleHQgaW4gb3VyIG5leHQgdmVyc2lvbiB0byBiZSBtb3JlIGNvbmZvcm1hbnQgdG8g
dGhlIGFyY2hpdGVjdHVyZSB0ZXJtaW5vbG9neS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBSb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01h
aWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk
ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWYiPiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9u
IEJlaGFsZiBPZiA8L2I+Q2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpPGJyPg0KPGI+U2VudDo8
L2I+IEZyaWRheSwgSnVseSAyNCwgMjAxNSA1OjE0IEFNPGJyPg0KPGI+VG86PC9iPiBzZmNAaWV0
Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW3NmY10gZHJhZnQtd3ctc2ZjLWNvbnRyb2wtcGxh
bmUtMDYgLSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpIENvbnRyb2wgUGxhbmUgQ29t
cG9uZW50cyAmYW1wOyBSZXF1aXJlbWVudHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rIHlvdSBSb24gZm9yIHByZXNlbnRpbmcgdG9k
YXkgdGhpcyB2ZXJ5IG5pY2Ugd29yayE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+TG9va2luZyB0aHJvdWdoIHRoZSBkb2N1bWVudCwgdGhlcmUg
aXMgb25lIG1ldGEtY29tbWVudCB0aGF0IEkgd2FudGVkIHRvIG1ha2U6IGl0IHNlZW1zIHRvIG1l
IHRoYXQgaW4gbWFueS9tb3N0IHBsYWNlcyB3aGVyZSB0aGlzIGRvY3VtZW50IHNheXMg4oCcU0ZD
4oCdLCBpdCByZWFsbHkgbWVhbnMg4oCcU0ZQ4oCdLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgZXhhbXBsZSwgdGhlIGRvY3Vt
ZW50IHNheXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+4oCcU0ZD
IElkZW50aWZpZXIgY2FycmllZCBpbiB0aGUgcGFja2V0IGhlYWRlcuKAnTxvOnA+PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBJIGFtIG9ubHkgYXdh
cmUgb2YgYW4gU0ZQIElEIGNhcnJpZWQgaW4gdGhlIHBhY2tldC48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBzaG91bGQgYWxpZ24gdG8g
ZHJhZnQtaWV0Zi1zZmMtbnNoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXd3LXNm
Yy1jb250cm9sLXBsYW5lLTA2Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd3ct
c2ZjLWNvbnRyb2wtcGxhbmUtMDYNCjwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCUIENhcmxvcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_CDF2F015F4429F458815ED2A6C2B6B0B2E8EB09EMBX021W3CA2exch_--


From nobody Fri Jul 24 04:51:45 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE751A8763 for ; Fri, 24 Jul 2015 04:51:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idhLdxesZS_9 for ; Fri, 24 Jul 2015 04:51:36 -0700 (PDT)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 70E261A86F4 for ; Fri, 24 Jul 2015 04:51:36 -0700 (PDT)
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0195.001; Fri, 24 Jul 2015 07:51:35 -0400
From: Dave Dolson 
To: "sfc@ietf.org" 
Thread-Topic: Security framework
Thread-Index: AdDGBxc1PsvEjvCBSd6Dy88RvbmsKw==
Date: Fri, 24 Jul 2015 11:51:35 +0000
Message-ID: <20150724115135.34242647.29728.26055@sandvine.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="utf-8"
Content-ID: <54BA95134D06BA408810A16172829368@sandvine.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: [sfc] Security framework
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jul 2015 11:51:44 -0000

TGlzdGVuaW5nIHRvIHRoZSBzZWN1cml0eSBkaXNjdXNzaW9uIHRoaXMgbW9ybmluZywgaXQgb2Nj
dXJyZWQgdG8gbWUgdGhhdCB3ZSDigI5jb3VsZCBpbXByb3ZlIHRoZSBjb252ZXJzYXRpb24gYnkg
ZGVsaW1pdGluZyBwaHlzaWNhbCBzZWN1cml0eSwgbWVhbmluZyB0aGUgbmV0d29yayBkb21haW4g
YXQgd2hpY2ggYW4gYXR0YWNrZXIgY2Fubm90IGluc2VydCB0aGVtc2VsdmVzLg0KDQpBcyB3ZSBr
bm93LCBub3RoaW5nIGlzIHNlY3VyZSB3aXRob3V0IHBoeXNpY2FsIHNlY3VyaXR5OyBpZiBhbiBh
dHRhY2tlciBjYW4gb3BlbiB5b3VyIHNlcnZlciwgcm9vdCBwYXNzd29yZCBpcyBtZWFuaW5nbGVz
cy4NCg0KU28sIGluIFNGQyB0ZXJtcywgd2hhdCBpcyB0aGUgcGh5c2ljYWwgc2VjdXJpdHkgYm91
bmRhcnk/IElzIGl0IGEgc2luZ2xlIG5vZGUsIGEgc2luZ2xlIHBoeXNpY2FsIGJveCwgYSBzaW5n
bGUgcmFjaywgYSByb29tIGluIGEgZGF0YSBjZW50ZXIsIHRoZSBlbnRpcmUgZGF0YSBjZW50ZXI/
DQrigI5PbmNlIGEgYm91bmRhcnkgaXMgc2V0LCBwYWNrZXRzIHRyYXZlbGluZyB3aXRoaW4gdGhl
IGJvdW5kYXJ5IGNhbiBiZSB0cnVzdGVkLCBhbmQgaGVuY2UgZG9uJ3QgcmVxdWlyZSBlbmNyeXB0
aW9uIG9yIGF1dGhlbnRpY2F0aW9uLCBieSBkZWZpbml0aW9uIG9mIHRoZSBib3VuZGFyeS4NCg0K
V2hlbiBwYWNrZXRzIGVudGVyIG9yIGxlYXZlIGEgYm91bmRhcnksIHRoYXQgaXMgd2hlcmUgdG8g
Zm9jdXMuDQoNCg0KSSB3YXMgYWxzbyB0aGlua2luZyB0aGF0IHdoZW4gYSB2aXJ0dWFsaXphdGlv
biBpbmZyYXN0cnVjdHVyZSBwcm92aWRlcyBhIGxheWVyMiBuZXR3b3JrLCBpdCBpcyBhc3N1bWVk
IHRvIGJlIGEgcHJvdGVjdGVkIHN1Ym5ldC4gVHJ1ZT8gSWYgdGhlIGxheWVyMiBuZXR3b3JrIGNy
b3NzZXMgcGh5c2ljYWwgc2VjdXJpdHkgYm91bmRhcmllcywgaXQgd291bGQgYmUgdGhlIHJlc3Bv
bnNpYmlsaXR5IG9mIHRoYXQgdW5kZXJsYXkgKGUuZy4gVnhMQU4pIHRvIHByb3ZpZGUgdGhlIGVu
Y3J5cHRpb24vYXV0aGVudGljYXRpb24uDQoNClNvLCBpbiB0aGUgY29udGV4dCBvZiBOU0gsIGlu
IHRoZSBjYXNlIG9mIEV0aGVybmV0L05TSCB0cmFuc3BvcnQgcGFja2V0cyBjYW4gb25seSBiZSBz
ZW50IG9uIHRoZSBzYW1lIHN1Ym5ldC4gSWYgdGhpcyBpcyBhIHRydXN0ZWQgc3VibmV0LCB3aXRo
aW4gYSBwaHlzaWNhbCBvciB2aXJ0dWFsIHNlY3VyaXR5IGJvdW5kYXJ5LCB0aGUgdHJhZmZpYyBk
b2Vzbid0IG5lZWQgdG8gYmUgZW5jcnlwdGVkIG9yIGF1dGhlbnRpY2F0ZWQuDQoNCklmLCBvbiB0
aGUgb3RoZXIgaGFuZCwgYW4gTlNIIHBhY2tldCBpcyBlbmNhcHN1bGF0ZWQgaW4gYW4gSVAgcGFj
a2V0IGFuZCBzZW50IGFjcm9zcyB0aGUgc2VjdXJpdHkgYm91bmRzLCB0aGVuIGl0IHdvdWxkIGJl
IHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgTlNIIGVuY2Fwc3VsYXRpb24gdG8gcHJvdGVjdCBh
bmQgYXV0aGVudGljYXRlIHNlbnQvcmVjZWl2ZWQgcGFja2V0cy4NCg0KU28gYWdhaW4sIGRlZmlu
ZSB0aGUgYm91bmRhcmllcyBvZiB0aGUgc2VjdXJlIGFyZWEuDQoNCkhvcGVmdWxseSBJJ20ganVz
dCBmaW5hbGx5IGNsdWluZyBpbiB0byB3aGF0IGV2ZXJ5b25lIGVsc2UgYWxyZWFkeSBrbm93cy4u
Lg0KQW55aG93IEknbGwgcHV0IGl0IG91dCB0aGVyZS4NCg0KKEkgZG9uJ3QgdGhpbmsgSSBxdWFs
aWZ5IGFzIGEgc2VjdXJpdHkgZXhwZXJ04oCOLCBhbHRob3VnaCBJIHdvcmtlZCBvbiBzZWN1cmUg
WC13aW5kb3dzIGFuZCBuZXR3b3JraW5nIGluIDE5OTIpDQoNCi1EYXZlDQoNCg0KDQo=


From nobody Fri Jul 24 07:52:34 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9591ACDB7; Fri, 24 Jul 2015 07:52:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrCAJ3J48npQ; Fri, 24 Jul 2015 07:52:31 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D501ACDBA; Fri, 24 Jul 2015 07:52:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.1.0.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150724145225.22259.47624.idtracker@ietfa.amsl.com>
Date: Fri, 24 Jul 2015 07:52:25 -0700
Archived-At: 
Cc: sfc@ietf.org
Subject: [sfc] I-D Action: draft-ietf-sfc-architecture-11.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 24 Jul 2015 14:52:32 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Service Function Chaining Working Group of the IETF.

        Title           : Service Function Chaining (SFC) Architecture
        Authors         : Joel Halpern
                          Carlos Pignataro
	Filename        : draft-ietf-sfc-architecture-11.txt
	Pages           : 30
	Date            : 2015-07-24

Abstract:
   This document describes an architecture for the specification,
   creation, and ongoing maintenance of Service Function Chains (SFC) in
   a network.  It includes architectural concepts, principles, and
   components used in the construction of composite services through
   deployment of SFCs, with a focus on those to be standardized in the
   IETF.  This document does not propose solutions, protocols, or
   extensions to existing protocols.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sfc-architecture-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Fri Jul 24 08:20:35 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BEE11A0267 for ; Tue, 21 Jul 2015 01:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.274
X-Spam-Level: *
X-Spam-Status: No, score=1.274 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ijl_GmHwuBW9 for ; Tue, 21 Jul 2015 01:11:10 -0700 (PDT)
Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 91EFF1A0102 for ; Tue, 21 Jul 2015 01:11:09 -0700 (PDT)
Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 482951748100; Tue, 21 Jul 2015 17:11:08 +0900 (JST)
X-Virus-Scanned: amavisd-new at kddilabs.jp
Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt4xujKblMCy; Tue, 21 Jul 2015 17:11:06 +0900 (JST)
Received: from fruits.mip.kddilabs.jp (unknown [IPv6:2001:200:601:401:2e0:81ff:fe28:594a]) by mandala.kddilabs.jp (Postfix) with ESMTP id CDCA417480B7; Tue, 21 Jul 2015 17:11:06 +0900 (JST)
Received: from tea.mip.kddilabs.jp (tea.mip.kddilabs.jp [IPv6:2001:200:601:400::5]) by fruits.mip.kddilabs.jp (Postfix) with ESMTP id C979EEF471; Tue, 21 Jul 2015 17:11:06 +0900 (JST)
Received: from [172.19.113.4] (ovb004.vpn.kddilabs.jp [172.19.113.4]) by tea.mip.kddilabs.jp (Postfix) with SMTP id AF38995835; Tue, 21 Jul 2015 17:11:06 +0900 (JST)
Date: Tue, 21 Jul 2015 17:11:08 +0900
From: Takeshi Usui 
To: Alla Goldner , "Jeffrey Napper (jenapper)" , "sfc@ietf.org" 
In-Reply-To: 
References:  
Message-Id: <20150721171108.2E05.C088274E@kddi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.68 [ja] (Unregistered)
Archived-At: 
X-Mailman-Approved-At: Fri, 24 Jul 2015 08:20:33 -0700
Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 21 Jul 2015 08:11:14 -0000

Dear All,

As Alla told, FMSS (Flexible Mobile Service Steering) in 3GPP SA2 concluded
the architecture to report the policy information from PCRF.

I agree with updating the usecase draft in order to fit the conclusion of 3GPP SA2.

The architecture in 3GPP SA2 accepts the three solutions.
The first assumes that PCEF executes the classification, and Gx is used as the interface from PCRF.
The second assumes that TDF executes the classification and Sd is used.
The third assumes that the new entity out of 3GPP scope receives the policy
from the PCRF, and uses the interface which semantecs is the same with the Sd interface. 

The current draft describes only the first and second solutions.

> Dear Jeffrey,
> 
> I reviewed the latest version of the document.
> 
> Unfortunately, it includes many incorrect claims with regards to 3GPP related functionality, as well as recent work done by 3GPP is referenced incorrectly (as study has reached its conclusions and normative specification already in 3GPP, while this document discusses some of the solutions brought during the study phase).
> 
> I can provide a more detailed comments, if I get editable document's version from you.
> 
> Best Regards,
> 
> Alla Goldner
> Director of Mobile Technologies and Standards
> Allot Communications
> Tel ?? +972 9 761 9251
> Cell ? +972 54 249 3985 
> agoldner@allot.com 
> www.allot.com 
> 
> 
> 
> 
> 
> 
> 
> ?
> 
> 
> -----Original Message-----
> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jeffrey Napper (jenapper)
> Sent: Monday, July 20, 2015 11:52 PM
> To: sfc@ietf.org
> Subject: Re: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt
> 
> 
> The version 4 of the use case mobility draft
> (draft-ietf-sfc-use-case-mobility-04) differs from version 03 by a short note on recently discussed security issues with http header enrichment and a possible way out by using one-time, session-based keys. Also included a remark on the recent 3GPP work on service classifiers.
> 
> 
> The authors believe this revision is ready for WG last call.
> 
> Cheers,
> Jeff
> 
> 
> 
> -----Original Message-----
> From: sfc  on behalf of "internet-drafts@ietf.org"
> 
> Date: Monday, July 20, 2015 at 10:48 PM
> To: "i-d-announce@ietf.org" 
> Cc: "sfc@ietf.org" 
> Subject: [sfc] I-D Action: draft-ietf-sfc-use-case-mobility-04.txt
> 
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts 
> >directories.
> > This draft is a work item of the Service Function Chaining Working 
> >Group of the IETF.
> >
> >        Title           : Service Function Chaining Use Cases in Mobile
> >Networks
> >        Authors         : Walter Haeffner
> >                          Jeffrey Napper
> >                          Martin Stiemerling
> >                          Diego R. Lopez
> >                          Jim Uttaro
> >	Filename        : draft-ietf-sfc-use-case-mobility-04.txt
> >	Pages           : 26
> >	Date            : 2015-07-20
> >
> >Abstract:
> >   This document provides some exemplary use cases for service function
> >   chaining in mobile service provider networks.  The objective of this
> >   draft is not to cover all conceivable service chains in detail.
> >   Rather, the intention is to localize and explain the application
> >   domain of service chaining within mobile networks as far as it is
> >   required to complement the problem statement [RFC7498] and
> >   architecture framework [ietf-sfc-arch] of the working group.
> >
> >   Service function chains typically reside in a LAN segment which links
> >   the mobile access network to the actual application platforms located
> >   in the carrier's datacenters or somewhere else in the Internet.
> >   Service function chains (SFC) ensure a fair distribution of network
> >   resources according to agreed service policies, enhance the
> >   performance of service delivery or take care of security and privacy.
> >   SFCs may also include Value Added Services (VAS).  Commonly, SFCs are
> >   typical middle box based services.
> >
> >   General considerations and specific use cases are presented in this
> >   document to demonstrate the different technical requirements of these
> >   goals for service function chaining in mobile service provider
> >   networks.
> >
> >   The specification of service function chaining for mobile networks
> >   must take into account an interaction between service function chains
> >   and the 3GPP Policy and Charging Control (PCC) environment.
> >
> >
> >
> >The IETF datatracker status page for this draft is:
> >https://datatracker.ietf.org/doc/draft-ietf-sfc-use-case-mobility/
> >
> >There's also a htmlized version available at:
> >https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-04
> >
> >A diff from the previous version is available at:
> >https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-use-case-mobility-04
> >
> >
> >Please note that it may take a couple of minutes from the time of 
> >submission until the htmlized version and diff are available at 
> >tools.ietf.org.
> >
> >Internet-Drafts are also available by anonymous FTP at:
> >ftp://ftp.ietf.org/internet-drafts/
> >
> >_______________________________________________
> >sfc mailing list
> >sfc@ietf.org
> >https://www.ietf.org/mailman/listinfo/sfc
> 
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
> ##############################################################################################
> This message is intended only for the designated recipient(s).It may contain confidential or proprietary information.
> If you are not the designated recipient, you may not review, copy or distribute this message.
> If you have mistakenly received this message, please notify the sender by a reply e-mail and delete this message. 
> Thank you.
> ##############################################################################################
> 
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc

-- 
Takeshi Usui 


From nobody Tue Jul 28 06:19:54 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEFD1A8BC0 for ; Tue, 28 Jul 2015 06:19:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYr5tYVhcbxa for ; Tue, 28 Jul 2015 06:19:52 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F7F1A8BAF for ; Tue, 28 Jul 2015 06:19:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1445; q=dns/txt; s=iport; t=1438089592; x=1439299192; h=from:to:subject:date:message-id:mime-version; bh=3yjKRuSPN6u7/HrTyXRVRiueaH17kLrLhfUNYwsOiXo=; b=AOE6IlYVYdTZcBj7Bx7e3XpNYjPQ1kxn+L7b96KLRT5w2xGPNAHBvEdE GcEqo0MpWQytlChO5qO+ww4rBOujg3wqpvKAIxJQcy8pDZGVZ09Pu5pRc sw5F4LhJtc7HoRwC7FAnUgd/D085IFZc6nmpYaZdqjcZfuo5jWY0g0FRI c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DXAwAdgLdV/4UNJK1cgkhNVG+8KgmCAYV5gVk4FAEBAQEBAQF/C4QaEB1uAQsBdCcEiEENqV+lewEBAQcBAQEBARkEkFGENwWUaAGEeIdJgUWEHZNJJoN9gjeBBAEBAQ
X-IronPort-AV: E=Sophos; i="5.15,563,1432598400"; d="scan'208,217"; a="15648855"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP; 28 Jul 2015 13:19:51 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6SDJp0i022361 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 28 Jul 2015 13:19:51 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.72]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Tue, 28 Jul 2015 08:19:51 -0500
From: "Jim Guichard (jguichar)" 
To: "sfc@ietf.org" 
Thread-Topic: WG LC draft-ietf-sfc-dc-use-cases-03
Thread-Index: AQHQyTgVjvn3DJkZAE6HWLqFqdLu3g==
Date: Tue, 28 Jul 2015 13:19:50 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [10.98.43.179]
Content-Type: multipart/alternative; boundary="_000_D1DCF9CC1A885jguicharciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: [sfc] WG LC draft-ietf-sfc-dc-use-cases-03
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jul 2015 13:19:53 -0000

--_000_D1DCF9CC1A885jguicharciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Greetings WG:

This note begins a 2 week WG last-call for draft-ietf-sfc-dc-use-cases-03.t=
xt https://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/

Please send any substantive comments to the list while editorial comments c=
an go directly to the authors.

Jim & Thomas

--_000_D1DCF9CC1A885jguicharciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







Greetings WG:







This note begins a 2 week WG last-call for draft-ietf-sfc-dc-use-cases=
-03.txt https://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/







Please send any substantive comments to the list while editorial comme=
nts can go directly to the authors.







Jim & Thomas




--_000_D1DCF9CC1A885jguicharciscocom_--


From nobody Tue Jul 28 08:11:37 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808351AC42A for ; Tue, 28 Jul 2015 08:11:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBTpxF4l8lRj for ; Tue, 28 Jul 2015 08:11:33 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5EEC1AC422 for ; Tue, 28 Jul 2015 08:11:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B1A481C0242; Tue, 28 Jul 2015 08:11:33 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 47FD9280044; Tue, 28 Jul 2015 08:11:33 -0700 (PDT)
To: "Jim Guichard (jguichar)" , "sfc@ietf.org" 
References: 
From: "Joel M. Halpern" 
Message-ID: <55B79BA4.5050305@joelhalpern.com>
Date: Tue, 28 Jul 2015 11:11:32 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [sfc] WG LC draft-ietf-sfc-dc-use-cases-03
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jul 2015 15:11:35 -0000

The draft itself looks reasonable.  But what is the value in publishing 
it as an RFC?  (I went and looked, and our charter does not call for 
publishing use cases as separate documents.  It calls only for including 
the core use cases in the problem statement to illuminate the problem.

For our own work, having use case drafts that help us understand 
different aspects of the environment, and needs our solution must meet, 
is very helpful.  Thus, drafts like this which illuminate aspects of the 
problem are useful to the working group.

But what is the value to the greater community?
And what explanation will we offer to the IESG for taking up the 
community and leaderships' time processing this?

Yours,
Joel

On 7/28/15 9:19 AM, Jim Guichard (jguichar) wrote:
> Greetings WG:
>
> This note begins a 2 week WG last-call for
> draft-ietf-sfc-dc-use-cases-03.txt
> https://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/
>
> Please send any substantive comments to the list while editorial
> comments can go directly to the authors.
>
> Jim & Thomas
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>


From nobody Tue Jul 28 08:27:07 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D806B1ACCFA for ; Tue, 28 Jul 2015 08:27:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level: 
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQmZ58PQMKKs for ; Tue, 28 Jul 2015 08:27:02 -0700 (PDT)
Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9BE1ACCF8 for ; Tue, 28 Jul 2015 08:27:01 -0700 (PDT)
Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D4CE4604D7; Tue, 28 Jul 2015 17:26:58 +0200 (CEST)
Received: from ESTGVMSP108.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id C14E0604D1; Tue, 28 Jul 2015 17:26:58 +0200 (CEST)
Received: from emea01-db3-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.52) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 28 Jul 2015 17:26:57 +0200
Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (10.161.13.142) by DB4PR06MB0622.eurprd06.prod.outlook.com (10.161.13.140) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 28 Jul 2015 15:26:56 +0000
Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([10.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([10.161.13.142]) with mapi id 15.01.0225.018; Tue, 28 Jul 2015 15:26:56 +0000
From: DIEGO LOPEZ GARCIA 
To: "sfc@ietf.org" 
Thread-Topic: [sfc] WG LC draft-ietf-sfc-dc-use-cases-03
Thread-Index: AQHQyTgVjvn3DJkZAE6HWLqFqdLu3p3w/O8AgAAESwA=
Date: Tue, 28 Jul 2015 15:26:56 +0000
Message-ID: <305C05B8-E1C0-440A-A126-DB8F67A32D6F@telefonica.com>
References:  <55B79BA4.5050305@joelhalpern.com>
In-Reply-To: <55B79BA4.5050305@joelhalpern.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [156.39.191.244]
x-microsoft-exchange-diagnostics: 1; DB4PR06MB0622; 5:q9UA/KKGCV61O9Thidnh+K1rtypNU/ZKDVZkxNLlYUcPUB/0KxC9Xd5jzdPXgxBOAri/PLADq1DdG8OrMRCMT2FY8ZtIuxTmsbMW3ItMcYmqxtcLEsZ7IwklVdK7Jn2Siul14kxAMyO6LtvUADErcA==; 24:NNBtPr16nQsj1nQj+Sgz6ymUjjReMq7IW0tXF60ZxcBVKxfTfVpBDPtZFoiD3I1LQU5TOuw50qBcVdoUDf7KltMbjX+EN3xp4mhWuqZoegU=; 20:Tj5SBgWr9rC6YaL4Fht5ZZSsfmJ2rSYT/qU9+A22PHKRlqUM9TmcpRWXY91+80GULLGiprIiIIvsEk7o4qp8+g==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0622;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB4PR06MB0622; BCL:0; PCL:0; RULEID:;  SRVR:DB4PR06MB0622; 
x-forefront-prvs: 06515DA04B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(252514010)(377454003)(479174004)(33656002)(76176999)(189998001)(2501003)(19617315012)(19580395003)(62966003)(82746002)(5001960100002)(5002640100001)(83716003)(66066001)(2656002)(87936001)(36756003)(54356999)(110136002)(16236675004)(46102003)(86362001)(230783001)(50986999)(40100003)(2950100001)(92566002)(106116001)(102836002)(19580405001)(122556002)(77096005)(15975445007)(77156002)(2351001)(2900100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0622; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_305C05B8E1C0440AA126DB8F67A32D6Ftelefonicacom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2015 15:26:56.6179 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0622
X-OriginatorOrg: telefonica.com
X-TM-AS-MML: No
Archived-At: 
Cc: "Jim Guichard \(jguichar\)" , "Joel M. Halpern" 
Subject: Re: [sfc] WG LC draft-ietf-sfc-dc-use-cases-03
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jul 2015 15:27:07 -0000

--_000_305C05B8E1C0440AA126DB8F67A32D6Ftelefonicacom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

I agree with Joel. I see the value of the use case, but would not support t=
o have it as a separate document, and rather integrate it with the problem =
statement.

Be goode,

On 28 Jul 2015, at 08:11 , Joel M. Halpern > wrote:

The draft itself looks reasonable.  But what is the value in publishing it =
as an RFC?  (I went and looked, and our charter does not call for publishin=
g use cases as separate documents.  It calls only for including the core us=
e cases in the problem statement to illuminate the problem.

For our own work, having use case drafts that help us understand different =
aspects of the environment, and needs our solution must meet, is very helpf=
ul.  Thus, drafts like this which illuminate aspects of the problem are use=
ful to the working group.

But what is the value to the greater community?
And what explanation will we offer to the IESG for taking up the community =
and leaderships' time processing this?

Yours,
Joel

On 7/28/15 9:19 AM, Jim Guichard (jguichar) wrote:
Greetings WG:

This note begins a 2 week WG last-call for
draft-ietf-sfc-dc-use-cases-03.txt
https://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/

Please send any substantive comments to the list while editorial
comments can go directly to the authors.

Jim & Thomas


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


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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu=
ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc=
lusivo de la persona o entidad de destino. Si no es usted. el destinatario =
indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=
=C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de =
la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga=
mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a=
 su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti=
al information intended only for the use of the individual or entity named =
above. If the reader of this message is not the intended recipient, you are=
 hereby notified that any dissemination, distribution or copying of this co=
mmunication is strictly prohibited. If you have received this transmission =
in error, do not read it. Please immediately reply to the sender that you h=
ave received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1=
rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9=
 para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo=
ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura=
, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=
=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent=
e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi=
atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o

--_000_305C05B8E1C0440AA126DB8F67A32D6Ftelefonicacom_
Content-Type: text/html; charset="utf-8"
Content-ID: <12C1A32456239D4093CB694F33ECA58B@eurprd06.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable






I agree with Joel. I see the value of the use case, but would not support t=
o have it as a separate document, and rather integrate it with the problem =
statement.






Be goode,










The draft itself looks reasonable.  But what=
 is the value in publishing it as an RFC?  (I went and looked, and our=
 charter does not call for publishing use cases as separate documents. &nbs=
p;It calls only for including the core use cases
 in the problem statement to illuminate the problem.



For our own work, having use case drafts that help us understand different =
aspects of the environment, and needs our solution must meet, is very helpf=
ul.  Thus, drafts like this which illuminate aspects of the problem ar=
e useful to the working group.



But what is the value to the greater community?

And what explanation will we offer to the IESG for taking up the community =
and leaderships' time processing this?



Yours,

Joel



On 7/28/15 9:19 AM, Jim Guichard (jguichar) wrote:


Greetings WG:



This note begins a 2 week WG last-call for

draft-ietf-sfc-dc-use-cases-03.txt

h=
ttps://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/



Please send any substantive comments to the list while editorial

comments can go directly to the authors.



Jim & Thomas





_______________________________________________

sfc mailing list

sfc@ietf.org

https://www.ietf.org/mailman/listinfo/sfc







_______________________________________________

sfc mailing list

sfc@ietf.org

https://www.ietf.org/mailman/listinfo/sfc











--

"Esta vez no fallaremos, Doctor Infierno"



Dr Diego R. Lopez

Telefonica I+D

http://people.tid.es/diego.lo=
pez/



e-mail: diego.r.lopez@telefonica.com

Tel:    +34 913 129 041

Mobile: +34 682 051 091

----------------------------------













Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu=
ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc=
lusivo de la persona o entidad de destino. Si no es usted. el destinatario =
indicado, queda notificado de que la
 lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3=
n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec=
ibido este mensaje por error, le rogamos que nos lo comunique inmediatament=
e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.



The information contained in this transmission is privileged and confidenti=
al information intended only for the use of the individual or entity named =
above. If the reader of this message is not the intended recipient, you are=
 hereby notified that any dissemination,
 distribution or copying of this communication is strictly prohibited. If y=
ou have received this transmission in error, do not read it. Please immedia=
tely reply to the sender that you have received this communication in error=
 and then delete it.



Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1=
rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9=
 para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo=
ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a
 leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au=
toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o =
vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique=
 imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o





--_000_305C05B8E1C0440AA126DB8F67A32D6Ftelefonicacom_--


From nobody Tue Jul 28 08:44:55 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358D91ACD2A for ; Tue, 28 Jul 2015 08:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaSTn9iqw9Wk for ; Tue, 28 Jul 2015 08:44:48 -0700 (PDT)
Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 871261ACD22 for ; Tue, 28 Jul 2015 08:44:46 -0700 (PDT)
Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 933843A0221; Tue, 28 Jul 2015 17:44:44 +0200 (CEST)
Received: from ESTGVMSP112.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 7554F3A01F5; Tue, 28 Jul 2015 17:44:44 +0200 (CEST)
Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.93.6.54) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 28 Jul 2015 17:44:44 +0200
Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (10.161.13.142) by DB4PR06MB0622.eurprd06.prod.outlook.com (10.161.13.140) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 28 Jul 2015 15:44:43 +0000
Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([10.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([10.161.13.142]) with mapi id 15.01.0225.018; Tue, 28 Jul 2015 15:44:43 +0000
From: DIEGO LOPEZ GARCIA 
To: "sfc@ietf.org" 
Thread-Topic: [sfc] WG LC draft-ietf-sfc-dc-use-cases-03
Thread-Index: AQHQyTgVjvn3DJkZAE6HWLqFqdLu3p3w/O8AgAAESwCAAAT4gA==
Date: Tue, 28 Jul 2015 15:44:43 +0000
Message-ID: 
References:  <55B79BA4.5050305@joelhalpern.com> <305C05B8-E1C0-440A-A126-DB8F67A32D6F@telefonica.com>
In-Reply-To: <305C05B8-E1C0-440A-A126-DB8F67A32D6F@telefonica.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [156.39.191.244]
x-microsoft-exchange-diagnostics: 1; DB4PR06MB0622; 5:UVOHlqCGxLCWCnEehNpu06fa3g6Va7kJ/DqEFV1YdJYuK7T1Hti7GKw88dLche76slI3+jrIrVa5F9k8zegX95E/v+VQbP+bFAazu/SNp0oDL4duH6+qfeFrX/17WWqmbw95ZHKCqn+S/T1XyNPoow==; 24:mE6MRCEuWlz5+4l4LMmueP3dOdvciKRwikODgEjpJhLclh4gDp2eew/UpOh3nSP0ww5xCW5rr5h1qYu6bY+PVA8hUMDNy+WJIFpIbu8Otso=; 20:yiwFN8RxiJUmdOKGrcF6iM6IjHSsqpWdq6NBdvKnS1W4xw2GzxikiVcmrPjMvwLf2thKNe11hQnvq8mCl/1lOQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0622;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB4PR06MB0622; BCL:0; PCL:0; RULEID:;  SRVR:DB4PR06MB0622; 
x-forefront-prvs: 06515DA04B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(252514010)(377454003)(52314003)(479174004)(33656002)(76176999)(2501003)(189998001)(19617315012)(19580395003)(62966003)(82746002)(83716003)(5002640100001)(5001960100002)(2656002)(66066001)(87936001)(36756003)(16236675004)(54356999)(110136002)(46102003)(86362001)(230783001)(50986999)(40100003)(2950100001)(92566002)(102836002)(106116001)(122556002)(19580405001)(77096005)(15975445007)(2351001)(77156002)(2900100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0622; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_C1213CC9319A4231B40ED8BB9743F521telefonicacom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2015 15:44:43.3785 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0622
X-OriginatorOrg: telefonica.com
X-TM-AS-MML: No
Archived-At: 
Cc: "Jim Guichard \(jguichar\)" , "Joel M. Halpern" 
Subject: Re: [sfc] WG LC draft-ietf-sfc-dc-use-cases-03
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 28 Jul 2015 15:44:52 -0000

--_000_C1213CC9319A4231B40ED8BB9743F521telefonicacom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

I have been warned the problem statement is already published as RFC, and t=
hat implies that integration would be complicated. My apologies for the sli=
p.
Anyway, I still agree with Joel in not seeing a clear value in publishing t=
he use case as a standalone RFC.

On 28 Jul 2015, at 08:26 , DIEGO LOPEZ GARCIA > wrote:

I agree with Joel. I see the value of the use case, but would not support t=
o have it as a separate document, and rather integrate it with the problem =
statement.

Be goode,

On 28 Jul 2015, at 08:11 , Joel M. Halpern > wrote:

The draft itself looks reasonable.  But what is the value in publishing it =
as an RFC?  (I went and looked, and our charter does not call for publishin=
g use cases as separate documents.  It calls only for including the core us=
e cases in the problem statement to illuminate the problem.

For our own work, having use case drafts that help us understand different =
aspects of the environment, and needs our solution must meet, is very helpf=
ul.  Thus, drafts like this which illuminate aspects of the problem are use=
ful to the working group.

But what is the value to the greater community?
And what explanation will we offer to the IESG for taking up the community =
and leaderships' time processing this?

Yours,
Joel

On 7/28/15 9:19 AM, Jim Guichard (jguichar) wrote:
Greetings WG:

This note begins a 2 week WG last-call for
draft-ietf-sfc-dc-use-cases-03.txt
https://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/

Please send any substantive comments to the list while editorial
comments can go directly to the authors.

Jim & Thomas


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


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

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------


--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego.r.lopez@telefonica.com
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------


________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu=
ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc=
lusivo de la persona o entidad de destino. Si no es usted. el destinatario =
indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci=
=C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de =
la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga=
mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a=
 su destrucci=C3=B3n.

The information contained in this transmission is privileged and confidenti=
al information intended only for the use of the individual or entity named =
above. If the reader of this message is not the intended recipient, you are=
 hereby notified that any dissemination, distribution or copying of this co=
mmunication is strictly prohibited. If you have received this transmission =
in error, do not read it. Please immediately reply to the sender that you h=
ave received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1=
rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9=
 para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo=
ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura=
, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza=
=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent=
e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi=
atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o

--_000_C1213CC9319A4231B40ED8BB9743F521telefonicacom_
Content-Type: text/html; charset="utf-8"
Content-ID: <6AB3534B16AECB449CFBA6C99CE0E73A@eurprd06.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable






I have been warned the problem statement is already published as RFC, and t=
hat implies that integration would be complicated. My apologies for the sli=
p.

Anyway, I still agree with Joel in not seeing a clear value in publish=
ing the use case as a standalone RFC.






On 28 Jul 2015, at 08:26 , DIEGO LOPEZ GARCIA <diego.r.lopez@telefonica.com> wrote:






I agree with Joel. I see the value of the use case, but would not support t=
o have it as a separate document, and rather integrate it with the problem =
statement.






Be goode,







On 28 Jul 2015, at 08:11 , Joel M. Halpern <jmh@joelhalpern.com> wrote:




The draft itself looks reasonable.  But what=
 is the value in publishing it as an RFC?  (I went and looked, and our=
 charter does not call for publishing use cases as separate documents. &nbs=
p;It calls only for including the core use cases
 in the problem statement to illuminate the problem.



For our own work, having use case drafts that help us understand different =
aspects of the environment, and needs our solution must meet, is very helpf=
ul.  Thus, drafts like this which illuminate aspects of the problem ar=
e useful to the working group.



But what is the value to the greater community?

And what explanation will we offer to the IESG for taking up the community =
and leaderships' time processing this?



Yours,

Joel



On 7/28/15 9:19 AM, Jim Guichard (jguichar) wrote:


Greetings WG:



This note begins a 2 week WG last-call for

draft-ietf-sfc-dc-use-cases-03.txt

h=
ttps://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/



Please send any substantive comments to the list while editorial

comments can go directly to the authors.



Jim & Thomas





_______________________________________________

sfc mailing list

sfc@ietf.org

https://www.ietf.org/mailman/listinfo/sfc







_______________________________________________

sfc mailing list

sfc@ietf.org

https://www.ietf.org/=
mailman/listinfo/sfc











--

"Esta vez no fallaremos, Doctor Infierno"



Dr Diego R. Lopez

Telefonica I+D

http://people.tid.es/diego.lo=
pez/



e-mail: diego.r.lopez@telef=
onica.com

Tel:    +34 913 129 041

Mobile: +34 682 051 091

----------------------------------



















--

"Esta vez no fallaremos, Doctor Infierno"



Dr Diego R. Lopez

Telefonica I+D

http://people.tid.es/diego.lo=
pez/



e-mail: diego.r.lopez@telefonica.com

Tel:    +34 913 129 041

Mobile: +34 682 051 091

----------------------------------















Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu=
ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc=
lusivo de la persona o entidad de destino. Si no es usted. el destinatario =
indicado, queda notificado de que la
 lectura, utilizaci=C3=B3n, divulgaci=C3=B3n y/o copia sin autorizaci=C3=B3=
n puede estar prohibida en virtud de la legislaci=C3=B3n vigente. Si ha rec=
ibido este mensaje por error, le rogamos que nos lo comunique inmediatament=
e por esta misma v=C3=ADa y proceda a su destrucci=C3=B3n.



The information contained in this transmission is privileged and confidenti=
al information intended only for the use of the individual or entity named =
above. If the reader of this message is not the intended recipient, you are=
 hereby notified that any dissemination,
 distribution or copying of this communication is strictly prohibited. If y=
ou have received this transmission in error, do not read it. Please immedia=
tely reply to the sender that you have received this communication in error=
 and then delete it.



Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1=
rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9=
 para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo=
ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a
 leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au=
toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o =
vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique=
 imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o





--_000_C1213CC9319A4231B40ED8BB9743F521telefonicacom_--


From nobody Tue Jul 28 23:09:36 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B871A8704 for ; Tue, 28 Jul 2015 23:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.103
X-Spam-Level: 
X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iw66ea_Bae2J for ; Tue, 28 Jul 2015 23:09:33 -0700 (PDT)
Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 695951A86FC for ; Tue, 28 Jul 2015 23:09:33 -0700 (PDT)
Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t6T69W1J014850 for ; Wed, 29 Jul 2015 15:09:32 +0900
Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 975F85F611 for ; Wed, 29 Jul 2015 15:09:32 +0900 (JST)
Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 8038D5F593 for ; Wed, 29 Jul 2015 15:09:32 +0900 (JST)
Received: from [IPv6:::1] ([129.60.13.28]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t6T69O9H006314 for ; Wed, 29 Jul 2015 15:09:32 +0900
References: 
From: Shunsuke Homma 
Message-ID: <55B86E4F.8040401@lab.ntt.co.jp>
Date: Wed, 29 Jul 2015 15:10:23 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
To: sfc@ietf.org
X-TM-AS-MML: disable
Archived-At: 
Subject: Re: [sfc] WG LC draft-ietf-sfc-dc-use-cases-03
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 29 Jul 2015 06:09:35 -0000

I would like to support the LC of draft-ietf-sfc-dc-use-cases-03. I 
think that this draft will be important for showing concrete examples of 
using SFC. DC network is one of basic scenarios in which SFC is applied.

Regards,
Shunsuke

On 2015/07/28 22:19, Jim Guichard (jguichar) wrote:
> Greetings WG:
>
> This note begins a 2 week WG last-call for
> draft-ietf-sfc-dc-use-cases-03.txt
> https://datatracker.ietf.org/doc/draft-ietf-sfc-dc-use-cases/
>
> Please send any substantive comments to the list while editorial
> comments can go directly to the authors.
>
> Jim & Thomas
>
>
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
>


-- 
----------------------------------
Shunsuke Homma

TEL: +81 422 59 3486
FAX: +81 422 60 7460

NTT Network Service System Labs.
Musashino city, Tokyo, Japan
----------------------------------



From nobody Fri Jul 31 07:14:07 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18881A88EC; Fri, 31 Jul 2015 07:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.4
X-Spam-Level: 
X-Spam-Status: No, score=0.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08jwirjMJ6mG; Fri, 31 Jul 2015 07:14:02 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6751A88CE; Fri, 31 Jul 2015 07:13:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Stephen Farrell" 
To: "The IESG" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.2.0.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150731141354.6868.4366.idtracker@ietfa.amsl.com>
Date: Fri, 31 Jul 2015 07:13:54 -0700
Archived-At: 
Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org
Subject: [sfc] Stephen Farrell's No Objection on draft-ietf-sfc-architecture-11: (with COMMENT)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 31 Jul 2015 14:14:04 -0000

Stephen Farrell has entered the following ballot position for
draft-ietf-sfc-architecture-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Thanks for the extensive discussion about the security aspects
of this architecture. I think in -11 we've probably gotten as far
as we're likely to agree upon in terms of addressing those (which
is far enough for me to change from a discuss to a no-objection
ballot) and we can work further on the topic as specific protocols 
that adhere to this architecture emerge.

I didn't check if the (non-blocking) comments below were
taken into account or not in -11. If we need to chat about 
any of them feel to ping me.

OLD COMMENTS BELOW

- It occurs to me that it might really be better for the WG
to not publish this as an RFC now, but rather to put it on
hold until they've made progress on the solutions. Perhaps
revistiting this when the solutions are just at WGLC would
result in the eventual RFC being a much more useful document.
I think this one has to hedge so many bets that it's quite
vague and won't be very useful even in the medium term. But
that's just a suggestion, I can see why the WG might prefer
to push this out, even if that might only give the appearance
of progress and not reflect real progress.

- While IPR on an architecture document is sad to see, esp
with what seems like it may be restrictive licensing, I do
see the wg debated that and decided to move on.

- The charter text describing this deliverable notes that
"The initial scope is restricted to a single administrative
domain, keeping in mind that architectural decisions made for
the intra-domain case may have implications for the
inter-domain case." So I think there is also a currently
missing analysis (or the results of that) as to how the
single-domain elements of this architecture might impinge on
a later inter-domain architecture. So the text at the 
end of section 1.1 appears to contradict the chartered 
goals.

- Chains will require some representation, and re-ordering
that is security sensitive (e.g. swap order of f/w and nat
for fun) therefore there must be a requirement for some data
integrity service and origin authentication and an
authorisation decision function and therefore there must
(istm) be a need for the architecture to define a chain
producing entity of some kind that could be authenticated.
That is an example of the missing security analysis that
really is needed before this proceeds. (See my discuss point
2)

- 1.1: "classified on ingress" and applicable to mobile
networks are slightly incongrous. In the case of WiFi when do
the packet ingress? (When it gets to the AP or leaves the
mobile node transmitter?) I suspect you really mean the wired
bits of a mobile network so it might be better to say that.

- 1.2 should follow 1.3 I think.

- 1.2: What does "chaining logic" mean? You say there's no
standard chaining logic, which is maybe right, but then you
imply that a fully ordered set of SF's is a well defined
thing. I'm not sure that makes sense. Perhaps what you want
to say is that the architecture doesn't determine if an SFC
{{A,B},C} is or is not the same as {{B,A},C} but that later
protocol work will have to do that. (In fact, I think you
could say a lot more here and probably should.)

- 1.2: what is a "chaining policy"? Isn't here where those
terms need to be defined.

- 1.3: SFC definition: by ordered do you mean fully or
partially ordered?

- 1.3: I'd omit LI as a SF - we won't be standardising that
(cf. RFC2804) so better to not drag in the controversy
really. Similarly, HOST_ID injection is not afaik any kind of
standard and perhaps not likely to be (cf. some confict
reviews on the same telechat as this) so I'd also drop that.
And I think all of the exemplar SF's should really have a
reference (ideally an RFC).

- Figure 1 caption is misleading. That seems to me to show a
set of paths through (one or more) graphs but doesn't show
the full graphs themselves.

- 2.2: The concept of a bi-directional SFC seems odd.  Does
the example given imply that all traffic (of what kind?) that
followed SF1->SF2->SF3 on the way "in" must follow
SF3->SF2->SF1 on the way "out"? If so, then I think more
precision is needed really. The hybrid concept seems even
odder to me.

- 2.3: How can an SFP "be vague" - surely the point of an
architecture is to avoid such vagueness? If you mean that an
SFP representation can embody an if-statement then saying
that would be the thing to do.

- Section 3: I think there's maybe a missing principle here
about not making security and privacy worse in general.

- 4.1: I wonder if one could ever get enough SFC control
traffic that congestion would be an issue?  If so, should you
say rather that any transport that has some way of handling
congestion is ok. If not, then I guess the current text is
fine.