From nobody Sun Sep 6 23:53:14 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 5DDC91B46D7 for ; Sun, 6 Sep 2015 23:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, 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=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 coO3MeCG9qVp for ; Sun, 6 Sep 2015 23:53:10 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDEE1B4CA6 for ; Sun, 6 Sep 2015 23:53:10 -0700 (PDT) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t876r9Ad011760 for ; Mon, 7 Sep 2015 15:53:09 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 42D8B5F612 for ; Mon, 7 Sep 2015 15:53:09 +0900 (JST) Received: from imail1.m.ecl.ntt.co.jp (imail1.m.ecl.ntt.co.jp [129.60.5.246]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 34D5F5F58A for ; Mon, 7 Sep 2015 15:53:09 +0900 (JST) Received: from [129.60.21.195] (Netsu-shiomoto-Dell.silab.ecl.ntt.co.jp [129.60.21.195]) by imail1.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t876r9HG011298 for ; Mon, 7 Sep 2015 15:53:09 +0900 From: Kohei Shiomoto To: sfc@ietf.org Message-ID: <55ED354D.3080607@lab.ntt.co.jp> Date: Mon, 7 Sep 2015 15:57:17 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable Archived-At: Subject: [sfc] Call for Papers: Special Issue on "Management of Softwarized Networks" in IEEE TNSM 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, 07 Sep 2015 06:53:12 -0000 [Apologies, if you receive multiple copies of this CFP] --------------------------------------- CALL FOR PAPERS Special Issue on "Management of Softwarized Networks" IEEE Transactions on Network and Service Management -- http://www.comsoc.org/tnsm/cfp/si-msn -- * Paper submission date: January 31, 2016 * Notification of acceptance: April 30, 2016 * Publication date*: September 1, 2016 Currently, there is a strong interest in both industry and academia in the softwarization of telecommunication networks and cloud computing infrastructures. This evolution of network softwarization is enabled by three paradigms: (i) Software-Defined Networking (SDN), which allows network control to be separated from the forwarding plane and allows for a flexible management of the network resources, (ii) Network Virtualization (NV), which enables virtualization of network resources, and (iii) Network Function Virtualization (NFV), which focuses on virtualization of software-based network functions. Instead of installing and managing dedicated hardware devices for these functions, they are instead implemented as software components and deployed on commodity hardware infrastructures. There are also ongoing research efforts focusing on Software-Defined Clouds, including edge clouds and Fog Computing. In order to efficiently manage softwarized networks and to be able to use them to their full potential, there are many interesting challenges to be addressed (see the areas listed below). We welcome submissions addressing the important challenges and presenting novel research or experimentation results. Survey papers that offer a perspective on related work and identify key challenges for future research will be considered as well. We look forward to your submissions! Topics of interest for this special issue, include, but are not limited to the following: * APIs and management protocols for software programmable networks * Management of SDIs (Software-Defined Infrastructures) * Virtualization of resources, services and functions in SDN and NFV * Management of software-defined datacenters * Resource management for SDN or NFV-based systems * Efficient management of cloud computing and softwarized edge cloud infrastructures * Network softwarization for 5G networks * Life cycle management of virtual network functions, SFC modeling and representation * Composition algorithms and automated deployment of Service Function Chains (SFCs) * Algorithms for efficient orchestration in softwarized networks * Dynamic resource scaling and migration of network functions in NFV-based systems * Efficient network and service monitoring for SDN or NFV * Security management for SDN and NFV-based systems * Automated configuration and repair of virtualized software-defined systems * Algorithms for diagnosis and correlation of events in SDN or NFV-based systems * Availability and resilience of virtualized software-defined systems * Debugging and introspection of software-defined virtualized systems * Management of federated SDN/NFV infrastructures * Detailed experience reports from experimental testbeds * Transition strategies from existing networks to SDN/NFV **Submission guidelines** All manuscripts and any supplementary material should be submitted through the IEEE ManuscriptCentral service located at: http://mc.manuscriptcentral.com/tnsm Authors must indicate in the submission cover letter that their manuscript is intended for the "Management of Softwarized Networks" special issue. We are looking forward to your submissions! *Guest editors* * Raouf Boutaba, University of Waterloo, Canada * Prosper Chemouil, Orange Labs, France * Filip De Turck, Ghent University-iMinds, Belgium * Christian Esteve Rothenberg, University of Campinas, Brazil * Kohei Shiomoto, NTT, Japan * Minlan Yu, University of Southern California, USA -- Kohei Shiomoto, Ph.D Senior Manager, Communication Traffic & Service Quality Project NTT Network Technology Laboratories NIPPON TELEGRAPH AND TELEPHONE CORPORATION TEL +81-422-59-4402 FAX +81-422-59-6364 From nobody Wed Sep 9 02:46:05 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 1D8D31B2E83; Wed, 9 Sep 2015 02:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YKe3jK3Wg73; Wed, 9 Sep 2015 02:45:59 -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 975C21B2E7F; Wed, 9 Sep 2015 02:45:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBB21907; Wed, 09 Sep 2015 09:45:56 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 9 Sep 2015 10:45:26 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.42]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0235.001; Wed, 9 Sep 2015 17:45:19 +0800 From: Xuxiaohu To: "'sfc@ietf.org'" , "sfc-chairs@tools.ietf.org" Thread-Topic: New Version Notification for draft-xu-sfc-using-mpls-spring-04.txt Thread-Index: AQHQ6uEhwUT+nrZsQk6IpAAbYfyXTp4z7JRg Date: Wed, 9 Sep 2015 09:45:18 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB20CD2@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'mpls@ietf.org'" , "mpls-chairs@tools.ietf.org" Subject: [sfc] FW: New Version Notification for draft-xu-sfc-using-mpls-spring-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: Wed, 09 Sep 2015 09:46:02 -0000 SGkgYWxsLA0KDQpTZXJ2aWNlIGNoYWluaW5nIGlzIGFuIGltcG9ydGFudCBmdW5jdGlvbiBmb3Ig YWxsIHR5cGUgb2YgbmV0d29ya3MgaW5jbHVkaW5nIHRob3NlIHVzaW5nIHRoZSBzb3VyY2Ugcm91 dGluZyBwYXJhZGlnbSBhcyBzcGVjaWZpZWQgYnkgdGhlIFNQUklORyB3b3JraW5nIGdyb3VwLiBU aGlzIGRyYWZ0IGlzIGVzcGVjaWFsbHkgZm9jdXNlZCBvbiB0aGUgU1BSSU5HL01QTFMgbmV0d29y ayBzY2VuYXJpby4NCg0KV2hlbiB3ZSBwb3N0ZWQgdGhlIGVhcmx5IHZlcnNpb25zICgtMDAgdG8g LTAyKSwgdGhlIGZlZWRiYWNrIGZyb20gdGhlIFNGQyB3b3JraW5nIGdyb3VwIGNoYWlycyB3YXMg dGhhdCB0aGUgc29sdXRpb24gcmVxdWlyZWQgY2hhbmdlcyB0byB0aGUgTVBMUyBhcmNoaXRlY3R1 cmUuIFdlIGRpc2N1c3NlZCB0aGlzIGFtb25nIHRoZSBhdXRob3JzIGFuZCBwb3N0ZWQgYSBuZXcg dmVyc2lvbiAoLTAzKSB0aGF0IGRvZXMgbm90IHJlcXVpcmUgYW55IGNoYW5nZSB0byB0aGUgTVBM UyBBcmNoaXRlY3R1cmUgYW55bW9yZS4gVmVyc2lvbiAtMDQgbWVyZWx5IGNvcnJlY3RzIHNvbWUg dHlwb3MuDQoNCk5vdyB3ZSB3b3VsZCBsaWtlIHRvIGFzayB0aGUgU0ZDIGNoYWlycyBhbmQgV0dz IGlmIHRoZSBkcmFmdCBjYW4gbm93IGJlIGNvbnNpZGVyZWQgZm9yIGFkb3B0aW9uIGJ5IHRoZSBT RkMgd29ya2luZyBncm91cC4NCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPiBTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJl ciAwOSwgMjAxNSA1OjIzIFBNDQo+IFRvOiBMaXpoZW5iaW47IEx1aXMgTS4gQ29udHJlcmFzOyBY dXhpYW9odTsgSGltYW5zaHUgQy4gU2hhaDsgWHV4aWFvaHU7DQo+IEhpbWFuc2h1IFNoYWg7IEx1 aXMgTS4gQ29udHJlcmFzOyBMaXpoZW5iaW4NCj4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC14dS1zZmMtdXNpbmctbXBscy1zcHJpbmctMDQudHh0DQo+IA0KPiAN Cj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXh1LXNmYy11c2luZy1tcGxzLXNwcmluZy0w NC50eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBYaWFvaHUgWHUgYW5k IHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LXh1LXNm Yy11c2luZy1tcGxzLXNwcmluZw0KPiBSZXZpc2lvbjoJMDQNCj4gVGl0bGU6CQlTZXJ2aWNlIEZ1 bmN0aW9uIENoYWluaW5nIFVzaW5nIE1QTFMtU1BSSU5HDQo+IERvY3VtZW50IGRhdGU6CTIwMTUt MDktMDkNCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gUGFnZXM6CQk3DQo+IFVS TDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXh1LXNmYy11 c2luZy1tcGxzLXNwcmluZy0wNC50eHQNCj4gU3RhdHVzOg0KPiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC14dS1zZmMtdXNpbmctbXBscy1zcHJpbmcvDQo+IEh0bWxpemVk OiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtc2ZjLXVzaW5nLW1w bHMtc3ByaW5nLTA0DQo+IERpZmY6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC14dS1zZmMtdXNpbmctbXBscy1zcHJpbmctMDQNCj4gDQo+IEFic3RyYWN0Og0KPiAg ICBTb3VyY2UgUGFja2V0IFJvdXRpbmcgaW4gTmV0d29ya2luZyAoU1BSSU5HKSBXRyBzcGVjaWZp ZXMgYSBzcGVjaWFsDQo+ICAgIHNvdXJjZSByb3V0aW5nIG1lY2hhbmlzbS4gIFN1Y2ggc291cmNl IHJvdXRpbmcgbWVjaGFuaXNtIGNhbiBiZQ0KPiAgICBsZXZlcmFnZWQgdG8gcmVhbGl6ZSB0aGUg c2VydmljZSBwYXRoIGxheWVyIGZ1bmN0aW9uYWxpdHkgb2YgdGhlDQo+ICAgIHNlcnZpY2UgZnVu Y3Rpb24gY2hhaW5pbmcgKGkuZSwgc3RlZXJpbmcgdHJhZmZpYyB0aHJvdWdoIGEgcGFydGljdWxh cg0KPiAgICBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGgpIGJ5IGVuY29kaW5nIHRoZSBzZXJ2aWNlIGZ1 bmN0aW9uIHBhdGggb3IgdGhlDQo+ICAgIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4gaW5mb3JtYXRp b24gYXMgdGhlIGV4cGxpY2l0IHBhdGggaW5mb3JtYXRpb24uDQo+ICAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIGhvdyB0byBsZXZlcmFnZSB0aGUgTVBMUy1iYXNlZCBzb3VyY2Ugcm91dGluZw0K PiAgICBtZWNoYW5pc20gYXMgZGV2ZWxvcGVkIGJ5IHRoZSBTUFJJTkcgV0cgdG8gcmVhbGl6ZSB0 aGUgc2VydmljZSBwYXRoDQo+ICAgIGxheWVyIGZ1bmN0aW9uYWxpdHkgb2YgdGhlIHNlcnZpY2Ug ZnVuY3Rpb24gY2hhaW5pbmcuDQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u DQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Wed Sep 9 07:21: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 C05A51A8725; Wed, 9 Sep 2015 07:21:33 -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 8VcEwBD72_WV; Wed, 9 Sep 2015 07:21:31 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48CE01B2C3D; Wed, 9 Sep 2015 07:21:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 2B98F241025; Wed, 9 Sep 2015 07:21:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.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 maila2.tigertech.net (Postfix) with ESMTPSA id B8691240A39; Wed, 9 Sep 2015 07:21:30 -0700 (PDT) To: Xuxiaohu , "'sfc@ietf.org'" References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB20CD2@NKGEML512-MBS.china.huawei.com> From: "Joel M. Halpern" Message-ID: <55F04069.8090403@joelhalpern.com> Date: Wed, 9 Sep 2015 10:21:29 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB20CD2@NKGEML512-MBS.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "'mpls@ietf.org'" Subject: Re: [sfc] [mpls] FW: New Version Notification for draft-xu-sfc-using-mpls-spring-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: Wed, 09 Sep 2015 14:21:33 -0000 This draft seems to be written as if MPLS were a transport-independent forwarding mechanism for SFC. While I expect MPLS (and MPLS-SPRING) to be used as a transport for MPLS, and sometimes as a transport across multiple service functions, I would NOT claim that it is itself transport independent. As such, I am unclear on how the SFC working group could adopt this document. Considered as a transport description, it does not appear to standardize anything, so it would seem at most to be an informational document. Yours, Joel M. Halpern On 9/9/15 5:45 AM, Xuxiaohu wrote: > Hi all, > > Service chaining is an important function for all type of networks including those using the source routing paradigm as specified by the SPRING working group. This draft is especially focused on the SPRING/MPLS network scenario. > > When we posted the early versions (-00 to -02), the feedback from the SFC working group chairs was that the solution required changes to the MPLS architecture. We discussed this among the authors and posted a new version (-03) that does not require any change to the MPLS Architecture anymore. Version -04 merely corrects some typos. > > Now we would like to ask the SFC chairs and WGs if the draft can now be considered for adoption by the SFC working group. > > Best regards, > Xiaohu > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Wednesday, September 09, 2015 5:23 PM >> To: Lizhenbin; Luis M. Contreras; Xuxiaohu; Himanshu C. Shah; Xuxiaohu; >> Himanshu Shah; Luis M. Contreras; Lizhenbin >> Subject: New Version Notification for draft-xu-sfc-using-mpls-spring-04.txt >> >> >> A new version of I-D, draft-xu-sfc-using-mpls-spring-04.txt >> has been successfully submitted by Xiaohu Xu and posted to the IETF repository. >> >> Name: draft-xu-sfc-using-mpls-spring >> Revision: 04 >> Title: Service Function Chaining Using MPLS-SPRING >> Document date: 2015-09-09 >> Group: Individual Submission >> Pages: 7 >> URL: >> https://www.ietf.org/internet-drafts/draft-xu-sfc-using-mpls-spring-04.txt >> Status: >> https://datatracker.ietf.org/doc/draft-xu-sfc-using-mpls-spring/ >> Htmlized: https://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-04 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-xu-sfc-using-mpls-spring-04 >> >> Abstract: >> Source Packet Routing in Networking (SPRING) WG specifies a special >> source routing mechanism. Such source routing mechanism can be >> leveraged to realize the service path layer functionality of the >> service function chaining (i.e, steering traffic through a particular >> service function path) by encoding the service function path or the >> service function chain information as the explicit path information. >> This document describes how to leverage the MPLS-based source routing >> mechanism as developed by the SPRING WG to realize the service path >> layer functionality of the service function chaining. >> >> >> >> >> 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 > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From nobody Wed Sep 9 09:19:10 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 6734C1B2E85 for ; Wed, 9 Sep 2015 09:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 WOfy4Z9hIR9v for ; Wed, 9 Sep 2015 09:19:04 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2BA41ACD1D for ; Wed, 9 Sep 2015 09:19:03 -0700 (PDT) Received: by lanb10 with SMTP id b10so10270043lan.3 for ; Wed, 09 Sep 2015 09:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; bh=keF0L9ytFgI+/rLq6jxDitKznKGCAX9HJHtyE2zHadk=; b=ImxdK/QhtHxziJeH3M1T69ppNwMzHsoeNQodk5EmRiat63Hdie0TkIhvIv5epQgaBm xcyh6PAFWbrGVG6rZxbIIIt90WBslFX63YCb2KQL8IMklrlb/Ko6UppWPRwDrILksEHI q22G3Ms1hcL8kTGHS19ZISk2lN7gEl4CYUMHZyegumj5HaVMo8ciF4sxPhnqdht1YZSS XtcB+CPHaotBOHfzQLv7Sl200ncvGttq99T4EEjFyb90Gs12szcHX6fsHonTVKxVzGsH mO5Iq52NhvgdA6uqWCHyIXrpRXbvZzIrwpyzxuSIudA79dtL3i39V5zam2z+kra5zGUl mI8Q== MIME-Version: 1.0 X-Received: by 10.112.161.40 with SMTP id xp8mr29720276lbb.71.1441815541589; Wed, 09 Sep 2015 09:19:01 -0700 (PDT) Received: by 10.114.185.230 with HTTP; Wed, 9 Sep 2015 09:19:01 -0700 (PDT) Date: Wed, 9 Sep 2015 11:19:01 -0500 Message-ID: From: Behcet Sarikaya To: "sfc@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [sfc] New Version Notification for draft-sarikaya-sfc-hostid-serviceheader-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2015 16:19:09 -0000 Hi all, We submitted our draft on Service Function Chaining (SFC): Subscriber and Host Identification Considerations. Any comments will be appreciated. Regards, Behcet A new version of I-D, draft-sarikaya-sfc-hostid-serviceheader-00.txt has been successfully submitted by Behcet Sarikaya and posted to the IETF repository. Name: draft-sarikaya-sfc-hostid-serviceheader Revision: 00 Title: Service Function Chaining (SFC): Subscriber and Host Identification Considerations Document date: 2015-09-09 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-sarikaya-sfc-hostid-serviceheader-00.txt Status: https://datatracker.ietf.org/doc/draft-sarikaya-sfc-hostid-serviceheader/ Htmlized: https://tools.ietf.org/html/draft-sarikaya-sfc-hostid-serviceheader-00 Abstract: This document discusses considerations related to passing host- and subscriber-related information to upstream Service Functions for the sake of policy enforcement and appropriate SFC-inferred forwarding. Once the information is consumed by SFC-aware functional elements, the information is stripped from packets so that privacy-sensitive information is not leaked outside an SFC-enabled domain. 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 Wed Sep 9 19:40:41 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 E8F471B562A; Wed, 9 Sep 2015 19:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZszHu23hS7X5; Wed, 9 Sep 2015 19:40:35 -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 721B91B560E; Wed, 9 Sep 2015 19:40:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBC03960; Thu, 10 Sep 2015 02:40:26 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 10 Sep 2015 03:40:25 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.42]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0235.001; Thu, 10 Sep 2015 10:40:20 +0800 From: Xuxiaohu To: "Joel M. Halpern" , "'sfc@ietf.org'" Thread-Topic: [sfc] [mpls] FW: New Version Notification for draft-xu-sfc-using-mpls-spring-04.txt Thread-Index: AQHQ6uEhwUT+nrZsQk6IpAAbYfyXTp4z7JRg///NMICAAUGTEA== Date: Thu, 10 Sep 2015 02:40:20 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB2114E@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0CB20CD2@NKGEML512-MBS.china.huawei.com> <55F04069.8090403@joelhalpern.com> In-Reply-To: <55F04069.8090403@joelhalpern.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "'mpls@ietf.org'" Subject: Re: [sfc] [mpls] FW: New Version Notification for draft-xu-sfc-using-mpls-spring-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: Thu, 10 Sep 2015 02:40:39 -0000 Hi Joel, As described in this draft, an MPLS label stack is used to indicate a certa= in service function path. In other word, the MPLS label stack is now looked= as another SFC encapsulation form. As MPLS encapsulated packets could be t= ransported over MPLS networks or IP networks through IP-based tunnels (e.g.= , GRE or UDP), the MPLS-formatted SFC header could be safely deemed as tran= sport-independent. Since the MPLS-SPRING-based SFC approach as described in this draft is buil= t on the mature MPLS forwarding paradigm, SFF functionalities could be easi= ly implemented on existing MPLS devices without any change to their data-pl= anes if the attached SFs are SFC-aware. Note that SFC-aware here (i.e., in = the MPLS-SPRING-based SFC context) means MPLS-aware at least (e.g., being c= apable of receiving and treating received packets with the MPLS encapsulati= on). As SFC-aware SFs tend to be implemented in the NFV form, MPLS-awarenes= s would not be a excessive demand for them, IMHO. Best regards, Xiaohu > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Wednesday, September 09, 2015 10:21 PM > To: Xuxiaohu; 'sfc@ietf.org' > Cc: 'mpls@ietf.org' > Subject: Re: [sfc] [mpls] FW: New Version Notification for > draft-xu-sfc-using-mpls-spring-04.txt >=20 > This draft seems to be written as if MPLS were a transport-independent > forwarding mechanism for SFC. While I expect MPLS (and MPLS-SPRING) to b= e > used as a transport for MPLS, and sometimes as a transport across multipl= e > service functions, I would NOT claim that it is itself transport independ= ent. >=20 > As such, I am unclear on how the SFC working group could adopt this docum= ent. >=20 > Considered as a transport description, it does not appear to standardize > anything, so it would seem at most to be an informational document. >=20 > Yours, > Joel M. Halpern >=20 > On 9/9/15 5:45 AM, Xuxiaohu wrote: > > Hi all, > > > > Service chaining is an important function for all type of networks incl= uding > those using the source routing paradigm as specified by the SPRING workin= g > group. This draft is especially focused on the SPRING/MPLS network scenar= io. > > > > When we posted the early versions (-00 to -02), the feedback from the S= FC > working group chairs was that the solution required changes to the MPLS > architecture. We discussed this among the authors and posted a new versio= n > (-03) that does not require any change to the MPLS Architecture anymore. > Version -04 merely corrects some typos. > > > > Now we would like to ask the SFC chairs and WGs if the draft can now be > considered for adoption by the SFC working group. > > > > Best regards, > > Xiaohu > > > >> -----Original Message----- > >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >> Sent: Wednesday, September 09, 2015 5:23 PM > >> To: Lizhenbin; Luis M. Contreras; Xuxiaohu; Himanshu C. Shah; > >> Xuxiaohu; Himanshu Shah; Luis M. Contreras; Lizhenbin > >> Subject: New Version Notification for > >> draft-xu-sfc-using-mpls-spring-04.txt > >> > >> > >> A new version of I-D, draft-xu-sfc-using-mpls-spring-04.txt > >> has been successfully submitted by Xiaohu Xu and posted to the IETF > repository. > >> > >> Name: draft-xu-sfc-using-mpls-spring > >> Revision: 04 > >> Title: Service Function Chaining Using MPLS-SPRING > >> Document date: 2015-09-09 > >> Group: Individual Submission > >> Pages: 7 > >> URL: > >> https://www.ietf.org/internet-drafts/draft-xu-sfc-using-mpls-spring-0 > >> 4.txt > >> Status: > >> https://datatracker.ietf.org/doc/draft-xu-sfc-using-mpls-spring/ > >> Htmlized: > https://tools.ietf.org/html/draft-xu-sfc-using-mpls-spring-04 > >> Diff: > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-xu-sfc-using-mpls-spring-04 > >> > >> Abstract: > >> Source Packet Routing in Networking (SPRING) WG specifies a specia= l > >> source routing mechanism. Such source routing mechanism can be > >> leveraged to realize the service path layer functionality of the > >> service function chaining (i.e, steering traffic through a particu= lar > >> service function path) by encoding the service function path or th= e > >> service function chain information as the explicit path informatio= n. > >> This document describes how to leverage the MPLS-based source > routing > >> mechanism as developed by the SPRING WG to realize the service pat= h > >> layer functionality of the service function chaining. > >> > >> > >> > >> > >> 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 > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Sep 16 07:27:06 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 CB2191B3AB8 for ; Wed, 16 Sep 2015 06:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptkEgX0pV95F for ; Wed, 16 Sep 2015 06:28:54 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 019041B3AA6 for ; Wed, 16 Sep 2015 06:28:54 -0700 (PDT) Received: from localhost ([::1]:51317 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZcClV-0007r9-W6; Wed, 16 Sep 2015 06:28:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-control-plane@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Wed, 16 Sep 2015 13:28:49 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/12 Message-ID: <066.b9c0bf0afb954ba77cd50884cf983935@tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-control-plane@tools.ietf.org, mohamed.boucadair@orange.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-control-plane@ietf.org Resent-Message-Id: <20150916132854.019041B3AA6@ietfa.amsl.com> Resent-Date: Wed, 16 Sep 2015 06:28:54 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Wed, 16 Sep 2015 07:27:03 -0700 Cc: sfc@ietf.org Subject: [sfc] #12 (control-plane): Remove "SFC/SFP Diagnosis" Section 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, 16 Sep 2015 13:28:56 -0000 #12: Remove "SFC/SFP Diagnosis" Section [[Note: This section is expected to be removed once the working group adopts a document on OAM.]] 4.9. SFC/SFP Diagnosis The Control & Management planes should allow for the following: o Assess the status of the serviceability of a SF (i.e., the SF provides the service(s) it is configured for). Obviously, this assessment must not rely only on IP reachability to decide whether a SF is up and running. o Diagnose the availability of a SFC (including the availability of a particular SFP bound to a given SFC). o Retrieve the set of service function chains that are enabled within a domain. o Assess whether an SFC-enabled domain is appropriately configured (including, check the configured chains are matching what should be configured in that domain, and ensure coherent classification rules are installed in and enforced by all the Classifiers of the SFC-enabled domain). o Correlate classification policies with observed forwarding actions (including, assess the output of the classification rule applied on a packet presented to a Classifier of an SFC-enabled domain). o Support the correlation between a service function chain and the actual forwarding path followed by a packet matching that service function chain. o Notify the SFC Control Element whenever some (critical) events occur (for example, a malfunctioning SF instance). o Re-use SF built-in diagnostic procedures specific to each SF. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc-control- mohamed.boucadair@orange.com | plane@tools.ietf.org Type: task | Status: new Priority: minor | Milestone: Component: control-plane | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Wed Sep 16 07:51:08 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 58AC61B3B37 for ; Wed, 16 Sep 2015 06:30:58 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdQXSS06B7Ff for ; Wed, 16 Sep 2015 06:30:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 B8B911B3B39 for ; Wed, 16 Sep 2015 06:30:54 -0700 (PDT) Received: from localhost ([::1]:51430 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZcCnW-0007pg-Dc; Wed, 16 Sep 2015 06:30:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-architecture@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Wed, 16 Sep 2015 13:30:54 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/13 Message-ID: <066.e47bcbfaf64ea83e17548ea0b67b4a27@tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-architecture@tools.ietf.org, mohamed.boucadair@orange.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-architecture@ietf.org Resent-Message-Id: <20150916133054.B8B911B3B39@ietfa.amsl.com> Resent-Date: Wed, 16 Sep 2015 06:30:54 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Wed, 16 Sep 2015 07:51:06 -0700 Cc: sfc@ietf.org Subject: [sfc] #13 (architecture): Sumandra Majee's comments 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, 16 Sep 2015 13:30:58 -0000 #13: Sumandra Majee's comments Following are my comments and we should be able to discuss this before the last call. 1. 4.7 SF liveliness detection: An inband liveliness also should be considered and this control point should be the only recipient of this information. In a large distributed system this architecture may have a) scalability issues b) issues with reaction time. If node#1 has the health information for node#2 it can (sometimes) independently take local decision. This will scale well. Furthermore attributes like latency etc. are measured at the local node, and this makes the feedback loop between observer and corresponding local control point much shorter. This is in addition to what is described in draft. 2. 4.8 Monitoring and counters: Yes it is needed, but I am not sure this needs to be part of this draft. Either way the list of attributes are best incomplete and it will be always be like that. Why bother with this section at all. 3. 4. SFC Classification policy entry should be bound to one single service 5. function chain (or one single SFP) The above appears to be unnecessary, if I create a policy object I would rather refer it to multiple places. Can you describe a case or thought process behind this assertion. Regards Sumandra -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | architecture@tools.ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: architecture | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Wed Sep 16 07:51:29 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 E52AC1B3B41 for ; Wed, 16 Sep 2015 06:31:12 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ni69DGboJMg for ; Wed, 16 Sep 2015 06:31:12 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 EBC8F1B3B3F for ; Wed, 16 Sep 2015 06:31:11 -0700 (PDT) Received: from localhost ([::1]:51447 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZcCnn-0000pY-N5; Wed, 16 Sep 2015 06:31:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-control-plane@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Wed, 16 Sep 2015 13:31:11 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/13#comment:1 Message-ID: <081.03bc2d7188f35088c425ec8fa274d04a@tools.ietf.org> References: <066.e47bcbfaf64ea83e17548ea0b67b4a27@tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <066.e47bcbfaf64ea83e17548ea0b67b4a27@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-control-plane@tools.ietf.org, mohamed.boucadair@orange.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-control-plane@ietf.org Resent-Message-Id: <20150916133111.EBC8F1B3B3F@ietfa.amsl.com> Resent-Date: Wed, 16 Sep 2015 06:31:11 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Wed, 16 Sep 2015 07:51:28 -0700 Cc: sfc@ietf.org Subject: Re: [sfc] #13 (control-plane): Sumandra Majee's comments 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, 16 Sep 2015 13:31:13 -0000 #13: Sumandra Majee's comments Changes (by mohamed.boucadair@orange.com): * owner: draft-ietf-sfc-architecture@tools.ietf.org => draft-ietf-sfc- control-plane@tools.ietf.org * component: architecture => control-plane -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | control-plane@tools.ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: control-plane | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Wed Sep 16 07:51: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 E97321B3B5C for ; Wed, 16 Sep 2015 06:32:45 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OGIasipgi3b for ; Wed, 16 Sep 2015 06:32:43 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 174AB1B3B57 for ; Wed, 16 Sep 2015 06:32:43 -0700 (PDT) Received: from localhost ([::1]:51482 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZcCpG-0004qu-Af; Wed, 16 Sep 2015 06:32:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-control-plane@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Wed, 16 Sep 2015 13:32:42 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/14 Message-ID: <066.30544c61f7d483f2c92b00ddfacd598d@tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-control-plane@tools.ietf.org, mohamed.boucadair@orange.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-control-plane@ietf.org Resent-Message-Id: <20150916133243.174AB1B3B57@ietfa.amsl.com> Resent-Date: Wed, 16 Sep 2015 06:32:43 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Wed, 16 Sep 2015 07:51:48 -0700 Cc: sfc@ietf.org Subject: [sfc] #14 (control-plane): Taeho's Comments 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, 16 Sep 2015 13:32:46 -0000 #14: Taeho's Comments IMHO, for SFC resiliency, the aspect of high availability of SF/SFF should be emphasized, including failover of SF. Some attributes of SFF(e.g. high capacity) and SF(mandatory/optional) could be considered for dynamic path selection and connectivity of SFs. (http://datatracker.ietf.org/doc/draft-kang-sfc-dynamic-path-selection/) Dynamic path selection of multiple instances of SF can be used for policy- based load balancing as well. Draft-ww-sfc-control-plane-06 treats resiliency and load balancing, and I think these parts could be further extended with support of WG. Best Regards, Taeho -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc-control- mohamed.boucadair@orange.com | plane@tools.ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: control-plane | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Wed Sep 16 07:52:08 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 51FAE1B3BFD for ; Wed, 16 Sep 2015 06:46:48 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nloemN7PO1dY for ; Wed, 16 Sep 2015 06:46:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 16AEB1B3BFB for ; Wed, 16 Sep 2015 06:46:47 -0700 (PDT) Received: from localhost ([::1]:51920 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZcD2s-0006Lh-Os; Wed, 16 Sep 2015 06:46:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-control-plane@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Wed, 16 Sep 2015 13:46:46 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/15 Message-ID: <066.a5062f0b71b46ed47abec3662c87c450@tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-control-plane@tools.ietf.org, mohamed.boucadair@orange.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-control-plane@ietf.org Resent-Message-Id: <20150916134647.16AEB1B3BFB@ietfa.amsl.com> Resent-Date: Wed, 16 Sep 2015 06:46:47 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Wed, 16 Sep 2015 07:52:06 -0700 Cc: sfc@ietf.org Subject: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc. 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, 16 Sep 2015 13:46:48 -0000 #15: Whether the control plane operates on SFC IDs, SFP IDs, etc. The draft includes this note: [[Note: The question of whether the data plane operates just in terms of SFP IDs or needs SFC IDs, as described in this version of the draft, is still under discussion among the authors.]] The current version of the draft is more generic as it does not preclude manipulating service chains based on an identifier of the chain. Also, it does not assume that the SFP indirection level is mandatory (SFP IDs). Note the current version accommodates various deployment contexts: e.g., rely solely on a chain ID, rely on a chain ID and a SFP, supply a strict path, supply a loose path, etc. The purpose is to not dictate deployment choices on how forwarding is actually achieved within an SFC-enabled domain. An identifier of the chain is the minimum information that is needed, but other information may be supplied as well. Feedback from the WG about which information to supply is needed. FWIW, there is a ticket issue for this issue for the nsh spec. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc-control- mohamed.boucadair@orange.com | plane@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: control-plane | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Wed Sep 16 07:52:27 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 464E21B3C2B for ; Wed, 16 Sep 2015 06:49:36 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6A4I6GOYSMx for ; Wed, 16 Sep 2015 06:49:35 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 275691B3C29 for ; Wed, 16 Sep 2015 06:49:35 -0700 (PDT) Received: from localhost ([::1]:51979 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZcD5a-0006pq-UU; Wed, 16 Sep 2015 06:49:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-control-plane@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Wed, 16 Sep 2015 13:49:34 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/12#comment:1 Message-ID: <081.8aac95d02b910b80e0aac0cd33a86343@tools.ietf.org> References: <066.b9c0bf0afb954ba77cd50884cf983935@tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <066.b9c0bf0afb954ba77cd50884cf983935@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-control-plane@tools.ietf.org, mohamed.boucadair@orange.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-control-plane@ietf.org Resent-Message-Id: <20150916134935.275691B3C29@ietfa.amsl.com> Resent-Date: Wed, 16 Sep 2015 06:49:35 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Wed, 16 Sep 2015 07:52:21 -0700 Cc: sfc@ietf.org Subject: Re: [sfc] #12 (control-plane): Remove "SFC/SFP Diagnosis" Section 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, 16 Sep 2015 13:49:36 -0000 #12: Remove "SFC/SFP Diagnosis" Section Changes (by mohamed.boucadair@orange.com): * status: new => closed * resolution: => fixed Comment: Removed from draft-ietf-sfc-control-plane-00. This sentence was added to Section 3.1 Note, the SFC control plane must be able to invoke SFC OAM mechanisms, and to determine the results of OAM operations. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc- mohamed.boucadair@orange.com | control-plane@tools.ietf.org Type: task | Status: closed Priority: minor | Milestone: Component: control-plane | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Wed Sep 16 10:15: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 7FDB41B3B91 for ; Wed, 16 Sep 2015 10:15:16 -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 Dn_l-ztZYHiz for ; Wed, 16 Sep 2015 10:15:15 -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 778A61B3936 for ; Wed, 16 Sep 2015 10:15:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 391BC4E0028; Wed, 16 Sep 2015 10:15:15 -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 A855D1C0899; Wed, 16 Sep 2015 10:15:14 -0700 (PDT) To: sfc issue tracker , draft-ietf-sfc-control-plane@tools.ietf.org, mohamed.boucadair@orange.com References: <066.a5062f0b71b46ed47abec3662c87c450@tools.ietf.org> From: "Joel M. Halpern" Message-ID: <55F9A3A1.8000100@joelhalpern.com> Date: Wed, 16 Sep 2015 13:15:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <066.a5062f0b71b46ed47abec3662c87c450@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc. 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, 16 Sep 2015 17:15:16 -0000 Given that we have an adopted architecture that specifies that the system should function in terms of service function paths, I would prefer that the control requirements draft align with the architecture in that regard. We are, as far as I know, specifying the requirements for control mechanisms in support of the architecture and data plane we standardize. Yours, Joel On 9/16/15 9:46 AM, sfc issue tracker wrote: > #15: Whether the control plane operates on SFC IDs, SFP IDs, etc. > > The draft includes this note: > > [[Note: The question of whether the data plane operates just in > terms of SFP IDs or needs SFC IDs, as described in this version > of the draft, is still under discussion among the authors.]] > > The current version of the draft is more generic as it does not preclude > manipulating service chains based on an identifier of the chain. Also, it > does not assume that the SFP indirection level is mandatory (SFP IDs). > > Note the current version accommodates various deployment contexts: e.g., > rely solely on a chain ID, rely on a chain ID and a SFP, supply a strict > path, supply a loose path, etc. The purpose is to not dictate deployment > choices on how forwarding is actually achieved within an SFC-enabled > domain. > > An identifier of the chain is the minimum information that is needed, but > other information may be supplied as well. > > Feedback from the WG about which information to supply is needed. > > FWIW, there is a ticket issue for this issue for the nsh spec. > From nobody Wed Sep 16 10:16: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 AB9141B3D3B for ; Wed, 16 Sep 2015 10:16:31 -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 0NqvQ49PDlBI for ; Wed, 16 Sep 2015 10:16:30 -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 95A581B3DDF for ; Wed, 16 Sep 2015 10:16:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8061A4E0028; Wed, 16 Sep 2015 10:16:27 -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 ECF784E0021; Wed, 16 Sep 2015 10:16:26 -0700 (PDT) To: sfc issue tracker , draft-ietf-sfc-control-plane@tools.ietf.org, mohamed.boucadair@orange.com References: <066.b9c0bf0afb954ba77cd50884cf983935@tools.ietf.org> <081.8aac95d02b910b80e0aac0cd33a86343@tools.ietf.org> From: "Joel M. Halpern" Message-ID: <55F9A3E9.1010209@joelhalpern.com> Date: Wed, 16 Sep 2015 13:16:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <081.8aac95d02b910b80e0aac0cd33a86343@tools.ietf.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sfc@ietf.org Subject: Re: [sfc] #12 (control-plane): Remove "SFC/SFP Diagnosis" Section 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, 16 Sep 2015 17:16:31 -0000 I do not consider this issue closed or fixed. More generally, as a working group document, the working group needs to agree to the resolution the authors make before any issue is considered closed. Yours, Joel On 9/16/15 9:49 AM, sfc issue tracker wrote: > #12: Remove "SFC/SFP Diagnosis" Section > > Changes (by mohamed.boucadair@orange.com): > > * status: new => closed > * resolution: => fixed > > > Comment: > > Removed from draft-ietf-sfc-control-plane-00. > > This sentence was added to Section 3.1 > > > Note, the SFC control plane must be able to invoke SFC OAM > mechanisms, and to determine the results of OAM operations. > From nobody Thu Sep 17 04:33: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 669BB1B2D41 for ; Thu, 17 Sep 2015 04:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 o0KDwStD0Gdw for ; Thu, 17 Sep 2015 04:33:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBAF21B2D3D for ; Thu, 17 Sep 2015 04:33:30 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 31E1622CB4F; Thu, 17 Sep 2015 13:33:29 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.61]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1124535C070; Thu, 17 Sep 2015 13:33:29 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0248.002; Thu, 17 Sep 2015 13:33:28 +0200 From: To: "Joel M. Halpern" , sfc issue tracker , "draft-ietf-sfc-control-plane@tools.ietf.org" Thread-Topic: [sfc] #12 (control-plane): Remove "SFC/SFP Diagnosis" Section Thread-Index: AQHQ8KNuwegz1AIYx0qXpLr9yPTjgZ5AlfZA Date: Thu, 17 Sep 2015 11:33:28 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300539507D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <066.b9c0bf0afb954ba77cd50884cf983935@tools.ietf.org> <081.8aac95d02b910b80e0aac0cd33a86343@tools.ietf.org> <55F9A3E9.1010209@joelhalpern.com> In-Reply-To: <55F9A3E9.1010209@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.17.103615 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] #12 (control-plane): Remove "SFC/SFP Diagnosis" Section 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, 17 Sep 2015 11:33:32 -0000 Hi Joel, The issue is "closed" as there is no such section in draft-ietf-sfc-control= -plane-00!=20 We had a note in draft-ww that basically says that we need to move that sec= tion once an OAM draft is adopted by the WG. I created an issue in the trac= ker so that the authors of the OAM draft are aware of that text, fwiw.=20 Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Envoy=E9=A0: mercredi 16 septembre 2015 19:16 > =C0=A0: sfc issue tracker; draft-ietf-sfc-control-plane@tools.ietf.org; > BOUCADAIR Mohamed IMT/OLN > Cc=A0: sfc@ietf.org > Objet=A0: Re: [sfc] #12 (control-plane): Remove "SFC/SFP Diagnosis" Secti= on >=20 > I do not consider this issue closed or fixed. >=20 > More generally, as a working group document, the working group needs to > agree to the resolution the authors make before any issue is considered > closed. >=20 > Yours, > Joel >=20 > On 9/16/15 9:49 AM, sfc issue tracker wrote: > > #12: Remove "SFC/SFP Diagnosis" Section > > > > Changes (by mohamed.boucadair@orange.com): > > > > * status: new =3D> closed > > * resolution: =3D> fixed > > > > > > Comment: > > > > Removed from draft-ietf-sfc-control-plane-00. > > > > This sentence was added to Section 3.1 > > > > > > Note, the SFC control plane must be able to invoke SFC OAM > > mechanisms, and to determine the results of OAM operations. > > From nobody Thu Sep 17 04:53:40 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 EAC6C1B2D6D for ; Thu, 17 Sep 2015 04:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 KiLgkgJqLzoV for ; Thu, 17 Sep 2015 04:53:28 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5B11B2D7C for ; Thu, 17 Sep 2015 04:53:28 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id B98E32AC41E; Thu, 17 Sep 2015 13:53:26 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.57]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 97B23C804F; Thu, 17 Sep 2015 13:53:26 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0248.002; Thu, 17 Sep 2015 13:53:26 +0200 From: To: "Joel M. Halpern" , sfc issue tracker , "draft-ietf-sfc-control-plane@tools.ietf.org" Thread-Topic: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc. Thread-Index: AQHQ8KND9nmb2XDqT0i0s5pcNVz1gp5AmM9Q Date: Thu, 17 Sep 2015 11:53:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330053950B1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <066.a5062f0b71b46ed47abec3662c87c450@tools.ietf.org> <55F9A3A1.8000100@joelhalpern.com> In-Reply-To: <55F9A3A1.8000100@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.17.103615 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc. 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, 17 Sep 2015 11:53:35 -0000 Re-, The control draft as it stands is compliant with the data plane architectur= e document.=20 Indeed, the arch draft acknowledges the following:=20 (1) SFPs are "associated with a given SFC".=20 (2) SFPs are presented as a form of constrained SFCs.=20 (3) Some deployments may not impose any constraint on the abstract SFC. (4) Some others may impose either loose or strict routes. =20 Requiring SFP IDs for deployments that do not impose any constraint on the = SFC is an oxymoron because according to the data plane architecture, an SFP= is a "constrained version of the original SFC". For deployments that do not impose any constraint on the abstract SFC, but = adopt a fully distributed SFC forwarding strategy, a chain identifier is su= fficient. Because an SFP may be associated with several SFCs, the identifier of the S= FC may be required to associate an SFP with its SFC.=20 Below an excerpt from the arch draft, fwiw: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A service function path (SFP) is a mechanism used by service chaining to express the result of applying more granular policy and operational constraints to the abstract requirements of a service chain (SFC). This architecture does not mandate the degree of specificity of the SFP. Architecturally, within the same SFC-enabled domain, some SFPs may be fully specified, selecting exactly which SFF and which SF are to be visited by packets using that SFP, while other SFPs may be quite vague, deferring to the SFF the decisions about the exact sequence of steps to be used to realize the SFC. The specificity may be anywhere in between these extremes. As an example of such an intermediate specificity, there may be two SFPs associated with a given SFC, where one SFP specifies that any order of SFF and SF may be used as long as it is within data center 1, and where the second SFP allows the same latitude, but only within data center 2. Thus, the policies and logic of SFP selection or creation (depending upon the solution) produce what may be thought of as a constrained version of the original SFC. Since multiple policies may apply to different traffic that uses the same SFC, it also follows that there may be multiple SFPs may be associated with a single SFC. =3D=3D=3D=3D=3D=3D=3D Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Envoy=E9=A0: mercredi 16 septembre 2015 19:15 > =C0=A0: sfc issue tracker; draft-ietf-sfc-control-plane@tools.ietf.org; > BOUCADAIR Mohamed IMT/OLN > Cc=A0: sfc@ietf.org > Objet=A0: Re: [sfc] #15 (control-plane): Whether the control plane operat= es > on SFC IDs, SFP IDs, etc. >=20 > Given that we have an adopted architecture that specifies that the > system should function in terms of service function paths, I would > prefer that the control requirements draft align with the architecture > in that regard. We are, as far as I know, specifying the requirements > for control mechanisms in support of the architecture and data plane we > standardize. >=20 > Yours, > Joel >=20 > On 9/16/15 9:46 AM, sfc issue tracker wrote: > > #15: Whether the control plane operates on SFC IDs, SFP IDs, etc. > > > > The draft includes this note: > > > > [[Note: The question of whether the data plane operates just > in > > terms of SFP IDs or needs SFC IDs, as described in this > version > > of the draft, is still under discussion among the authors.]] > > > > The current version of the draft is more generic as it does not > preclude > > manipulating service chains based on an identifier of the chain. Also= , > it > > does not assume that the SFP indirection level is mandatory (SFP IDs)= . > > > > Note the current version accommodates various deployment contexts: > e.g., > > rely solely on a chain ID, rely on a chain ID and a SFP, supply a > strict > > path, supply a loose path, etc. The purpose is to not dictate > deployment > > choices on how forwarding is actually achieved within an SFC-enabled > > domain. > > > > An identifier of the chain is the minimum information that is needed, > but > > other information may be supplied as well. > > > > Feedback from the WG about which information to supply is needed. > > > > FWIW, there is a ticket issue for this issue for the nsh spec. > > From nobody Thu Sep 17 08:34: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 5D5301A1B03 for ; Thu, 17 Sep 2015 08:34:06 -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 cnIj0m1LYySa for ; Thu, 17 Sep 2015 08:34:00 -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 760D21A21A7 for ; Thu, 17 Sep 2015 08:34:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 200B55E025E; Thu, 17 Sep 2015 08:34:00 -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 8514E1C0D5E; Thu, 17 Sep 2015 08:33:59 -0700 (PDT) To: mohamed.boucadair@orange.com, "Joel M. Halpern" , sfc issue tracker , "draft-ietf-sfc-control-plane@tools.ietf.org" References: <066.b9c0bf0afb954ba77cd50884cf983935@tools.ietf.org> <081.8aac95d02b910b80e0aac0cd33a86343@tools.ietf.org> <55F9A3E9.1010209@joelhalpern.com> <787AE7BB302AE849A7480A190F8B93300539507D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: <55FADD65.7020900@joelhalpern.com> Date: Thu, 17 Sep 2015 11:33:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300539507D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] #12 (control-plane): Remove "SFC/SFP Diagnosis" Section 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, 17 Sep 2015 15:34:06 -0000 I actually think your proposed resolution for this issue is correct. However, until the WG agrees, it is merely a proposed resolution. We as authors (and you as lead author) do not get to declare issues closed based on our own judgment. Yours, Joel On 9/17/15 7:33 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > The issue is "closed" as there is no such section in draft-ietf-sfc-control-plane-00! > > We had a note in draft-ww that basically says that we need to move that section once an OAM draft is adopted by the WG. I created an issue in the tracker so that the authors of the OAM draft are aware of that text, fwiw. > > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoyé : mercredi 16 septembre 2015 19:16 >> À : sfc issue tracker; draft-ietf-sfc-control-plane@tools.ietf.org; >> BOUCADAIR Mohamed IMT/OLN >> Cc : sfc@ietf.org >> Objet : Re: [sfc] #12 (control-plane): Remove "SFC/SFP Diagnosis" Section >> >> I do not consider this issue closed or fixed. >> >> More generally, as a working group document, the working group needs to >> agree to the resolution the authors make before any issue is considered >> closed. >> >> Yours, >> Joel >> >> On 9/16/15 9:49 AM, sfc issue tracker wrote: >>> #12: Remove "SFC/SFP Diagnosis" Section >>> >>> Changes (by mohamed.boucadair@orange.com): >>> >>> * status: new => closed >>> * resolution: => fixed >>> >>> >>> Comment: >>> >>> Removed from draft-ietf-sfc-control-plane-00. >>> >>> This sentence was added to Section 3.1 >>> >>> >>> Note, the SFC control plane must be able to invoke SFC OAM >>> mechanisms, and to determine the results of OAM operations. >>> From nobody Thu Sep 17 08:37: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 627C51A00CD for ; Thu, 17 Sep 2015 08:37:30 -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 y_Sq1EcS-2NT for ; Thu, 17 Sep 2015 08:37:27 -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 0C1951A8AA5 for ; Thu, 17 Sep 2015 08:37:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id E94281C0E19; Thu, 17 Sep 2015 08:36:59 -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 47B351C00C8; Thu, 17 Sep 2015 08:36:59 -0700 (PDT) To: mohamed.boucadair@orange.com, sfc issue tracker , "draft-ietf-sfc-control-plane@tools.ietf.org" References: <066.a5062f0b71b46ed47abec3662c87c450@tools.ietf.org> <55F9A3A1.8000100@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330053950B1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> From: "Joel M. Halpern" Message-ID: <55FADE19.4000703@joelhalpern.com> Date: Thu, 17 Sep 2015 11:36:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B9330053950B1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc. 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, 17 Sep 2015 15:37:30 -0000 As far as I can tell, there is nothing in the Service Chaining work that requires correlating service path IDs with service chain IDs within the data plane. Any such relationship exists entirely within the control plane or above, and would be driven by requirements other than the data plane. When I look at this document, all of the requirements that talk about service function chain IDs can be accurately captured, in terms of data plane requirements, by service function path IDs. Thus, the requirement that the data plane has is to see such path IDs. Yes, in some deployments those will be 1-1 with chain IDs. They are still path IDs. Introducing a requirement for the data plane to see and work with chain IDs is not grounded in the work of the group. Yours, Joel M. Halpern On 9/17/15 7:53 AM, mohamed.boucadair@orange.com wrote: > Re-, > > The control draft as it stands is compliant with the data plane architecture document. > > Indeed, the arch draft acknowledges the following: > (1) SFPs are "associated with a given SFC". > (2) SFPs are presented as a form of constrained SFCs. > (3) Some deployments may not impose any constraint on the abstract SFC. > (4) Some others may impose either loose or strict routes. > > Requiring SFP IDs for deployments that do not impose any constraint on the SFC is an oxymoron because according to the data plane architecture, an SFP is a "constrained version of the original SFC". > > For deployments that do not impose any constraint on the abstract SFC, but adopt a fully distributed SFC forwarding strategy, a chain identifier is sufficient. > > Because an SFP may be associated with several SFCs, the identifier of the SFC may be required to associate an SFP with its SFC. > > Below an excerpt from the arch draft, fwiw: > ========== > A service function path (SFP) is a mechanism used by service chaining > to express the result of applying more granular policy and > operational constraints to the abstract requirements of a service > chain (SFC). This architecture does not mandate the degree of > specificity of the SFP. Architecturally, within the same SFC-enabled > domain, some SFPs may be fully specified, selecting exactly which SFF > and which SF are to be visited by packets using that SFP, while other > SFPs may be quite vague, deferring to the SFF the decisions about the > exact sequence of steps to be used to realize the SFC. The > specificity may be anywhere in between these extremes. > > As an example of such an intermediate specificity, there may be two > SFPs associated with a given SFC, where one SFP specifies that any > order of SFF and SF may be used as long as it is within data center > 1, and where the second SFP allows the same latitude, but only within > data center 2. > > Thus, the policies and logic of SFP selection or creation (depending > upon the solution) produce what may be thought of as a constrained > version of the original SFC. Since multiple policies may apply to > different traffic that uses the same SFC, it also follows that there > may be multiple SFPs may be associated with a single SFC. > ======= > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoyé : mercredi 16 septembre 2015 19:15 >> À : sfc issue tracker; draft-ietf-sfc-control-plane@tools.ietf.org; >> BOUCADAIR Mohamed IMT/OLN >> Cc : sfc@ietf.org >> Objet : Re: [sfc] #15 (control-plane): Whether the control plane operates >> on SFC IDs, SFP IDs, etc. >> >> Given that we have an adopted architecture that specifies that the >> system should function in terms of service function paths, I would >> prefer that the control requirements draft align with the architecture >> in that regard. We are, as far as I know, specifying the requirements >> for control mechanisms in support of the architecture and data plane we >> standardize. >> >> Yours, >> Joel >> >> On 9/16/15 9:46 AM, sfc issue tracker wrote: >>> #15: Whether the control plane operates on SFC IDs, SFP IDs, etc. >>> >>> The draft includes this note: >>> >>> [[Note: The question of whether the data plane operates just >> in >>> terms of SFP IDs or needs SFC IDs, as described in this >> version >>> of the draft, is still under discussion among the authors.]] >>> >>> The current version of the draft is more generic as it does not >> preclude >>> manipulating service chains based on an identifier of the chain. Also, >> it >>> does not assume that the SFP indirection level is mandatory (SFP IDs). >>> >>> Note the current version accommodates various deployment contexts: >> e.g., >>> rely solely on a chain ID, rely on a chain ID and a SFP, supply a >> strict >>> path, supply a loose path, etc. The purpose is to not dictate >> deployment >>> choices on how forwarding is actually achieved within an SFC-enabled >>> domain. >>> >>> An identifier of the chain is the minimum information that is needed, >> but >>> other information may be supplied as well. >>> >>> Feedback from the WG about which information to supply is needed. >>> >>> FWIW, there is a ticket issue for this issue for the nsh spec. >>> From nobody Thu Sep 17 13:33: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 43BB91A00B0 for ; Thu, 17 Sep 2015 13:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8HFzC3329E-i for ; Thu, 17 Sep 2015 13:33:20 -0700 (PDT) Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4EB1A004E for ; Thu, 17 Sep 2015 13:33:20 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0224.002; Thu, 17 Sep 2015 13:33:19 -0700 From: Ron Parker To: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , sfc issue tracker , "draft-ietf-sfc-control-plane@tools.ietf.org" Thread-Topic: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc. Thread-Index: AQHQ8IYiW030y9EI+EyunoCSB8zDDp4/2suAgAE4bQCAAD5zgP//3IaA Date: Thu, 17 Sep 2015 20:33:19 +0000 Message-ID: References: <066.a5062f0b71b46ed47abec3662c87c450@tools.ietf.org> <55F9A3A1.8000100@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330053950B1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <55FADE19.4000703@joelhalpern.com> In-Reply-To: <55FADE19.4000703@joelhalpern.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc. 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, 17 Sep 2015 20:33:22 -0000 Joel, I agree with your position. Elements of the SFC architecture (e.g., SFF) = need to know about multiple aspects of any particular SFP including which o= f its SF's shall be invoked and in which order, which is the next SFF, if a= ny, etc. It is not unreasonable for it to also know to which chain it bel= ongs, if such knowledge is necessary or beneficial. And if it is benefici= al, this binding can come in the control plane along with the other attribu= tes describing the SFP. Ron -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Thursday, September 17, 2015 11:37 AM To: mohamed.boucadair@orange.com; sfc issue tracker ; draft-ietf-sfc-control-plane@tools.ietf.org Cc: sfc@ietf.org Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates = on SFC IDs, SFP IDs, etc. As far as I can tell, there is nothing in the Service Chaining work that re= quires correlating service path IDs with service chain IDs within the data = plane. Any such relationship exists entirely within the control plane or a= bove, and would be driven by requirements other than the data plane. When = I look at this document, all of the requirements that talk about service fu= nction chain IDs can be accurately captured, in terms of data plane require= ments, by service function path IDs. Thus, the requirement that the data p= lane has is to see such path IDs. Yes, in some deployments those will be 1= -1 with chain IDs. They are still path IDs. Introducing a requirement for the data plane to see and work with chain IDs= is not grounded in the work of the group. Yours, Joel M. Halpern On 9/17/15 7:53 AM, mohamed.boucadair@orange.com wrote: > Re-, > > The control draft as it stands is compliant with the data plane architect= ure document. > > Indeed, the arch draft acknowledges the following: > (1) SFPs are "associated with a given SFC". > (2) SFPs are presented as a form of constrained SFCs. > (3) Some deployments may not impose any constraint on the abstract SFC. > (4) Some others may impose either loose or strict routes. > > Requiring SFP IDs for deployments that do not impose any constraint on th= e SFC is an oxymoron because according to the data plane architecture, an S= FP is a "constrained version of the original SFC". > > For deployments that do not impose any constraint on the abstract SFC, bu= t adopt a fully distributed SFC forwarding strategy, a chain identifier is = sufficient. > > Because an SFP may be associated with several SFCs, the identifier of the= SFC may be required to associate an SFP with its SFC. > > Below an excerpt from the arch draft, fwiw: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > A service function path (SFP) is a mechanism used by service chaining > to express the result of applying more granular policy and > operational constraints to the abstract requirements of a service > chain (SFC). This architecture does not mandate the degree of > specificity of the SFP. Architecturally, within the same SFC-enabled > domain, some SFPs may be fully specified, selecting exactly which SFF > and which SF are to be visited by packets using that SFP, while other > SFPs may be quite vague, deferring to the SFF the decisions about the > exact sequence of steps to be used to realize the SFC. The > specificity may be anywhere in between these extremes. > > As an example of such an intermediate specificity, there may be two > SFPs associated with a given SFC, where one SFP specifies that any > order of SFF and SF may be used as long as it is within data center > 1, and where the second SFP allows the same latitude, but only within > data center 2. > > Thus, the policies and logic of SFP selection or creation (depending > upon the solution) produce what may be thought of as a constrained > version of the original SFC. Since multiple policies may apply to > different traffic that uses the same SFC, it also follows that there > may be multiple SFPs may be associated with a single SFC. > =3D=3D=3D=3D=3D=3D=3D > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : mercredi=20 >> 16 septembre 2015 19:15 =C0 : sfc issue tracker;=20 >> draft-ietf-sfc-control-plane@tools.ietf.org; >> BOUCADAIR Mohamed IMT/OLN >> Cc : sfc@ietf.org >> Objet : Re: [sfc] #15 (control-plane): Whether the control plane=20 >> operates on SFC IDs, SFP IDs, etc. >> >> Given that we have an adopted architecture that specifies that the=20 >> system should function in terms of service function paths, I would=20 >> prefer that the control requirements draft align with the=20 >> architecture in that regard. We are, as far as I know, specifying=20 >> the requirements for control mechanisms in support of the=20 >> architecture and data plane we standardize. >> >> Yours, >> Joel >> >> On 9/16/15 9:46 AM, sfc issue tracker wrote: >>> #15: Whether the control plane operates on SFC IDs, SFP IDs, etc. >>> >>> The draft includes this note: >>> >>> [[Note: The question of whether the data plane operates=20 >>> just >> in >>> terms of SFP IDs or needs SFC IDs, as described in this >> version >>> of the draft, is still under discussion among the=20 >>> authors.]] >>> >>> The current version of the draft is more generic as it does not >> preclude >>> manipulating service chains based on an identifier of the chain.=20 >>> Also, >> it >>> does not assume that the SFP indirection level is mandatory (SFP IDs= ). >>> >>> Note the current version accommodates various deployment contexts: >> e.g., >>> rely solely on a chain ID, rely on a chain ID and a SFP, supply a >> strict >>> path, supply a loose path, etc. The purpose is to not dictate >> deployment >>> choices on how forwarding is actually achieved within an SFC-enabled >>> domain. >>> >>> An identifier of the chain is the minimum information that is=20 >>> needed, >> but >>> other information may be supplied as well. >>> >>> Feedback from the WG about which information to supply is needed. >>> >>> FWIW, there is a ticket issue for this issue for the nsh spec. >>> From nobody Thu Sep 17 23:06: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 5D9811A9092 for ; Thu, 17 Sep 2015 23:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 o7DZgRds5RCf for ; Thu, 17 Sep 2015 23:06:29 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D5B1A908F for ; Thu, 17 Sep 2015 23:06:28 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 5799B2AC866; Fri, 18 Sep 2015 08:06:26 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.2]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 35832C8058; Fri, 18 Sep 2015 08:06:26 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0248.002; Fri, 18 Sep 2015 08:06:26 +0200 From: To: "Joel M. Halpern" , sfc issue tracker , "draft-ietf-sfc-control-plane@tools.ietf.org" Thread-Topic: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc. Thread-Index: AQHQ8V6zIgFEh1dCbUaqFch3Bu1Uop5Bxfbw Date: Fri, 18 Sep 2015 06:06:25 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300539567F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <066.a5062f0b71b46ed47abec3662c87c450@tools.ietf.org> <55F9A3A1.8000100@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330053950B1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <55FADE19.4000703@joelhalpern.com> In-Reply-To: <55FADE19.4000703@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.17.205417 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc. 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, 18 Sep 2015 06:06:31 -0000 Hi Joel, The excerpt I provided from the arch draft clearly shows that extreme cases= are allowed: non-constrained SFCs, fully constrained SFCs, and any variati= on in between. The control plane should be able to accommodate all those ca= ses. The data plane draft is also explicit there is a binding between the servic= e chain and its SFPs. The control plane relies on that ground for the requi= rements it derives for the interfaces that are in scope. It does not mandat= e that correlation should be transported in packets, but it identifies this= is a piece of information that is needed to be communicated via control in= terfaces.=20 The document DOES NOT mandate any IDs.=20 Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Envoy=E9=A0: jeudi 17 septembre 2015 17:37 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; sfc issue tracker; draft-ietf-sfc-cont= rol- > plane@tools.ietf.org > Cc=A0: sfc@ietf.org > Objet=A0: Re: [sfc] #15 (control-plane): Whether the control plane operat= es > on SFC IDs, SFP IDs, etc. >=20 > As far as I can tell, there is nothing in the Service Chaining work that > requires correlating service path IDs with service chain IDs within the > data plane. Any such relationship exists entirely within the control > plane or above, and would be driven by requirements other than the data > plane. When I look at this document, all of the requirements that talk > about service function chain IDs can be accurately captured, in terms of > data plane requirements, by service function path IDs. Thus, the > requirement that the data plane has is to see such path IDs. Yes, in > some deployments those will be 1-1 with chain IDs. They are still path > IDs. >=20 > Introducing a requirement for the data plane to see and work with chain > IDs is not grounded in the work of the group. >=20 > Yours, > Joel M. Halpern >=20 > On 9/17/15 7:53 AM, mohamed.boucadair@orange.com wrote: > > Re-, > > > > The control draft as it stands is compliant with the data plane > architecture document. > > > > Indeed, the arch draft acknowledges the following: > > (1) SFPs are "associated with a given SFC". > > (2) SFPs are presented as a form of constrained SFCs. > > (3) Some deployments may not impose any constraint on the abstract SFC. > > (4) Some others may impose either loose or strict routes. > > > > Requiring SFP IDs for deployments that do not impose any constraint on > the SFC is an oxymoron because according to the data plane architecture, > an SFP is a "constrained version of the original SFC". > > > > For deployments that do not impose any constraint on the abstract SFC, > but adopt a fully distributed SFC forwarding strategy, a chain identifier > is sufficient. > > > > Because an SFP may be associated with several SFCs, the identifier of > the SFC may be required to associate an SFP with its SFC. > > > > Below an excerpt from the arch draft, fwiw: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > A service function path (SFP) is a mechanism used by service > chaining > > to express the result of applying more granular policy and > > operational constraints to the abstract requirements of a service > > chain (SFC). This architecture does not mandate the degree of > > specificity of the SFP. Architecturally, within the same SFC- > enabled > > domain, some SFPs may be fully specified, selecting exactly which > SFF > > and which SF are to be visited by packets using that SFP, while > other > > SFPs may be quite vague, deferring to the SFF the decisions about > the > > exact sequence of steps to be used to realize the SFC. The > > specificity may be anywhere in between these extremes. > > > > As an example of such an intermediate specificity, there may be two > > SFPs associated with a given SFC, where one SFP specifies that any > > order of SFF and SF may be used as long as it is within data center > > 1, and where the second SFP allows the same latitude, but only > within > > data center 2. > > > > Thus, the policies and logic of SFP selection or creation (dependin= g > > upon the solution) produce what may be thought of as a constrained > > version of the original SFC. Since multiple policies may apply to > > different traffic that uses the same SFC, it also follows that ther= e > > may be multiple SFPs may be associated with a single SFC. > > =3D=3D=3D=3D=3D=3D=3D > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Envoy=E9 : mercredi 16 septembre 2015 19:15 > >> =C0 : sfc issue tracker; draft-ietf-sfc-control-plane@tools.ietf.org; > >> BOUCADAIR Mohamed IMT/OLN > >> Cc : sfc@ietf.org > >> Objet : Re: [sfc] #15 (control-plane): Whether the control plane > operates > >> on SFC IDs, SFP IDs, etc. > >> > >> Given that we have an adopted architecture that specifies that the > >> system should function in terms of service function paths, I would > >> prefer that the control requirements draft align with the architecture > >> in that regard. We are, as far as I know, specifying the requirements > >> for control mechanisms in support of the architecture and data plane w= e > >> standardize. > >> > >> Yours, > >> Joel > >> > >> On 9/16/15 9:46 AM, sfc issue tracker wrote: > >>> #15: Whether the control plane operates on SFC IDs, SFP IDs, etc. > >>> > >>> The draft includes this note: > >>> > >>> [[Note: The question of whether the data plane operates > just > >> in > >>> terms of SFP IDs or needs SFC IDs, as described in this > >> version > >>> of the draft, is still under discussion among the > authors.]] > >>> > >>> The current version of the draft is more generic as it does not > >> preclude > >>> manipulating service chains based on an identifier of the chain. > Also, > >> it > >>> does not assume that the SFP indirection level is mandatory (SFP > IDs). > >>> > >>> Note the current version accommodates various deployment contexts: > >> e.g., > >>> rely solely on a chain ID, rely on a chain ID and a SFP, supply a > >> strict > >>> path, supply a loose path, etc. The purpose is to not dictate > >> deployment > >>> choices on how forwarding is actually achieved within an SFC- > enabled > >>> domain. > >>> > >>> An identifier of the chain is the minimum information that is > needed, > >> but > >>> other information may be supplied as well. > >>> > >>> Feedback from the WG about which information to supply is needed. > >>> > >>> FWIW, there is a ticket issue for this issue for the nsh spec. > >>> From nobody Fri Sep 18 08:03:15 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 D972C1A909A for ; Thu, 17 Sep 2015 23:08:20 -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=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnwWiZW2cxOX for ; Thu, 17 Sep 2015 23:08:19 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (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 2AE331A1BC3 for ; Thu, 17 Sep 2015 23:08:19 -0700 (PDT) Received: from localhost ([::1]:39426 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1ZcoqI-0004pv-6W; Thu, 17 Sep 2015 23:08:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "sfc issue tracker" X-Trac-Version: 0.12.5 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.5, by Edgewall Software To: draft-ietf-sfc-control-plane@tools.ietf.org, mohamed.boucadair@orange.com X-Trac-Project: sfc Date: Fri, 18 Sep 2015 06:08:18 -0000 X-URL: http://tools.ietf.org/sfc/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sfc/trac/ticket/16 Message-ID: <066.4de1a1b2496e7fbeb2cea22aa41193b6@tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-sfc-control-plane@tools.ietf.org, mohamed.boucadair@orange.com, sfc@ietf.org X-SA-Exim-Mail-From: trac+sfc@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: draft-ietf-sfc-control-plane@ietf.org Resent-Message-Id: <20150918060819.2AE331A1BC3@ietfa.amsl.com> Resent-Date: Thu, 17 Sep 2015 23:08:19 -0700 (PDT) Resent-From: trac+sfc@tools.ietf.org Archived-At: X-Mailman-Approved-At: Fri, 18 Sep 2015 08:03:13 -0700 Cc: sfc@ietf.org Subject: [sfc] #16 (control-plane): RSP-related Considerations (L. Dunbar/A. Malis) 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, 18 Sep 2015 06:08:21 -0000 #16: RSP-related Considerations (L. Dunbar/A. Malis) Discuss what to do with this appendix. == Appendix A. RSP-related Considerations NOTE: This section records some contributions proposed by L. Dunbar and A. Malis, but have not been discussed yet among authors. A.1. Encoding the Exact SFF-SF-sequence in Data Packets Encoding the exact RSP in every packet has the benefit and the issues associated with source routing. This approach may not be optimal when the SFP doesn't change very frequently, as in minutes or hours. There are contexts that it might not be feasible for the head end Classifier to be notified of the changes of SFF-sequence or SFF-SF- Sequence for a given SFP because of the time taken for the notification and the limited capability of the Classifier nodes. A.2. Fully Controlled SFF-SF-Sequence for a SFP This section describes the information that can be exchanged over C2 interface (Section 3.3.2) when the SFC Control Element explicitly passes the steering policies to all SFFs for the SFF-SF-Sequence of a given SFC. In this model, each SFF doesn't need to signal other SFFs for the SFP. Suppose the SFC ID for this SFP is "yellow", an example of policy to "sff-a" is depicted in Figure 2 (for illustration proposes) Matching | Action ----------------------------------------+------------------------- SFC ID = "yellow" & ingress = sffx-port | next-hop: "sf2" & VID SFC ID = "yellow" & ingress = sf2-port | next-hop: "sf3" & VID SFC ID = "yellow" & ingress = sf3-port | next-hop: sff-b Figure 2: Example of Traffic Steering Policy to a SFF node The SFF nodes may not be directly adjacent to each other. They can be interconnected by tunnels, such as GRE, VxLAN, etc. SFs are attached to a SFF node or SFC Proxy node via Ethernet link or other link types. Therefore, the steering policies to a SFF node for service function chain depends on if the packet comes from previous SFF or comes from a specific SF, i.e., the SFC Forwarding Policy Table entries have to be ingress port specific. There are multiple different steering policies for one flow within one SFF and each set of steering policies is specific for an ingress port. The semantics of traffic steering rules can be "Match" and "Action", similar to the "route" described in [I-D.ietf-i2rs-rib-info-model]. The "match" and "action" for distinct ports can be different. The matching criteria for SFF can be more sophisticated. For example, the matching criteria could be any fields in the data packets: o Ingress port o Destination MAC address o Source MAC address o VLAN_id, o Destination IP address o Source IP address o Source port number o Destination port number o DSCP o Packet size, etc., or any combination thereof. A SFF node may not support some of the matching criteria listed above. It is important that SFC control plane can retrieve the supported matching criteria by SFF nodes. The "Actions" for traffic steering could be to steer traffic to the attached service function or SF instantiations via a specific port. The "Actions" to SFC Proxy may include a method to map the SFC Identifier carried in the packet header to a locally significant link identifier, e.g., VLAN-ID, and a method to construct and encapsulate the SFC header back to the packets when they come back from the attached SFs. This approach does not require using an end-to-end signaling protocol among Classier nodes and SFF nodes. However, there may be problems encountered if SFF nodes are not updated in the proper order or not at the same time. For example, if the SFF "A" and SFF "C" get flow steering policies at slightly different times, some packets might not be directed to some service functions on a chain. ========== -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-sfc-control- mohamed.boucadair@orange.com | plane@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: control-plane | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: sfc From nobody Sat Sep 19 20:02:29 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 BCC341B3695 for ; Sat, 19 Sep 2015 20:02:28 -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 j_yqJ9vCsn96 for ; Sat, 19 Sep 2015 20:02:26 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5241B3694 for ; Sat, 19 Sep 2015 20:02:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7446; q=dns/txt; s=iport; t=1442718146; x=1443927746; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=P4FERAmnuO/bEIkXGmAQsIDZOd6+pCXIiSe9cGJ/DWs=; b=aMdODPD4bZkAi7IJwMG0/lzcm8qD+W4RhKPRr7uGBpYeaUk16FJCzL2K bgCkkCIlzEFu86EqCRPCMzVAM0T2qnv1EITvZ4C6k4/1OiVTtRhzruac0 28qfMkLI9ctASH4RRHdCmoi7rylvrdyo9ghoYkc/yA68o2zp6dNuju9J5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D0AQBxIf5V/4gNJK1dgyRUab1AAQ2BcQqFeQKBHjgUAQEBAQEBAX8LhCMBAQEDAQEBAWsEBwULAgEIEgYnBycLFAMOAgQOBRuICwgNyW4BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIZzgg+CboRIEjMHgxiBFAWNNoguAYd+hQiBTYdWhyOKUwEfAQFCgkOBPnGJbQEBAQ X-IronPort-AV: E=Sophos;i="5.17,560,1437436800"; d="scan'208";a="189389231" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Sep 2015 03:02:25 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t8K32OoA019581 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 20 Sep 2015 03:02:24 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 19 Sep 2015 22:02:24 -0500 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.000; Sat, 19 Sep 2015 22:02:24 -0500 From: "Carlos Pignataro (cpignata)" To: "mohamed.boucadair@orange.com" Thread-Topic: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc. Thread-Index: AQHQ8V6zW030y9EI+EyunoCSB8zDDp5BxfbwgAL42Pc= Date: Sun, 20 Sep 2015 03:02:23 +0000 Message-ID: <70ABF9A1-38A5-4A41-B533-BDF607E186C2@cisco.com> References: <066.a5062f0b71b46ed47abec3662c87c450@tools.ietf.org> <55F9A3A1.8000100@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330053950B1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <55FADE19.4000703@joelhalpern.com>, <787AE7BB302AE849A7480A190F8B93300539567F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300539567F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sfc-control-plane@tools.ietf.org" , "Joel M. Halpern" , sfc issue tracker , "sfc@ietf.org" Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc. 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: Sun, 20 Sep 2015 03:02:28 -0000 Med, It seems to me you are reading what you want to read from the architecture = and data plane documents, and not what it's actually there.=20 Where are service chain IDs within the data plane? Thanks, Thumb typed by Carlos Pignataro. Excuze typofraphicak errows > On Sep 18, 2015, at 02:06, "mohamed.boucadair@orange.com" wrote: >=20 > Hi Joel, >=20 > The excerpt I provided from the arch draft clearly shows that extreme cas= es are allowed: non-constrained SFCs, fully constrained SFCs, and any varia= tion in between. The control plane should be able to accommodate all those = cases. >=20 > The data plane draft is also explicit there is a binding between the serv= ice chain and its SFPs. The control plane relies on that ground for the req= uirements it derives for the interfaces that are in scope. It does not mand= ate that correlation should be transported in packets, but it identifies th= is is a piece of information that is needed to be communicated via control = interfaces.=20 >=20 > The document DOES NOT mandate any IDs.=20 >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoy=E9 : jeudi 17 septembre 2015 17:37 >> =C0 : BOUCADAIR Mohamed IMT/OLN; sfc issue tracker; draft-ietf-sfc-contr= ol- >> plane@tools.ietf.org >> Cc : sfc@ietf.org >> Objet : Re: [sfc] #15 (control-plane): Whether the control plane operate= s >> on SFC IDs, SFP IDs, etc. >>=20 >> As far as I can tell, there is nothing in the Service Chaining work that >> requires correlating service path IDs with service chain IDs within the >> data plane. Any such relationship exists entirely within the control >> plane or above, and would be driven by requirements other than the data >> plane. When I look at this document, all of the requirements that talk >> about service function chain IDs can be accurately captured, in terms of >> data plane requirements, by service function path IDs. Thus, the >> requirement that the data plane has is to see such path IDs. Yes, in >> some deployments those will be 1-1 with chain IDs. They are still path >> IDs. >>=20 >> Introducing a requirement for the data plane to see and work with chain >> IDs is not grounded in the work of the group. >>=20 >> Yours, >> Joel M. Halpern >>=20 >>> On 9/17/15 7:53 AM, mohamed.boucadair@orange.com wrote: >>> Re-, >>>=20 >>> The control draft as it stands is compliant with the data plane >> architecture document. >>>=20 >>> Indeed, the arch draft acknowledges the following: >>> (1) SFPs are "associated with a given SFC". >>> (2) SFPs are presented as a form of constrained SFCs. >>> (3) Some deployments may not impose any constraint on the abstract SFC. >>> (4) Some others may impose either loose or strict routes. >>>=20 >>> Requiring SFP IDs for deployments that do not impose any constraint on >> the SFC is an oxymoron because according to the data plane architecture, >> an SFP is a "constrained version of the original SFC". >>>=20 >>> For deployments that do not impose any constraint on the abstract SFC, >> but adopt a fully distributed SFC forwarding strategy, a chain identifie= r >> is sufficient. >>>=20 >>> Because an SFP may be associated with several SFCs, the identifier of >> the SFC may be required to associate an SFP with its SFC. >>>=20 >>> Below an excerpt from the arch draft, fwiw: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> A service function path (SFP) is a mechanism used by service >> chaining >>> to express the result of applying more granular policy and >>> operational constraints to the abstract requirements of a service >>> chain (SFC). This architecture does not mandate the degree of >>> specificity of the SFP. Architecturally, within the same SFC- >> enabled >>> domain, some SFPs may be fully specified, selecting exactly which >> SFF >>> and which SF are to be visited by packets using that SFP, while >> other >>> SFPs may be quite vague, deferring to the SFF the decisions about >> the >>> exact sequence of steps to be used to realize the SFC. The >>> specificity may be anywhere in between these extremes. >>>=20 >>> As an example of such an intermediate specificity, there may be two >>> SFPs associated with a given SFC, where one SFP specifies that any >>> order of SFF and SF may be used as long as it is within data center >>> 1, and where the second SFP allows the same latitude, but only >> within >>> data center 2. >>>=20 >>> Thus, the policies and logic of SFP selection or creation (depending >>> upon the solution) produce what may be thought of as a constrained >>> version of the original SFC. Since multiple policies may apply to >>> different traffic that uses the same SFC, it also follows that there >>> may be multiple SFPs may be associated with a single SFC. >>> =3D=3D=3D=3D=3D=3D=3D >>>=20 >>> Cheers, >>> Med >>>=20 >>>> -----Message d'origine----- >>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Envoy=E9 : mercredi 16 septembre 2015 19:15 >>>> =C0 : sfc issue tracker; draft-ietf-sfc-control-plane@tools.ietf.org; >>>> BOUCADAIR Mohamed IMT/OLN >>>> Cc : sfc@ietf.org >>>> Objet : Re: [sfc] #15 (control-plane): Whether the control plane >> operates >>>> on SFC IDs, SFP IDs, etc. >>>>=20 >>>> Given that we have an adopted architecture that specifies that the >>>> system should function in terms of service function paths, I would >>>> prefer that the control requirements draft align with the architecture >>>> in that regard. We are, as far as I know, specifying the requirements >>>> for control mechanisms in support of the architecture and data plane w= e >>>> standardize. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>>> On 9/16/15 9:46 AM, sfc issue tracker wrote: >>>>> #15: Whether the control plane operates on SFC IDs, SFP IDs, etc. >>>>>=20 >>>>> The draft includes this note: >>>>>=20 >>>>> [[Note: The question of whether the data plane operates >> just >>>> in >>>>> terms of SFP IDs or needs SFC IDs, as described in this >>>> version >>>>> of the draft, is still under discussion among the >> authors.]] >>>>>=20 >>>>> The current version of the draft is more generic as it does not >>>> preclude >>>>> manipulating service chains based on an identifier of the chain. >> Also, >>>> it >>>>> does not assume that the SFP indirection level is mandatory (SFP >> IDs). >>>>>=20 >>>>> Note the current version accommodates various deployment contexts: >>>> e.g., >>>>> rely solely on a chain ID, rely on a chain ID and a SFP, supply a >>>> strict >>>>> path, supply a loose path, etc. The purpose is to not dictate >>>> deployment >>>>> choices on how forwarding is actually achieved within an SFC- >> enabled >>>>> domain. >>>>>=20 >>>>> An identifier of the chain is the minimum information that is >> needed, >>>> but >>>>> other information may be supplied as well. >>>>>=20 >>>>> Feedback from the WG about which information to supply is needed. >>>>>=20 >>>>> FWIW, there is a ticket issue for this issue for the nsh spec. >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Sun Sep 20 22:30: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 665AB1A8826 for ; Sun, 20 Sep 2015 22:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Ntazs5p4NT7i for ; Sun, 20 Sep 2015 22:30:31 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3371C1A8823 for ; Sun, 20 Sep 2015 22:30:30 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 8B6573B425E; Mon, 21 Sep 2015 07:30:28 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.2]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6783438404E; Mon, 21 Sep 2015 07:30:28 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0248.002; Mon, 21 Sep 2015 07:30:28 +0200 From: To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc. Thread-Index: AQHQ8V6zIgFEh1dCbUaqFch3Bu1Uop5BxfbwgAL42PeAAbal0A== Date: Mon, 21 Sep 2015 05:30:27 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933005396026@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <066.a5062f0b71b46ed47abec3662c87c450@tools.ietf.org> <55F9A3A1.8000100@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330053950B1@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <55FADE19.4000703@joelhalpern.com>, <787AE7BB302AE849A7480A190F8B93300539567F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <70ABF9A1-38A5-4A41-B533-BDF607E186C2@cisco.com> In-Reply-To: <70ABF9A1-38A5-4A41-B533-BDF607E186C2@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.21.50315 Archived-At: Cc: "draft-ietf-sfc-control-plane@tools.ietf.org" , "Joel M. Halpern" , sfc issue tracker , "sfc@ietf.org" Subject: Re: [sfc] #15 (control-plane): Whether the control plane operates on SFC IDs, SFP IDs, etc. 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, 21 Sep 2015 05:30:34 -0000 Hi Carlos, As I mentioned in my previous message to Joel, the control plane draft DOES= NOT mandate any IDs. It lists a set of information that is needed to be in= structed via control plane interfaces. I'm arguing that not only SFPs are n= eeded to be communicated to the control points, but also service chains.=20 Please refer to the excerpt from the data plane arch I included in one of m= y messages.=20 FWIW, there is a ticket for the NSH specification draft since almost 5 mont= hs: http://trac.tools.ietf.org/wg/sfc/trac/ticket/1=20 Cheers, Med > -----Message d'origine----- > De=A0: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Envoy=E9=A0: dimanche 20 septembre 2015 05:02 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: Joel M. Halpern; sfc issue tracker; draft-ietf-sfc-control- > plane@tools.ietf.org; sfc@ietf.org > Objet=A0: Re: [sfc] #15 (control-plane): Whether the control plane operat= es > on SFC IDs, SFP IDs, etc. >=20 > Med, >=20 > It seems to me you are reading what you want to read from the architectur= e > and data plane documents, and not what it's actually there. >=20 > Where are service chain IDs within the data plane? >=20 > Thanks, >=20 > Thumb typed by Carlos Pignataro. > Excuze typofraphicak errows >=20 > > On Sep 18, 2015, at 02:06, "mohamed.boucadair@orange.com" > wrote: > > > > Hi Joel, > > > > The excerpt I provided from the arch draft clearly shows that extreme > cases are allowed: non-constrained SFCs, fully constrained SFCs, and any > variation in between. The control plane should be able to accommodate all > those cases. > > > > The data plane draft is also explicit there is a binding between the > service chain and its SFPs. The control plane relies on that ground for > the requirements it derives for the interfaces that are in scope. It does > not mandate that correlation should be transported in packets, but it > identifies this is a piece of information that is needed to be > communicated via control interfaces. > > > > The document DOES NOT mandate any IDs. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Envoy=E9 : jeudi 17 septembre 2015 17:37 > >> =C0 : BOUCADAIR Mohamed IMT/OLN; sfc issue tracker; draft-ietf-sfc- > control- > >> plane@tools.ietf.org > >> Cc : sfc@ietf.org > >> Objet : Re: [sfc] #15 (control-plane): Whether the control plane > operates > >> on SFC IDs, SFP IDs, etc. > >> > >> As far as I can tell, there is nothing in the Service Chaining work > that > >> requires correlating service path IDs with service chain IDs within th= e > >> data plane. Any such relationship exists entirely within the control > >> plane or above, and would be driven by requirements other than the dat= a > >> plane. When I look at this document, all of the requirements that tal= k > >> about service function chain IDs can be accurately captured, in terms > of > >> data plane requirements, by service function path IDs. Thus, the > >> requirement that the data plane has is to see such path IDs. Yes, in > >> some deployments those will be 1-1 with chain IDs. They are still pat= h > >> IDs. > >> > >> Introducing a requirement for the data plane to see and work with chai= n > >> IDs is not grounded in the work of the group. > >> > >> Yours, > >> Joel M. Halpern > >> > >>> On 9/17/15 7:53 AM, mohamed.boucadair@orange.com wrote: > >>> Re-, > >>> > >>> The control draft as it stands is compliant with the data plane > >> architecture document. > >>> > >>> Indeed, the arch draft acknowledges the following: > >>> (1) SFPs are "associated with a given SFC". > >>> (2) SFPs are presented as a form of constrained SFCs. > >>> (3) Some deployments may not impose any constraint on the abstract > SFC. > >>> (4) Some others may impose either loose or strict routes. > >>> > >>> Requiring SFP IDs for deployments that do not impose any constraint o= n > >> the SFC is an oxymoron because according to the data plane > architecture, > >> an SFP is a "constrained version of the original SFC". > >>> > >>> For deployments that do not impose any constraint on the abstract SFC= , > >> but adopt a fully distributed SFC forwarding strategy, a chain > identifier > >> is sufficient. > >>> > >>> Because an SFP may be associated with several SFCs, the identifier of > >> the SFC may be required to associate an SFP with its SFC. > >>> > >>> Below an excerpt from the arch draft, fwiw: > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> A service function path (SFP) is a mechanism used by service > >> chaining > >>> to express the result of applying more granular policy and > >>> operational constraints to the abstract requirements of a service > >>> chain (SFC). This architecture does not mandate the degree of > >>> specificity of the SFP. Architecturally, within the same SFC- > >> enabled > >>> domain, some SFPs may be fully specified, selecting exactly which > >> SFF > >>> and which SF are to be visited by packets using that SFP, while > >> other > >>> SFPs may be quite vague, deferring to the SFF the decisions about > >> the > >>> exact sequence of steps to be used to realize the SFC. The > >>> specificity may be anywhere in between these extremes. > >>> > >>> As an example of such an intermediate specificity, there may be tw= o > >>> SFPs associated with a given SFC, where one SFP specifies that any > >>> order of SFF and SF may be used as long as it is within data cente= r > >>> 1, and where the second SFP allows the same latitude, but only > >> within > >>> data center 2. > >>> > >>> Thus, the policies and logic of SFP selection or creation > (depending > >>> upon the solution) produce what may be thought of as a constrained > >>> version of the original SFC. Since multiple policies may apply to > >>> different traffic that uses the same SFC, it also follows that > there > >>> may be multiple SFPs may be associated with a single SFC. > >>> =3D=3D=3D=3D=3D=3D=3D > >>> > >>> Cheers, > >>> Med > >>> > >>>> -----Message d'origine----- > >>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] > >>>> Envoy=E9 : mercredi 16 septembre 2015 19:15 > >>>> =C0 : sfc issue tracker; draft-ietf-sfc-control-plane@tools.ietf.org= ; > >>>> BOUCADAIR Mohamed IMT/OLN > >>>> Cc : sfc@ietf.org > >>>> Objet : Re: [sfc] #15 (control-plane): Whether the control plane > >> operates > >>>> on SFC IDs, SFP IDs, etc. > >>>> > >>>> Given that we have an adopted architecture that specifies that the > >>>> system should function in terms of service function paths, I would > >>>> prefer that the control requirements draft align with the > architecture > >>>> in that regard. We are, as far as I know, specifying the > requirements > >>>> for control mechanisms in support of the architecture and data plane > we > >>>> standardize. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>>> On 9/16/15 9:46 AM, sfc issue tracker wrote: > >>>>> #15: Whether the control plane operates on SFC IDs, SFP IDs, etc. > >>>>> > >>>>> The draft includes this note: > >>>>> > >>>>> [[Note: The question of whether the data plane operates > >> just > >>>> in > >>>>> terms of SFP IDs or needs SFC IDs, as described in this > >>>> version > >>>>> of the draft, is still under discussion among the > >> authors.]] > >>>>> > >>>>> The current version of the draft is more generic as it does not > >>>> preclude > >>>>> manipulating service chains based on an identifier of the chain. > >> Also, > >>>> it > >>>>> does not assume that the SFP indirection level is mandatory (SFP > >> IDs). > >>>>> > >>>>> Note the current version accommodates various deployment contexts= : > >>>> e.g., > >>>>> rely solely on a chain ID, rely on a chain ID and a SFP, supply a > >>>> strict > >>>>> path, supply a loose path, etc. The purpose is to not dictate > >>>> deployment > >>>>> choices on how forwarding is actually achieved within an SFC- > >> enabled > >>>>> domain. > >>>>> > >>>>> An identifier of the chain is the minimum information that is > >> needed, > >>>> but > >>>>> other information may be supplied as well. > >>>>> > >>>>> Feedback from the WG about which information to supply is needed. > >>>>> > >>>>> FWIW, there is a ticket issue for this issue for the nsh spec. > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Sep 21 01:26:21 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 3D2F41A89BB for ; Mon, 21 Sep 2015 01:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.36 X-Spam-Level: X-Spam-Status: No, score=-100.36 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 tPFsYW88u_YV for ; Mon, 21 Sep 2015 01:26:16 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7357A1A89C5 for ; Mon, 21 Sep 2015 01:26:16 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 4D61F630B0F5A for ; Mon, 21 Sep 2015 16:16:43 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 5B93D11D73018 for ; Mon, 21 Sep 2015 16:26:10 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t8L8PYLp086694 for ; Mon, 21 Sep 2015 16:25:34 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn) In-Reply-To: <20150921081357.8630.47947.idtracker@ietfa.amsl.com> References: <20150921081357.8630.47947.idtracker@ietfa.amsl.com> To: "'sfc@ietf.org'" MIME-Version: 1.0 X-KeepSent: 14418120:6B38098A-48257EC7:002DE822; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: wang.cui1@zte.com.cn Date: Mon, 21 Sep 2015 16:25:34 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-09-21 16:25:22, Serialize complete at 2015-09-21 16:25:22 Content-Type: multipart/alternative; boundary="=_alternative 002E49F548257EC7_=" X-MAIL: mse01.zte.com.cn t8L8PYLp086694 Archived-At: Cc: Wei Meng , Cui Wang Subject: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-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, 21 Sep 2015 08:26:19 -0000 This is a multipart message in MIME format. --=_alternative 002E49F548257EC7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 RGVhciBhbGwsDQoNCiAgIEhlcmUgaXMgYSBuZXcgZHJhZnQgcHJvcG9zZWQgdG8gcmFpc2UgYW4g aXNzdWUgd2hpY2ggbWF5IGV4aXN0IHdoZW4gTUQgDQpUeXBlPTB4MDEgaXMgbWFuZGF0b3J5Lg0K QW5kIHRvIG1vdGl2YXRlIHRoZSBmdXJ0aGVyIGRpc2N1c3Npb24gYWJvdXQgTUQgVHlwZS4gV2lz aCB5b3UgY2FuIHBheSANCmF0dGVudGlvbiB0byB0aGlzIHRvIA0KY29udGludWUgdGhlIGRpc2N1 c3Npb24gYW5kIG1ha2UgYSBjb25zZW5zdXMgOykNCg0KICBUaGFua3MuLg0KDQpCZXN0IFdpc2hl cywNCkxpbmRhIFdhbmcNCg0KIA0KDQoNCmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyDQtNPaIDIw MTUvMDkvMjEgMTY6MTM6NTc6DQoNCj4gaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIA0KPiAyMDE1 LzA5LzIxIDE2OjEzDQo+IA0KPiDK1bz+yMsNCj4gDQo+ICJDdWkgV2FuZyIgPHdhbmcuY3VpMUB6 dGUuY29tLmNuPiwgIldlaSBNZW5nIiANCj4gPG1lbmcud2VpMkB6dGUuY29tLmNuPiwgIkN1aSBX YW5nIiA8d2FuZy5jdWkxQHp0ZS5jb20uY24+LCAiV2VpIA0KPiBNZW5nIiA8bWVuZy53ZWkyQHp0 ZS5jb20uY24+LCANCj4gDQo+ILOty80NCj4gDQo+INb3zOINCj4gDQo+IE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FuZy1zZmMtbWQtdHlwZS1pc3N1ZXMtMDAudHh0DQo+IA0K PiANCj4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNzdWVz LTAwLnR4dA0KPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEN1aSBXYW5nIGFu ZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6ICAgICAgZHJh ZnQtd2FuZy1zZmMtbWQtdHlwZS1pc3N1ZXMNCj4gUmV2aXNpb246ICAgMDANCj4gVGl0bGU6ICAg ICAgTWV0YWRhdGEgVHlwZSBJc3N1ZXMNCj4gRG9jdW1lbnQgZGF0ZTogICAyMDE1LTA5LTIxDQo+ IEdyb3VwOiAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQYWdlczogICAgICAxNA0KPiBV Ukw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0 LXdhbmctc2ZjLQ0KPiBtZC10eXBlLWlzc3Vlcy0wMC50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhbmctc2ZjLW1kLQ0KPiB0eXBl LWlzc3Vlcy8NCj4gSHRtbGl6ZWQ6ICAgICAgIA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNzdWVzLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ ICAgIFNlcnZpY2UgZnVuY3Rpb24gY2hhaW4gaXMgdGhlIGRlZmluaXRpb24gb2YgYW4gb3JkZXJl ZCBzZXQgb2Ygc2VydmljZQ0KPiAgICBmdW5jdGlvbnMuICBBZnRlciBpbnN0YW50aWF0ZWQsIHRo ZSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggaXMgY3JlYXRlZA0KPiAgICBhbmQgdGhlIGNsYXNzaWZp ZWQgdHJhZmZpYyBpcyBzdGVlcmVkIHRocm91Z2ggdGhlIGNvcnJlc3BvbmRpbmcNCj4gICAgc2Vy dmljZSBmdW5jdGlvbiBwYXRoIGFuZCB0aGVuIGZvcndhcmRlZCB0byB0aGUgZmluYWwgZGVzdGlu YXRpb24uDQo+ICAgIE1ldGFkYXRhIChNRCkgaXMgY29udmV5ZWQgaW4gU0ZDIGRhdGEgcGxhbmUg d2hpY2ggcHJvdmlkZXMgdGhlDQo+ICAgIGFiaWxpdHkgdG8gZXhjaGFuZ2UgY29udGV4dCBpbmZv cm1hdGlvbiBiZXR3ZWVuIGNsYXNzaWZpZXJzIGFuZCBTRnMsDQo+ICAgIGFtb25nIFNGcywgYW5k IGJldHdlZW4gZXh0ZXJuYWwgc3lzdGVtcyBhbmQgU0ZzLiAgVGhpcyBkb2N1bWVudCBpcw0KPiAg ICBtb3RpdmF0ZWQgdG8gc3RhdGUgYW4gaXNzdWUgd2hlbiBNRCBUeXBlID0gMHgxIGFuZCBkaXNj dXNzIHdoaWNoDQo+ICAgIE1ldGFkYXRhIFR5cGUgaW4gbW9yZSBhcHByb3ByaWF0ZSB0byBiZSBt YW5kYXRlIGluIFNGQyBkYXRhIHBsYW5lLg0KPiANCj4gIA0KPiANCj4gDQo+IFBsZWFzZSBub3Rl IHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0K c3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4g DQoNCg== --=_alternative 002E49F548257EC7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkRlYXIgYWxsLDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO0hlcmUg aXMgYSBuZXcgZHJhZnQgcHJvcG9zZWQNCnRvIHJhaXNlIGFuIGlzc3VlIHdoaWNoIG1heSBleGlz dCB3aGVuIE1EIFR5cGU9MHgwMSBpcyBtYW5kYXRvcnkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5BbmQgdG8gbW90aXZhdGUgdGhlIGZ1cnRoZXIgZGlzY3Vzc2lv bg0KYWJvdXQgTUQgVHlwZS4gV2lzaCB5b3UgY2FuIHBheSBhdHRlbnRpb24gdG8gdGhpcyB0byA8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmNvbnRpbnVlIHRoZSBk aXNjdXNzaW9uIGFuZCBtYWtlIGEgY29uc2Vuc3VzDQo7KTwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IFRoYW5rcy4uPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5CZXN0IFdpc2hlcyw8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkxpbmRhIFdhbmc8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwvZm9udD4NCjxicj4N Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyDQtNPa IDIwMTUvMDkvMjEgMTY6MTM6NTc6PGJyPg0KPGJyPg0KJmd0OyBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmcgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDIwMTUvMDkvMjEg MTY6MTM8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDK 1bz+yMs8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAm cXVvdDtDdWkgV2FuZyZxdW90OyAmbHQ7d2FuZy5jdWkxQHp0ZS5jb20uY24mZ3Q7LCAmcXVvdDtX ZWkgTWVuZyZxdW90Ow0KPGJyPg0KJmd0OyAmbHQ7bWVuZy53ZWkyQHp0ZS5jb20uY24mZ3Q7LCAm cXVvdDtDdWkgV2FuZyZxdW90OyAmbHQ7d2FuZy5jdWkxQHp0ZS5jb20uY24mZ3Q7LA0KJnF1b3Q7 V2VpIDxicj4NCiZndDsgTWVuZyZxdW90OyAmbHQ7bWVuZy53ZWkyQHp0ZS5jb20uY24mZ3Q7LCA8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyCzrcvNPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg1vfM4jwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FuZy1zZmMtbWQtdHlwZS1pc3N1ZXMtMDAudHh0PC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0 OyBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd2FuZy1zZmMtbWQtdHlwZS1pc3N1ZXMtMDAu dHh0PGJyPg0KJmd0OyBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEN1aSBXYW5n IGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KJmd0OyBJRVRGIHJlcG9zaXRvcnkuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IE5hbWU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtd2FuZy1zZmMtbWQtdHlw ZS1pc3N1ZXM8YnI+DQomZ3Q7IFJldmlzaW9uOiAmbmJzcDsgMDA8YnI+DQomZ3Q7IFRpdGxlOiAm bmJzcDsgJm5ic3A7ICZuYnNwO01ldGFkYXRhIFR5cGUgSXNzdWVzPGJyPg0KJmd0OyBEb2N1bWVu dCBkYXRlOiAmbmJzcDsgMjAxNS0wOS0yMTxicj4NCiZndDsgR3JvdXA6ICZuYnNwOyAmbmJzcDsg Jm5ic3A7SW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KJmd0OyBQYWdlczogJm5ic3A7ICZuYnNw OyAmbmJzcDsxNDxicj4NCiZndDsgVVJMOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC13YW5nLXNmYy0iPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdhbmctc2ZjLTwvZm9udD48L3R0PjwvYT48 dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgbWQtdHlwZS1pc3N1ZXMtMDAudHh0PGJyPg0KJmd0 OyBTdGF0dXM6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+PC90dD48YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13YW5nLXNmYy1tZC0iPjx0 dD48Zm9udCBzaXplPTI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2Fu Zy1zZmMtbWQtPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyB0eXBl LWlzc3Vlcy88YnI+DQomZ3Q7IEh0bWxpemVkOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+ PC90dD48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FuZy1zZmMt bWQtdHlwZS1pc3N1ZXMtMDAiPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNzdWVzLTAwPC9mb250PjwvdHQ+PC9hPjx0 dD48Zm9udCBzaXplPTI+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQWJzdHJhY3Q6 PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7U2VydmljZSBmdW5jdGlvbiBjaGFpbiBpcyB0aGUgZGVm aW5pdGlvbiBvZiBhbiBvcmRlcmVkDQpzZXQgb2Ygc2VydmljZTxicj4NCiZndDsgJm5ic3A7ICZu YnNwO2Z1bmN0aW9ucy4gJm5ic3A7QWZ0ZXIgaW5zdGFudGlhdGVkLCB0aGUgc2VydmljZSBmdW5j dGlvbg0KcGF0aCBpcyBjcmVhdGVkPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7YW5kIHRoZSBjbGFz c2lmaWVkIHRyYWZmaWMgaXMgc3RlZXJlZCB0aHJvdWdoIHRoZSBjb3JyZXNwb25kaW5nPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7c2VydmljZSBmdW5jdGlvbiBwYXRoIGFuZCB0aGVuIGZvcndhcmRl ZCB0byB0aGUgZmluYWwNCmRlc3RpbmF0aW9uLjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO01ldGFk YXRhIChNRCkgaXMgY29udmV5ZWQgaW4gU0ZDIGRhdGEgcGxhbmUgd2hpY2ggcHJvdmlkZXMNCnRo ZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2FiaWxpdHkgdG8gZXhjaGFuZ2UgY29udGV4dCBpbmZv cm1hdGlvbiBiZXR3ZWVuIGNsYXNzaWZpZXJzDQphbmQgU0ZzLDxicj4NCiZndDsgJm5ic3A7ICZu YnNwO2Ftb25nIFNGcywgYW5kIGJldHdlZW4gZXh0ZXJuYWwgc3lzdGVtcyBhbmQgU0ZzLiAmbmJz cDtUaGlzDQpkb2N1bWVudCBpczxicj4NCiZndDsgJm5ic3A7ICZuYnNwO21vdGl2YXRlZCB0byBz dGF0ZSBhbiBpc3N1ZSB3aGVuIE1EIFR5cGUgPSAweDEgYW5kIGRpc2N1c3MNCndoaWNoPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7TWV0YWRhdGEgVHlwZSBpbiBtb3JlIGFwcHJvcHJpYXRlIHRvIGJl IG1hbmRhdGUgaW4gU0ZDDQpkYXRhIHBsYW5lLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQpzdWJtaXNzaW9uPGJyPg0KJmd0OyB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgSUVURiBTZWNyZXRhcmlhdDxicj4NCiZndDsgPGJy Pg0KPC9mb250PjwvdHQ+DQo= --=_alternative 002E49F548257EC7_=-- From nobody Mon Sep 21 03:37: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 4826F1B3058 for ; Mon, 21 Sep 2015 03:37:00 -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 PxVP4qqs94fy for ; Mon, 21 Sep 2015 03:36:57 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7581B304B for ; Mon, 21 Sep 2015 03:36:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10682; q=dns/txt; s=iport; t=1442831817; x=1444041417; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QHjiG/edG0KFMzaZcimU3Xwpq+QVugzRjG2kRAIwDE4=; b=KXucYaM84g18M60UZ638DBi3kLJMYXm09VTSeIsQXXiwEd+GmOx+XitL VRpCXc8AZBgJ3jzkl9g9OW3f/1fl7OTRzWVzWQIjeoGl7BIIj6qt14BEZ OvgLbnkOHz+q9xseTXk/EVryN5iSoMOrD3F1SzwQY4dXeJu0/zypB8nVy U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D+AQDj3P9V/4ENJK1dgyRUab1CAQ2BcQEJhXkCgTQ4FAEBAQEBAQF/C4QkAQEDAQEBAWsJAgULAgEIPwcnCxQRAgQOBRuICwgNyhgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXhnOCD4JuhQkEBwmDD4EUBYU9h0CIZwGFEIVEgjKBTUaDb5UXAREOAQFChAFxiW0BAQE X-IronPort-AV: E=Sophos; i="5.17,567,1437436800"; d="scan'208,217"; a="30575041" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP; 21 Sep 2015 10:36:55 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t8LAatDx009688 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Sep 2015 10:36:55 GMT Received: from xch-aln-020.cisco.com (173.36.7.30) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 21 Sep 2015 05:36:54 -0500 Received: from xch-aln-020.cisco.com ([173.36.7.30]) by XCH-ALN-020.cisco.com ([173.36.7.30]) with mapi id 15.00.1104.000; Mon, 21 Sep 2015 05:36:54 -0500 From: "Carlos Pignataro (cpignata)" To: "wang.cui1@zte.com.cn" Thread-Topic: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt Thread-Index: AQHQ9Ec2SO0Xvs+Sh0iQWX2DxHhd9p5Gyk+3 Date: Mon, 21 Sep 2015 10:36:54 +0000 Message-ID: <6C7D9374-9A11-4D22-9E3C-7FA1EF2B9A95@cisco.com> References: <20150921081357.8630.47947.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_6C7D93749A114D229E3C7FA1EF2B9A95ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Wei Meng , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-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, 21 Sep 2015 10:37:00 -0000 --_000_6C7D93749A114D229E3C7FA1EF2B9A95ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Linda, It seems the issue that this draft attempts to raise can be summarized with= this question: "When traffic is steered to SF3, how SF3 to correctly analyze the Mandatory Context Headers in NSH within the arriving traffic?" The solution to this, however, is neither of what's presented in Sections 4= .1 and 4.2. The answer is much simpler and already there: the SFP (by way o= f the SFP ID) provides context to understand the format of the metadata. In= other words, a given SFP ID will use one of the MD formats/syntax (DC, Mob= ility, something else). Thanks, Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On Sep 21, 2015, at 04:26, "wang.cui1@zte.com.cn" > wrote: Dear all, Here is a new draft proposed to raise an issue which may exist when MD T= ype=3D0x01 is mandatory. And to motivate the further discussion about MD Type. Wish you can pay atte= ntion to this to continue the discussion and make a consensus ;) Thanks.. Best Wishes, Linda Wang internet-drafts@ietf.org ?? 2015/09/21 16:= 13:57: > internet-drafts@ietf.org > 2015/09/21 16:13 > > ??? > > "Cui Wang" >, "Wei Meng= " > >, "Cui Wang" >, "Wei > Meng" >, > > ?? > > ?? > > New Version Notification for draft-wang-sfc-md-type-issues-00.txt > > > A new version of I-D, draft-wang-sfc-md-type-issues-00.txt > has been successfully submitted by Cui Wang and posted to the > IETF repository. > > Name: draft-wang-sfc-md-type-issues > Revision: 00 > Title: Metadata Type Issues > Document date: 2015-09-21 > Group: Individual Submission > Pages: 14 > URL: https://www.ietf.org/internet-drafts/draft-wang-sfc- > md-type-issues-00.txt > Status: https://datatracker.ietf.org/doc/draft-wang-sfc-md- > type-issues/ > Htmlized: https://tools.ietf.org/html/draft-wang-sfc-md-type-issues= -00 > > > Abstract: > Service function chain is the definition of an ordered set of service > functions. After instantiated, the service function path is created > and the classified traffic is steered through the corresponding > service function path and then forwarded to the final destination. > Metadata (MD) is conveyed in SFC data plane which provides the > ability to exchange context information between classifiers and SFs, > among SFs, and between external systems and SFs. This document is > motivated to state an issue when MD Type =3D 0x1 and discuss which > Metadata Type in more appropriate to be mandate in SFC data plane. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > 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 --_000_6C7D93749A114D229E3C7FA1EF2B9A95ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Linda,

It seems the issue that this draft attempts to raise can be summarized= with this question:

"When t=
raffic is steered to SF3, how SF3 to correctly analyze the
   Mandatory Context Headers in NSH within the arriving traffic?"

The solution to this, however, is neither of what's presented in Secti= ons 4.1 and 4.2. The answer is much simpler and already there: the SFP (by = way of the SFP ID) provides context to understand the format of the metadat= a. In other words, a given SFP ID will use one of the MD formats/syntax (DC, Mobility, something else). = ;

Thanks,

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Sep 21, 2015, at 04:26, "wa= ng.cui1@zte.com.cn" <wa= ng.cui1@zte.com.cn> wrote:


Dear all,

   Here is a new draft propo= sed to raise an issue which may exist when MD Type=3D0x01 is mandatory.
And to motivate the further discussion= about MD Type. Wish you can pay attention to this to
continue the discussion and make a con= sensus ;)

  Thanks..

Best Wishes,
Linda Wang

 


internet-d= rafts@ietf.org 写于 2015/09/21 16:13:57:

> internet-drafts@ietf.org
> 2015/09/21 16:13
>
> 收件人
>
> "Cui Wang" <wang.= cui1@zte.com.cn>, "Wei Meng"
> <meng.wei2@zte.com.cn&g= t;, "Cui Wang" <wang.c= ui1@zte.com.cn>, "Wei
> Meng" <meng.wei2@zte.c= om.cn>,
>
> 抄送
>
> 主题
>
> New Version Notification for draft-wang-sfc-md-type-issues-00.txt
>
>
> A new version of I-D, draft-wang-sfc-md-type-issues-00.txt
> has been successfully submitted by Cui Wang and posted to the
> IETF repository.
>
> Name:      draft-wang-sfc-md-type-issues
> Revision:   00
> Title:      Metadata Type Issues
> Document date:   2015-09-21
> Group:      Individual Submission
> Pages:      14
> URL:            h= ttps://www.ietf.org/internet-drafts/draft-wang-sfc-
> md-type-issues-00.txt
> Status:         https://data= tracker.ietf.org/doc/draft-wang-sfc-md-
> type-issues/
> Htmlized:       https://= tools.ietf.org/html/draft-wang-sfc-md-type-issues-00
>
>
> Abstract:
>    Service function chain is the definition of an ordered se= t of service
>    functions.  After instantiated, the service function= path is created
>    and the classified traffic is steered through the corresp= onding
>    service function path and then forwarded to the final des= tination.
>    Metadata (MD) is conveyed in SFC data plane which provide= s the
>    ability to exchange context information between classifie= rs and SFs,
>    among SFs, and between external systems and SFs.  Th= is document is
>    motivated to state an issue when MD Type =3D 0x1 and disc= uss which
>    Metadata Type in more appropriate to be mandate in SFC da= ta plane.
>
>                     =                      = ;                     &nb= sp;              
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
--_000_6C7D93749A114D229E3C7FA1EF2B9A95ciscocom_-- From nobody Mon Sep 21 09:56:15 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 B2F7D1A9173 for ; Mon, 21 Sep 2015 09:56:14 -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 nIiaJXSB0Kki for ; Mon, 21 Sep 2015 09:56:13 -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 1AFD91A9250 for ; Mon, 21 Sep 2015 09:56:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id E650B1C0B23; Mon, 21 Sep 2015 09:56:12 -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 521E01C043A; Mon, 21 Sep 2015 09:56:12 -0700 (PDT) To: "Carlos Pignataro (cpignata)" , "wang.cui1@zte.com.cn" References: <20150921081357.8630.47947.idtracker@ietfa.amsl.com> <6C7D9374-9A11-4D22-9E3C-7FA1EF2B9A95@cisco.com> From: "Joel M. Halpern" Message-ID: <560036AB.1030001@joelhalpern.com> Date: Mon, 21 Sep 2015 12:56:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <6C7D9374-9A11-4D22-9E3C-7FA1EF2B9A95@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Wei Meng , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-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, 21 Sep 2015 16:56:14 -0000 First, if we are doing to assume that Service Functions will use the SFP-ID to disambiguate type-1 metadata in mixed environments, we should say that in the draft. Second, I am a bit concerned by this proposed behavior, because we have been careful up till now to have the Service Functions act on metadata without requiring per-SFP state. This would mark a significant shift. yours, Joel On 9/21/15 6:36 AM, Carlos Pignataro (cpignata) wrote: > Linda, > > It seems the issue that this draft attempts to raise can be summarized > with this question: > > "When traffic is steered to SF3, how SF3 to correctly analyze the > Mandatory Context Headers in NSH within the arriving traffic?" > > > The solution to this, however, is neither of what's presented in > Sections 4.1 and 4.2. The answer is much simpler and already there: the > SFP (by way of the SFP ID) provides context to understand the format of > the metadata. In other words, a given SFP ID will use one of the MD > formats/syntax (DC, Mobility, something else). > > Thanks, > > Thumb typed by Carlos Pignataro. > Excuze typofraphicak errows > > On Sep 21, 2015, at 04:26, "wang.cui1@zte.com.cn > " > wrote: > >> >> Dear all, >> >> Here is a new draft proposed to raise an issue which may exist when >> MD Type=0x01 is mandatory. >> And to motivate the further discussion about MD Type. Wish you can pay >> attention to this to >> continue the discussion and make a consensus ;) >> >> Thanks.. >> >> Best Wishes, >> Linda Wang >> >> >> >> >> internet-drafts@ietf.org 写于 >> 2015/09/21 16:13:57: >> >> > internet-drafts@ietf.org >> > 2015/09/21 16:13 >> > >> > 收件人 >> > >> > "Cui Wang" >, >> "Wei Meng" >> > >, "Cui Wang" >> >, "Wei >> > Meng" >, >> > >> > æŠ„é€ >> > >> > 主题 >> > >> > New Version Notification for draft-wang-sfc-md-type-issues-00.txt >> > >> > >> > A new version of I-D, draft-wang-sfc-md-type-issues-00.txt >> > has been successfully submitted by Cui Wang and posted to the >> > IETF repository. >> > >> > Name: draft-wang-sfc-md-type-issues >> > Revision: 00 >> > Title: Metadata Type Issues >> > Document date: 2015-09-21 >> > Group: Individual Submission >> > Pages: 14 >> > URL: https://www.ietf.org/internet-drafts/draft-wang-sfc- >> > md-type-issues-00.txt >> > Status: https://datatracker.ietf.org/doc/draft-wang-sfc-md- >> > type-issues/ >> > Htmlized: https://tools.ietf.org/html/draft-wang-sfc-md-type-issues-00 >> > >> > >> > Abstract: >> > Service function chain is the definition of an ordered set of service >> > functions. After instantiated, the service function path is created >> > and the classified traffic is steered through the corresponding >> > service function path and then forwarded to the final destination. >> > Metadata (MD) is conveyed in SFC data plane which provides the >> > ability to exchange context information between classifiers and SFs, >> > among SFs, and between external systems and SFs. This document is >> > motivated to state an issue when MD Type = 0x1 and discuss which >> > Metadata Type in more appropriate to be mandate in SFC data plane. >> > >> > >> > >> > >> > 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 > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Sep 21 10:11: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 29DC21A92FE for ; Mon, 21 Sep 2015 10:11:32 -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 iSsXL_0hHD9R for ; Mon, 21 Sep 2015 10:11:30 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4119F1A92F7 for ; Mon, 21 Sep 2015 10:11:30 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%16]) with mapi id 14.03.0195.001; Mon, 21 Sep 2015 13:11:25 -0400 From: Dave Dolson To: "Joel M. Halpern" , "Carlos Pignataro (cpignata)" , "wang.cui1@zte.com.cn" Thread-Topic: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt Thread-Index: AQHQ9Fl06pIs/ZtMB0i2g3DtwGjCep5HdzGA///A/gA= Date: Mon, 21 Sep 2015 17:11:29 +0000 Message-ID: References: <20150921081357.8630.47947.idtracker@ietfa.amsl.com> <6C7D9374-9A11-4D22-9E3C-7FA1EF2B9A95@cisco.com> <560036AB.1030001@joelhalpern.com> In-Reply-To: <560036AB.1030001@joelhalpern.com> 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: Cc: Wei Meng , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-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, 21 Sep 2015 17:11:32 -0000 QXQgbGVhc3Qgc29tZSBzZXJ2aWNlIGZ1bmN0aW9ucyByZXF1aXJlIHBlci1TRlAgc3RhdGUgdG8g YXNzb2NpYXRlIGJpZGlyZWN0aW9uYWwgcGF0aHMgdG8gZWFjaCBvdGhlci4NCg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBKb2VsIE0uIEhhbHBlcm4NClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVy IDIxLCAyMDE1IDEyOjU2IFBNDQpUbzogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpOyB3YW5n LmN1aTFAenRlLmNvbS5jbg0KQ2M6IFdlaSBNZW5nOyBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbc2ZjXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdhbmctc2ZjLW1kLXR5 cGUtaXNzdWVzLTAwLnR4dA0KDQpGaXJzdCwgaWYgd2UgYXJlIGRvaW5nIHRvIGFzc3VtZSB0aGF0 IFNlcnZpY2UgRnVuY3Rpb25zIHdpbGwgdXNlIHRoZSANClNGUC1JRCB0byBkaXNhbWJpZ3VhdGUg dHlwZS0xIG1ldGFkYXRhIGluIG1peGVkIGVudmlyb25tZW50cywgd2Ugc2hvdWxkIA0Kc2F5IHRo YXQgaW4gdGhlIGRyYWZ0Lg0KDQpTZWNvbmQsIEkgYW0gYSBiaXQgY29uY2VybmVkIGJ5IHRoaXMg cHJvcG9zZWQgYmVoYXZpb3IsIGJlY2F1c2Ugd2UgaGF2ZSANCmJlZW4gY2FyZWZ1bCB1cCB0aWxs IG5vdyB0byBoYXZlIHRoZSBTZXJ2aWNlIEZ1bmN0aW9ucyBhY3Qgb24gbWV0YWRhdGEgDQp3aXRo b3V0IHJlcXVpcmluZyBwZXItU0ZQIHN0YXRlLiAgVGhpcyB3b3VsZCBtYXJrIGEgc2lnbmlmaWNh bnQgc2hpZnQuDQoNCnlvdXJzLA0KSm9lbA0KDQpPbiA5LzIxLzE1IDY6MzYgQU0sIENhcmxvcyBQ aWduYXRhcm8gKGNwaWduYXRhKSB3cm90ZToNCj4gTGluZGEsDQo+DQo+IEl0IHNlZW1zIHRoZSBp c3N1ZSB0aGF0IHRoaXMgZHJhZnQgYXR0ZW1wdHMgdG8gcmFpc2UgY2FuIGJlIHN1bW1hcml6ZWQN Cj4gd2l0aCB0aGlzIHF1ZXN0aW9uOg0KPg0KPiAiV2hlbiB0cmFmZmljIGlzIHN0ZWVyZWQgdG8g U0YzLCBob3cgU0YzIHRvIGNvcnJlY3RseSBhbmFseXplIHRoZQ0KPiBNYW5kYXRvcnkgQ29udGV4 dCBIZWFkZXJzIGluIE5TSCB3aXRoaW4gdGhlIGFycml2aW5nIHRyYWZmaWM/Ig0KPg0KPg0KPiBU aGUgc29sdXRpb24gdG8gdGhpcywgaG93ZXZlciwgaXMgbmVpdGhlciBvZiB3aGF0J3MgcHJlc2Vu dGVkIGluDQo+IFNlY3Rpb25zIDQuMSBhbmQgNC4yLiBUaGUgYW5zd2VyIGlzIG11Y2ggc2ltcGxl ciBhbmQgYWxyZWFkeSB0aGVyZTogdGhlDQo+IFNGUCAoYnkgd2F5IG9mIHRoZSBTRlAgSUQpIHBy b3ZpZGVzIGNvbnRleHQgdG8gdW5kZXJzdGFuZCB0aGUgZm9ybWF0IG9mDQo+IHRoZSBtZXRhZGF0 YS4gSW4gb3RoZXIgd29yZHMsIGEgZ2l2ZW4gU0ZQIElEIHdpbGwgdXNlIG9uZSBvZiB0aGUgTUQN Cj4gZm9ybWF0cy9zeW50YXggKERDLCBNb2JpbGl0eSwgc29tZXRoaW5nIGVsc2UpLg0KPg0KPiBU aGFua3MsDQo+DQo+IFRodW1iIHR5cGVkIGJ5IENhcmxvcyBQaWduYXRhcm8uDQo+IEV4Y3V6ZSB0 eXBvZnJhcGhpY2FrIGVycm93cw0KPg0KPiBPbiBTZXAgMjEsIDIwMTUsIGF0IDA0OjI2LCAid2Fu Zy5jdWkxQHp0ZS5jb20uY24NCj4gPG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj4iIDx3YW5n LmN1aTFAenRlLmNvbS5jbg0KPiA8bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuPj4gd3JvdGU6 DQo+DQo+Pg0KPj4gRGVhciBhbGwsDQo+Pg0KPj4gICAgSGVyZSBpcyBhIG5ldyBkcmFmdCBwcm9w b3NlZCB0byByYWlzZSBhbiBpc3N1ZSB3aGljaCBtYXkgZXhpc3Qgd2hlbg0KPj4gTUQgVHlwZT0w eDAxIGlzIG1hbmRhdG9yeS4NCj4+IEFuZCB0byBtb3RpdmF0ZSB0aGUgZnVydGhlciBkaXNjdXNz aW9uIGFib3V0IE1EIFR5cGUuIFdpc2ggeW91IGNhbiBwYXkNCj4+IGF0dGVudGlvbiB0byB0aGlz IHRvDQo+PiBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiBhbmQgbWFrZSBhIGNvbnNlbnN1cyA7KQ0K Pj4NCj4+ICAgVGhhbmtzLi4NCj4+DQo+PiBCZXN0IFdpc2hlcywNCj4+IExpbmRhIFdhbmcNCj4+ DQo+Pg0KPj4NCj4+DQo+PiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgPG1haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc+IOWGmeS6jg0KPj4gMjAxNS8wOS8yMSAxNjoxMzo1NzoNCj4+DQo+ PiA+IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyA8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZz4NCj4+ID4gMjAxNS8wOS8yMSAxNjoxMw0KPj4gPg0KPj4gPiDmlLbku7bkuroNCj4+ID4N Cj4+ID4gIkN1aSBXYW5nIiA8d2FuZy5jdWkxQHp0ZS5jb20uY24gPG1haWx0bzp3YW5nLmN1aTFA enRlLmNvbS5jbj4+LA0KPj4gIldlaSBNZW5nIg0KPj4gPiA8bWVuZy53ZWkyQHp0ZS5jb20uY24g PG1haWx0bzptZW5nLndlaTJAenRlLmNvbS5jbj4+LCAiQ3VpIFdhbmciDQo+PiA8d2FuZy5jdWkx QHp0ZS5jb20uY24gPG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj4+LCAiV2VpDQo+PiA+IE1l bmciIDxtZW5nLndlaTJAenRlLmNvbS5jbiA8bWFpbHRvOm1lbmcud2VpMkB6dGUuY29tLmNuPj4s DQo+PiA+DQo+PiA+IOaKhOmAgQ0KPj4gPg0KPj4gPiDkuLvpopgNCj4+ID4NCj4+ID4gTmV3IFZl cnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13YW5nLXNmYy1tZC10eXBlLWlzc3Vlcy0wMC50 eHQNCj4+ID4NCj4+ID4NCj4+ID4gQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdhbmctc2Zj LW1kLXR5cGUtaXNzdWVzLTAwLnR4dA0KPj4gPiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IEN1aSBXYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQo+PiA+IElFVEYgcmVwb3NpdG9yeS4N Cj4+ID4NCj4+ID4gTmFtZTogICAgICBkcmFmdC13YW5nLXNmYy1tZC10eXBlLWlzc3Vlcw0KPj4g PiBSZXZpc2lvbjogICAwMA0KPj4gPiBUaXRsZTogICAgICBNZXRhZGF0YSBUeXBlIElzc3Vlcw0K Pj4gPiBEb2N1bWVudCBkYXRlOiAgIDIwMTUtMDktMjENCj4+ID4gR3JvdXA6ICAgICAgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQo+PiA+IFBhZ2VzOiAgICAgIDE0DQo+PiA+IFVSTDogaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdhbmctc2ZjLQ0KPj4gPiBtZC10eXBl LWlzc3Vlcy0wMC50eHQNCj4+ID4gU3RhdHVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC13YW5nLXNmYy1tZC0NCj4+ID4gdHlwZS1pc3N1ZXMvDQo+PiA+IEh0bWxpemVk OiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FuZy1zZmMtbWQtdHlwZS1pc3N1 ZXMtMDANCj4+ID4NCj4+ID4NCj4+ID4gQWJzdHJhY3Q6DQo+PiA+ICAgIFNlcnZpY2UgZnVuY3Rp b24gY2hhaW4gaXMgdGhlIGRlZmluaXRpb24gb2YgYW4gb3JkZXJlZCBzZXQgb2Ygc2VydmljZQ0K Pj4gPiAgICBmdW5jdGlvbnMuICBBZnRlciBpbnN0YW50aWF0ZWQsIHRoZSBzZXJ2aWNlIGZ1bmN0 aW9uIHBhdGggaXMgY3JlYXRlZA0KPj4gPiAgICBhbmQgdGhlIGNsYXNzaWZpZWQgdHJhZmZpYyBp cyBzdGVlcmVkIHRocm91Z2ggdGhlIGNvcnJlc3BvbmRpbmcNCj4+ID4gICAgc2VydmljZSBmdW5j dGlvbiBwYXRoIGFuZCB0aGVuIGZvcndhcmRlZCB0byB0aGUgZmluYWwgZGVzdGluYXRpb24uDQo+ PiA+ICAgIE1ldGFkYXRhIChNRCkgaXMgY29udmV5ZWQgaW4gU0ZDIGRhdGEgcGxhbmUgd2hpY2gg cHJvdmlkZXMgdGhlDQo+PiA+ICAgIGFiaWxpdHkgdG8gZXhjaGFuZ2UgY29udGV4dCBpbmZvcm1h dGlvbiBiZXR3ZWVuIGNsYXNzaWZpZXJzIGFuZCBTRnMsDQo+PiA+ICAgIGFtb25nIFNGcywgYW5k IGJldHdlZW4gZXh0ZXJuYWwgc3lzdGVtcyBhbmQgU0ZzLiAgVGhpcyBkb2N1bWVudCBpcw0KPj4g PiAgICBtb3RpdmF0ZWQgdG8gc3RhdGUgYW4gaXNzdWUgd2hlbiBNRCBUeXBlID0gMHgxIGFuZCBk aXNjdXNzIHdoaWNoDQo+PiA+ICAgIE1ldGFkYXRhIFR5cGUgaW4gbW9yZSBhcHByb3ByaWF0ZSB0 byBiZSBtYW5kYXRlIGluIFNGQyBkYXRhIHBsYW5lLg0KPj4gPg0KPj4gPg0KPj4gPg0KPj4gPg0K Pj4gPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZSBvZg0KPj4gc3VibWlzc2lvbg0KPj4gPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVy c2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnDQo+PiA8aHR0cDov L3Rvb2xzLmlldGYub3JnPi4NCj4+ID4NCj4+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4+ID4N Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBz ZmMgbWFpbGluZyBsaXN0DQo+PiBzZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+ PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPg0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGlu ZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K From nobody Mon Sep 21 10:32:01 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 0F96A1ACDBA for ; Mon, 21 Sep 2015 10:32:00 -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 TJtNW-TnBV2o for ; Mon, 21 Sep 2015 10:31:58 -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 ACBEF1ACDA9 for ; Mon, 21 Sep 2015 10:31:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 867E06C0075; Mon, 21 Sep 2015 10:31:57 -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 AF35A6C0068; Mon, 21 Sep 2015 10:31:56 -0700 (PDT) To: Dave Dolson , "Carlos Pignataro (cpignata)" , "wang.cui1@zte.com.cn" References: <20150921081357.8630.47947.idtracker@ietfa.amsl.com> <6C7D9374-9A11-4D22-9E3C-7FA1EF2B9A95@cisco.com> <560036AB.1030001@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <56003F0B.9040002@joelhalpern.com> Date: Mon, 21 Sep 2015 13:31:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Wei Meng , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-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, 21 Sep 2015 17:32:00 -0000 Unless we are using per-subscriber SFPs (which scalesvery badly, but you can do it) I would expect that association to be made on the basis of subscriber metadata. In normal circumstances, the path ID is neither necessary nor sufficient for the service function to enable symmetry. Even if the SFPs are at a granularity so that there are separate SFP IDs for helping enforce path symmetry, that will not provide the state needed for the service functions. And the state that is needed for the service functions is, in all cases I can see, sufficeint without examining the SFP ID. Yours, Joel On 9/21/15 1:11 PM, Dave Dolson wrote: > At least some service functions require per-SFP state to associate bidirectional paths to each other. > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Monday, September 21, 2015 12:56 PM > To: Carlos Pignataro (cpignata); wang.cui1@zte.com.cn > Cc: Wei Meng; sfc@ietf.org > Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt > > First, if we are doing to assume that Service Functions will use the > SFP-ID to disambiguate type-1 metadata in mixed environments, we should > say that in the draft. > > Second, I am a bit concerned by this proposed behavior, because we have > been careful up till now to have the Service Functions act on metadata > without requiring per-SFP state. This would mark a significant shift. > > yours, > Joel > > On 9/21/15 6:36 AM, Carlos Pignataro (cpignata) wrote: >> Linda, >> >> It seems the issue that this draft attempts to raise can be summarized >> with this question: >> >> "When traffic is steered to SF3, how SF3 to correctly analyze the >> Mandatory Context Headers in NSH within the arriving traffic?" >> >> >> The solution to this, however, is neither of what's presented in >> Sections 4.1 and 4.2. The answer is much simpler and already there: the >> SFP (by way of the SFP ID) provides context to understand the format of >> the metadata. In other words, a given SFP ID will use one of the MD >> formats/syntax (DC, Mobility, something else). >> >> Thanks, >> >> Thumb typed by Carlos Pignataro. >> Excuze typofraphicak errows >> >> On Sep 21, 2015, at 04:26, "wang.cui1@zte.com.cn >> " > > wrote: >> >>> >>> Dear all, >>> >>> Here is a new draft proposed to raise an issue which may exist when >>> MD Type=0x01 is mandatory. >>> And to motivate the further discussion about MD Type. Wish you can pay >>> attention to this to >>> continue the discussion and make a consensus ;) >>> >>> Thanks.. >>> >>> Best Wishes, >>> Linda Wang >>> >>> >>> >>> >>> internet-drafts@ietf.org 写于 >>> 2015/09/21 16:13:57: >>> >>>> internet-drafts@ietf.org >>>> 2015/09/21 16:13 >>>> >>>> 收件人 >>>> >>>> "Cui Wang" >, >>> "Wei Meng" >>>> >, "Cui Wang" >>> >, "Wei >>>> Meng" >, >>>> >>>> æŠ„é€ >>>> >>>> 主题 >>>> >>>> New Version Notification for draft-wang-sfc-md-type-issues-00.txt >>>> >>>> >>>> A new version of I-D, draft-wang-sfc-md-type-issues-00.txt >>>> has been successfully submitted by Cui Wang and posted to the >>>> IETF repository. >>>> >>>> Name: draft-wang-sfc-md-type-issues >>>> Revision: 00 >>>> Title: Metadata Type Issues >>>> Document date: 2015-09-21 >>>> Group: Individual Submission >>>> Pages: 14 >>>> URL: https://www.ietf.org/internet-drafts/draft-wang-sfc- >>>> md-type-issues-00.txt >>>> Status: https://datatracker.ietf.org/doc/draft-wang-sfc-md- >>>> type-issues/ >>>> Htmlized: https://tools.ietf.org/html/draft-wang-sfc-md-type-issues-00 >>>> >>>> >>>> Abstract: >>>> Service function chain is the definition of an ordered set of service >>>> functions. After instantiated, the service function path is created >>>> and the classified traffic is steered through the corresponding >>>> service function path and then forwarded to the final destination. >>>> Metadata (MD) is conveyed in SFC data plane which provides the >>>> ability to exchange context information between classifiers and SFs, >>>> among SFs, and between external systems and SFs. This document is >>>> motivated to state an issue when MD Type = 0x1 and discuss which >>>> Metadata Type in more appropriate to be mandate in SFC data plane. >>>> >>>> >>>> >>>> >>>> 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 >> >> >> _______________________________________________ >> 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 > From nobody Mon Sep 21 10:40:09 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 10E0C1ACDD4 for ; Mon, 21 Sep 2015 10:40:08 -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 EetdZCwH9VdW for ; Mon, 21 Sep 2015 10:40:06 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id D63FA1ACDCF for ; Mon, 21 Sep 2015 10:40:05 -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; Mon, 21 Sep 2015 13:40:01 -0400 From: Dave Dolson To: "Joel M. Halpern" , "Carlos Pignataro (cpignata)" , "wang.cui1@zte.com.cn" Thread-Topic: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt Thread-Index: AQHQ9Fl06pIs/ZtMB0i2g3DtwGjCep5HdzGA///A/gCAAEj9gP//vgUQ Date: Mon, 21 Sep 2015 17:40:06 +0000 Message-ID: References: <20150921081357.8630.47947.idtracker@ietfa.amsl.com> <6C7D9374-9A11-4D22-9E3C-7FA1EF2B9A95@cisco.com> <560036AB.1030001@joelhalpern.com> <56003F0B.9040002@joelhalpern.com> In-Reply-To: <56003F0B.9040002@joelhalpern.com> 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: Cc: Wei Meng , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-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, 21 Sep 2015 17:40:08 -0000 SSBtaWdodCBiZSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IGxldCdzIHRha2UgYSB2ZXJ5IHNpbXBs ZSBjYXNlOiBhIHByb3h5IFNGIG5lZWRzIHRvIHJlc3BvbmQgdG8gYSBTWU4gcGFja2V0IHJlY2Vp dmVkIG9uIGEgU0ZQIHdpdGggYSBTWU4tQUNLLiBXaGljaCBTRlAgc2hvdWxkIHRoZSBTWU4tQUNL IGJlIHBsYWNlZCBvbj8NCg0KSSd2ZSBiZWVuIGFzc3VtaW5nIHRoZXJlIG5lZWRzIHRvIGJlIGEg Y29uZmlndXJhdGlvbiB0byBwYWlyIHVwIGxlZnQtdG8tcmlnaHQgd2l0aCByaWdodC10by1sZWZ0 IFNGUHMsIGFuZCB0aGF0IHRoZSBDMyBpbnRlcmZhY2Ugd291bGQgZXZlbnR1YWxseSBwcm92aWRl IHRoaXMuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvZWwgTS4gSGFs cGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dIA0KU2VudDogTW9uZGF5LCBTZXB0ZW1i ZXIgMjEsIDIwMTUgMTozMiBQTQ0KVG86IERhdmUgRG9sc29uOyBDYXJsb3MgUGlnbmF0YXJvIChj cGlnbmF0YSk7IHdhbmcuY3VpMUB6dGUuY29tLmNuDQpDYzogV2VpIE1lbmc7IHNmY0BpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtzZmNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt d2FuZy1zZmMtbWQtdHlwZS1pc3N1ZXMtMDAudHh0DQoNClVubGVzcyB3ZSBhcmUgdXNpbmcgcGVy LXN1YnNjcmliZXIgU0ZQcyAod2hpY2ggc2NhbGVzdmVyeSBiYWRseSwgYnV0IHlvdSANCmNhbiBk byBpdCkgSSB3b3VsZCBleHBlY3QgdGhhdCBhc3NvY2lhdGlvbiB0byBiZSBtYWRlIG9uIHRoZSBi YXNpcyBvZiANCnN1YnNjcmliZXIgbWV0YWRhdGEuICBJbiBub3JtYWwgY2lyY3Vtc3RhbmNlcywg dGhlIHBhdGggSUQgaXMgbmVpdGhlciANCm5lY2Vzc2FyeSBub3Igc3VmZmljaWVudCBmb3IgdGhl IHNlcnZpY2UgZnVuY3Rpb24gdG8gZW5hYmxlIHN5bW1ldHJ5Lg0KDQpFdmVuIGlmIHRoZSBTRlBz IGFyZSBhdCBhIGdyYW51bGFyaXR5IHNvIHRoYXQgdGhlcmUgYXJlIHNlcGFyYXRlIFNGUCBJRHMg DQpmb3IgaGVscGluZyBlbmZvcmNlIHBhdGggc3ltbWV0cnksIHRoYXQgd2lsbCBub3QgcHJvdmlk ZSB0aGUgc3RhdGUgDQpuZWVkZWQgZm9yIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucy4gIEFuZCB0aGUg c3RhdGUgdGhhdCBpcyBuZWVkZWQgZm9yIHRoZSANCnNlcnZpY2UgZnVuY3Rpb25zIGlzLCBpbiBh bGwgY2FzZXMgSSBjYW4gc2VlLCBzdWZmaWNlaW50IHdpdGhvdXQgDQpleGFtaW5pbmcgdGhlIFNG UCBJRC4NCg0KWW91cnMsDQpKb2VsDQoNCk9uIDkvMjEvMTUgMToxMSBQTSwgRGF2ZSBEb2xzb24g d3JvdGU6DQo+IEF0IGxlYXN0IHNvbWUgc2VydmljZSBmdW5jdGlvbnMgcmVxdWlyZSBwZXItU0ZQ IHN0YXRlIHRvIGFzc29jaWF0ZSBiaWRpcmVjdGlvbmFsIHBhdGhzIHRvIGVhY2ggb3RoZXIuDQo+ DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNmYyBbbWFpbHRvOnNm Yy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJuDQo+IFNlbnQ6 IE1vbmRheSwgU2VwdGVtYmVyIDIxLCAyMDE1IDEyOjU2IFBNDQo+IFRvOiBDYXJsb3MgUGlnbmF0 YXJvIChjcGlnbmF0YSk7IHdhbmcuY3VpMUB6dGUuY29tLmNuDQo+IENjOiBXZWkgTWVuZzsgc2Zj QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2ZjXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNzdWVzLTAwLnR4dA0KPg0KPiBGaXJzdCwgaWYg d2UgYXJlIGRvaW5nIHRvIGFzc3VtZSB0aGF0IFNlcnZpY2UgRnVuY3Rpb25zIHdpbGwgdXNlIHRo ZQ0KPiBTRlAtSUQgdG8gZGlzYW1iaWd1YXRlIHR5cGUtMSBtZXRhZGF0YSBpbiBtaXhlZCBlbnZp cm9ubWVudHMsIHdlIHNob3VsZA0KPiBzYXkgdGhhdCBpbiB0aGUgZHJhZnQuDQo+DQo+IFNlY29u ZCwgSSBhbSBhIGJpdCBjb25jZXJuZWQgYnkgdGhpcyBwcm9wb3NlZCBiZWhhdmlvciwgYmVjYXVz ZSB3ZSBoYXZlDQo+IGJlZW4gY2FyZWZ1bCB1cCB0aWxsIG5vdyB0byBoYXZlIHRoZSBTZXJ2aWNl IEZ1bmN0aW9ucyBhY3Qgb24gbWV0YWRhdGENCj4gd2l0aG91dCByZXF1aXJpbmcgcGVyLVNGUCBz dGF0ZS4gIFRoaXMgd291bGQgbWFyayBhIHNpZ25pZmljYW50IHNoaWZ0Lg0KPg0KPiB5b3VycywN Cj4gSm9lbA0KPg0KPiBPbiA5LzIxLzE1IDY6MzYgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWdu YXRhKSB3cm90ZToNCj4+IExpbmRhLA0KPj4NCj4+IEl0IHNlZW1zIHRoZSBpc3N1ZSB0aGF0IHRo aXMgZHJhZnQgYXR0ZW1wdHMgdG8gcmFpc2UgY2FuIGJlIHN1bW1hcml6ZWQNCj4+IHdpdGggdGhp cyBxdWVzdGlvbjoNCj4+DQo+PiAiV2hlbiB0cmFmZmljIGlzIHN0ZWVyZWQgdG8gU0YzLCBob3cg U0YzIHRvIGNvcnJlY3RseSBhbmFseXplIHRoZQ0KPj4gTWFuZGF0b3J5IENvbnRleHQgSGVhZGVy cyBpbiBOU0ggd2l0aGluIHRoZSBhcnJpdmluZyB0cmFmZmljPyINCj4+DQo+Pg0KPj4gVGhlIHNv bHV0aW9uIHRvIHRoaXMsIGhvd2V2ZXIsIGlzIG5laXRoZXIgb2Ygd2hhdCdzIHByZXNlbnRlZCBp bg0KPj4gU2VjdGlvbnMgNC4xIGFuZCA0LjIuIFRoZSBhbnN3ZXIgaXMgbXVjaCBzaW1wbGVyIGFu ZCBhbHJlYWR5IHRoZXJlOiB0aGUNCj4+IFNGUCAoYnkgd2F5IG9mIHRoZSBTRlAgSUQpIHByb3Zp ZGVzIGNvbnRleHQgdG8gdW5kZXJzdGFuZCB0aGUgZm9ybWF0IG9mDQo+PiB0aGUgbWV0YWRhdGEu IEluIG90aGVyIHdvcmRzLCBhIGdpdmVuIFNGUCBJRCB3aWxsIHVzZSBvbmUgb2YgdGhlIE1EDQo+ PiBmb3JtYXRzL3N5bnRheCAoREMsIE1vYmlsaXR5LCBzb21ldGhpbmcgZWxzZSkuDQo+Pg0KPj4g VGhhbmtzLA0KPj4NCj4+IFRodW1iIHR5cGVkIGJ5IENhcmxvcyBQaWduYXRhcm8uDQo+PiBFeGN1 emUgdHlwb2ZyYXBoaWNhayBlcnJvd3MNCj4+DQo+PiBPbiBTZXAgMjEsIDIwMTUsIGF0IDA0OjI2 LCAid2FuZy5jdWkxQHp0ZS5jb20uY24NCj4+IDxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24+ IiA8d2FuZy5jdWkxQHp0ZS5jb20uY24NCj4+IDxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24+ PiB3cm90ZToNCj4+DQo+Pj4NCj4+PiBEZWFyIGFsbCwNCj4+Pg0KPj4+ICAgICBIZXJlIGlzIGEg bmV3IGRyYWZ0IHByb3Bvc2VkIHRvIHJhaXNlIGFuIGlzc3VlIHdoaWNoIG1heSBleGlzdCB3aGVu DQo+Pj4gTUQgVHlwZT0weDAxIGlzIG1hbmRhdG9yeS4NCj4+PiBBbmQgdG8gbW90aXZhdGUgdGhl IGZ1cnRoZXIgZGlzY3Vzc2lvbiBhYm91dCBNRCBUeXBlLiBXaXNoIHlvdSBjYW4gcGF5DQo+Pj4g YXR0ZW50aW9uIHRvIHRoaXMgdG8NCj4+PiBjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiBhbmQgbWFr ZSBhIGNvbnNlbnN1cyA7KQ0KPj4+DQo+Pj4gICAgVGhhbmtzLi4NCj4+Pg0KPj4+IEJlc3QgV2lz aGVzLA0KPj4+IExpbmRhIFdhbmcNCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyA8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4g5YaZ5LqODQo+ Pj4gMjAxNS8wOS8yMSAxNjoxMzo1NzoNCj4+Pg0KPj4+PiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcgPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+Pj4+IDIwMTUvMDkvMjEgMTY6 MTMNCj4+Pj4NCj4+Pj4g5pS25Lu25Lq6DQo+Pj4+DQo+Pj4+ICJDdWkgV2FuZyIgPHdhbmcuY3Vp MUB6dGUuY29tLmNuIDxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24+PiwNCj4+PiAiV2VpIE1l bmciDQo+Pj4+IDxtZW5nLndlaTJAenRlLmNvbS5jbiA8bWFpbHRvOm1lbmcud2VpMkB6dGUuY29t LmNuPj4sICJDdWkgV2FuZyINCj4+PiA8d2FuZy5jdWkxQHp0ZS5jb20uY24gPG1haWx0bzp3YW5n LmN1aTFAenRlLmNvbS5jbj4+LCAiV2VpDQo+Pj4+IE1lbmciIDxtZW5nLndlaTJAenRlLmNvbS5j biA8bWFpbHRvOm1lbmcud2VpMkB6dGUuY29tLmNuPj4sDQo+Pj4+DQo+Pj4+IOaKhOmAgQ0KPj4+ Pg0KPj4+PiDkuLvpopgNCj4+Pj4NCj4+Pj4gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC13YW5nLXNmYy1tZC10eXBlLWlzc3Vlcy0wMC50eHQNCj4+Pj4NCj4+Pj4NCj4+Pj4gQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNzdWVzLTAwLnR4dA0K Pj4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEN1aSBXYW5nIGFuZCBwb3N0 ZWQgdG8gdGhlDQo+Pj4+IElFVEYgcmVwb3NpdG9yeS4NCj4+Pj4NCj4+Pj4gTmFtZTogICAgICBk cmFmdC13YW5nLXNmYy1tZC10eXBlLWlzc3Vlcw0KPj4+PiBSZXZpc2lvbjogICAwMA0KPj4+PiBU aXRsZTogICAgICBNZXRhZGF0YSBUeXBlIElzc3Vlcw0KPj4+PiBEb2N1bWVudCBkYXRlOiAgIDIw MTUtMDktMjENCj4+Pj4gR3JvdXA6ICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+Pj4+IFBh Z2VzOiAgICAgIDE0DQo+Pj4+IFVSTDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh ZnRzL2RyYWZ0LXdhbmctc2ZjLQ0KPj4+PiBtZC10eXBlLWlzc3Vlcy0wMC50eHQNCj4+Pj4gU3Rh dHVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13YW5nLXNmYy1tZC0N Cj4+Pj4gdHlwZS1pc3N1ZXMvDQo+Pj4+IEh0bWxpemVkOiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtd2FuZy1zZmMtbWQtdHlwZS1pc3N1ZXMtMDANCj4+Pj4NCj4+Pj4NCj4+Pj4g QWJzdHJhY3Q6DQo+Pj4+ICAgICBTZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGlzIHRoZSBkZWZpbml0 aW9uIG9mIGFuIG9yZGVyZWQgc2V0IG9mIHNlcnZpY2UNCj4+Pj4gICAgIGZ1bmN0aW9ucy4gIEFm dGVyIGluc3RhbnRpYXRlZCwgdGhlIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBpcyBjcmVhdGVkDQo+ Pj4+ICAgICBhbmQgdGhlIGNsYXNzaWZpZWQgdHJhZmZpYyBpcyBzdGVlcmVkIHRocm91Z2ggdGhl IGNvcnJlc3BvbmRpbmcNCj4+Pj4gICAgIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBhbmQgdGhlbiBm b3J3YXJkZWQgdG8gdGhlIGZpbmFsIGRlc3RpbmF0aW9uLg0KPj4+PiAgICAgTWV0YWRhdGEgKE1E KSBpcyBjb252ZXllZCBpbiBTRkMgZGF0YSBwbGFuZSB3aGljaCBwcm92aWRlcyB0aGUNCj4+Pj4g ICAgIGFiaWxpdHkgdG8gZXhjaGFuZ2UgY29udGV4dCBpbmZvcm1hdGlvbiBiZXR3ZWVuIGNsYXNz aWZpZXJzIGFuZCBTRnMsDQo+Pj4+ICAgICBhbW9uZyBTRnMsIGFuZCBiZXR3ZWVuIGV4dGVybmFs IHN5c3RlbXMgYW5kIFNGcy4gIFRoaXMgZG9jdW1lbnQgaXMNCj4+Pj4gICAgIG1vdGl2YXRlZCB0 byBzdGF0ZSBhbiBpc3N1ZSB3aGVuIE1EIFR5cGUgPSAweDEgYW5kIGRpc2N1c3Mgd2hpY2gNCj4+ Pj4gICAgIE1ldGFkYXRhIFR5cGUgaW4gbW9yZSBhcHByb3ByaWF0ZSB0byBiZSBtYW5kYXRlIGlu IFNGQyBkYXRhIHBsYW5lLg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0K Pj4+IHN1Ym1pc3Npb24NCj4+Pj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZw0KPj4+IDxodHRwOi8vdG9vbHMuaWV0Zi5v cmc+Lg0KPj4+Pg0KPj4+PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPj4+Pg0KPj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc2ZjIG1haWxpbmcg bGlzdA0KPj4+IHNmY0BpZXRmLm9yZyA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCj4+DQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlz dA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCg== From nobody Mon Sep 21 10:59:31 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 8731C1ACE13 for ; Mon, 21 Sep 2015 10:59:30 -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 4IvPOmaU8T2v for ; Mon, 21 Sep 2015 10:59:28 -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 748821A916D for ; Mon, 21 Sep 2015 10:59:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 513506C0065; Mon, 21 Sep 2015 10:59:28 -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 D1F8E1C043A; Mon, 21 Sep 2015 10:59:27 -0700 (PDT) To: Dave Dolson References: <20150921081357.8630.47947.idtracker@ietfa.amsl.com> <6C7D9374-9A11-4D22-9E3C-7FA1EF2B9A95@cisco.com> <560036AB.1030001@joelhalpern.com> <56003F0B.9040002@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <5600457E.90604@joelhalpern.com> Date: Mon, 21 Sep 2015 13:59:26 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] in-path packet generation 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, 21 Sep 2015 17:59:30 -0000 That is an aspect that I had not considered in asking your question. That is not about symmetry of SFPs, but about the behavior of service functions which generate extra packets in each direction. Over all, that is seriously under-specified, and we should address it. While I don't know what answer the working group will adopt, my inclination is to say that such packet generation needs a classifier. The service function generates the packet with whatever metadata it wants to attach, and then hands it to a classifier to determine what to do with it. Separately, I would note that even if we adopt an SFP-stateful solution for such service functions, I would not want the metadata handling to drive a requirement for such state in all service functions in order to understand the metadata. Before someone argues that this would only be needed in hybrid deployments, I would observe that I expect service functions to be designed and built to work in both dedicated and hybrid deployments. And if MD-1 is a MUST (as it currently is written) then they all have to have this capability. Yours, Joel On 9/21/15 1:40 PM, Dave Dolson wrote: > I might be missing something, but let's take a very simple case: a proxy SF needs to respond to a SYN packet received on a SFP with a SYN-ACK. Which SFP should the SYN-ACK be placed on? > > I've been assuming there needs to be a configuration to pair up left-to-right with right-to-left SFPs, and that the C3 interface would eventually provide this. > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, September 21, 2015 1:32 PM > To: Dave Dolson; Carlos Pignataro (cpignata); wang.cui1@zte.com.cn > Cc: Wei Meng; sfc@ietf.org > Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt > > Unless we are using per-subscriber SFPs (which scalesvery badly, but you > can do it) I would expect that association to be made on the basis of > subscriber metadata. In normal circumstances, the path ID is neither > necessary nor sufficient for the service function to enable symmetry. > > Even if the SFPs are at a granularity so that there are separate SFP IDs > for helping enforce path symmetry, that will not provide the state > needed for the service functions. And the state that is needed for the > service functions is, in all cases I can see, sufficeint without > examining the SFP ID. > > Yours, > Joel > > On 9/21/15 1:11 PM, Dave Dolson wrote: >> At least some service functions require per-SFP state to associate bidirectional paths to each other. >> >> >> -----Original Message----- >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >> Sent: Monday, September 21, 2015 12:56 PM >> To: Carlos Pignataro (cpignata); wang.cui1@zte.com.cn >> Cc: Wei Meng; sfc@ietf.org >> Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt >> >> First, if we are doing to assume that Service Functions will use the >> SFP-ID to disambiguate type-1 metadata in mixed environments, we should >> say that in the draft. >> >> Second, I am a bit concerned by this proposed behavior, because we have >> been careful up till now to have the Service Functions act on metadata >> without requiring per-SFP state. This would mark a significant shift. >> >> yours, >> Joel >> >> On 9/21/15 6:36 AM, Carlos Pignataro (cpignata) wrote: >>> Linda, >>> >>> It seems the issue that this draft attempts to raise can be summarized >>> with this question: >>> >>> "When traffic is steered to SF3, how SF3 to correctly analyze the >>> Mandatory Context Headers in NSH within the arriving traffic?" >>> >>> >>> The solution to this, however, is neither of what's presented in >>> Sections 4.1 and 4.2. The answer is much simpler and already there: the >>> SFP (by way of the SFP ID) provides context to understand the format of >>> the metadata. In other words, a given SFP ID will use one of the MD >>> formats/syntax (DC, Mobility, something else). >>> >>> Thanks, >>> >>> Thumb typed by Carlos Pignataro. >>> Excuze typofraphicak errows >>> >>> On Sep 21, 2015, at 04:26, "wang.cui1@zte.com.cn >>> " >> > wrote: >>> >>>> >>>> Dear all, >>>> >>>> Here is a new draft proposed to raise an issue which may exist when >>>> MD Type=0x01 is mandatory. >>>> And to motivate the further discussion about MD Type. Wish you can pay >>>> attention to this to >>>> continue the discussion and make a consensus ;) >>>> >>>> Thanks.. >>>> >>>> Best Wishes, >>>> Linda Wang >>>> >>>> >>>> >>>> >>>> internet-drafts@ietf.org 写于 >>>> 2015/09/21 16:13:57: >>>> >>>>> internet-drafts@ietf.org >>>>> 2015/09/21 16:13 >>>>> >>>>> 收件人 >>>>> >>>>> "Cui Wang" >, >>>> "Wei Meng" >>>>> >, "Cui Wang" >>>> >, "Wei >>>>> Meng" >, >>>>> >>>>> æŠ„é€ >>>>> >>>>> 主题 >>>>> >>>>> New Version Notification for draft-wang-sfc-md-type-issues-00.txt >>>>> >>>>> >>>>> A new version of I-D, draft-wang-sfc-md-type-issues-00.txt >>>>> has been successfully submitted by Cui Wang and posted to the >>>>> IETF repository. >>>>> >>>>> Name: draft-wang-sfc-md-type-issues >>>>> Revision: 00 >>>>> Title: Metadata Type Issues >>>>> Document date: 2015-09-21 >>>>> Group: Individual Submission >>>>> Pages: 14 >>>>> URL: https://www.ietf.org/internet-drafts/draft-wang-sfc- >>>>> md-type-issues-00.txt >>>>> Status: https://datatracker.ietf.org/doc/draft-wang-sfc-md- >>>>> type-issues/ >>>>> Htmlized: https://tools.ietf.org/html/draft-wang-sfc-md-type-issues-00 >>>>> >>>>> >>>>> Abstract: >>>>> Service function chain is the definition of an ordered set of service >>>>> functions. After instantiated, the service function path is created >>>>> and the classified traffic is steered through the corresponding >>>>> service function path and then forwarded to the final destination. >>>>> Metadata (MD) is conveyed in SFC data plane which provides the >>>>> ability to exchange context information between classifiers and SFs, >>>>> among SFs, and between external systems and SFs. This document is >>>>> motivated to state an issue when MD Type = 0x1 and discuss which >>>>> Metadata Type in more appropriate to be mandate in SFC data plane. >>>>> >>>>> >>>>> >>>>> >>>>> 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 >>> >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Sep 21 11:06: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 CA7C51ACEAE for ; Mon, 21 Sep 2015 11:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.06 X-Spam-Level: X-Spam-Status: No, score=-12.06 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, MIME_CHARSET_FARAWAY=2.45, 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 PKihEbP7_253 for ; Mon, 21 Sep 2015 11:06:27 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D5151ACEB1 for ; Mon, 21 Sep 2015 11:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28359; q=dns/txt; s=iport; t=1442858786; x=1444068386; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=N0TwrPSw7uVFfKxezj5GSaaakJ8wsxHtoADK0OVgIH8=; b=S2359L/IsFfQdLsDUUmTi7nNgPCxH5atBobGtyMeuqGfpyam+Zf7jhc4 LOrljYDjZ2lMxAuNnSoBwjyb+QAn7C/YFn/Ego6b/onQd0z46f37WU8XF ZlgH5qFouk5iQe/NpgIVYaIZiEYzVfGnvhQHAy9qVWO2nONQwkvTsfmRq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D0AQCPRgBW/5xdJa1dgldNVGkGhA2BIbgSAQ2BcQEJhCCBWQIcgRs4FAEBAQEBAQGBCoQjAQEBBAEBAWsLDAQCAQYCEQQBASEHBQICJQsUCQgCBAENBRuIEw2aJJ0lCJQJAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4ZzhH2EchYBBAcGA4JcgUcBBIU9h0CFPoMpAYUQgm6CVoIygU1Gg2+RK4NtEQ4BAUKBYIIhcQGIZ4EFAQEB X-IronPort-AV: E=Sophos;i="5.17,568,1437436800"; d="scan'208,217";a="190307330" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Sep 2015 18:06:25 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t8LI6P1e006613 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Sep 2015 18:06:25 GMT Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 21 Sep 2015 13:06:24 -0500 Received: from xhc-aln-x03.cisco.com (173.36.12.77) by xch-rcd-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Mon, 21 Sep 2015 13:06:24 -0500 Received: from xmb-rcd-x04.cisco.com ([169.254.8.230]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0248.002; Mon, 21 Sep 2015 13:06:24 -0500 From: "Reinaldo Penno (repenno)" To: "Joel M. Halpern" , Dave Dolson Thread-Topic: [sfc] in-path packet generation Thread-Index: AQHQ9JdRlkmyZ4H690y908zbXHU9lJ5HJbqA Date: Mon, 21 Sep 2015 18:06:23 +0000 Message-ID: References: <20150921081357.8630.47947.idtracker@ietfa.amsl.com> <6C7D9374-9A11-4D22-9E3C-7FA1EF2B9A95@cisco.com> <560036AB.1030001@joelhalpern.com> <56003F0B.9040002@joelhalpern.com> <5600457E.90604@joelhalpern.com> In-Reply-To: <5600457E.90604@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [173.37.102.30] Content-Type: multipart/alternative; boundary="_000_D22594E5196B1repennociscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] in-path packet generation 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, 21 Sep 2015 18:06:31 -0000 --_000_D22594E5196B1repennociscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 V2Ugc3R1ZGllZCB0aGlzIGlzc3VlIGNvbnNpZGVyYWJseSBhbmQgZG9jdW1lbnRlZCB0aGUgc29s dXRpb25zIHdlIGltcGxlbWVudGVkIGhlcmU6DQoNCg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1wZW5uby1zZmMtcGFja2V0LTAwLnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXBlbm5vLXNmYy1wYWNrZXQvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXBlbm5vLXNmYy1wYWNrZXQtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFNlcnZp Y2UgRnVuY3Rpb25zIChlLmcuLCBGaXJld2FsbCwgTkFULCBQcm94aWVzIGFuZCBJbnRydXNpb24N CiAgIFByZXZlbnRpb24gU3lzdGVtcykgZ2VuZXJhdGUgcGFja2V0cyBpbiB0aGUgcmV2ZXJzZSBm bG93IGRpcmVjdGlvbiB0bw0KICAgdGhlIHNvdXJjZSBvZiB0aGUgY3VycmVudCBpbi1wcm9jZXNz IHBhY2tldC9mbG93LiAgSW4gdGhpcyBkb2N1bWVudA0KICAgd2UgZGlzY3VzcyBhbmQgcHJvcG9z ZSBob3cgdG8gc3VwcG9ydCB0aGlzIHJlcXVpcmVkIGZ1bmN0aW9uYWxpdHkNCiAgIHdpdGhpbiB0 aGUgU0ZDIGZyYW1ld29yay4NCg0KDQoNCg0KT24gOS8yMS8xNSwgMTA6NTkgQU0sICJzZmMgb24g YmVoYWxmIG9mIEpvZWwgTS4gSGFscGVybiIgPHNmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIGptaEBqb2VsaGFscGVybi5jb208bWFp bHRvOmptaEBqb2VsaGFscGVybi5jb20+PiB3cm90ZToNCg0KVGhhdCBpcyBhbiBhc3BlY3QgdGhh dCBJIGhhZCBub3QgY29uc2lkZXJlZCBpbiBhc2tpbmcgeW91ciBxdWVzdGlvbi4NClRoYXQgaXMg bm90IGFib3V0IHN5bW1ldHJ5IG9mIFNGUHMsIGJ1dCBhYm91dCB0aGUgYmVoYXZpb3Igb2Ygc2Vy dmljZQ0KZnVuY3Rpb25zIHdoaWNoIGdlbmVyYXRlIGV4dHJhIHBhY2tldHMgaW4gZWFjaCBkaXJl Y3Rpb24uDQoNCk92ZXIgYWxsLCB0aGF0IGlzIHNlcmlvdXNseSB1bmRlci1zcGVjaWZpZWQsIGFu ZCB3ZSBzaG91bGQgYWRkcmVzcyBpdC4NCg0KV2hpbGUgSSBkb24ndCBrbm93IHdoYXQgYW5zd2Vy IHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRvcHQsIG15DQppbmNsaW5hdGlvbiBpcyB0byBzYXkg dGhhdCBzdWNoIHBhY2tldCBnZW5lcmF0aW9uIG5lZWRzIGEgY2xhc3NpZmllci4NClRoZSBzZXJ2 aWNlIGZ1bmN0aW9uIGdlbmVyYXRlcyB0aGUgcGFja2V0IHdpdGggd2hhdGV2ZXIgbWV0YWRhdGEg aXQNCndhbnRzIHRvIGF0dGFjaCwgYW5kIHRoZW4gaGFuZHMgaXQgdG8gYSBjbGFzc2lmaWVyIHRv IGRldGVybWluZSB3aGF0IHRvDQpkbyB3aXRoIGl0Lg0KDQpTZXBhcmF0ZWx5LCBJIHdvdWxkIG5v dGUgdGhhdCBldmVuIGlmIHdlIGFkb3B0IGFuIFNGUC1zdGF0ZWZ1bCBzb2x1dGlvbg0KZm9yIHN1 Y2ggc2VydmljZSBmdW5jdGlvbnMsIEkgd291bGQgbm90IHdhbnQgdGhlIG1ldGFkYXRhIGhhbmRs aW5nIHRvDQpkcml2ZSBhIHJlcXVpcmVtZW50IGZvciBzdWNoIHN0YXRlIGluIGFsbCBzZXJ2aWNl IGZ1bmN0aW9ucyBpbiBvcmRlciB0bw0KdW5kZXJzdGFuZCB0aGUgbWV0YWRhdGEuDQpCZWZvcmUg c29tZW9uZSBhcmd1ZXMgdGhhdCB0aGlzIHdvdWxkIG9ubHkgYmUgbmVlZGVkIGluIGh5YnJpZA0K ZGVwbG95bWVudHMsIEkgd291bGQgb2JzZXJ2ZSB0aGF0IEkgZXhwZWN0IHNlcnZpY2UgZnVuY3Rp b25zIHRvIGJlDQpkZXNpZ25lZCBhbmQgYnVpbHQgdG8gd29yayBpbiBib3RoIGRlZGljYXRlZCBh bmQgaHlicmlkIGRlcGxveW1lbnRzLg0KQW5kIGlmIE1ELTEgaXMgYSBNVVNUIChhcyBpdCBjdXJy ZW50bHkgaXMgd3JpdHRlbikgdGhlbiB0aGV5IGFsbCBoYXZlIHRvDQpoYXZlIHRoaXMgY2FwYWJp bGl0eS4NCg0KWW91cnMsDQpKb2VsDQoNCk9uIDkvMjEvMTUgMTo0MCBQTSwgRGF2ZSBEb2xzb24g d3JvdGU6DQpJIG1pZ2h0IGJlIG1pc3Npbmcgc29tZXRoaW5nLCBidXQgbGV0J3MgdGFrZSBhIHZl cnkgc2ltcGxlIGNhc2U6IGEgcHJveHkgU0YgbmVlZHMgdG8gcmVzcG9uZCB0byBhIFNZTiBwYWNr ZXQgcmVjZWl2ZWQgb24gYSBTRlAgd2l0aCBhIFNZTi1BQ0suIFdoaWNoIFNGUCBzaG91bGQgdGhl IFNZTi1BQ0sgYmUgcGxhY2VkIG9uPw0KDQpJJ3ZlIGJlZW4gYXNzdW1pbmcgdGhlcmUgbmVlZHMg dG8gYmUgYSBjb25maWd1cmF0aW9uIHRvIHBhaXIgdXAgbGVmdC10by1yaWdodCB3aXRoIHJpZ2h0 LXRvLWxlZnQgU0ZQcywgYW5kIHRoYXQgdGhlIEMzIGludGVyZmFjZSB3b3VsZCBldmVudHVhbGx5 IHByb3ZpZGUgdGhpcy4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9l bCBNLiBIYWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0NClNlbnQ6IE1vbmRheSwg U2VwdGVtYmVyIDIxLCAyMDE1IDE6MzIgUE0NClRvOiBEYXZlIERvbHNvbjsgQ2FybG9zIFBpZ25h dGFybyAoY3BpZ25hdGEpOyB3YW5nLmN1aTFAenRlLmNvbS5jbjxtYWlsdG86d2FuZy5jdWkxQHp0 ZS5jb20uY24+DQpDYzogV2VpIE1lbmc7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtzZmNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt d2FuZy1zZmMtbWQtdHlwZS1pc3N1ZXMtMDAudHh0DQoNClVubGVzcyB3ZSBhcmUgdXNpbmcgcGVy LXN1YnNjcmliZXIgU0ZQcyAod2hpY2ggc2NhbGVzdmVyeSBiYWRseSwgYnV0IHlvdQ0KY2FuIGRv IGl0KSBJIHdvdWxkIGV4cGVjdCB0aGF0IGFzc29jaWF0aW9uIHRvIGJlIG1hZGUgb24gdGhlIGJh c2lzIG9mDQpzdWJzY3JpYmVyIG1ldGFkYXRhLiAgSW4gbm9ybWFsIGNpcmN1bXN0YW5jZXMsIHRo ZSBwYXRoIElEIGlzIG5laXRoZXINCm5lY2Vzc2FyeSBub3Igc3VmZmljaWVudCBmb3IgdGhlIHNl cnZpY2UgZnVuY3Rpb24gdG8gZW5hYmxlIHN5bW1ldHJ5Lg0KDQpFdmVuIGlmIHRoZSBTRlBzIGFy ZSBhdCBhIGdyYW51bGFyaXR5IHNvIHRoYXQgdGhlcmUgYXJlIHNlcGFyYXRlIFNGUCBJRHMNCmZv ciBoZWxwaW5nIGVuZm9yY2UgcGF0aCBzeW1tZXRyeSwgdGhhdCB3aWxsIG5vdCBwcm92aWRlIHRo ZSBzdGF0ZQ0KbmVlZGVkIGZvciB0aGUgc2VydmljZSBmdW5jdGlvbnMuICBBbmQgdGhlIHN0YXRl IHRoYXQgaXMgbmVlZGVkIGZvciB0aGUNCnNlcnZpY2UgZnVuY3Rpb25zIGlzLCBpbiBhbGwgY2Fz ZXMgSSBjYW4gc2VlLCBzdWZmaWNlaW50IHdpdGhvdXQNCmV4YW1pbmluZyB0aGUgU0ZQIElELg0K DQpZb3VycywNCkpvZWwNCg0KT24gOS8yMS8xNSAxOjExIFBNLCBEYXZlIERvbHNvbiB3cm90ZToN CkF0IGxlYXN0IHNvbWUgc2VydmljZSBmdW5jdGlvbnMgcmVxdWlyZSBwZXItU0ZQIHN0YXRlIHRv IGFzc29jaWF0ZSBiaWRpcmVjdGlvbmFsIHBhdGhzIHRvIGVhY2ggb3RoZXIuDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJuDQpTZW50OiBNb25kYXksIFNlcHRlbWJl ciAyMSwgMjAxNSAxMjo1NiBQTQ0KVG86IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKTsgd2Fu Zy5jdWkxQHp0ZS5jb20uY248bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuPg0KQ2M6IFdlaSBN ZW5nOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2Zj XSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNz dWVzLTAwLnR4dA0KDQpGaXJzdCwgaWYgd2UgYXJlIGRvaW5nIHRvIGFzc3VtZSB0aGF0IFNlcnZp Y2UgRnVuY3Rpb25zIHdpbGwgdXNlIHRoZQ0KU0ZQLUlEIHRvIGRpc2FtYmlndWF0ZSB0eXBlLTEg bWV0YWRhdGEgaW4gbWl4ZWQgZW52aXJvbm1lbnRzLCB3ZSBzaG91bGQNCnNheSB0aGF0IGluIHRo ZSBkcmFmdC4NCg0KU2Vjb25kLCBJIGFtIGEgYml0IGNvbmNlcm5lZCBieSB0aGlzIHByb3Bvc2Vk IGJlaGF2aW9yLCBiZWNhdXNlIHdlIGhhdmUNCmJlZW4gY2FyZWZ1bCB1cCB0aWxsIG5vdyB0byBo YXZlIHRoZSBTZXJ2aWNlIEZ1bmN0aW9ucyBhY3Qgb24gbWV0YWRhdGENCndpdGhvdXQgcmVxdWly aW5nIHBlci1TRlAgc3RhdGUuICBUaGlzIHdvdWxkIG1hcmsgYSBzaWduaWZpY2FudCBzaGlmdC4N Cg0KeW91cnMsDQpKb2VsDQoNCk9uIDkvMjEvMTUgNjozNiBBTSwgQ2FybG9zIFBpZ25hdGFybyAo Y3BpZ25hdGEpIHdyb3RlOg0KTGluZGEsDQoNCkl0IHNlZW1zIHRoZSBpc3N1ZSB0aGF0IHRoaXMg ZHJhZnQgYXR0ZW1wdHMgdG8gcmFpc2UgY2FuIGJlIHN1bW1hcml6ZWQNCndpdGggdGhpcyBxdWVz dGlvbjoNCg0KIldoZW4gdHJhZmZpYyBpcyBzdGVlcmVkIHRvIFNGMywgaG93IFNGMyB0byBjb3Jy ZWN0bHkgYW5hbHl6ZSB0aGUNCk1hbmRhdG9yeSBDb250ZXh0IEhlYWRlcnMgaW4gTlNIIHdpdGhp biB0aGUgYXJyaXZpbmcgdHJhZmZpYz8iDQoNCg0KVGhlIHNvbHV0aW9uIHRvIHRoaXMsIGhvd2V2 ZXIsIGlzIG5laXRoZXIgb2Ygd2hhdCdzIHByZXNlbnRlZCBpbg0KU2VjdGlvbnMgNC4xIGFuZCA0 LjIuIFRoZSBhbnN3ZXIgaXMgbXVjaCBzaW1wbGVyIGFuZCBhbHJlYWR5IHRoZXJlOiB0aGUNClNG UCAoYnkgd2F5IG9mIHRoZSBTRlAgSUQpIHByb3ZpZGVzIGNvbnRleHQgdG8gdW5kZXJzdGFuZCB0 aGUgZm9ybWF0IG9mDQp0aGUgbWV0YWRhdGEuIEluIG90aGVyIHdvcmRzLCBhIGdpdmVuIFNGUCBJ RCB3aWxsIHVzZSBvbmUgb2YgdGhlIE1EDQpmb3JtYXRzL3N5bnRheCAoREMsIE1vYmlsaXR5LCBz b21ldGhpbmcgZWxzZSkuDQoNClRoYW5rcywNCg0KVGh1bWIgdHlwZWQgYnkgQ2FybG9zIFBpZ25h dGFyby4NCkV4Y3V6ZSB0eXBvZnJhcGhpY2FrIGVycm93cw0KDQpPbiBTZXAgMjEsIDIwMTUsIGF0 IDA0OjI2LCAid2FuZy5jdWkxQHp0ZS5jb20uY248bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNu Pg0KPG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj4iIDx3YW5nLmN1aTFAenRlLmNvbS5jbjxt YWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24+DQo8bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNu Pj4gd3JvdGU6DQoNCg0KRGVhciBhbGwsDQoNCiAgICAgIEhlcmUgaXMgYSBuZXcgZHJhZnQgcHJv cG9zZWQgdG8gcmFpc2UgYW4gaXNzdWUgd2hpY2ggbWF5IGV4aXN0IHdoZW4NCk1EIFR5cGU9MHgw MSBpcyBtYW5kYXRvcnkuDQpBbmQgdG8gbW90aXZhdGUgdGhlIGZ1cnRoZXIgZGlzY3Vzc2lvbiBh Ym91dCBNRCBUeXBlLiBXaXNoIHlvdSBjYW4gcGF5DQphdHRlbnRpb24gdG8gdGhpcyB0bw0KY29u dGludWUgdGhlIGRpc2N1c3Npb24gYW5kIG1ha2UgYSBjb25zZW5zdXMgOykNCg0KICAgICBUaGFu a3MuLg0KDQpCZXN0IFdpc2hlcywNCkxpbmRhIFdhbmcNCg0KDQoNCg0KaW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IDxtYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPiDQtNPaDQoyMDE1LzA5LzIxIDE2OjEzOjU3Og0KDQppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gPG1haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQoyMDE1LzA5LzIxIDE2OjEzDQoNCsrVvP7Iyw0K DQoiQ3VpIFdhbmciIDx3YW5nLmN1aTFAenRlLmNvbS5jbjxtYWlsdG86d2FuZy5jdWkxQHp0ZS5j b20uY24+IDxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24+PiwNCiJXZWkgTWVuZyINCjxtZW5n LndlaTJAenRlLmNvbS5jbjxtYWlsdG86bWVuZy53ZWkyQHp0ZS5jb20uY24+IDxtYWlsdG86bWVu Zy53ZWkyQHp0ZS5jb20uY24+PiwgIkN1aSBXYW5nIg0KPHdhbmcuY3VpMUB6dGUuY29tLmNuPG1h aWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj4gPG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj4+ LCAiV2VpDQpNZW5nIiA8bWVuZy53ZWkyQHp0ZS5jb20uY248bWFpbHRvOm1lbmcud2VpMkB6dGUu Y29tLmNuPiA8bWFpbHRvOm1lbmcud2VpMkB6dGUuY29tLmNuPj4sDQoNCrOty80NCg0K1vfM4g0K DQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNz dWVzLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13YW5nLXNmYy1tZC10 eXBlLWlzc3Vlcy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQ3Vp IFdhbmcgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICBk cmFmdC13YW5nLXNmYy1tZC10eXBlLWlzc3Vlcw0KUmV2aXNpb246ICAgMDANClRpdGxlOiAgICAg IE1ldGFkYXRhIFR5cGUgSXNzdWVzDQpEb2N1bWVudCBkYXRlOiAgIDIwMTUtMDktMjENCkdyb3Vw OiAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgMTQNClVSTDogaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdhbmctc2ZjLQ0KbWQtdHlwZS1p c3N1ZXMtMDAudHh0DQpTdGF0dXM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXdhbmctc2ZjLW1kLQ0KdHlwZS1pc3N1ZXMvDQpIdG1saXplZDogaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNzdWVzLTAwDQoNCg0KQWJzdHJh Y3Q6DQogICAgICBTZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGlzIHRoZSBkZWZpbml0aW9uIG9mIGFu IG9yZGVyZWQgc2V0IG9mIHNlcnZpY2UNCiAgICAgIGZ1bmN0aW9ucy4gIEFmdGVyIGluc3RhbnRp YXRlZCwgdGhlIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBpcyBjcmVhdGVkDQogICAgICBhbmQgdGhl IGNsYXNzaWZpZWQgdHJhZmZpYyBpcyBzdGVlcmVkIHRocm91Z2ggdGhlIGNvcnJlc3BvbmRpbmcN CiAgICAgIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBhbmQgdGhlbiBmb3J3YXJkZWQgdG8gdGhlIGZp bmFsIGRlc3RpbmF0aW9uLg0KICAgICAgTWV0YWRhdGEgKE1EKSBpcyBjb252ZXllZCBpbiBTRkMg ZGF0YSBwbGFuZSB3aGljaCBwcm92aWRlcyB0aGUNCiAgICAgIGFiaWxpdHkgdG8gZXhjaGFuZ2Ug Y29udGV4dCBpbmZvcm1hdGlvbiBiZXR3ZWVuIGNsYXNzaWZpZXJzIGFuZCBTRnMsDQogICAgICBh bW9uZyBTRnMsIGFuZCBiZXR3ZWVuIGV4dGVybmFsIHN5c3RlbXMgYW5kIFNGcy4gIFRoaXMgZG9j dW1lbnQgaXMNCiAgICAgIG1vdGl2YXRlZCB0byBzdGF0ZSBhbiBpc3N1ZSB3aGVuIE1EIFR5cGUg PSAweDEgYW5kIGRpc2N1c3Mgd2hpY2gNCiAgICAgIE1ldGFkYXRhIFR5cGUgaW4gbW9yZSBhcHBy b3ByaWF0ZSB0byBiZSBtYW5kYXRlIGluIFNGQyBkYXRhIHBsYW5lLg0KDQoNCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv Zg0Kc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZw0KPGh0dHA6Ly90b29scy5pZXRmLm9yZz4uDQoNClRo ZSBJRVRGIFNlY3JldGFyaWF0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0Bp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWls aW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxt YWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= --_000_D22594E5196B1repennociscocom_ Content-Type: text/html; charset="gb2312" Content-ID: <366832851474CA409B88A735E3150021@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
We studied this is= sue considerably and documented the solutions we implemented here:




Abstract:
   Servi= ce Functions (e.g., Firewall, NAT, Proxies and Intrusion
   Preve= ntion Systems) generate packets in the reverse flow direction to
   the s= ource of the current in-process packet/flow.  In this document
   we di= scuss and propose how to support this required functionality
   withi= n the SFC framework.




On 9/21/15, 10:59 AM, "sfc on behalf of Joel M. Halpern" <= ;sfc-bounces@ietf.org on behalf= of jmh@joelhalpern.com> wrote:

That is an aspect that I had not considered in asking your question. <= /div>
That is not about symmetry of SFPs, but about the behavior of service =
functions which generate extra packets in each direction.

Over all, that is seriously under-specified, and we should address it.=

While I don't know what answer the working group will adopt, my
inclination is to say that such packet generation needs a classifier. =
The service function generates the packet with whatever metadata it
wants to attach, and then hands it to a classifier to determine what t= o
do with it.

Separately, I would note that even if we adopt an SFP-stateful solutio= n
for such service functions, I would not want the metadata handling to =
drive a requirement for such state in all service functions in order t= o
understand the metadata.
Before someone argues that this would only be needed in hybrid
deployments, I would observe that I expect service functions to be
designed and built to work in both dedicated and hybrid deployments. <= /div>
And if MD-1 is a MUST (as it currently is written) then they all have = to
have this capability.

Yours,
Joel

On 9/21/15 1:40 PM, Dave Dolson wrote:
I might be missing something, but let's take a very simple case: a pro= xy SF needs to respond to a SYN packet received on a SFP with a SYN-ACK. Wh= ich SFP should the SYN-ACK be placed on?

I've been assuming there needs to be a configuration to pair up left-t= o-right with right-to-left SFPs, and that the C3 interface would eventually= provide this.


-----Original Message-----
From: Joel M. Halpern [mailto:j= mh@joelhalpern.com]
Sent: Monday, September 21, 2015 1:32 PM
To: Dave Dolson; Carlos Pignataro (cpignata); wang.cui1@zte.com.cn
Cc: Wei Meng; sfc@ietf.org
Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type= -issues-00.txt

Unless we are using per-subscriber SFPs (which scalesvery badly, but y= ou
can do it) I would expect that association to be made on the basis of<= /div>
subscriber metadata.  In normal circumstances, the path ID i= s neither
necessary nor sufficient for the service function to enable symmetry.<= /div>

Even if the SFPs are at a granularity so that there are separate SFP I= Ds
for helping enforce path symmetry, that will not provide the state
needed for the service functions.  And the state that is nee= ded for the
service functions is, in all cases I can see, sufficeint without
examining the SFP ID.

Yours,
Joel

On 9/21/15 1:11 PM, Dave Dolson wrote:
At least some service functions require per-SFP state to associate bid= irectional paths to each other.


-----Original Message-----
From: sfc [mailto:sfc-bounces@= ietf.org] On Behalf Of Joel M. Halpern
Sent: Monday, September 21, 2015 12:56 PM
To: Carlos Pignataro (cpignata); wang.cui1@zte.com.cn
Cc: Wei Meng; sfc@ietf.org
Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type= -issues-00.txt

First, if we are doing to assume that Service Functions will use the
SFP-ID to disambiguate type-1 metadata in mixed environments, we shoul= d
say that in the draft.

Second, I am a bit concerned by this proposed behavior, because we hav= e
been careful up till now to have the Service Functions act on metadata=
without requiring per-SFP state.  This would mark a signific= ant shift.

yours,
Joel

On 9/21/15 6:36 AM, Carlos Pignataro (cpignata) wrote:
Linda,

It seems the issue that this draft attempts to raise can be summarized=
with this question:

"When traffic is steered to SF3, how SF3 to correctly analyze the=
Mandatory Context Headers in NSH within the arriving traffic?"


The solution to this, however, is neither of what's presented in
Sections 4.1 and 4.2. The answer is much simpler and already there: th= e
SFP (by way of the SFP ID) provides context to understand the format o= f
the metadata. In other words, a given SFP ID will use one of the MD
formats/syntax (DC, Mobility, something else).

Thanks,

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Sep 21, 2015, at 04:26, "wang.cui1@zte.com.cn


Dear all,

      Here is a new draft proposed to ra= ise an issue which may exist when
MD Type=3D0x01 is mandatory.
And to motivate the further discussion about MD Type. Wish you can pay=
attention to this to
continue the discussion and make a consensus ;)

     Thanks..

Best Wishes,
Linda Wang




2015/09/21 16:13:57:

2015/09/21 16:13

=CA=D5=BC=FE=C8=CB

"Wei Meng"

=B3=AD=CB=CD

=D6=F7=CC=E2

New Version Notification for draft-wang-sfc-md-type-issues-00.txt


A new version of I-D, draft-wang-sfc-md-type-issues-00.txt
has been successfully submitted by Cui Wang and posted to the
IETF repository.

Name:      draft-wang-sfc-md-type-issues=
Revision:   00
Title:      Metadata Type Issues
Document date:   2015-09-21
Group:      Individual Submission
Pages:      14
md-type-issues-00.txt
type-issues/


Abstract:
      Service function chain is the defi= nition of an ordered set of service
      functions.  After instan= tiated, the service function path is created
      and the classified traffic is stee= red through the corresponding
      service function path and then for= warded to the final destination.
      Metadata (MD) is conveyed in SFC d= ata plane which provides the
      ability to exchange context inform= ation between classifiers and SFs,
      among SFs, and between external sy= stems and SFs.  This document is
      motivated to state an issue when M= D Type =3D 0x1 and discuss which
      Metadata Type in more appropriate = to be mandate in SFC data plane.




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
<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
sfc mailing list


_______________________________________________
sfc mailing list


_______________________________________________
sfc mailing list

_______________________________________________
sfc mailing list


_______________________________________________
sfc mailing list

--_000_D22594E5196B1repennociscocom_-- From nobody Mon Sep 21 11:40: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 0B2491B340E for ; Mon, 21 Sep 2015 11:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.152 X-Spam-Level: X-Spam-Status: No, score=-0.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, 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 9GJrh7dN9I1r for ; Mon, 21 Sep 2015 11:40:47 -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 9C8C61B3419 for ; Mon, 21 Sep 2015 11:40:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 868BF6C0058; Mon, 21 Sep 2015 11:40:47 -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 DCE146C005B; Mon, 21 Sep 2015 11:40:46 -0700 (PDT) To: "Reinaldo Penno (repenno)" , Dave Dolson References: <20150921081357.8630.47947.idtracker@ietfa.amsl.com> <6C7D9374-9A11-4D22-9E3C-7FA1EF2B9A95@cisco.com> <560036AB.1030001@joelhalpern.com> <56003F0B.9040002@joelhalpern.com> <5600457E.90604@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <56004F2D.5010805@joelhalpern.com> Date: Mon, 21 Sep 2015 14:40:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] in-path packet generation 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, 21 Sep 2015 18:40:50 -0000 Thanks. That looks like a nice coverage of the space. Yours, Joel On 9/21/15 2:06 PM, Reinaldo Penno (repenno) wrote: > We studied this issue considerably and documented the solutions we > implemented here: > > > URL: https://www.ietf.org/internet-drafts/draft-penno-sfc-packet-00.txt > Status: https://datatracker.ietf.org/doc/draft-penno-sfc-packet/ > Htmlized: https://tools.ietf.org/html/draft-penno-sfc-packet-00 > > > Abstract: > Service Functions (e.g., Firewall, NAT, Proxies and Intrusion > Prevention Systems) generate packets in the reverse flow direction to > the source of the current in-process packet/flow. In this document > we discuss and propose how to support this required functionality > within the SFC framework. > > > > > On 9/21/15, 10:59 AM, "sfc on behalf of Joel M. Halpern" > on behalf of > jmh@joelhalpern.com > wrote: > > That is an aspect that I had not considered in asking your question. > That is not about symmetry of SFPs, but about the behavior of service > functions which generate extra packets in each direction. > > Over all, that is seriously under-specified, and we should address it. > > While I don't know what answer the working group will adopt, my > inclination is to say that such packet generation needs a classifier. > The service function generates the packet with whatever metadata it > wants to attach, and then hands it to a classifier to determine what to > do with it. > > Separately, I would note that even if we adopt an SFP-stateful solution > for such service functions, I would not want the metadata handling to > drive a requirement for such state in all service functions in order to > understand the metadata. > Before someone argues that this would only be needed in hybrid > deployments, I would observe that I expect service functions to be > designed and built to work in both dedicated and hybrid deployments. > And if MD-1 is a MUST (as it currently is written) then they all > have to > have this capability. > > Yours, > Joel > > On 9/21/15 1:40 PM, Dave Dolson wrote: > > I might be missing something, but let's take a very simple case: > a proxy SF needs to respond to a SYN packet received on a SFP > with a SYN-ACK. Which SFP should the SYN-ACK be placed on? > > I've been assuming there needs to be a configuration to pair up > left-to-right with right-to-left SFPs, and that the C3 interface > would eventually provide this. > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, September 21, 2015 1:32 PM > To: Dave Dolson; Carlos Pignataro (cpignata); > wang.cui1@zte.com.cn > Cc: Wei Meng; sfc@ietf.org > Subject: Re: [sfc] New Version Notification for > draft-wang-sfc-md-type-issues-00.txt > > Unless we are using per-subscriber SFPs (which scalesvery badly, > but you > can do it) I would expect that association to be made on the > basis of > subscriber metadata. In normal circumstances, the path ID is > neither > necessary nor sufficient for the service function to enable > symmetry. > > Even if the SFPs are at a granularity so that there are separate > SFP IDs > for helping enforce path symmetry, that will not provide the state > needed for the service functions. And the state that is needed > for the > service functions is, in all cases I can see, sufficeint without > examining the SFP ID. > > Yours, > Joel > > On 9/21/15 1:11 PM, Dave Dolson wrote: > > At least some service functions require per-SFP state to > associate bidirectional paths to each other. > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. > Halpern > Sent: Monday, September 21, 2015 12:56 PM > To: Carlos Pignataro (cpignata); wang.cui1@zte.com.cn > > Cc: Wei Meng; sfc@ietf.org > Subject: Re: [sfc] New Version Notification for > draft-wang-sfc-md-type-issues-00.txt > > First, if we are doing to assume that Service Functions will > use the > SFP-ID to disambiguate type-1 metadata in mixed > environments, we should > say that in the draft. > > Second, I am a bit concerned by this proposed behavior, > because we have > been careful up till now to have the Service Functions act > on metadata > without requiring per-SFP state. This would mark a > significant shift. > > yours, > Joel > > On 9/21/15 6:36 AM, Carlos Pignataro (cpignata) wrote: > > Linda, > > It seems the issue that this draft attempts to raise can > be summarized > with this question: > > "When traffic is steered to SF3, how SF3 to correctly > analyze the > Mandatory Context Headers in NSH within the arriving > traffic?" > > > The solution to this, however, is neither of what's > presented in > Sections 4.1 and 4.2. The answer is much simpler and > already there: the > SFP (by way of the SFP ID) provides context to > understand the format of > the metadata. In other words, a given SFP ID will use > one of the MD > formats/syntax (DC, Mobility, something else). > > Thanks, > > Thumb typed by Carlos Pignataro. > Excuze typofraphicak errows > > On Sep 21, 2015, at 04:26, "wang.cui1@zte.com.cn > > " > > wrote: > > > Dear all, > > Here is a new draft proposed to raise an > issue which may exist when > MD Type=0x01 is mandatory. > And to motivate the further discussion about MD > Type. Wish you can pay > attention to this to > continue the discussion and make a consensus ;) > > Thanks.. > > Best Wishes, > Linda Wang > > > > > internet-drafts@ietf.org > > дÓÚ > 2015/09/21 16:13:57: > > internet-drafts@ietf.org > > > 2015/09/21 16:13 > > ÊÕ¼þÈË > > "Cui Wang" > >, > > "Wei Meng" > > > >, "Cui Wang" > > > >, "Wei > > Meng" > >, > > ³­ËÍ > > Ö÷Ìâ > > New Version Notification for > draft-wang-sfc-md-type-issues-00.txt > > > A new version of I-D, > draft-wang-sfc-md-type-issues-00.txt > has been successfully submitted by Cui Wang and > posted to the > IETF repository. > > Name: draft-wang-sfc-md-type-issues > Revision: 00 > Title: Metadata Type Issues > Document date: 2015-09-21 > Group: Individual Submission > Pages: 14 > URL: > https://www.ietf.org/internet-drafts/draft-wang-sfc- > md-type-issues-00.txt > Status: > https://datatracker.ietf.org/doc/draft-wang-sfc-md- > type-issues/ > Htmlized: > https://tools.ietf.org/html/draft-wang-sfc-md-type-issues-00 > > > Abstract: > Service function chain is the definition > of an ordered set of service > functions. After instantiated, the > service function path is created > and the classified traffic is steered > through the corresponding > service function path and then forwarded > to the final destination. > Metadata (MD) is conveyed in SFC data > plane which provides the > ability to exchange context information > between classifiers and SFs, > among SFs, and between external systems > and SFs. This document is > motivated to state an issue when MD Type > = 0x1 and discuss which > Metadata Type in more appropriate to be > mandate in SFC data plane. > > > > > 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 > > > > _______________________________________________ > 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 > > _______________________________________________ > 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 > From nobody Mon Sep 21 14: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 958231A88C6 for ; Mon, 21 Sep 2015 14:51:56 -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 pw0INUfLn9Rd for ; Mon, 21 Sep 2015 14:51:51 -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 3C6301A8839 for ; Mon, 21 Sep 2015 14:51:50 -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 BXW63481; Mon, 21 Sep 2015 21:51:48 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 21 Sep 2015 22:51:47 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0235.001; Mon, 21 Sep 2015 14:51:42 -0700 From: Linda Dunbar To: "Reinaldo Penno (repenno)" , "Joel M. Halpern" , Dave Dolson Thread-Topic: [sfc] in-path packet generation Thread-Index: AQHQ9JdT2ID2eSrH6kCnVVrdNFCmCJ5HvJ2A///GmmA= Date: Mon, 21 Sep 2015 21:51:41 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657D59743@dfweml701-chm> References: <20150921081357.8630.47947.idtracker@ietfa.amsl.com> <6C7D9374-9A11-4D22-9E3C-7FA1EF2B9A95@cisco.com> <560036AB.1030001@joelhalpern.com> <56003F0B.9040002@joelhalpern.com> <5600457E.90604@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.139] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657D59743dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] in-path packet generation 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, 21 Sep 2015 21:51:56 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657D59743dfweml701chm_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 UGVubm8sDQoNClRoYXQgaXMgYW4gaW50ZXJlc3RpbmcgcHJvYmxlbS4gVGhhbmtzIGZvciBkb2N1 bWVudGluZyBpdC4NCg0KSSBoYXZlIGEgY291cGxlIG9mIHF1ZXN0aW9uczoNCg0KDQotICAgICAg ICAgIFdoZW4gYSBwYWNrZXQsIHdoaWNoIGNhbiBiZSBlbmNhcHN1bGF0ZWQgaW4gdmFyaW91cyBv dXRlciBoZWFkZXJzIChWeExBTiwgU0ZDoa9zIE5TSCwgb3Igb3RoZXIgaGVhZGVyKSwgYXJyaXZl cyBhdCB0aGUgRlcgaW5ncmVzcyBwb3J0LCB3aGljaCBTb3VyY2UgQWRkcmVzcyB3aWxsIEZXIHNl bmQgIHRoZSChsGdlbmVyYXRlZCBwYWNrZXRzobEgdG8/IElzIGl0IHRoZSBtb3N0IG91dGVyIGhl YWRlcqGvcyBTb3VyY2UgYWRkcmVzcz8NCg0KLSAgICAgICAgICBXaGF0IGtpbmQgb2YgZXZlbnRz IGNhbiB0cmlnZ2VyIGEgRlcgdG8gZ2VuZXJhdGUgcGFja2V0cyB0byB0aGUgc291cmNlPw0KDQot ICAgICAgICAgIElmIHRoZSBzZXF1ZW5jZSBvZiB0aGUgU2VydmljZSBGdW5jdGlvbnMgaXM6IFdl YiBPcHRpbWl6YXRpb24gLT4gRlcsIHdoYXQga2luZCBvZiBjaXJjdW1zdGFuY2VzIHdpbGwgcmVx dWlyZSB0aGUgRlcgdG8gZ2VuZXJhdGUgbWVzc2FnZSB0byB0cmF2ZXJzZSB0aGUgobBXZWIgT3B0 aW1pemF0aW9uobE/DQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2guDQoNCkxpbmRhDQoNCg0KDQpGcm9t OiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJlaW5hbGRv IFBlbm5vIChyZXBlbm5vKQ0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjEsIDIwMTUgMTowNiBQ TQ0KVG86IEpvZWwgTS4gSGFscGVybjsgRGF2ZSBEb2xzb24NCkNjOiBzZmNAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBbc2ZjXSBpbi1wYXRoIHBhY2tldCBnZW5lcmF0aW9uDQoNCldlIHN0dWRpZWQg dGhpcyBpc3N1ZSBjb25zaWRlcmFibHkgYW5kIGRvY3VtZW50ZWQgdGhlIHNvbHV0aW9ucyB3ZSBp bXBsZW1lbnRlZCBoZXJlOg0KDQoNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcGVubm8tc2ZjLXBhY2tldC0wMC50eHQNClN0YXR1czog ICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1wZW5uby1zZmMt cGFja2V0Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1wZW5uby1zZmMtcGFja2V0LTAwDQoNCg0KQWJzdHJhY3Q6DQogICBTZXJ2aWNlIEZ1bmN0aW9u cyAoZS5nLiwgRmlyZXdhbGwsIE5BVCwgUHJveGllcyBhbmQgSW50cnVzaW9uDQogICBQcmV2ZW50 aW9uIFN5c3RlbXMpIGdlbmVyYXRlIHBhY2tldHMgaW4gdGhlIHJldmVyc2UgZmxvdyBkaXJlY3Rp b24gdG8NCiAgIHRoZSBzb3VyY2Ugb2YgdGhlIGN1cnJlbnQgaW4tcHJvY2VzcyBwYWNrZXQvZmxv dy4gIEluIHRoaXMgZG9jdW1lbnQNCiAgIHdlIGRpc2N1c3MgYW5kIHByb3Bvc2UgaG93IHRvIHN1 cHBvcnQgdGhpcyByZXF1aXJlZCBmdW5jdGlvbmFsaXR5DQogICB3aXRoaW4gdGhlIFNGQyBmcmFt ZXdvcmsuDQoNCg0KDQoNCk9uIDkvMjEvMTUsIDEwOjU5IEFNLCAic2ZjIG9uIGJlaGFsZiBvZiBK b2VsIE0uIEhhbHBlcm4iIDxzZmMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBqbWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tPj4gd3JvdGU6DQoNClRoYXQgaXMgYW4gYXNwZWN0IHRoYXQgSSBoYWQgbm90 IGNvbnNpZGVyZWQgaW4gYXNraW5nIHlvdXIgcXVlc3Rpb24uDQpUaGF0IGlzIG5vdCBhYm91dCBz eW1tZXRyeSBvZiBTRlBzLCBidXQgYWJvdXQgdGhlIGJlaGF2aW9yIG9mIHNlcnZpY2UNCmZ1bmN0 aW9ucyB3aGljaCBnZW5lcmF0ZSBleHRyYSBwYWNrZXRzIGluIGVhY2ggZGlyZWN0aW9uLg0KDQpP dmVyIGFsbCwgdGhhdCBpcyBzZXJpb3VzbHkgdW5kZXItc3BlY2lmaWVkLCBhbmQgd2Ugc2hvdWxk IGFkZHJlc3MgaXQuDQoNCldoaWxlIEkgZG9uJ3Qga25vdyB3aGF0IGFuc3dlciB0aGUgd29ya2lu ZyBncm91cCB3aWxsIGFkb3B0LCBteQ0KaW5jbGluYXRpb24gaXMgdG8gc2F5IHRoYXQgc3VjaCBw YWNrZXQgZ2VuZXJhdGlvbiBuZWVkcyBhIGNsYXNzaWZpZXIuDQpUaGUgc2VydmljZSBmdW5jdGlv biBnZW5lcmF0ZXMgdGhlIHBhY2tldCB3aXRoIHdoYXRldmVyIG1ldGFkYXRhIGl0DQp3YW50cyB0 byBhdHRhY2gsIGFuZCB0aGVuIGhhbmRzIGl0IHRvIGEgY2xhc3NpZmllciB0byBkZXRlcm1pbmUg d2hhdCB0bw0KZG8gd2l0aCBpdC4NCg0KU2VwYXJhdGVseSwgSSB3b3VsZCBub3RlIHRoYXQgZXZl biBpZiB3ZSBhZG9wdCBhbiBTRlAtc3RhdGVmdWwgc29sdXRpb24NCmZvciBzdWNoIHNlcnZpY2Ug ZnVuY3Rpb25zLCBJIHdvdWxkIG5vdCB3YW50IHRoZSBtZXRhZGF0YSBoYW5kbGluZyB0bw0KZHJp dmUgYSByZXF1aXJlbWVudCBmb3Igc3VjaCBzdGF0ZSBpbiBhbGwgc2VydmljZSBmdW5jdGlvbnMg aW4gb3JkZXIgdG8NCnVuZGVyc3RhbmQgdGhlIG1ldGFkYXRhLg0KQmVmb3JlIHNvbWVvbmUgYXJn dWVzIHRoYXQgdGhpcyB3b3VsZCBvbmx5IGJlIG5lZWRlZCBpbiBoeWJyaWQNCmRlcGxveW1lbnRz LCBJIHdvdWxkIG9ic2VydmUgdGhhdCBJIGV4cGVjdCBzZXJ2aWNlIGZ1bmN0aW9ucyB0byBiZQ0K ZGVzaWduZWQgYW5kIGJ1aWx0IHRvIHdvcmsgaW4gYm90aCBkZWRpY2F0ZWQgYW5kIGh5YnJpZCBk ZXBsb3ltZW50cy4NCkFuZCBpZiBNRC0xIGlzIGEgTVVTVCAoYXMgaXQgY3VycmVudGx5IGlzIHdy aXR0ZW4pIHRoZW4gdGhleSBhbGwgaGF2ZSB0bw0KaGF2ZSB0aGlzIGNhcGFiaWxpdHkuDQoNCllv dXJzLA0KSm9lbA0KDQpPbiA5LzIxLzE1IDE6NDAgUE0sIERhdmUgRG9sc29uIHdyb3RlOg0KSSBt aWdodCBiZSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IGxldCdzIHRha2UgYSB2ZXJ5IHNpbXBsZSBj YXNlOiBhIHByb3h5IFNGIG5lZWRzIHRvIHJlc3BvbmQgdG8gYSBTWU4gcGFja2V0IHJlY2VpdmVk IG9uIGEgU0ZQIHdpdGggYSBTWU4tQUNLLiBXaGljaCBTRlAgc2hvdWxkIHRoZSBTWU4tQUNLIGJl IHBsYWNlZCBvbj8NCg0KSSd2ZSBiZWVuIGFzc3VtaW5nIHRoZXJlIG5lZWRzIHRvIGJlIGEgY29u ZmlndXJhdGlvbiB0byBwYWlyIHVwIGxlZnQtdG8tcmlnaHQgd2l0aCByaWdodC10by1sZWZ0IFNG UHMsIGFuZCB0aGF0IHRoZSBDMyBpbnRlcmZhY2Ugd291bGQgZXZlbnR1YWxseSBwcm92aWRlIHRo aXMuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvZWwgTS4gSGFscGVy biBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAy MSwgMjAxNSAxOjMyIFBNDQpUbzogRGF2ZSBEb2xzb247IENhcmxvcyBQaWduYXRhcm8gKGNwaWdu YXRhKTsgd2FuZy5jdWkxQHp0ZS5jb20uY248bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuPg0K Q2M6IFdlaSBNZW5nOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbc2ZjXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdhbmctc2ZjLW1k LXR5cGUtaXNzdWVzLTAwLnR4dA0KDQpVbmxlc3Mgd2UgYXJlIHVzaW5nIHBlci1zdWJzY3JpYmVy IFNGUHMgKHdoaWNoIHNjYWxlc3ZlcnkgYmFkbHksIGJ1dCB5b3UNCmNhbiBkbyBpdCkgSSB3b3Vs ZCBleHBlY3QgdGhhdCBhc3NvY2lhdGlvbiB0byBiZSBtYWRlIG9uIHRoZSBiYXNpcyBvZg0Kc3Vi c2NyaWJlciBtZXRhZGF0YS4gIEluIG5vcm1hbCBjaXJjdW1zdGFuY2VzLCB0aGUgcGF0aCBJRCBp cyBuZWl0aGVyDQpuZWNlc3Nhcnkgbm9yIHN1ZmZpY2llbnQgZm9yIHRoZSBzZXJ2aWNlIGZ1bmN0 aW9uIHRvIGVuYWJsZSBzeW1tZXRyeS4NCg0KRXZlbiBpZiB0aGUgU0ZQcyBhcmUgYXQgYSBncmFu dWxhcml0eSBzbyB0aGF0IHRoZXJlIGFyZSBzZXBhcmF0ZSBTRlAgSURzDQpmb3IgaGVscGluZyBl bmZvcmNlIHBhdGggc3ltbWV0cnksIHRoYXQgd2lsbCBub3QgcHJvdmlkZSB0aGUgc3RhdGUNCm5l ZWRlZCBmb3IgdGhlIHNlcnZpY2UgZnVuY3Rpb25zLiAgQW5kIHRoZSBzdGF0ZSB0aGF0IGlzIG5l ZWRlZCBmb3IgdGhlDQpzZXJ2aWNlIGZ1bmN0aW9ucyBpcywgaW4gYWxsIGNhc2VzIEkgY2FuIHNl ZSwgc3VmZmljZWludCB3aXRob3V0DQpleGFtaW5pbmcgdGhlIFNGUCBJRC4NCg0KWW91cnMsDQpK b2VsDQoNCk9uIDkvMjEvMTUgMToxMSBQTSwgRGF2ZSBEb2xzb24gd3JvdGU6DQpBdCBsZWFzdCBz b21lIHNlcnZpY2UgZnVuY3Rpb25zIHJlcXVpcmUgcGVyLVNGUCBzdGF0ZSB0byBhc3NvY2lhdGUg YmlkaXJlY3Rpb25hbCBwYXRocyB0byBlYWNoIG90aGVyLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEpvZWwgTS4gSGFscGVybg0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjEsIDIwMTUg MTI6NTYgUE0NClRvOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSk7IHdhbmcuY3VpMUB6dGUu Y29tLmNuPG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj4NCkNjOiBXZWkgTWVuZzsgc2ZjQGll dGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NmY10gTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13YW5nLXNmYy1tZC10eXBlLWlzc3Vlcy0wMC50eHQN Cg0KRmlyc3QsIGlmIHdlIGFyZSBkb2luZyB0byBhc3N1bWUgdGhhdCBTZXJ2aWNlIEZ1bmN0aW9u cyB3aWxsIHVzZSB0aGUNClNGUC1JRCB0byBkaXNhbWJpZ3VhdGUgdHlwZS0xIG1ldGFkYXRhIGlu IG1peGVkIGVudmlyb25tZW50cywgd2Ugc2hvdWxkDQpzYXkgdGhhdCBpbiB0aGUgZHJhZnQuDQoN ClNlY29uZCwgSSBhbSBhIGJpdCBjb25jZXJuZWQgYnkgdGhpcyBwcm9wb3NlZCBiZWhhdmlvciwg YmVjYXVzZSB3ZSBoYXZlDQpiZWVuIGNhcmVmdWwgdXAgdGlsbCBub3cgdG8gaGF2ZSB0aGUgU2Vy dmljZSBGdW5jdGlvbnMgYWN0IG9uIG1ldGFkYXRhDQp3aXRob3V0IHJlcXVpcmluZyBwZXItU0ZQ IHN0YXRlLiAgVGhpcyB3b3VsZCBtYXJrIGEgc2lnbmlmaWNhbnQgc2hpZnQuDQoNCnlvdXJzLA0K Sm9lbA0KDQpPbiA5LzIxLzE1IDY6MzYgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSB3 cm90ZToNCkxpbmRhLA0KDQpJdCBzZWVtcyB0aGUgaXNzdWUgdGhhdCB0aGlzIGRyYWZ0IGF0dGVt cHRzIHRvIHJhaXNlIGNhbiBiZSBzdW1tYXJpemVkDQp3aXRoIHRoaXMgcXVlc3Rpb246DQoNCiJX aGVuIHRyYWZmaWMgaXMgc3RlZXJlZCB0byBTRjMsIGhvdyBTRjMgdG8gY29ycmVjdGx5IGFuYWx5 emUgdGhlDQpNYW5kYXRvcnkgQ29udGV4dCBIZWFkZXJzIGluIE5TSCB3aXRoaW4gdGhlIGFycml2 aW5nIHRyYWZmaWM/Ig0KDQoNClRoZSBzb2x1dGlvbiB0byB0aGlzLCBob3dldmVyLCBpcyBuZWl0 aGVyIG9mIHdoYXQncyBwcmVzZW50ZWQgaW4NClNlY3Rpb25zIDQuMSBhbmQgNC4yLiBUaGUgYW5z d2VyIGlzIG11Y2ggc2ltcGxlciBhbmQgYWxyZWFkeSB0aGVyZTogdGhlDQpTRlAgKGJ5IHdheSBv ZiB0aGUgU0ZQIElEKSBwcm92aWRlcyBjb250ZXh0IHRvIHVuZGVyc3RhbmQgdGhlIGZvcm1hdCBv Zg0KdGhlIG1ldGFkYXRhLiBJbiBvdGhlciB3b3JkcywgYSBnaXZlbiBTRlAgSUQgd2lsbCB1c2Ug b25lIG9mIHRoZSBNRA0KZm9ybWF0cy9zeW50YXggKERDLCBNb2JpbGl0eSwgc29tZXRoaW5nIGVs c2UpLg0KDQpUaGFua3MsDQoNClRodW1iIHR5cGVkIGJ5IENhcmxvcyBQaWduYXRhcm8uDQpFeGN1 emUgdHlwb2ZyYXBoaWNhayBlcnJvd3MNCg0KT24gU2VwIDIxLCAyMDE1LCBhdCAwNDoyNiwgIndh bmcuY3VpMUB6dGUuY29tLmNuPG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj4NCjxtYWlsdG86 d2FuZy5jdWkxQHp0ZS5jb20uY24+PG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbiUzZT4iIDx3 YW5nLmN1aTFAenRlLmNvbS5jbjxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24+DQo8bWFpbHRv OndhbmcuY3VpMUB6dGUuY29tLmNuPjxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24lM2U+PiB3 cm90ZToNCg0KDQpEZWFyIGFsbCwNCg0KICAgICAgSGVyZSBpcyBhIG5ldyBkcmFmdCBwcm9wb3Nl ZCB0byByYWlzZSBhbiBpc3N1ZSB3aGljaCBtYXkgZXhpc3Qgd2hlbg0KTUQgVHlwZT0weDAxIGlz IG1hbmRhdG9yeS4NCkFuZCB0byBtb3RpdmF0ZSB0aGUgZnVydGhlciBkaXNjdXNzaW9uIGFib3V0 IE1EIFR5cGUuIFdpc2ggeW91IGNhbiBwYXkNCmF0dGVudGlvbiB0byB0aGlzIHRvDQpjb250aW51 ZSB0aGUgZGlzY3Vzc2lvbiBhbmQgbWFrZSBhIGNvbnNlbnN1cyA7KQ0KDQogICAgIFRoYW5rcy4u DQoNCkJlc3QgV2lzaGVzLA0KTGluZGEgV2FuZw0KDQoNCg0KDQppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gPG1haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc+INC009oNCjIwMTUvMDkvMjEgMTY6MTM6NTc6DQoNCmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiA8bWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCjIwMTUvMDkvMjEgMTY6MTMNCg0KytW8/sjLDQoNCiJD dWkgV2FuZyIgPHdhbmcuY3VpMUB6dGUuY29tLmNuPG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5j bj4gPG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj48bWFpbHRvOndhbmcuY3VpMUB6dGUuY29t LmNuJTNlPj4sDQoiV2VpIE1lbmciDQo8bWVuZy53ZWkyQHp0ZS5jb20uY248bWFpbHRvOm1lbmcu d2VpMkB6dGUuY29tLmNuPiA8bWFpbHRvOm1lbmcud2VpMkB6dGUuY29tLmNuPjxtYWlsdG86bWVu Zy53ZWkyQHp0ZS5jb20uY24lM2U+PiwgIkN1aSBXYW5nIg0KPHdhbmcuY3VpMUB6dGUuY29tLmNu PG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj4gPG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5j bj48bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuJTNlPj4sICJXZWkNCk1lbmciIDxtZW5nLndl aTJAenRlLmNvbS5jbjxtYWlsdG86bWVuZy53ZWkyQHp0ZS5jb20uY24+IDxtYWlsdG86bWVuZy53 ZWkyQHp0ZS5jb20uY24+PG1haWx0bzptZW5nLndlaTJAenRlLmNvbS5jbiUzZT4+LA0KDQqzrcvN DQoNCtb3zOINCg0KTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13YW5nLXNmYy1t ZC10eXBlLWlzc3Vlcy0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd2Fu Zy1zZmMtbWQtdHlwZS1pc3N1ZXMtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0 dGVkIGJ5IEN1aSBXYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5h bWU6ICAgICAgZHJhZnQtd2FuZy1zZmMtbWQtdHlwZS1pc3N1ZXMNClJldmlzaW9uOiAgIDAwDQpU aXRsZTogICAgICBNZXRhZGF0YSBUeXBlIElzc3Vlcw0KRG9jdW1lbnQgZGF0ZTogICAyMDE1LTA5 LTIxDQpHcm91cDogICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgIDE0DQpV Ukw6IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC13YW5nLXNmYy0N Cm1kLXR5cGUtaXNzdWVzLTAwLnR4dA0KU3RhdHVzOiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC13YW5nLXNmYy1tZC0NCnR5cGUtaXNzdWVzLw0KSHRtbGl6ZWQ6IGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YW5nLXNmYy1tZC10eXBlLWlzc3Vlcy0wMA0K DQoNCkFic3RyYWN0Og0KICAgICAgU2VydmljZSBmdW5jdGlvbiBjaGFpbiBpcyB0aGUgZGVmaW5p dGlvbiBvZiBhbiBvcmRlcmVkIHNldCBvZiBzZXJ2aWNlDQogICAgICBmdW5jdGlvbnMuICBBZnRl ciBpbnN0YW50aWF0ZWQsIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggaXMgY3JlYXRlZA0KICAg ICAgYW5kIHRoZSBjbGFzc2lmaWVkIHRyYWZmaWMgaXMgc3RlZXJlZCB0aHJvdWdoIHRoZSBjb3Jy ZXNwb25kaW5nDQogICAgICBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggYW5kIHRoZW4gZm9yd2FyZGVk IHRvIHRoZSBmaW5hbCBkZXN0aW5hdGlvbi4NCiAgICAgIE1ldGFkYXRhIChNRCkgaXMgY29udmV5 ZWQgaW4gU0ZDIGRhdGEgcGxhbmUgd2hpY2ggcHJvdmlkZXMgdGhlDQogICAgICBhYmlsaXR5IHRv IGV4Y2hhbmdlIGNvbnRleHQgaW5mb3JtYXRpb24gYmV0d2VlbiBjbGFzc2lmaWVycyBhbmQgU0Zz LA0KICAgICAgYW1vbmcgU0ZzLCBhbmQgYmV0d2VlbiBleHRlcm5hbCBzeXN0ZW1zIGFuZCBTRnMu ICBUaGlzIGRvY3VtZW50IGlzDQogICAgICBtb3RpdmF0ZWQgdG8gc3RhdGUgYW4gaXNzdWUgd2hl biBNRCBUeXBlID0gMHgxIGFuZCBkaXNjdXNzIHdoaWNoDQogICAgICBNZXRhZGF0YSBUeXBlIGlu IG1vcmUgYXBwcm9wcmlhdGUgdG8gYmUgbWFuZGF0ZSBpbiBTRkMgZGF0YSBwbGFuZS4NCg0KDQoN Cg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2YNCnN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBk aWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcNCjxodHRwOi8vdG9vbHMuaWV0Zi5v cmc+Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+IDxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K --_000_4A95BA014132FF49AE685FAB4B9F17F657D59743dfweml701chm_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Penno,

 <= /p>

That is an interesting pr= oblem. Thanks for documenting it.

 <= /p>

I have a couple of questi= ons:

 <= /p>

- =          When a packet, wh= ich can be encapsulated in various outer headers (VxLAN, SFC=A1=AFs NSH, or= other header), arrives at the FW ingress port, which Source Address will FW send  the =A1=B0generated packets=A1=B1 to? Is it the= most outer header=A1=AFs Source address?

- =          What kind of even= ts can trigger a FW to generate packets to the source?

- =          If the sequence o= f the Service Functions is: Web Optimization -> FW, what kind of circums= tances will require the FW to generate message to traverse the =A1=B0Web Optimization=A1=B1?

 <= /p>

Thank you very much.

 <= /p>

Linda

 <= /p>

 <= /p>

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, September 21, 2015 1:06 PM
To: Joel M. Halpern; Dave Dolson
Cc: sfc@ietf.org
Subject: Re: [sfc] in-path packet generation

 

We studied this issue considerably and documented the solutio= ns we implemented here:

 

 

 

 

Abstract:

   Service Functions (e.g., Firewall, NAT, Proxies = and Intrusion

   Prevention Systems) generate packets in the reve= rse flow direction to

   the source of the current in-process packet/flow= .  In this document

   we discuss and propose how to support this requi= red functionality

   within the SFC framework.

 

 

 

 

On 9/21/15, 10:59 AM, "= sfc on behalf of Joel M. Halpern" <sfc-bounces@ietf.org on behalf of jmh@joelhalpern.com> wrote:

 

That is an aspect that I had= not considered in asking your question.

That is not about symmetry o= f SFPs, but about the behavior of service

functions which generate ext= ra packets in each direction.

 

Over all, that is seriously = under-specified, and we should address it.

 

While I don't know what answ= er the working group will adopt, my

inclination is to say that s= uch packet generation needs a classifier.

The service function generat= es the packet with whatever metadata it

wants to attach, and then ha= nds it to a classifier to determine what to

do with it.

 

Separately, I would note tha= t even if we adopt an SFP-stateful solution

for such service functions, = I would not want the metadata handling to

drive a requirement for such= state in all service functions in order to

understand the metadata.

Before someone argues that t= his would only be needed in hybrid

deployments, I would observe= that I expect service functions to be

designed and built to work i= n both dedicated and hybrid deployments.

And if MD-1 is a MUST (as it= currently is written) then they all have to

have this capability.

 

Yours,

Joel

 

On 9/21/15 1:40 PM, Dave Dol= son wrote:

I might be missing something= , but let's take a very simple case: a proxy SF needs to respond to a SYN p= acket received on a SFP with a SYN-ACK. Which SFP should the SYN-ACK be placed on?

 

I've been assuming there nee= ds to be a configuration to pair up left-to-right with right-to-left SFPs, = and that the C3 interface would eventually provide this.<= /p>

 

 

-----Original Message-----

From: Joel M. Halpern [mailto:jmh@joelhalpern.com]

Sent: Monday, September 21, = 2015 1:32 PM

To: Dave Dolson; Carlos Pign= ataro (cpignata); wang.cui1@zte.com.cn=

Cc: Wei Meng; sfc@ietf.org

Subject: Re: [sfc] New Versi= on Notification for draft-wang-sfc-md-type-issues-00.txt<= /p>

 

Unless we are using per-subs= criber SFPs (which scalesvery badly, but you

can do it) I would expect th= at association to be made on the basis of

subscriber metadata. &n= bsp;In normal circumstances, the path ID is neither

necessary nor sufficient for= the service function to enable symmetry.

 

Even if the SFPs are at a gr= anularity so that there are separate SFP IDs

for helping enforce path sym= metry, that will not provide the state

needed for the service funct= ions.  And the state that is needed for the

service functions is, in all= cases I can see, sufficeint without

examining the SFP ID.

 

Yours,

Joel

 

On 9/21/15 1:11 PM, Dave Dol= son wrote:

At least some service functi= ons require per-SFP state to associate bidirectional paths to each other.

 

 

-----Original Message-----

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M= . Halpern

Sent: Monday, September 21, = 2015 12:56 PM

To: Carlos Pignataro (cpigna= ta); wang.cui1@zte.com.cn=

Cc: Wei Meng; sfc@ietf.org

Subject: Re: [sfc] New Versi= on Notification for draft-wang-sfc-md-type-issues-00.txt<= /p>

 

First, if we are doing to as= sume that Service Functions will use the

SFP-ID to disambiguate type-= 1 metadata in mixed environments, we should

say that in the draft.<= /o:p>

 

Second, I am a bit concerned= by this proposed behavior, because we have

been careful up till now to = have the Service Functions act on metadata

without requiring per-SFP st= ate.  This would mark a significant shift.

 

yours,

Joel

 

On 9/21/15 6:36 AM, Carlos P= ignataro (cpignata) wrote:

Linda,

 

It seems the issue that this= draft attempts to raise can be summarized

with this question:

 

"When traffic is steere= d to SF3, how SF3 to correctly analyze the

Mandatory Context Headers in= NSH within the arriving traffic?"

 

 

The solution to this, howeve= r, is neither of what's presented in

Sections 4.1 and 4.2. The an= swer is much simpler and already there: the

SFP (by way of the SFP ID) p= rovides context to understand the format of

the metadata. In other words= , a given SFP ID will use one of the MD

formats/syntax (DC, Mobility= , something else).

 

Thanks,

 

Thumb typed by Carlos Pignat= aro.

Excuze typofraphicak errows<= o:p>

 

On Sep 21, 2015, at 04:26, &= quot;wang.cui1@zte.com.cn<= /o:p>

 

 

Dear all,<= /p>

 

    &nbs= p; Here is a new draft proposed to raise an issue which may exist when=

MD Type=3D0x01 is mandatory.=

And to motivate the further = discussion about MD Type. Wish you can pay

attention to this to

continue the discussion and = make a consensus ;)

 

     Tha= nks..

 

Best Wishes,

Linda Wang=

 

 

 

 

2015/09/21 16:13:57:

 

2015/09/21 16:13<= /span>

 

=CA=D5=BC=FE=C8=CB<= /p>

 

"Wei Meng"

 

=B3=AD=CB=CD

 

=D6=F7=CC=E2

 

New Version Notification for= draft-wang-sfc-md-type-issues-00.txt

 

 

A new version of I-D, draft-= wang-sfc-md-type-issues-00.txt

has been successfully submit= ted by Cui Wang and posted to the

IETF repository.<= /span>

 

Name:    = ;  draft-wang-sfc-md-type-issues

Revision:   00

Title:   &nbs= p;  Metadata Type Issues

Document date:   2= 015-09-21

Group:   &nbs= p;  Individual Submission

Pages:   &nbs= p;  14

md-type-issues-00.txt

type-issues/

 

 

Abstract:<= /p>

    &nbs= p; Service function chain is the definition of an ordered set of servi= ce

    &nbs= p; functions.  After instantiated, the service function path= is created

    &nbs= p; and the classified traffic is steered through the corresponding

    &nbs= p; service function path and then forwarded to the final destination.<= o:p>

    &nbs= p; Metadata (MD) is conveyed in SFC data plane which provides the=

    &nbs= p; ability to exchange context information between classifiers and SFs= ,

    &nbs= p; among SFs, and between external systems and SFs.  This do= cument is

    &nbs= p; motivated to state an issue when MD Type =3D 0x1 and discuss which<= o:p>

    &nbs= p; Metadata Type in more appropriate to be mandate in SFC data plane.<= o:p>

 

 

 

 

Please note that it may take= a couple of minutes from the time of

submission=

until the htmlized version a= nd diff are available at tools.ietf.org

 

The IETF Secretariat

 

____________________________= ___________________

sfc mailing list<= /span>

 

 

____________________________= ___________________

sfc mailing list<= /span>

 

 

____________________________= ___________________

sfc mailing list<= /span>

 

____________________________= ___________________

sfc mailing list<= /span>

 

 

____________________________= ___________________

sfc mailing list<= /span>

 

--_000_4A95BA014132FF49AE685FAB4B9F17F657D59743dfweml701chm_-- From nobody Mon Sep 21 22:54:51 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 77C3D1A8F48 for ; Mon, 21 Sep 2015 22:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.561 X-Spam-Level: X-Spam-Status: No, score=-4.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, 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 Rtr3u--ZKR26 for ; Mon, 21 Sep 2015 22:54:47 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67BA91A8F3F for ; Mon, 21 Sep 2015 22:54:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1442901287; x=1474437287; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CnU6SX6fl8Z2N1HNGSvUVT93AU5lQA/KkAGWl+AecUA=; b=r+GAO1I3V14DPpYcYJh64JoXcCesm9UEb5m+BT0qa68Qr/rPzkqk8uQu Hg6JwocT6lS3PhI03pqKrMYIZ7TYANJOtgLYQGoaukOS1k4qK09igReva eAHUGTDnIvph9xm9H7HXUBjXTHExYQPXHcVz89peNiFYPhx44wP2vbbGX s=; X-IronPort-AV: E=Sophos;i="5.17,571,1437436800"; d="scan'208";a="180924364" X-IPAS-Result: A2HWCACO7ABW/+sKqMBdGQEBAQUBAQGDVGkGrBsBkxAeCoV5AhyBawEBAQEBAQSBB4I+FBABAQEBAQEmAQEBAQEBIwI+LQEBAQEDAQEBMToJAgwEAgEGAhEEAQEBBCMFAgIlCxQJCAIEAQ0FG4ggmUSdJQiUNAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBHoVVg3eBBoRaGBsHBoJfgUcBBIU9h0CIaIURhUWEAEaDb5UbhGRxiGiBBQEBAQ Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 22 Sep 2015 05:54:46 +0000 Received: from SEAEXCHMBX02.olympus.F5Net.com (192.168.15.224) by SEAEXCHMBX06.olympus.F5Net.com (192.168.15.49) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 21 Sep 2015 22:54:45 -0700 Received: from SEAEXCHMBX02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f]) by seaexchmbx02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f%13]) with mapi id 15.00.1044.021; Mon, 21 Sep 2015 22:54:45 -0700 From: Sumandra Majee To: "Joel M. Halpern" , Dave Dolson , "Carlos Pignataro (cpignata)" , "wang.cui1@zte.com.cn" Thread-Topic: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt Thread-Index: AQHQ9Fl1IrpxWtXX7keTznL0rfXWD55HqXuAgAAERoCAAAW2gIAAWjCA Date: Tue, 22 Sep 2015 05:54:45 +0000 Message-ID: References: <20150921081357.8630.47947.idtracker@ietfa.amsl.com> <6C7D9374-9A11-4D22-9E3C-7FA1EF2B9A95@cisco.com> <560036AB.1030001@joelhalpern.com> <56003F0B.9040002@joelhalpern.com> In-Reply-To: <56003F0B.9040002@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="gb2312" Content-ID: <1BEF3F53254FBB4498619E5A45C76306@F5.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Wei Meng , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-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: Tue, 22 Sep 2015 05:54:49 -0000 VGhlIGFzc29jaWF0aW9uIGNhbiBiZSBtYWRlIG9uIHZhcmlldHkgb2YgYXR0cmlidXRlLA0KICAg QSkgc3Vic2NyaWJlciBpbmZvDQogICBCKSBuZXR3b3JrIGluZm8gZS5nLiBWbGFuLiBJbiB0aGUg ZGlhZ3JhbSBTRjMgaXMgcmN2aW5nIGZsb3dzIGZyb20gdHdvDQpkaWZmZXJlbnQgdHlwZSBzZXJ2 aWNlcyBvbiB0d28gZGlzdGluY3QgaW50ZXJmYWNlcy4NCg0KSG93ZXZlciB0aGlzIGNhbiBiZSBl aXRoZXIgY29uZmlndXJlZCwgcHVzaGVkIG92ZXIgY29udHJvbCBwbGFuZS4gQWxsIGFyZQ0KZmlu ZSBidXQgaXQgaXMgcGVyaGFwcyBtdWNoIGJldHRlciB0byBjb2xvciB0aGUgY29udGV4dCBwYXls b2FkDQpleHBsaWNpdGx5LiBJIGFsc28gZG9uoa90IHRoaW5rIHRoZSBhbGxvY2F0aW9uIHdpbGwg ZW5kIHdpdGggbW9iaWxlIGFuZCBkYy4NCg0KUmVnYXJkcw0KU3VtYW5kcmENCg0KT24gOS8yMS8x NSwgMTA6MzEgQU0sICJzZmMgb24gYmVoYWxmIG9mIEpvZWwgTS4gSGFscGVybiINCjxzZmMtYm91 bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygam1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQoN Cj5Vbmxlc3Mgd2UgYXJlIHVzaW5nIHBlci1zdWJzY3JpYmVyIFNGUHMgKHdoaWNoIHNjYWxlc3Zl cnkgYmFkbHksIGJ1dCB5b3UNCj5jYW4gZG8gaXQpIEkgd291bGQgZXhwZWN0IHRoYXQgYXNzb2Np YXRpb24gdG8gYmUgbWFkZSBvbiB0aGUgYmFzaXMgb2YNCj5zdWJzY3JpYmVyIG1ldGFkYXRhLiAg SW4gbm9ybWFsIGNpcmN1bXN0YW5jZXMsIHRoZSBwYXRoIElEIGlzIG5laXRoZXINCj5uZWNlc3Nh cnkgbm9yIHN1ZmZpY2llbnQgZm9yIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIHRvIGVuYWJsZSBzeW1t ZXRyeS4NCj4NCj5FdmVuIGlmIHRoZSBTRlBzIGFyZSBhdCBhIGdyYW51bGFyaXR5IHNvIHRoYXQg dGhlcmUgYXJlIHNlcGFyYXRlIFNGUCBJRHMNCj5mb3IgaGVscGluZyBlbmZvcmNlIHBhdGggc3lt bWV0cnksIHRoYXQgd2lsbCBub3QgcHJvdmlkZSB0aGUgc3RhdGUNCj5uZWVkZWQgZm9yIHRoZSBz ZXJ2aWNlIGZ1bmN0aW9ucy4gIEFuZCB0aGUgc3RhdGUgdGhhdCBpcyBuZWVkZWQgZm9yIHRoZQ0K PnNlcnZpY2UgZnVuY3Rpb25zIGlzLCBpbiBhbGwgY2FzZXMgSSBjYW4gc2VlLCBzdWZmaWNlaW50 IHdpdGhvdXQNCj5leGFtaW5pbmcgdGhlIFNGUCBJRC4NCj4NCj5Zb3VycywNCj5Kb2VsDQo+DQo+ T24gOS8yMS8xNSAxOjExIFBNLCBEYXZlIERvbHNvbiB3cm90ZToNCj4+IEF0IGxlYXN0IHNvbWUg c2VydmljZSBmdW5jdGlvbnMgcmVxdWlyZSBwZXItU0ZQIHN0YXRlIHRvIGFzc29jaWF0ZQ0KPj5i aWRpcmVjdGlvbmFsIHBhdGhzIHRvIGVhY2ggb3RoZXIuDQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybg0KPj4gU2VudDogTW9uZGF5LCBTZXB0ZW1i ZXIgMjEsIDIwMTUgMTI6NTYgUE0NCj4+IFRvOiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSk7 IHdhbmcuY3VpMUB6dGUuY29tLmNuDQo+PiBDYzogV2VpIE1lbmc7IHNmY0BpZXRmLm9yZw0KPj4g U3ViamVjdDogUmU6IFtzZmNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4+ZHJhZnQt d2FuZy1zZmMtbWQtdHlwZS1pc3N1ZXMtMDAudHh0DQo+Pg0KPj4gRmlyc3QsIGlmIHdlIGFyZSBk b2luZyB0byBhc3N1bWUgdGhhdCBTZXJ2aWNlIEZ1bmN0aW9ucyB3aWxsIHVzZSB0aGUNCj4+IFNG UC1JRCB0byBkaXNhbWJpZ3VhdGUgdHlwZS0xIG1ldGFkYXRhIGluIG1peGVkIGVudmlyb25tZW50 cywgd2Ugc2hvdWxkDQo+PiBzYXkgdGhhdCBpbiB0aGUgZHJhZnQuDQo+Pg0KPj4gU2Vjb25kLCBJ IGFtIGEgYml0IGNvbmNlcm5lZCBieSB0aGlzIHByb3Bvc2VkIGJlaGF2aW9yLCBiZWNhdXNlIHdl IGhhdmUNCj4+IGJlZW4gY2FyZWZ1bCB1cCB0aWxsIG5vdyB0byBoYXZlIHRoZSBTZXJ2aWNlIEZ1 bmN0aW9ucyBhY3Qgb24gbWV0YWRhdGENCj4+IHdpdGhvdXQgcmVxdWlyaW5nIHBlci1TRlAgc3Rh dGUuICBUaGlzIHdvdWxkIG1hcmsgYSBzaWduaWZpY2FudCBzaGlmdC4NCj4+DQo+PiB5b3VycywN Cj4+IEpvZWwNCj4+DQo+PiBPbiA5LzIxLzE1IDY6MzYgQU0sIENhcmxvcyBQaWduYXRhcm8gKGNw aWduYXRhKSB3cm90ZToNCj4+PiBMaW5kYSwNCj4+Pg0KPj4+IEl0IHNlZW1zIHRoZSBpc3N1ZSB0 aGF0IHRoaXMgZHJhZnQgYXR0ZW1wdHMgdG8gcmFpc2UgY2FuIGJlIHN1bW1hcml6ZWQNCj4+PiB3 aXRoIHRoaXMgcXVlc3Rpb246DQo+Pj4NCj4+PiAiV2hlbiB0cmFmZmljIGlzIHN0ZWVyZWQgdG8g U0YzLCBob3cgU0YzIHRvIGNvcnJlY3RseSBhbmFseXplIHRoZQ0KPj4+IE1hbmRhdG9yeSBDb250 ZXh0IEhlYWRlcnMgaW4gTlNIIHdpdGhpbiB0aGUgYXJyaXZpbmcgdHJhZmZpYz8iDQo+Pj4NCj4+ Pg0KPj4+IFRoZSBzb2x1dGlvbiB0byB0aGlzLCBob3dldmVyLCBpcyBuZWl0aGVyIG9mIHdoYXQn cyBwcmVzZW50ZWQgaW4NCj4+PiBTZWN0aW9ucyA0LjEgYW5kIDQuMi4gVGhlIGFuc3dlciBpcyBt dWNoIHNpbXBsZXIgYW5kIGFscmVhZHkgdGhlcmU6IHRoZQ0KPj4+IFNGUCAoYnkgd2F5IG9mIHRo ZSBTRlAgSUQpIHByb3ZpZGVzIGNvbnRleHQgdG8gdW5kZXJzdGFuZCB0aGUgZm9ybWF0IG9mDQo+ Pj4gdGhlIG1ldGFkYXRhLiBJbiBvdGhlciB3b3JkcywgYSBnaXZlbiBTRlAgSUQgd2lsbCB1c2Ug b25lIG9mIHRoZSBNRA0KPj4+IGZvcm1hdHMvc3ludGF4IChEQywgTW9iaWxpdHksIHNvbWV0aGlu ZyBlbHNlKS4NCj4+Pg0KPj4+IFRoYW5rcywNCj4+Pg0KPj4+IFRodW1iIHR5cGVkIGJ5IENhcmxv cyBQaWduYXRhcm8uDQo+Pj4gRXhjdXplIHR5cG9mcmFwaGljYWsgZXJyb3dzDQo+Pj4NCj4+PiBP biBTZXAgMjEsIDIwMTUsIGF0IDA0OjI2LCAid2FuZy5jdWkxQHp0ZS5jb20uY24NCj4+PiA8bWFp bHRvOndhbmcuY3VpMUB6dGUuY29tLmNuPiIgPHdhbmcuY3VpMUB6dGUuY29tLmNuDQo+Pj4gPG1h aWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj4+IHdyb3RlOg0KPj4+DQo+Pj4+DQo+Pj4+IERlYXIg YWxsLA0KPj4+Pg0KPj4+PiAgICAgSGVyZSBpcyBhIG5ldyBkcmFmdCBwcm9wb3NlZCB0byByYWlz ZSBhbiBpc3N1ZSB3aGljaCBtYXkgZXhpc3QNCj4+Pj53aGVuDQo+Pj4+IE1EIFR5cGU9MHgwMSBp cyBtYW5kYXRvcnkuDQo+Pj4+IEFuZCB0byBtb3RpdmF0ZSB0aGUgZnVydGhlciBkaXNjdXNzaW9u IGFib3V0IE1EIFR5cGUuIFdpc2ggeW91IGNhbiBwYXkNCj4+Pj4gYXR0ZW50aW9uIHRvIHRoaXMg dG8NCj4+Pj4gY29udGludWUgdGhlIGRpc2N1c3Npb24gYW5kIG1ha2UgYSBjb25zZW5zdXMgOykN Cj4+Pj4NCj4+Pj4gICAgVGhhbmtzLi4NCj4+Pj4NCj4+Pj4gQmVzdCBXaXNoZXMsDQo+Pj4+IExp bmRhIFdhbmcNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gaW50ZXJuZXQtZHJhZnRzQGll dGYub3JnIDxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiDQtNPaDQo+Pj4+IDIwMTUv MDkvMjEgMTY6MTM6NTc6DQo+Pj4+DQo+Pj4+PiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgPG1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+Pj4+PiAyMDE1LzA5LzIxIDE2OjEzDQo+ Pj4+Pg0KPj4+Pj4gytW8/sjLDQo+Pj4+Pg0KPj4+Pj4gIkN1aSBXYW5nIiA8d2FuZy5jdWkxQHp0 ZS5jb20uY24gPG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj4+LA0KPj4+PiAiV2VpIE1lbmci DQo+Pj4+PiA8bWVuZy53ZWkyQHp0ZS5jb20uY24gPG1haWx0bzptZW5nLndlaTJAenRlLmNvbS5j bj4+LCAiQ3VpIFdhbmciDQo+Pj4+IDx3YW5nLmN1aTFAenRlLmNvbS5jbiA8bWFpbHRvOndhbmcu Y3VpMUB6dGUuY29tLmNuPj4sICJXZWkNCj4+Pj4+IE1lbmciIDxtZW5nLndlaTJAenRlLmNvbS5j biA8bWFpbHRvOm1lbmcud2VpMkB6dGUuY29tLmNuPj4sDQo+Pj4+Pg0KPj4+Pj4gs63LzQ0KPj4+ Pj4NCj4+Pj4+INb3zOINCj4+Pj4+DQo+Pj4+PiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNzdWVzLTAwLnR4dA0KPj4+Pj4NCj4+Pj4+DQo+Pj4+ PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd2FuZy1zZmMtbWQtdHlwZS1pc3N1ZXMtMDAu dHh0DQo+Pj4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEN1aSBXYW5nIGFu ZCBwb3N0ZWQgdG8gdGhlDQo+Pj4+PiBJRVRGIHJlcG9zaXRvcnkuDQo+Pj4+Pg0KPj4+Pj4gTmFt ZTogICAgICBkcmFmdC13YW5nLXNmYy1tZC10eXBlLWlzc3Vlcw0KPj4+Pj4gUmV2aXNpb246ICAg MDANCj4+Pj4+IFRpdGxlOiAgICAgIE1ldGFkYXRhIFR5cGUgSXNzdWVzDQo+Pj4+PiBEb2N1bWVu dCBkYXRlOiAgIDIwMTUtMDktMjENCj4+Pj4+IEdyb3VwOiAgICAgIEluZGl2aWR1YWwgU3VibWlz c2lvbg0KPj4+Pj4gUGFnZXM6ICAgICAgMTQNCj4+Pj4+IFVSTDogaHR0cHM6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdhbmctc2ZjLQ0KPj4+Pj4gbWQtdHlwZS1pc3N1ZXMt MDAudHh0DQo+Pj4+PiBTdGF0dXM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXdhbmctc2ZjLW1kLQ0KPj4+Pj4gdHlwZS1pc3N1ZXMvDQo+Pj4+PiBIdG1saXplZDogDQo+ Pj4+Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YW5nLXNmYy1tZC10eXBlLWlz c3Vlcy0wMA0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBBYnN0cmFjdDoNCj4+Pj4+ICAgICBTZXJ2aWNl IGZ1bmN0aW9uIGNoYWluIGlzIHRoZSBkZWZpbml0aW9uIG9mIGFuIG9yZGVyZWQgc2V0IG9mDQo+ Pj4+PnNlcnZpY2UNCj4+Pj4+ICAgICBmdW5jdGlvbnMuICBBZnRlciBpbnN0YW50aWF0ZWQsIHRo ZSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggaXMNCj4+Pj4+Y3JlYXRlZA0KPj4+Pj4gICAgIGFuZCB0 aGUgY2xhc3NpZmllZCB0cmFmZmljIGlzIHN0ZWVyZWQgdGhyb3VnaCB0aGUgY29ycmVzcG9uZGlu Zw0KPj4+Pj4gICAgIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBhbmQgdGhlbiBmb3J3YXJkZWQgdG8g dGhlIGZpbmFsDQo+Pj4+PmRlc3RpbmF0aW9uLg0KPj4+Pj4gICAgIE1ldGFkYXRhIChNRCkgaXMg Y29udmV5ZWQgaW4gU0ZDIGRhdGEgcGxhbmUgd2hpY2ggcHJvdmlkZXMgdGhlDQo+Pj4+PiAgICAg YWJpbGl0eSB0byBleGNoYW5nZSBjb250ZXh0IGluZm9ybWF0aW9uIGJldHdlZW4gY2xhc3NpZmll cnMgYW5kDQo+Pj4+PlNGcywNCj4+Pj4+ICAgICBhbW9uZyBTRnMsIGFuZCBiZXR3ZWVuIGV4dGVy bmFsIHN5c3RlbXMgYW5kIFNGcy4gIFRoaXMgZG9jdW1lbnQNCj4+Pj4+aXMNCj4+Pj4+ICAgICBt b3RpdmF0ZWQgdG8gc3RhdGUgYW4gaXNzdWUgd2hlbiBNRCBUeXBlID0gMHgxIGFuZCBkaXNjdXNz IHdoaWNoDQo+Pj4+PiAgICAgTWV0YWRhdGEgVHlwZSBpbiBtb3JlIGFwcHJvcHJpYXRlIHRvIGJl IG1hbmRhdGUgaW4gU0ZDIGRhdGENCj4+Pj4+cGxhbmUuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+ Pj4+Pg0KPj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51 dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4+Pj4gc3VibWlzc2lvbg0KPj4+Pj4gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZw0K Pj4+PiA8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCj4+Pj4+DQo+Pj4+PiBUaGUgSUVURiBTZWNy ZXRhcmlhdA0KPj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+PiBzZmNAaWV0Zi5vcmcgPG1h aWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo+Pj4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+IHNmY0BpZXRmLm9yZw0K Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4NCj4+DQo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2Zj IG1haWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPnNmYyBtYWlsaW5nIGxpc3QNCj5zZmNAaWV0Zi5vcmcNCj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= From nobody Mon Sep 21 22:58:13 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 060611A8F4D for ; Mon, 21 Sep 2015 22:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.561 X-Spam-Level: X-Spam-Status: No, score=-4.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-5, 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 LEMFuV4ibBN7 for ; Mon, 21 Sep 2015 22:58:09 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B65C71A8F49 for ; Mon, 21 Sep 2015 22:58:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1442901490; x=1474437490; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=eHwFcMQVbQkyXPNOTeD6aEKe3+4XwpcgFJUwqUQnEYM=; b=qGDDmY+PD0pNvvbxyF9QgFavdYGUkMeMUxB5U79CBWzzvsLKvRaMnuQ9 i6Dd57aXrumloagedrhenYLAz4qu4Z0t7nGP4ZMlZH+hydnV5ttziemIr WGaJouPWUZZCGW6UnDAH1m999aGAfxqS2q1PXFYRYUUAvqsSaSZUuH4aC g=; X-IronPort-AV: E=Sophos;i="5.17,571,1437436800"; d="scan'208";a="180671498" X-IPAS-Result: A2HWCADU7ABW/+sKqMBdGQEBAQUBAQGDVGkGrBsBkxAeCoV5AhyBawEBAQEBAQSBB4I+FBABAQEBAQEmAQEBAQEBIwI+LQEBAQEDAQEBMToJAgwEAgEGAg4DBAEBAQQjBQICJQsUCQgCBAENBRuIIJlEnSUIlDQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgR6FVYR9hFoYGwcGgl+BRwEEhT2HQIhohRGFRYQARoNvlRuEZHGIaIEFAQEB Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP; 22 Sep 2015 05:58:09 +0000 Received: from SEAEXCHMBX02.olympus.F5Net.com (192.168.15.224) by SEAEXCHMBX08.olympus.F5Net.com (192.168.15.227) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 21 Sep 2015 22:58:08 -0700 Received: from SEAEXCHMBX02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f]) by seaexchmbx02.olympus.F5Net.com ([fe80::dd5e:c398:17d9:927f%13]) with mapi id 15.00.1044.021; Mon, 21 Sep 2015 22:58:08 -0700 From: Sumandra Majee To: Dave Dolson , "Joel M. Halpern" , "Carlos Pignataro (cpignata)" , "wang.cui1@zte.com.cn" Thread-Topic: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-00.txt Thread-Index: AQHQ9Fl1IrpxWtXX7keTznL0rfXWD55HqXuAgAAERoCAAAW2gIAAAkkAgABY2IA= Date: Tue, 22 Sep 2015 05:58:07 +0000 Message-ID: References: <20150921081357.8630.47947.idtracker@ietfa.amsl.com> <6C7D9374-9A11-4D22-9E3C-7FA1EF2B9A95@cisco.com> <560036AB.1030001@joelhalpern.com> <56003F0B.9040002@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="gb2312" Content-ID: <2AE77CE50F4C184AB5A3C7AE172BFF16@F5.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Wei Meng , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-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: Tue, 22 Sep 2015 05:58:12 -0000 DQoNCk9uIDkvMjEvMTUsIDEwOjQwIEFNLCAic2ZjIG9uIGJlaGFsZiBvZiBEYXZlIERvbHNvbiIg PHNmYy1ib3VuY2VzQGlldGYub3JnDQpvbiBiZWhhbGYgb2YgZGRvbHNvbkBzYW5kdmluZS5jb20+ IHdyb3RlOg0KDQo+SSBtaWdodCBiZSBtaXNzaW5nIHNvbWV0aGluZywgYnV0IGxldCdzIHRha2Ug YSB2ZXJ5IHNpbXBsZSBjYXNlOiBhIHByb3h5DQo+U0YgbmVlZHMgdG8gcmVzcG9uZCB0byBhIFNZ TiBwYWNrZXQgcmVjZWl2ZWQgb24gYSBTRlAgd2l0aCBhIFNZTi1BQ0suDQo+V2hpY2ggU0ZQIHNo b3VsZCB0aGUgU1lOLUFDSyBiZSBwbGFjZWQgb24/DQoNCiBUaGlzIGRlcGVuZHMgb24gdGhlIG5l eHQgaG9wIGxvb2t1cCBiYXNlZCBvbiBwYXRoX2lkLiBJIGRvbqGvdCB0aGluayBhbnkNCmV4cGxp Y2l0IGNvbmZpZ3VyYXRpb24gaXMgbmVjZXNzYXJ5Lg0KDQoNCg0KPg0KPkkndmUgYmVlbiBhc3N1 bWluZyB0aGVyZSBuZWVkcyB0byBiZSBhIGNvbmZpZ3VyYXRpb24gdG8gcGFpciB1cA0KPmxlZnQt dG8tcmlnaHQgd2l0aCByaWdodC10by1sZWZ0IFNGUHMsIGFuZCB0aGF0IHRoZSBDMyBpbnRlcmZh Y2Ugd291bGQNCj5ldmVudHVhbGx5IHByb3ZpZGUgdGhpcy4NCj4NCj4NCj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPkZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb21dDQo+U2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjEsIDIwMTUgMTozMiBQTQ0KPlRv OiBEYXZlIERvbHNvbjsgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpOyB3YW5nLmN1aTFAenRl LmNvbS5jbg0KPkNjOiBXZWkgTWVuZzsgc2ZjQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtzZmNd IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj5kcmFmdC13YW5nLXNmYy1tZC10eXBlLWlz c3Vlcy0wMC50eHQNCj4NCj5Vbmxlc3Mgd2UgYXJlIHVzaW5nIHBlci1zdWJzY3JpYmVyIFNGUHMg KHdoaWNoIHNjYWxlc3ZlcnkgYmFkbHksIGJ1dCB5b3UNCj5jYW4gZG8gaXQpIEkgd291bGQgZXhw ZWN0IHRoYXQgYXNzb2NpYXRpb24gdG8gYmUgbWFkZSBvbiB0aGUgYmFzaXMgb2YNCj5zdWJzY3Jp YmVyIG1ldGFkYXRhLiAgSW4gbm9ybWFsIGNpcmN1bXN0YW5jZXMsIHRoZSBwYXRoIElEIGlzIG5l aXRoZXINCj5uZWNlc3Nhcnkgbm9yIHN1ZmZpY2llbnQgZm9yIHRoZSBzZXJ2aWNlIGZ1bmN0aW9u IHRvIGVuYWJsZSBzeW1tZXRyeS4NCj4NCj5FdmVuIGlmIHRoZSBTRlBzIGFyZSBhdCBhIGdyYW51 bGFyaXR5IHNvIHRoYXQgdGhlcmUgYXJlIHNlcGFyYXRlIFNGUCBJRHMNCj5mb3IgaGVscGluZyBl bmZvcmNlIHBhdGggc3ltbWV0cnksIHRoYXQgd2lsbCBub3QgcHJvdmlkZSB0aGUgc3RhdGUNCj5u ZWVkZWQgZm9yIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucy4gIEFuZCB0aGUgc3RhdGUgdGhhdCBpcyBu ZWVkZWQgZm9yIHRoZQ0KPnNlcnZpY2UgZnVuY3Rpb25zIGlzLCBpbiBhbGwgY2FzZXMgSSBjYW4g c2VlLCBzdWZmaWNlaW50IHdpdGhvdXQNCj5leGFtaW5pbmcgdGhlIFNGUCBJRC4NCj4NCj5Zb3Vy cywNCj5Kb2VsDQo+DQo+T24gOS8yMS8xNSAxOjExIFBNLCBEYXZlIERvbHNvbiB3cm90ZToNCj4+ IEF0IGxlYXN0IHNvbWUgc2VydmljZSBmdW5jdGlvbnMgcmVxdWlyZSBwZXItU0ZQIHN0YXRlIHRv IGFzc29jaWF0ZQ0KPj5iaWRpcmVjdGlvbmFsIHBhdGhzIHRvIGVhY2ggb3RoZXIuDQo+Pg0KPj4N Cj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybg0KPj4gU2VudDog TW9uZGF5LCBTZXB0ZW1iZXIgMjEsIDIwMTUgMTI6NTYgUE0NCj4+IFRvOiBDYXJsb3MgUGlnbmF0 YXJvIChjcGlnbmF0YSk7IHdhbmcuY3VpMUB6dGUuY29tLmNuDQo+PiBDYzogV2VpIE1lbmc7IHNm Y0BpZXRmLm9yZw0KPj4gU3ViamVjdDogUmU6IFtzZmNdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3INCj4+ZHJhZnQtd2FuZy1zZmMtbWQtdHlwZS1pc3N1ZXMtMDAudHh0DQo+Pg0KPj4gRmly c3QsIGlmIHdlIGFyZSBkb2luZyB0byBhc3N1bWUgdGhhdCBTZXJ2aWNlIEZ1bmN0aW9ucyB3aWxs IHVzZSB0aGUNCj4+IFNGUC1JRCB0byBkaXNhbWJpZ3VhdGUgdHlwZS0xIG1ldGFkYXRhIGluIG1p eGVkIGVudmlyb25tZW50cywgd2Ugc2hvdWxkDQo+PiBzYXkgdGhhdCBpbiB0aGUgZHJhZnQuDQo+ Pg0KPj4gU2Vjb25kLCBJIGFtIGEgYml0IGNvbmNlcm5lZCBieSB0aGlzIHByb3Bvc2VkIGJlaGF2 aW9yLCBiZWNhdXNlIHdlIGhhdmUNCj4+IGJlZW4gY2FyZWZ1bCB1cCB0aWxsIG5vdyB0byBoYXZl IHRoZSBTZXJ2aWNlIEZ1bmN0aW9ucyBhY3Qgb24gbWV0YWRhdGENCj4+IHdpdGhvdXQgcmVxdWly aW5nIHBlci1TRlAgc3RhdGUuICBUaGlzIHdvdWxkIG1hcmsgYSBzaWduaWZpY2FudCBzaGlmdC4N Cj4+DQo+PiB5b3VycywNCj4+IEpvZWwNCj4+DQo+PiBPbiA5LzIxLzE1IDY6MzYgQU0sIENhcmxv cyBQaWduYXRhcm8gKGNwaWduYXRhKSB3cm90ZToNCj4+PiBMaW5kYSwNCj4+Pg0KPj4+IEl0IHNl ZW1zIHRoZSBpc3N1ZSB0aGF0IHRoaXMgZHJhZnQgYXR0ZW1wdHMgdG8gcmFpc2UgY2FuIGJlIHN1 bW1hcml6ZWQNCj4+PiB3aXRoIHRoaXMgcXVlc3Rpb246DQo+Pj4NCj4+PiAiV2hlbiB0cmFmZmlj IGlzIHN0ZWVyZWQgdG8gU0YzLCBob3cgU0YzIHRvIGNvcnJlY3RseSBhbmFseXplIHRoZQ0KPj4+ IE1hbmRhdG9yeSBDb250ZXh0IEhlYWRlcnMgaW4gTlNIIHdpdGhpbiB0aGUgYXJyaXZpbmcgdHJh ZmZpYz8iDQo+Pj4NCj4+Pg0KPj4+IFRoZSBzb2x1dGlvbiB0byB0aGlzLCBob3dldmVyLCBpcyBu ZWl0aGVyIG9mIHdoYXQncyBwcmVzZW50ZWQgaW4NCj4+PiBTZWN0aW9ucyA0LjEgYW5kIDQuMi4g VGhlIGFuc3dlciBpcyBtdWNoIHNpbXBsZXIgYW5kIGFscmVhZHkgdGhlcmU6IHRoZQ0KPj4+IFNG UCAoYnkgd2F5IG9mIHRoZSBTRlAgSUQpIHByb3ZpZGVzIGNvbnRleHQgdG8gdW5kZXJzdGFuZCB0 aGUgZm9ybWF0IG9mDQo+Pj4gdGhlIG1ldGFkYXRhLiBJbiBvdGhlciB3b3JkcywgYSBnaXZlbiBT RlAgSUQgd2lsbCB1c2Ugb25lIG9mIHRoZSBNRA0KPj4+IGZvcm1hdHMvc3ludGF4IChEQywgTW9i aWxpdHksIHNvbWV0aGluZyBlbHNlKS4NCj4+Pg0KPj4+IFRoYW5rcywNCj4+Pg0KPj4+IFRodW1i IHR5cGVkIGJ5IENhcmxvcyBQaWduYXRhcm8uDQo+Pj4gRXhjdXplIHR5cG9mcmFwaGljYWsgZXJy b3dzDQo+Pj4NCj4+PiBPbiBTZXAgMjEsIDIwMTUsIGF0IDA0OjI2LCAid2FuZy5jdWkxQHp0ZS5j b20uY24NCj4+PiA8bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuPiIgPHdhbmcuY3VpMUB6dGUu Y29tLmNuDQo+Pj4gPG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj4+IHdyb3RlOg0KPj4+DQo+ Pj4+DQo+Pj4+IERlYXIgYWxsLA0KPj4+Pg0KPj4+PiAgICAgSGVyZSBpcyBhIG5ldyBkcmFmdCBw cm9wb3NlZCB0byByYWlzZSBhbiBpc3N1ZSB3aGljaCBtYXkgZXhpc3QNCj4+Pj53aGVuDQo+Pj4+ IE1EIFR5cGU9MHgwMSBpcyBtYW5kYXRvcnkuDQo+Pj4+IEFuZCB0byBtb3RpdmF0ZSB0aGUgZnVy dGhlciBkaXNjdXNzaW9uIGFib3V0IE1EIFR5cGUuIFdpc2ggeW91IGNhbiBwYXkNCj4+Pj4gYXR0 ZW50aW9uIHRvIHRoaXMgdG8NCj4+Pj4gY29udGludWUgdGhlIGRpc2N1c3Npb24gYW5kIG1ha2Ug YSBjb25zZW5zdXMgOykNCj4+Pj4NCj4+Pj4gICAgVGhhbmtzLi4NCj4+Pj4NCj4+Pj4gQmVzdCBX aXNoZXMsDQo+Pj4+IExpbmRhIFdhbmcNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIDxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiDQ tNPaDQo+Pj4+IDIwMTUvMDkvMjEgMTY6MTM6NTc6DQo+Pj4+DQo+Pj4+PiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+Pj4+PiAyMDE1 LzA5LzIxIDE2OjEzDQo+Pj4+Pg0KPj4+Pj4gytW8/sjLDQo+Pj4+Pg0KPj4+Pj4gIkN1aSBXYW5n IiA8d2FuZy5jdWkxQHp0ZS5jb20uY24gPG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj4+LA0K Pj4+PiAiV2VpIE1lbmciDQo+Pj4+PiA8bWVuZy53ZWkyQHp0ZS5jb20uY24gPG1haWx0bzptZW5n LndlaTJAenRlLmNvbS5jbj4+LCAiQ3VpIFdhbmciDQo+Pj4+IDx3YW5nLmN1aTFAenRlLmNvbS5j biA8bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuPj4sICJXZWkNCj4+Pj4+IE1lbmciIDxtZW5n LndlaTJAenRlLmNvbS5jbiA8bWFpbHRvOm1lbmcud2VpMkB6dGUuY29tLmNuPj4sDQo+Pj4+Pg0K Pj4+Pj4gs63LzQ0KPj4+Pj4NCj4+Pj4+INb3zOINCj4+Pj4+DQo+Pj4+PiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNzdWVzLTAwLnR4dA0KPj4+ Pj4NCj4+Pj4+DQo+Pj4+PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd2FuZy1zZmMtbWQt dHlwZS1pc3N1ZXMtMDAudHh0DQo+Pj4+PiBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IEN1aSBXYW5nIGFuZCBwb3N0ZWQgdG8gdGhlDQo+Pj4+PiBJRVRGIHJlcG9zaXRvcnkuDQo+ Pj4+Pg0KPj4+Pj4gTmFtZTogICAgICBkcmFmdC13YW5nLXNmYy1tZC10eXBlLWlzc3Vlcw0KPj4+ Pj4gUmV2aXNpb246ICAgMDANCj4+Pj4+IFRpdGxlOiAgICAgIE1ldGFkYXRhIFR5cGUgSXNzdWVz DQo+Pj4+PiBEb2N1bWVudCBkYXRlOiAgIDIwMTUtMDktMjENCj4+Pj4+IEdyb3VwOiAgICAgIElu ZGl2aWR1YWwgU3VibWlzc2lvbg0KPj4+Pj4gUGFnZXM6ICAgICAgMTQNCj4+Pj4+IFVSTDogaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdhbmctc2ZjLQ0KPj4+Pj4g bWQtdHlwZS1pc3N1ZXMtMDAudHh0DQo+Pj4+PiBTdGF0dXM6IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LXdhbmctc2ZjLW1kLQ0KPj4+Pj4gdHlwZS1pc3N1ZXMvDQo+Pj4+ PiBIdG1saXplZDogDQo+Pj4+Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YW5n LXNmYy1tZC10eXBlLWlzc3Vlcy0wMA0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBBYnN0cmFjdDoNCj4+ Pj4+ICAgICBTZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGlzIHRoZSBkZWZpbml0aW9uIG9mIGFuIG9y ZGVyZWQgc2V0IG9mDQo+Pj4+PnNlcnZpY2UNCj4+Pj4+ICAgICBmdW5jdGlvbnMuICBBZnRlciBp bnN0YW50aWF0ZWQsIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggaXMNCj4+Pj4+Y3JlYXRlZA0K Pj4+Pj4gICAgIGFuZCB0aGUgY2xhc3NpZmllZCB0cmFmZmljIGlzIHN0ZWVyZWQgdGhyb3VnaCB0 aGUgY29ycmVzcG9uZGluZw0KPj4+Pj4gICAgIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBhbmQgdGhl biBmb3J3YXJkZWQgdG8gdGhlIGZpbmFsDQo+Pj4+PmRlc3RpbmF0aW9uLg0KPj4+Pj4gICAgIE1l dGFkYXRhIChNRCkgaXMgY29udmV5ZWQgaW4gU0ZDIGRhdGEgcGxhbmUgd2hpY2ggcHJvdmlkZXMg dGhlDQo+Pj4+PiAgICAgYWJpbGl0eSB0byBleGNoYW5nZSBjb250ZXh0IGluZm9ybWF0aW9uIGJl dHdlZW4gY2xhc3NpZmllcnMgYW5kDQo+Pj4+PlNGcywNCj4+Pj4+ICAgICBhbW9uZyBTRnMsIGFu ZCBiZXR3ZWVuIGV4dGVybmFsIHN5c3RlbXMgYW5kIFNGcy4gIFRoaXMgZG9jdW1lbnQNCj4+Pj4+ aXMNCj4+Pj4+ICAgICBtb3RpdmF0ZWQgdG8gc3RhdGUgYW4gaXNzdWUgd2hlbiBNRCBUeXBlID0g MHgxIGFuZCBkaXNjdXNzIHdoaWNoDQo+Pj4+PiAgICAgTWV0YWRhdGEgVHlwZSBpbiBtb3JlIGFw cHJvcHJpYXRlIHRvIGJlIG1hbmRhdGUgaW4gU0ZDIGRhdGENCj4+Pj4+cGxhbmUuDQo+Pj4+Pg0K Pj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCj4+Pj4gc3VibWlzc2lvbg0KPj4+ Pj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0 b29scy5pZXRmLm9yZw0KPj4+PiA8aHR0cDovL3Rvb2xzLmlldGYub3JnPi4NCj4+Pj4+DQo+Pj4+ PiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KPj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+PiBz ZmNAaWV0Zi5vcmcgPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+ IHNmY0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQo+Pj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBtYWlsaW5nIGxpc3QNCj5zZmNA aWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= From nobody Thu Sep 24 00:53: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 5DC241B37D0 for ; Thu, 24 Sep 2015 00:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.06 X-Spam-Level: X-Spam-Status: No, score=-12.06 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, MIME_CHARSET_FARAWAY=2.45, 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 pw3A4BE_yRsP for ; Thu, 24 Sep 2015 00:53:48 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931CD1B37D3 for ; Thu, 24 Sep 2015 00:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=73096; q=dns/txt; s=iport; t=1443081227; x=1444290827; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gDu7YNK9b/sQsGzMi2zCmRCYw7/nHJPK4uEJUBY6FuE=; b=KZoBXJqOK8npGlwoaRM19ewFJMunCp+x20X8OUvecpczRhp1EOYFU+0U 71z0naco0wgvUKwI9OTryIv+HJ6S4WdwzU/qSPihza2RkRhtt8wdszxvS he7jZzHp/qL9AYrpfQUF9Woo8mPPrKfYAs7HGs2wDIZF8BiMEnKi4lyqo g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AQAgDmqgNW/5xdJa1dgldNVGkGgyS6FAENgVYaAQmFeQIcgS44FAEBAQEBAQGBCoQkAQEBBAEBASQGQQsMBAIBBgIRAwEBASEBBgUCAiULFAkIAgQBDQUbiBMNmgadJQiUPAEBAQEBAQEBAQEBAQEBAQEBAQEBAReGc4R9hHIKDAEEBgEGA4JcgUcBBIU9h0CFQYMpAYURgm6CWIIzgU9Gg3CROINtEQ4BAUKEAXEBiGaBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,579,1437436800"; d="scan'208,217";a="190764759" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-4.cisco.com with ESMTP; 24 Sep 2015 07:53:46 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t8O7rkfm012234 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Sep 2015 07:53:46 GMT Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 24 Sep 2015 02:53:45 -0500 Received: from xhc-aln-x02.cisco.com (173.36.12.76) by xch-rcd-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 24 Sep 2015 02:53:45 -0500 Received: from xmb-rcd-x04.cisco.com ([169.254.8.230]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0248.002; Thu, 24 Sep 2015 02:53:45 -0500 From: "Reinaldo Penno (repenno)" To: Linda Dunbar , "Joel M. Halpern" , Dave Dolson Thread-Topic: [sfc] in-path packet generation Thread-Index: AQHQ9JdRlkmyZ4H690y908zbXHU9lJ5HJbqAgAC0ToCAA1eFAA== Date: Thu, 24 Sep 2015 07:53:44 +0000 Message-ID: References: <20150921081357.8630.47947.idtracker@ietfa.amsl.com> <6C7D9374-9A11-4D22-9E3C-7FA1EF2B9A95@cisco.com> <560036AB.1030001@joelhalpern.com> <56003F0B.9040002@joelhalpern.com> <5600457E.90604@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657D59743@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657D59743@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.4.150722 x-originating-ip: [173.37.102.14] Content-Type: multipart/alternative; boundary="_000_D227854D198F9repennociscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] in-path packet generation 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, 24 Sep 2015 07:53:52 -0000 --_000_D227854D198F9repennociscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SW5saW5lIHdpdGggW1JQXQ0KDQpGcm9tOiBMaW5kYSBEdW5iYXIgPGxpbmRhLmR1bmJhckBodWF3 ZWkuY29tPG1haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbT4+DQpEYXRlOiBNb25kYXksIFNl cHRlbWJlciAyMSwgMjAxNSBhdCAyOjUxIFBNDQpUbzogUmVpbmFsZG8gUGVubm8gPHJlcGVubm9A Y2lzY28uY29tPG1haWx0bzpyZXBlbm5vQGNpc2NvLmNvbT4+LCAiSm9lbCBNLiBIYWxwZXJuIiA8 am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbT4+LCBEYXZlIERv bHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb208bWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tPj4N CkNjOiAic2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+IiA8c2ZjQGlldGYub3JnPG1h aWx0bzpzZmNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IFtzZmNdIGluLXBhdGggcGFja2V0IGdl bmVyYXRpb24NCg0KUGVubm8sDQoNClRoYXQgaXMgYW4gaW50ZXJlc3RpbmcgcHJvYmxlbS4gVGhh bmtzIGZvciBkb2N1bWVudGluZyBpdC4NCg0KSSBoYXZlIGEgY291cGxlIG9mIHF1ZXN0aW9uczoN Cg0KDQotICAgICAgICAgIFdoZW4gYSBwYWNrZXQsIHdoaWNoIGNhbiBiZSBlbmNhcHN1bGF0ZWQg aW4gdmFyaW91cyBvdXRlciBoZWFkZXJzIChWeExBTiwgU0ZDoa9zIE5TSCwgb3Igb3RoZXIgaGVh ZGVyKSwgYXJyaXZlcyBhdCB0aGUgRlcgaW5ncmVzcyBwb3J0LCB3aGljaCBTb3VyY2UgQWRkcmVz cyB3aWxsIEZXIHNlbmQgIHRoZSChsGdlbmVyYXRlZCBwYWNrZXRzobEgdG8/IElzIGl0IHRoZSBt b3N0IG91dGVyIGhlYWRlcqGvcyBTb3VyY2UgYWRkcmVzcz8NCg0KW1JQXSBOb3QgbmVjZXNzYXJp bHkgYWx0aG91Z2ggaXMgYW4gb3B0aW9uLiAgVGhlIFNGIG1pZ2h0IGhhdmUgcmVjZWl2ZWQgYSBw YWNrZXQgZnJvbSBhIFNGRiB0aGF0IGlzIG5vdCBwYXJ0IG9mIHRoZSByZXZlcnNlIHBhdGguICBH ZW5lcmF0ZWQgcGFja2V0cyByZWNlaXZlZCBieSB0aGlzIFNGRiB3b3VsZCBiZSBkcm9wcGVkIG9y IHB1bnRlZCBzb21ld2hlcmUgdW5sZXNzIHRoZSBTRkYgaGFzIGFjY2VzcyB0byBhbGwgUlNQcy4g IFRoZXJlIGFyZSBvdGhlciB0ZWNobmlxdWVzIHRvIHNvbHZlIHRoaXMgcHJvYmxlbS4gIEkgd2ls bCBkaXNjdXNzIGEgZmV3IGluIHRoZSB1cGNvbWluZyByZXZpc2lvbnMgb2YgdGhlIGRvY3VtZW50 Lg0KDQoNCi0gICAgICAgICAgV2hhdCBraW5kIG9mIGV2ZW50cyBjYW4gdHJpZ2dlciBhIEZXIHRv IGdlbmVyYXRlIHBhY2tldHMgdG8gdGhlIHNvdXJjZT8NCg0KW1JQXSBBbnl0aGluZyB0aGF0IHZp b2xhdGVzIGEgZmlyZXdhbGwgcG9saWN5Lg0KDQoNCi0gICAgICAgICAgSWYgdGhlIHNlcXVlbmNl IG9mIHRoZSBTZXJ2aWNlIEZ1bmN0aW9ucyBpczogV2ViIE9wdGltaXphdGlvbiAtPiBGVywgd2hh dCBraW5kIG9mIGNpcmN1bXN0YW5jZXMgd2lsbCByZXF1aXJlIHRoZSBGVyB0byBnZW5lcmF0ZSBt ZXNzYWdlIHRvIHRyYXZlcnNlIHRoZSChsFdlYiBPcHRpbWl6YXRpb26hsT8NCg0KW1JQXSBSaWdo dCwgbm90IGFsbCByZXZlcnNlIHBhdGhzIGFyZSBzeW1tZXRyaWMgcGF0aHMuICBJZiByZXZlcnNl IHBhY2tldHMgc2hvdWxkIG5vdCBjcm9zcyB3ZWIgb3B0aW1pemF0aW9uIGl0IG1lYW5zIHRoZSBy ZXZlcnNlIHBhdGhzIGlzIGFzeW1tZXRyaWMuICBHZW5lcmF0ZWQgcmV2ZXJzZSBwYWNrZXRzIGZv bGxvdyB0aGUgcmVndWxhciBwYXRoIHJlc3Bvc2VzIHdvdWxkIHRha2UuIElmIHJlc3BvbnNlcyB3 b3VsZCBieXBhc3Mgd2ViIG9wdGltaXphdGlvbiBzbyB3aWxsIGdlbmVyYXRlZCBwYWNrZXRzLg0K DQpUaGFuayB5b3UgdmVyeSBtdWNoLg0KDQpMaW5kYQ0KDQoNCg0KRnJvbTogc2ZjIFttYWlsdG86 c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSZWluYWxkbyBQZW5ubyAocmVwZW5u bykNClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDIxLCAyMDE1IDE6MDYgUE0NClRvOiBKb2VsIE0u IEhhbHBlcm47IERhdmUgRG9sc29uDQpDYzogc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3NmY10gaW4tcGF0aCBwYWNrZXQgZ2VuZXJhdGlvbg0KDQpXZSBz dHVkaWVkIHRoaXMgaXNzdWUgY29uc2lkZXJhYmx5IGFuZCBkb2N1bWVudGVkIHRoZSBzb2x1dGlv bnMgd2UgaW1wbGVtZW50ZWQgaGVyZToNCg0KDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXBlbm5vLXNmYy1wYWNrZXQtMDAudHh0DQpT dGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcGVu bm8tc2ZjLXBhY2tldC8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtcGVubm8tc2ZjLXBhY2tldC0wMA0KDQoNCkFic3RyYWN0Og0KICAgU2VydmljZSBG dW5jdGlvbnMgKGUuZy4sIEZpcmV3YWxsLCBOQVQsIFByb3hpZXMgYW5kIEludHJ1c2lvbg0KICAg UHJldmVudGlvbiBTeXN0ZW1zKSBnZW5lcmF0ZSBwYWNrZXRzIGluIHRoZSByZXZlcnNlIGZsb3cg ZGlyZWN0aW9uIHRvDQogICB0aGUgc291cmNlIG9mIHRoZSBjdXJyZW50IGluLXByb2Nlc3MgcGFj a2V0L2Zsb3cuICBJbiB0aGlzIGRvY3VtZW50DQogICB3ZSBkaXNjdXNzIGFuZCBwcm9wb3NlIGhv dyB0byBzdXBwb3J0IHRoaXMgcmVxdWlyZWQgZnVuY3Rpb25hbGl0eQ0KICAgd2l0aGluIHRoZSBT RkMgZnJhbWV3b3JrLg0KDQoNCg0KDQpPbiA5LzIxLzE1LCAxMDo1OSBBTSwgInNmYyBvbiBiZWhh bGYgb2YgSm9lbCBNLiBIYWxwZXJuIiA8c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNmYy1i b3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Ygam1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbT4+IHdyb3RlOg0KDQpUaGF0IGlzIGFuIGFzcGVjdCB0aGF0IEkg aGFkIG5vdCBjb25zaWRlcmVkIGluIGFza2luZyB5b3VyIHF1ZXN0aW9uLg0KVGhhdCBpcyBub3Qg YWJvdXQgc3ltbWV0cnkgb2YgU0ZQcywgYnV0IGFib3V0IHRoZSBiZWhhdmlvciBvZiBzZXJ2aWNl DQpmdW5jdGlvbnMgd2hpY2ggZ2VuZXJhdGUgZXh0cmEgcGFja2V0cyBpbiBlYWNoIGRpcmVjdGlv bi4NCg0KT3ZlciBhbGwsIHRoYXQgaXMgc2VyaW91c2x5IHVuZGVyLXNwZWNpZmllZCwgYW5kIHdl IHNob3VsZCBhZGRyZXNzIGl0Lg0KDQpXaGlsZSBJIGRvbid0IGtub3cgd2hhdCBhbnN3ZXIgdGhl IHdvcmtpbmcgZ3JvdXAgd2lsbCBhZG9wdCwgbXkNCmluY2xpbmF0aW9uIGlzIHRvIHNheSB0aGF0 IHN1Y2ggcGFja2V0IGdlbmVyYXRpb24gbmVlZHMgYSBjbGFzc2lmaWVyLg0KVGhlIHNlcnZpY2Ug ZnVuY3Rpb24gZ2VuZXJhdGVzIHRoZSBwYWNrZXQgd2l0aCB3aGF0ZXZlciBtZXRhZGF0YSBpdA0K d2FudHMgdG8gYXR0YWNoLCBhbmQgdGhlbiBoYW5kcyBpdCB0byBhIGNsYXNzaWZpZXIgdG8gZGV0 ZXJtaW5lIHdoYXQgdG8NCmRvIHdpdGggaXQuDQoNClNlcGFyYXRlbHksIEkgd291bGQgbm90ZSB0 aGF0IGV2ZW4gaWYgd2UgYWRvcHQgYW4gU0ZQLXN0YXRlZnVsIHNvbHV0aW9uDQpmb3Igc3VjaCBz ZXJ2aWNlIGZ1bmN0aW9ucywgSSB3b3VsZCBub3Qgd2FudCB0aGUgbWV0YWRhdGEgaGFuZGxpbmcg dG8NCmRyaXZlIGEgcmVxdWlyZW1lbnQgZm9yIHN1Y2ggc3RhdGUgaW4gYWxsIHNlcnZpY2UgZnVu Y3Rpb25zIGluIG9yZGVyIHRvDQp1bmRlcnN0YW5kIHRoZSBtZXRhZGF0YS4NCkJlZm9yZSBzb21l b25lIGFyZ3VlcyB0aGF0IHRoaXMgd291bGQgb25seSBiZSBuZWVkZWQgaW4gaHlicmlkDQpkZXBs b3ltZW50cywgSSB3b3VsZCBvYnNlcnZlIHRoYXQgSSBleHBlY3Qgc2VydmljZSBmdW5jdGlvbnMg dG8gYmUNCmRlc2lnbmVkIGFuZCBidWlsdCB0byB3b3JrIGluIGJvdGggZGVkaWNhdGVkIGFuZCBo eWJyaWQgZGVwbG95bWVudHMuDQpBbmQgaWYgTUQtMSBpcyBhIE1VU1QgKGFzIGl0IGN1cnJlbnRs eSBpcyB3cml0dGVuKSB0aGVuIHRoZXkgYWxsIGhhdmUgdG8NCmhhdmUgdGhpcyBjYXBhYmlsaXR5 Lg0KDQpZb3VycywNCkpvZWwNCg0KT24gOS8yMS8xNSAxOjQwIFBNLCBEYXZlIERvbHNvbiB3cm90 ZToNCkkgbWlnaHQgYmUgbWlzc2luZyBzb21ldGhpbmcsIGJ1dCBsZXQncyB0YWtlIGEgdmVyeSBz aW1wbGUgY2FzZTogYSBwcm94eSBTRiBuZWVkcyB0byByZXNwb25kIHRvIGEgU1lOIHBhY2tldCBy ZWNlaXZlZCBvbiBhIFNGUCB3aXRoIGEgU1lOLUFDSy4gV2hpY2ggU0ZQIHNob3VsZCB0aGUgU1lO LUFDSyBiZSBwbGFjZWQgb24/DQoNCkkndmUgYmVlbiBhc3N1bWluZyB0aGVyZSBuZWVkcyB0byBi ZSBhIGNvbmZpZ3VyYXRpb24gdG8gcGFpciB1cCBsZWZ0LXRvLXJpZ2h0IHdpdGggcmlnaHQtdG8t bGVmdCBTRlBzLCBhbmQgdGhhdCB0aGUgQzMgaW50ZXJmYWNlIHdvdWxkIGV2ZW50dWFsbHkgcHJv dmlkZSB0aGlzLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2VsIE0u IEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KU2VudDogTW9uZGF5LCBTZXB0 ZW1iZXIgMjEsIDIwMTUgMTozMiBQTQ0KVG86IERhdmUgRG9sc29uOyBDYXJsb3MgUGlnbmF0YXJv IChjcGlnbmF0YSk7IHdhbmcuY3VpMUB6dGUuY29tLmNuPG1haWx0bzp3YW5nLmN1aTFAenRlLmNv bS5jbj4NCkNjOiBXZWkgTWVuZzsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW3NmY10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13YW5n LXNmYy1tZC10eXBlLWlzc3Vlcy0wMC50eHQNCg0KVW5sZXNzIHdlIGFyZSB1c2luZyBwZXItc3Vi c2NyaWJlciBTRlBzICh3aGljaCBzY2FsZXN2ZXJ5IGJhZGx5LCBidXQgeW91DQpjYW4gZG8gaXQp IEkgd291bGQgZXhwZWN0IHRoYXQgYXNzb2NpYXRpb24gdG8gYmUgbWFkZSBvbiB0aGUgYmFzaXMg b2YNCnN1YnNjcmliZXIgbWV0YWRhdGEuICBJbiBub3JtYWwgY2lyY3Vtc3RhbmNlcywgdGhlIHBh dGggSUQgaXMgbmVpdGhlcg0KbmVjZXNzYXJ5IG5vciBzdWZmaWNpZW50IGZvciB0aGUgc2Vydmlj ZSBmdW5jdGlvbiB0byBlbmFibGUgc3ltbWV0cnkuDQoNCkV2ZW4gaWYgdGhlIFNGUHMgYXJlIGF0 IGEgZ3JhbnVsYXJpdHkgc28gdGhhdCB0aGVyZSBhcmUgc2VwYXJhdGUgU0ZQIElEcw0KZm9yIGhl bHBpbmcgZW5mb3JjZSBwYXRoIHN5bW1ldHJ5LCB0aGF0IHdpbGwgbm90IHByb3ZpZGUgdGhlIHN0 YXRlDQpuZWVkZWQgZm9yIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucy4gIEFuZCB0aGUgc3RhdGUgdGhh dCBpcyBuZWVkZWQgZm9yIHRoZQ0Kc2VydmljZSBmdW5jdGlvbnMgaXMsIGluIGFsbCBjYXNlcyBJ IGNhbiBzZWUsIHN1ZmZpY2VpbnQgd2l0aG91dA0KZXhhbWluaW5nIHRoZSBTRlAgSUQuDQoNCllv dXJzLA0KSm9lbA0KDQpPbiA5LzIxLzE1IDE6MTEgUE0sIERhdmUgRG9sc29uIHdyb3RlOg0KQXQg bGVhc3Qgc29tZSBzZXJ2aWNlIGZ1bmN0aW9ucyByZXF1aXJlIHBlci1TRlAgc3RhdGUgdG8gYXNz b2NpYXRlIGJpZGlyZWN0aW9uYWwgcGF0aHMgdG8gZWFjaCBvdGhlci4NCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBKb2VsIE0uIEhhbHBlcm4NClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDIx LCAyMDE1IDEyOjU2IFBNDQpUbzogQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpOyB3YW5nLmN1 aTFAenRlLmNvbS5jbjxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24+DQpDYzogV2VpIE1lbmc7 IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNdIE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FuZy1zZmMtbWQtdHlwZS1pc3N1ZXMt MDAudHh0DQoNCkZpcnN0LCBpZiB3ZSBhcmUgZG9pbmcgdG8gYXNzdW1lIHRoYXQgU2VydmljZSBG dW5jdGlvbnMgd2lsbCB1c2UgdGhlDQpTRlAtSUQgdG8gZGlzYW1iaWd1YXRlIHR5cGUtMSBtZXRh ZGF0YSBpbiBtaXhlZCBlbnZpcm9ubWVudHMsIHdlIHNob3VsZA0Kc2F5IHRoYXQgaW4gdGhlIGRy YWZ0Lg0KDQpTZWNvbmQsIEkgYW0gYSBiaXQgY29uY2VybmVkIGJ5IHRoaXMgcHJvcG9zZWQgYmVo YXZpb3IsIGJlY2F1c2Ugd2UgaGF2ZQ0KYmVlbiBjYXJlZnVsIHVwIHRpbGwgbm93IHRvIGhhdmUg dGhlIFNlcnZpY2UgRnVuY3Rpb25zIGFjdCBvbiBtZXRhZGF0YQ0Kd2l0aG91dCByZXF1aXJpbmcg cGVyLVNGUCBzdGF0ZS4gIFRoaXMgd291bGQgbWFyayBhIHNpZ25pZmljYW50IHNoaWZ0Lg0KDQp5 b3VycywNCkpvZWwNCg0KT24gOS8yMS8xNSA2OjM2IEFNLCBDYXJsb3MgUGlnbmF0YXJvIChjcGln bmF0YSkgd3JvdGU6DQpMaW5kYSwNCg0KSXQgc2VlbXMgdGhlIGlzc3VlIHRoYXQgdGhpcyBkcmFm dCBhdHRlbXB0cyB0byByYWlzZSBjYW4gYmUgc3VtbWFyaXplZA0Kd2l0aCB0aGlzIHF1ZXN0aW9u Og0KDQoiV2hlbiB0cmFmZmljIGlzIHN0ZWVyZWQgdG8gU0YzLCBob3cgU0YzIHRvIGNvcnJlY3Rs eSBhbmFseXplIHRoZQ0KTWFuZGF0b3J5IENvbnRleHQgSGVhZGVycyBpbiBOU0ggd2l0aGluIHRo ZSBhcnJpdmluZyB0cmFmZmljPyINCg0KDQpUaGUgc29sdXRpb24gdG8gdGhpcywgaG93ZXZlciwg aXMgbmVpdGhlciBvZiB3aGF0J3MgcHJlc2VudGVkIGluDQpTZWN0aW9ucyA0LjEgYW5kIDQuMi4g VGhlIGFuc3dlciBpcyBtdWNoIHNpbXBsZXIgYW5kIGFscmVhZHkgdGhlcmU6IHRoZQ0KU0ZQIChi eSB3YXkgb2YgdGhlIFNGUCBJRCkgcHJvdmlkZXMgY29udGV4dCB0byB1bmRlcnN0YW5kIHRoZSBm b3JtYXQgb2YNCnRoZSBtZXRhZGF0YS4gSW4gb3RoZXIgd29yZHMsIGEgZ2l2ZW4gU0ZQIElEIHdp bGwgdXNlIG9uZSBvZiB0aGUgTUQNCmZvcm1hdHMvc3ludGF4IChEQywgTW9iaWxpdHksIHNvbWV0 aGluZyBlbHNlKS4NCg0KVGhhbmtzLA0KDQpUaHVtYiB0eXBlZCBieSBDYXJsb3MgUGlnbmF0YXJv Lg0KRXhjdXplIHR5cG9mcmFwaGljYWsgZXJyb3dzDQoNCk9uIFNlcCAyMSwgMjAxNSwgYXQgMDQ6 MjYsICJ3YW5nLmN1aTFAenRlLmNvbS5jbjxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24+DQo8 bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuPjxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24l M2U+IiA8d2FuZy5jdWkxQHp0ZS5jb20uY248bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuPg0K PG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj48bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNu JTNlPj4gd3JvdGU6DQoNCg0KRGVhciBhbGwsDQoNCiAgICAgIEhlcmUgaXMgYSBuZXcgZHJhZnQg cHJvcG9zZWQgdG8gcmFpc2UgYW4gaXNzdWUgd2hpY2ggbWF5IGV4aXN0IHdoZW4NCk1EIFR5cGU9 MHgwMSBpcyBtYW5kYXRvcnkuDQpBbmQgdG8gbW90aXZhdGUgdGhlIGZ1cnRoZXIgZGlzY3Vzc2lv biBhYm91dCBNRCBUeXBlLiBXaXNoIHlvdSBjYW4gcGF5DQphdHRlbnRpb24gdG8gdGhpcyB0bw0K Y29udGludWUgdGhlIGRpc2N1c3Npb24gYW5kIG1ha2UgYSBjb25zZW5zdXMgOykNCg0KICAgICBU aGFua3MuLg0KDQpCZXN0IFdpc2hlcywNCkxpbmRhIFdhbmcNCg0KDQoNCg0KaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IDxtYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPiDQtNPaDQoyMDE1LzA5LzIxIDE2OjEzOjU3Og0KDQppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gPG1h aWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQoyMDE1LzA5LzIxIDE2OjEzDQoNCsrVvP7I yw0KDQoiQ3VpIFdhbmciIDx3YW5nLmN1aTFAenRlLmNvbS5jbjxtYWlsdG86d2FuZy5jdWkxQHp0 ZS5jb20uY24+IDxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24+PG1haWx0bzp3YW5nLmN1aTFA enRlLmNvbS5jbiUzZT4+LA0KIldlaSBNZW5nIg0KPG1lbmcud2VpMkB6dGUuY29tLmNuPG1haWx0 bzptZW5nLndlaTJAenRlLmNvbS5jbj4gPG1haWx0bzptZW5nLndlaTJAenRlLmNvbS5jbj48bWFp bHRvOm1lbmcud2VpMkB6dGUuY29tLmNuJTNlPj4sICJDdWkgV2FuZyINCjx3YW5nLmN1aTFAenRl LmNvbS5jbjxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24+IDxtYWlsdG86d2FuZy5jdWkxQHp0 ZS5jb20uY24+PG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbiUzZT4+LCAiV2VpDQpNZW5nIiA8 bWVuZy53ZWkyQHp0ZS5jb20uY248bWFpbHRvOm1lbmcud2VpMkB6dGUuY29tLmNuPiA8bWFpbHRv Om1lbmcud2VpMkB6dGUuY29tLmNuPjxtYWlsdG86bWVuZy53ZWkyQHp0ZS5jb20uY24lM2U+PiwN Cg0Ks63LzQ0KDQrW98ziDQoNCk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2Fu Zy1zZmMtbWQtdHlwZS1pc3N1ZXMtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNzdWVzLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBDdWkgV2FuZyBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5 Lg0KDQpOYW1lOiAgICAgIGRyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNzdWVzDQpSZXZpc2lvbjog ICAwMA0KVGl0bGU6ICAgICAgTWV0YWRhdGEgVHlwZSBJc3N1ZXMNCkRvY3VtZW50IGRhdGU6ICAg MjAxNS0wOS0yMQ0KR3JvdXA6ICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAg ICAxNA0KVVJMOiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtd2Fu Zy1zZmMtDQptZC10eXBlLWlzc3Vlcy0wMC50eHQNClN0YXR1czogaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1zZmMtbWQtDQp0eXBlLWlzc3Vlcy8NCkh0bWxpemVk OiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FuZy1zZmMtbWQtdHlwZS1pc3N1 ZXMtMDANCg0KDQpBYnN0cmFjdDoNCiAgICAgIFNlcnZpY2UgZnVuY3Rpb24gY2hhaW4gaXMgdGhl IGRlZmluaXRpb24gb2YgYW4gb3JkZXJlZCBzZXQgb2Ygc2VydmljZQ0KICAgICAgZnVuY3Rpb25z LiAgQWZ0ZXIgaW5zdGFudGlhdGVkLCB0aGUgc2VydmljZSBmdW5jdGlvbiBwYXRoIGlzIGNyZWF0 ZWQNCiAgICAgIGFuZCB0aGUgY2xhc3NpZmllZCB0cmFmZmljIGlzIHN0ZWVyZWQgdGhyb3VnaCB0 aGUgY29ycmVzcG9uZGluZw0KICAgICAgc2VydmljZSBmdW5jdGlvbiBwYXRoIGFuZCB0aGVuIGZv cndhcmRlZCB0byB0aGUgZmluYWwgZGVzdGluYXRpb24uDQogICAgICBNZXRhZGF0YSAoTUQpIGlz IGNvbnZleWVkIGluIFNGQyBkYXRhIHBsYW5lIHdoaWNoIHByb3ZpZGVzIHRoZQ0KICAgICAgYWJp bGl0eSB0byBleGNoYW5nZSBjb250ZXh0IGluZm9ybWF0aW9uIGJldHdlZW4gY2xhc3NpZmllcnMg YW5kIFNGcywNCiAgICAgIGFtb25nIFNGcywgYW5kIGJldHdlZW4gZXh0ZXJuYWwgc3lzdGVtcyBh bmQgU0ZzLiAgVGhpcyBkb2N1bWVudCBpcw0KICAgICAgbW90aXZhdGVkIHRvIHN0YXRlIGFuIGlz c3VlIHdoZW4gTUQgVHlwZSA9IDB4MSBhbmQgZGlzY3VzcyB3aGljaA0KICAgICAgTWV0YWRhdGEg VHlwZSBpbiBtb3JlIGFwcHJvcHJpYXRlIHRvIGJlIG1hbmRhdGUgaW4gU0ZDIGRhdGEgcGxhbmUu DQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRl cyBmcm9tIHRoZSB0aW1lIG9mDQpzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lv biBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnDQo8aHR0cDovL3Rvb2xz LmlldGYub3JnPi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiA8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRm Lm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlz dA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRv OnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQoNCg== --_000_D227854D198F9repennociscocom_ Content-Type: text/html; charset="gb2312" Content-ID: <6048923E46D7CA40A6A9D9DC306946F8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Inline with [RP]

From: Linda Dunbar <linda.dunbar@huawei.com>
Date: Monday, September 21, 2015 at= 2:51 PM
To: Reinaldo Penno <repenno@cisco.com>, "Joel M. Halpern&q= uot; <jmh@joelhalpern.com>= , Dave Dolson <ddolson@sandvine.= com>
Cc: "sfc@ietf.org" <sfc@ietf.= org>
Subject: RE: [sfc] in-path packet g= eneration

Penno,

 

That is an interesting problem. Tha= nks for documenting it.

 

I have a couple of questions:<= /o:p>

 

-          When a packet, which ca= n be encapsulated in various outer headers (VxLAN, SFC=A1=AFs NSH, or other= header), arrives at the FW ingress port, which Source Address will FW send  the =A1=B0generated packets=A1=B1 = to? Is it the most outer header=A1=AFs Source address?

[RP] Not necessarily although is an option.  The SF might have re= ceived a packet from a SFF that is not part of the reverse path.  Gene= rated packets received by this SFF would be dropped or punted somewhere unl= ess the SFF has access to all RSPs.  There are other techniques to solve this problem.  I will discuss a few in = the upcoming revisions of the document.

-          What kind of events can= trigger a FW to generate packets to the source?

[RP] Anything that violates a firewall policy. 

-          If the sequence of the = Service Functions is: Web Optimization -> FW, what kind of circumstances= will require the FW to generate message to traverse the =A1=B0Web Optimization=A1=B1?

[RP] Right, not all reverse paths are symmetric paths.  If revers= e packets should not cross web optimization it means the reverse paths is a= symmetric.  Generated reverse packets follow the regular path resposes= would take. If responses would bypass web optimization so will generated packets.

 

Thank you very much.

 

Linda

 

 

 

From: sfc [mailt= o:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, September 21, 2015 1:06 PM
To: Joel M. Halpern; Dave Dolson
Cc: sfc@ietf.org
Subject: Re: [sfc] in-path packet generation

 

We studied this issue considerably and documented the solutio= ns we implemented here:

 

 

 

 

Abstract:

   Service Functions (e.g., Firewall, NAT, Proxies = and Intrusion

   Prevention Systems) generate packets in the reve= rse flow direction to

   the source of the current in-process packet/flow= .  In this document

   we discuss and propose how to support this requi= red functionality

   within the SFC framework.

 

 

 

 

On 9/21/15, 10:59 AM, "sfc on behalf of Jo= el M. Halpern" <sfc-bounces= @ietf.org on behalf of jmh@joelhalpern.com> wrote:

 

That is an aspect that I had not considered in = asking your question.

That is not about symmetry of SFPs, but about t= he behavior of service

functions which generate extra packets in each = direction.

 

Over all, that is seriously under-specified, an= d we should address it.

 

While I don't know what answer the working grou= p will adopt, my

inclination is to say that such packet generati= on needs a classifier.

The service function generates the packet with = whatever metadata it

wants to attach, and then hands it to a classif= ier to determine what to

do with it.

 

Separately, I would note that even if we adopt = an SFP-stateful solution

for such service functions, I would not want th= e metadata handling to

drive a requirement for such state in all servi= ce functions in order to

understand the metadata.

Before someone argues that this would only be n= eeded in hybrid

deployments, I would observe that I expect serv= ice functions to be

designed and built to work in both dedicated an= d hybrid deployments.

And if MD-1 is a MUST (as it currently is writt= en) then they all have to

have this capability.

 

Yours,

Joel

 

On 9/21/15 1:40 PM, Dave Dolson wrote:

I might be missing something, but let's take a = very simple case: a proxy SF needs to respond to a SYN packet received on a= SFP with a SYN-ACK. Which SFP should the SYN-ACK be placed on?

 

I've been assuming there needs to be a configur= ation to pair up left-to-right with right-to-left SFPs, and that the C3 int= erface would eventually provide this.

 

 

-----Original Message-----

From: Joel M. Halpern [mailto:jmh@joelhalpern.com]

Sent: Monday, September 21, 2015 1:32 PM

To: Dave Dolson; Carlos Pignataro (cpignata); wang.cui1@zte.com.cn=

Cc: Wei Meng; sfc@ietf.org

Subject: Re: [sfc] New Version Notification for= draft-wang-sfc-md-type-issues-00.txt

 

Unless we are using per-subscriber SFPs (which = scalesvery badly, but you

can do it) I would expect that association to b= e made on the basis of

subscriber metadata.  In normal circu= mstances, the path ID is neither

necessary nor sufficient for the service functi= on to enable symmetry.

 

Even if the SFPs are at a granularity so that t= here are separate SFP IDs

for helping enforce path symmetry, that will no= t provide the state

needed for the service functions.  An= d the state that is needed for the

service functions is, in all cases I can see, s= ufficeint without

examining the SFP ID.

 

Yours,

Joel

 

On 9/21/15 1:11 PM, Dave Dolson wrote:

At least some service functions require per-SFP= state to associate bidirectional paths to each other.

 

 

-----Original Message-----

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern

Sent: Monday, September 21, 2015 12:56 PM<= /o:p>

To: Carlos Pignataro (cpignata); wang.cui1@zte.com.cn=

Cc: Wei Meng; sfc@ietf.org

Subject: Re: [sfc] New Version Notification for= draft-wang-sfc-md-type-issues-00.txt

 

First, if we are doing to assume that Service F= unctions will use the

SFP-ID to disambiguate type-1 metadata in mixed= environments, we should

say that in the draft.

 

Second, I am a bit concerned by this proposed b= ehavior, because we have

been careful up till now to have the Service Fu= nctions act on metadata

without requiring per-SFP state.  Thi= s would mark a significant shift.

 

yours,

Joel

 

On 9/21/15 6:36 AM, Carlos Pignataro (cpignata)= wrote:

Linda,

 

It seems the issue that this draft attempts to = raise can be summarized

with this question:

 

"When traffic is steered to SF3, how SF3 t= o correctly analyze the

Mandatory Context Headers in NSH within the arr= iving traffic?"

 

 

The solution to this, however, is neither of wh= at's presented in

Sections 4.1 and 4.2. The answer is much simple= r and already there: the

SFP (by way of the SFP ID) provides context to = understand the format of

the metadata. In other words, a given SFP ID wi= ll use one of the MD

formats/syntax (DC, Mobility, something else).<= o:p>

 

Thanks,

 

Thumb typed by Carlos Pignataro.

Excuze typofraphicak errows

 

On Sep 21, 2015, at 04:26, "wang.cui1@zte.com.cn

 

 

Dear all,

 

      Here is a n= ew draft proposed to raise an issue which may exist when<= /p>

MD Type=3D0x01 is mandatory.<= /p>

And to motivate the further discussion about MD= Type. Wish you can pay

attention to this to

continue the discussion and make a consensus ;)=

 

     Thanks..

 

Best Wishes,

Linda Wang

 

 

 

 

2015/09/21 16:13:57:

 

2015/09/21 16:13

 

=CA=D5=BC=FE=C8=CB

 

"Wei Meng"

 

=B3=AD=CB=CD

 

=D6=F7=CC=E2

 

New Version Notification for draft-wang-sfc-md-= type-issues-00.txt

 

 

A new version of I-D, draft-wang-sfc-md-type-is= sues-00.txt

has been successfully submitted by Cui Wang and= posted to the

IETF repository.

 

Name:      draft-= wang-sfc-md-type-issues

Revision:   00

Title:      Metad= ata Type Issues

Document date:   2015-09-21

Group:      Indiv= idual Submission

Pages:      14

md-type-issues-00.txt

type-issues/

 

 

Abstract:

      Service fun= ction chain is the definition of an ordered set of service

      functions.&= nbsp; After instantiated, the service function path is created

      and the cla= ssified traffic is steered through the corresponding

      service fun= ction path and then forwarded to the final destination.

      Metadata (M= D) is conveyed in SFC data plane which provides the

      ability to = exchange context information between classifiers and SFs,=

      among SFs, = and between external systems and SFs.  This document is

      motivated t= o state an issue when MD Type =3D 0x1 and discuss which

      Metadata Ty= pe in more appropriate to be mandate in SFC data plane.

 

 

 

 

Please note that it may take a couple of minute= s from the time of

submission

until the htmlized version and diff are availab= le at tools.ietf.org

 

The IETF Secretariat

 

_______________________________________________=

sfc mailing list

 

 

_______________________________________________=

sfc mailing list

 

 

_______________________________________________=

sfc mailing list

 

_______________________________________________=

sfc mailing list

 

 

_______________________________________________=

sfc mailing list

 

 --_000_D227854D198F9repennociscocom_-- From nobody Thu Sep 24 10:46: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 5A4741B2E5E for ; Thu, 24 Sep 2015 10:46:46 -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 zU4tjBaDO0B6 for ; Thu, 24 Sep 2015 10:46:44 -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 8E8D41B2E59 for ; Thu, 24 Sep 2015 10:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7765; q=dns/txt; s=iport; t=1443116805; x=1444326405; h=from:to:cc:subject:date:message-id:references: mime-version; bh=kCg/SBJ5CorCHjL2Ksv4GOPLHjEqIDEQp+EdauyHcLo=; b=QlwLo7HVjV5y0UjISUzD/MDaM3Ugmt1oBiOxyPDfS1vLrz82Jhce9C2S avH2VacBOfbtejuchd4lO4sHQeoQM+8BBwun/mvFSAOMi4r1KFHMxzJVL qtXw4kYhwS7l7IUqt/1Aa4hL3AKh+fCEbcQgisLPyz/nJrDuDhS3Wz4/v 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AHAgAxNgRW/4YNJK1dgyRUaQaFLrdlKgENgXqEIIFZAoFKOBQBAQEBAQEBfwuEJAEBAQR3AhACARkDAQIoBzIUBwIIAgQOBYguDcwUAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4kCgm6EfA0EBgcDgw+BFAWMfYhqAYURh3mBT0aDcJUkAREOAQFChAFxAYhmgQUBAQE X-IronPort-AV: E=Sophos;i="5.17,582,1437436800"; d="scan'208,217";a="190405374" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP; 24 Sep 2015 17:46:44 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t8OHkhQZ008674 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 24 Sep 2015 17:46:43 GMT Received: from xch-rcd-011.cisco.com (173.37.102.21) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 24 Sep 2015 12:46:43 -0500 Received: from xch-rcd-011.cisco.com ([173.37.102.21]) by XCH-RCD-011.cisco.com ([173.37.102.21]) with mapi id 15.00.1104.000; Thu, 24 Sep 2015 12:46:42 -0500 From: "Eric Wang (ejwang)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-wang-sfc-ns-use-cases-00.txt Thread-Index: AQHQ9u4+T+/KSGyGGkak8lrcV+bZMg== Date: Thu, 24 Sep 2015 17:46:42 +0000 Message-ID: References: <20150924172705.32664.28325.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.59.189] Content-Type: multipart/alternative; boundary="_000_D9A261BF5CDC40D29CF53369A4E1AD54ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Kent Leung \(kleung\)" , "Jay Iyer \(jiyer\)" , "Jeremy Felix \(jefelix\)" Subject: [sfc] Fwd: New Version Notification for draft-wang-sfc-ns-use-cases-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: Thu, 24 Sep 2015 17:46:46 -0000 --_000_D9A261BF5CDC40D29CF53369A4E1AD54ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We just published this draft describing SFC use cases in network security. = Any comments are appreciated. Regards, -Eric Begin forwarded message: From: > Subject: New Version Notification for draft-wang-sfc-ns-use-cases-00.txt Date: September 24, 2015 at 10:27:05 AM PDT To: Kent Leung >, Jay Iyer >, Eric Wang >, Jeremy Felix >= , Jeremy Felix >, Jay Iyer >, Eric Wang >, Kent Leung > A new version of I-D, draft-wang-sfc-ns-use-cases-00.txt has been successfully submitted by Eric Wang and posted to the IETF repository. Name: draft-wang-sfc-ns-use-cases Revision: 00 Title: Service Function Chaining Use Cases for Network Security Document date: 2015-09-24 Group: Individual Submission Pages: 22 URL: https://www.ietf.org/internet-drafts/draft-wang-sfc-ns-use-= cases-00.txt Status: https://datatracker.ietf.org/doc/draft-wang-sfc-ns-use-case= s/ Htmlized: https://tools.ietf.org/html/draft-wang-sfc-ns-use-cases-00 Abstract: Enterprise networks deploy a variety of security devices to protect the network, hosts and endpoints. Network security devices, both hardware and virtual, operate at all OSI layers with scanning and analysis capabilities for application content. Multiple specific devices are often deployed together for breadth and depth of defense. This document describes use cases of Service Function Chaining (SFC) when deploying network security devices in the manner described above and also puts forth requirements for their effective operation. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --_000_D9A261BF5CDC40D29CF53369A4E1AD54ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7A54CAAE92AC2545927435999278EFAD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi all,

We just published this draft describing SFC use cases in network secur= ity.  Any comments are appreciated.

Regards,

-Eric


Begin forwarded message:

Subje= ct: New Version Notification= for draft-wang-sfc-ns-use-cases-00.txt
Date:= September 24, 2015 at = 10:27:05 AM PDT
To: <= /b>Kent Leung <kleung@cisco.com>, Jay Iyer <jiyer@cisco.com>, Eric Wang <ejwang@cisco.com>, Jer= emy Felix <jefelix@cisco.com>= ;, Jeremy Felix <jefelix@cisco.com<= /a>>, Jay Iyer <jiyer@cisco.com>, Eric Wang <ejwang@cisco.com>= , Kent Leung <kleung@cisco.com&g= t;


A new version of I-D, draft-wang-sfc-ns-use-cases-00.txt
has been successfully submitted by Eric Wang and posted to the
IETF repository.

Name: draft-wang-sfc-n= s-use-cases
Revision: 0= 0
Title: Service Functio= n Chaining Use Cases for Network Security
Document date: 2015-09-24
Group: Individual Subm= ission
Pages: 22
URL:            https://www.ietf.org/internet-drafts/draft-wang-sfc-ns-use-cases-00.tx= t
Status:         https://datatracker.= ietf.org/doc/draft-wang-sfc-ns-use-cases/
Htmlized:       https://tools.ietf.org/html/draft= -wang-sfc-ns-use-cases-00


Abstract:
  Enterprise networks deploy a variety of security devices to pro= tect
  the network, hosts and endpoints.  Network security device= s, both
  hardware and virtual, operate at all OSI layers with scanning a= nd
  analysis capabilities for application content.  Multiple s= pecific
  devices are often deployed together for breadth and depth of de= fense.
  This document describes use cases of Service Function Chaining = (SFC)
  when deploying network security devices in the manner described= above
  and also puts forth requirements for their effective operation.=




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

The IETF Secretariat


--_000_D9A261BF5CDC40D29CF53369A4E1AD54ciscocom_-- From nobody Thu Sep 24 10:50:38 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 4B1731B2FA3 for ; Thu, 24 Sep 2015 10:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.06 X-Spam-Level: X-Spam-Status: No, score=-12.06 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, MIME_CHARSET_FARAWAY=2.45, 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 gS_kGZsQuGNf for ; Thu, 24 Sep 2015 10:50:31 -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 63B821B2F24 for ; Thu, 24 Sep 2015 10:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=74896; q=dns/txt; s=iport; t=1443117031; x=1444326631; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Nnhl+dB5jvkiwrF9I9ld0u6ZbsLmGN99ezxha5TWnq0=; b=GDUdsA+DCGWnxulvGdvCBGsmf7LoaFOqkNr1wGFuQ/+0Lwd4kM8ZF2oe qcHGrok8GODdHdWnz/h1M7zQ7DdncM6eDQhBtPrJj7qxqaBvdG9lDuJGU lSVjgNRZB/dlJ5F1AyxzOIXW4pNeveg2QNNU2wQXD7y/Ft9+y8iA17Z8y I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ASAgCbNwRW/5FdJa1UCYJXTVRaDwaDJGm5MAENgVYaAQmFeQIcgS44FAEBAQEBAQGBCoQkAQEBBAEBARcNBkELDAQCAQYCEQMBAQEXAQkBBgUCAiULFAkIAgQOBRuIEw2aN50lCJQvAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4kCgm6EMREwCgwBBAYBBgMKAYJRgUcBBIU9h0CFQYMpAYURgm6CSg6CMwKBTUaDcJE4g2wBEQ4BAUKEAXEBiCUHFyOBBQEBAQ X-IronPort-AV: E=Sophos;i="5.17,582,1437436800"; d="scan'208,217";a="191276771" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP; 24 Sep 2015 17:50:30 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t8OHoTEM006902 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Sep 2015 17:50:30 GMT Received: from xch-rcd-011.cisco.com (173.37.102.21) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 24 Sep 2015 12:50:29 -0500 Received: from xch-rcd-011.cisco.com ([173.37.102.21]) by XCH-RCD-011.cisco.com ([173.37.102.21]) with mapi id 15.00.1104.000; Thu, 24 Sep 2015 12:50:28 -0500 From: "Eric Wang (ejwang)" To: "Reinaldo Penno (repenno)" Thread-Topic: [sfc] in-path packet generation Thread-Index: AQHQ9JdR0vFIrf9LQUqp9I9X0RW3HJ5HmxWAgAA+84CAA8zgAIAApruA Date: Thu, 24 Sep 2015 17:50:28 +0000 Message-ID: References: <20150921081357.8630.47947.idtracker@ietfa.amsl.com> <6C7D9374-9A11-4D22-9E3C-7FA1EF2B9A95@cisco.com> <560036AB.1030001@joelhalpern.com> <56003F0B.9040002@joelhalpern.com> <5600457E.90604@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657D59743@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.59.189] Content-Type: multipart/alternative; boundary="_000_E5E4D9DB1D4A40799E688932579465CBciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Joel M. Halpern" , "sfc@ietf.org" , Dave Dolson , Linda Dunbar Subject: Re: [sfc] in-path packet generation 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, 24 Sep 2015 17:50:36 -0000 --_000_E5E4D9DB1D4A40799E688932579465CBciscocom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQpPbiBTZXAgMjQsIDIwMTUsIGF0IDEyOjUzIEFNLCBSZWluYWxkbyBQZW5ubyAocmVwZW5ubykg PHJlcGVubm9AY2lzY28uY29tPG1haWx0bzpyZXBlbm5vQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpJ bmxpbmUgd2l0aCBbUlBdDQoNCkZyb206IExpbmRhIER1bmJhciA8bGluZGEuZHVuYmFyQGh1YXdl aS5jb208bWFpbHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tPj4NCkRhdGU6IE1vbmRheSwgU2Vw dGVtYmVyIDIxLCAyMDE1IGF0IDI6NTEgUE0NClRvOiBSZWluYWxkbyBQZW5ubyA8cmVwZW5ub0Bj aXNjby5jb208bWFpbHRvOnJlcGVubm9AY2lzY28uY29tPj4sICJKb2VsIE0uIEhhbHBlcm4iIDxq bWhAam9lbGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4sIERhdmUgRG9s c29uIDxkZG9sc29uQHNhbmR2aW5lLmNvbTxtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20+Pg0K Q2M6ICJzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW3NmY10gaW4tcGF0aCBwYWNrZXQgZ2Vu ZXJhdGlvbg0KDQpQZW5ubywNCg0KVGhhdCBpcyBhbiBpbnRlcmVzdGluZyBwcm9ibGVtLiBUaGFu a3MgZm9yIGRvY3VtZW50aW5nIGl0Lg0KDQpJIGhhdmUgYSBjb3VwbGUgb2YgcXVlc3Rpb25zOg0K DQoNCi0gICAgICAgICAgV2hlbiBhIHBhY2tldCwgd2hpY2ggY2FuIGJlIGVuY2Fwc3VsYXRlZCBp biB2YXJpb3VzIG91dGVyIGhlYWRlcnMgKFZ4TEFOLCBTRkOhr3MgTlNILCBvciBvdGhlciBoZWFk ZXIpLCBhcnJpdmVzIGF0IHRoZSBGVyBpbmdyZXNzIHBvcnQsIHdoaWNoIFNvdXJjZSBBZGRyZXNz IHdpbGwgRlcgc2VuZCAgdGhlIKGwZ2VuZXJhdGVkIHBhY2tldHOhsSB0bz8gSXMgaXQgdGhlIG1v c3Qgb3V0ZXIgaGVhZGVyoa9zIFNvdXJjZSBhZGRyZXNzPw0KDQpbUlBdIE5vdCBuZWNlc3Nhcmls eSBhbHRob3VnaCBpcyBhbiBvcHRpb24uICBUaGUgU0YgbWlnaHQgaGF2ZSByZWNlaXZlZCBhIHBh Y2tldCBmcm9tIGEgU0ZGIHRoYXQgaXMgbm90IHBhcnQgb2YgdGhlIHJldmVyc2UgcGF0aC4gIEdl bmVyYXRlZCBwYWNrZXRzIHJlY2VpdmVkIGJ5IHRoaXMgU0ZGIHdvdWxkIGJlIGRyb3BwZWQgb3Ig cHVudGVkIHNvbWV3aGVyZSB1bmxlc3MgdGhlIFNGRiBoYXMgYWNjZXNzIHRvIGFsbCBSU1BzLiAg VGhlcmUgYXJlIG90aGVyIHRlY2huaXF1ZXMgdG8gc29sdmUgdGhpcyBwcm9ibGVtLiAgSSB3aWxs IGRpc2N1c3MgYSBmZXcgaW4gdGhlIHVwY29taW5nIHJldmlzaW9ucyBvZiB0aGUgZG9jdW1lbnQu DQoNCg0KLSAgICAgICAgICBXaGF0IGtpbmQgb2YgZXZlbnRzIGNhbiB0cmlnZ2VyIGEgRlcgdG8g Z2VuZXJhdGUgcGFja2V0cyB0byB0aGUgc291cmNlPw0KDQpbUlBdIEFueXRoaW5nIHRoYXQgdmlv bGF0ZXMgYSBmaXJld2FsbCBwb2xpY3kuDQoNCg0KSGVyZSBhcmUgc29tZSBleGFtcGxlcyAoZHJp dmVuIGJ5IHBvbGljeSB2aW9sYXRpb24gb3IgYSByZWd1bGFyIHBvbGljeSBhY3Rpb24pOg0KDQog ICBvICAiV2ViIFByb3h5IiBpbnNlcnRzIGFuIEhUVFAgcGFnZSBjaGFsbGVuZ2luZyB0aGUgY2xp ZW50IHRvIGxvZ2luLA0KICAgICAgaW4gb3JkZXIgdG8gb2J0YWluIHRoZSBjbGllbnQncyBpZGVu dGl0eS4gIFRoaXMgaXMgaW4gcmVzcG9uc2UgdG8NCiAgICAgIGEgcGFja2V0IChsaWtlbHkgSFRU UCBSZXF1ZXN0KSBidXQgaW4gdGhlIG9wcG9zaXRlIGRpcmVjdGlvbiBvZg0KICAgICAgdGhlIGZs b3cuDQoNCiAgIG8gICJGaXJld2FsbCIgY2hlY2tzIGFuIGlkbGUgVENQIGNvbm5lY3Rpb24gYnkg c2VuZGluZyBUQ1Aga2VlcGFsaXZlcw0KICAgICAgdG8gdGhlIGNsaWVudCBhbmQvb3Igc2VydmVy IChrbm93biBhcyAiVENQIGRlYWQgY29ubmVjdGlvbg0KICAgICAgZGV0ZWN0aW9uIikuICBUaGlz IGlzIG9uIGV4aXN0aW5nIGZsb3dzIGJ1dCBub3QgcmVzcG9uZGluZyB0byBhDQogICAgICBwcmlv ciBwYWNrZXQuDQoNCiAgIG8gICJGaXJld2FsbCIgc2VuZHMgSUNNUCBlcnJvciBtZXNzYWdlIGFm dGVyIGRyb3BwaW5nIGEgcGFja2V0LiAgVGhpcw0KICAgICAgaXMgaW4gcmVzcG9uc2UgdG8gdGhl IHByaW9yIHBhY2tldCBidXQgb24gYSBuZXcgZmxvdy4NCg0KQlRXLCBJIGp1c3Qgc3VibWl0dGVk IGEgZHJhZnQgZGVzY3JpYmluZyB0aGlzIGFuZCBvdGhlciBuZXR3b3JrIHNlY3VyaXR5IHJlbGF0 ZWQgdXNlIGNhc2VzLg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtd2FuZy1zZmMtbnMt dXNlLWNhc2VzLTAwLnR4dA0KDQoNClJlZ2FyZHMsDQotRXJpYw0KDQoNCg0KDQoNCi0gICAgICAg ICAgSWYgdGhlIHNlcXVlbmNlIG9mIHRoZSBTZXJ2aWNlIEZ1bmN0aW9ucyBpczogV2ViIE9wdGlt aXphdGlvbiAtPiBGVywgd2hhdCBraW5kIG9mIGNpcmN1bXN0YW5jZXMgd2lsbCByZXF1aXJlIHRo ZSBGVyB0byBnZW5lcmF0ZSBtZXNzYWdlIHRvIHRyYXZlcnNlIHRoZSChsFdlYiBPcHRpbWl6YXRp b26hsT8NCg0KW1JQXSBSaWdodCwgbm90IGFsbCByZXZlcnNlIHBhdGhzIGFyZSBzeW1tZXRyaWMg cGF0aHMuICBJZiByZXZlcnNlIHBhY2tldHMgc2hvdWxkIG5vdCBjcm9zcyB3ZWIgb3B0aW1pemF0 aW9uIGl0IG1lYW5zIHRoZSByZXZlcnNlIHBhdGhzIGlzIGFzeW1tZXRyaWMuICBHZW5lcmF0ZWQg cmV2ZXJzZSBwYWNrZXRzIGZvbGxvdyB0aGUgcmVndWxhciBwYXRoIHJlc3Bvc2VzIHdvdWxkIHRh a2UuIElmIHJlc3BvbnNlcyB3b3VsZCBieXBhc3Mgd2ViIG9wdGltaXphdGlvbiBzbyB3aWxsIGdl bmVyYXRlZCBwYWNrZXRzLg0KDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2guDQoNCkxpbmRhDQoNCg0K DQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJl aW5hbGRvIFBlbm5vIChyZXBlbm5vKQ0KU2VudDogTW9uZGF5LCBTZXB0ZW1iZXIgMjEsIDIwMTUg MTowNiBQTQ0KVG86IEpvZWwgTS4gSGFscGVybjsgRGF2ZSBEb2xzb24NCkNjOiBzZmNAaWV0Zi5v cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2ZjXSBpbi1wYXRoIHBhY2tl dCBnZW5lcmF0aW9uDQoNCldlIHN0dWRpZWQgdGhpcyBpc3N1ZSBjb25zaWRlcmFibHkgYW5kIGRv Y3VtZW50ZWQgdGhlIHNvbHV0aW9ucyB3ZSBpbXBsZW1lbnRlZCBoZXJlOg0KDQoNClVSTDogICAg ICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtcGVubm8t c2ZjLXBhY2tldC0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1wZW5uby1zZmMtcGFja2V0Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1wZW5uby1zZmMtcGFja2V0LTAwDQoNCg0KQWJz dHJhY3Q6DQogICBTZXJ2aWNlIEZ1bmN0aW9ucyAoZS5nLiwgRmlyZXdhbGwsIE5BVCwgUHJveGll cyBhbmQgSW50cnVzaW9uDQogICBQcmV2ZW50aW9uIFN5c3RlbXMpIGdlbmVyYXRlIHBhY2tldHMg aW4gdGhlIHJldmVyc2UgZmxvdyBkaXJlY3Rpb24gdG8NCiAgIHRoZSBzb3VyY2Ugb2YgdGhlIGN1 cnJlbnQgaW4tcHJvY2VzcyBwYWNrZXQvZmxvdy4gIEluIHRoaXMgZG9jdW1lbnQNCiAgIHdlIGRp c2N1c3MgYW5kIHByb3Bvc2UgaG93IHRvIHN1cHBvcnQgdGhpcyByZXF1aXJlZCBmdW5jdGlvbmFs aXR5DQogICB3aXRoaW4gdGhlIFNGQyBmcmFtZXdvcmsuDQoNCg0KDQoNCk9uIDkvMjEvMTUsIDEw OjU5IEFNLCAic2ZjIG9uIGJlaGFsZiBvZiBKb2VsIE0uIEhhbHBlcm4iIDxzZmMtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBqbWhAam9l bGhhbHBlcm4uY29tPG1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tPj4gd3JvdGU6DQoNClRoYXQg aXMgYW4gYXNwZWN0IHRoYXQgSSBoYWQgbm90IGNvbnNpZGVyZWQgaW4gYXNraW5nIHlvdXIgcXVl c3Rpb24uDQpUaGF0IGlzIG5vdCBhYm91dCBzeW1tZXRyeSBvZiBTRlBzLCBidXQgYWJvdXQgdGhl IGJlaGF2aW9yIG9mIHNlcnZpY2UNCmZ1bmN0aW9ucyB3aGljaCBnZW5lcmF0ZSBleHRyYSBwYWNr ZXRzIGluIGVhY2ggZGlyZWN0aW9uLg0KDQpPdmVyIGFsbCwgdGhhdCBpcyBzZXJpb3VzbHkgdW5k ZXItc3BlY2lmaWVkLCBhbmQgd2Ugc2hvdWxkIGFkZHJlc3MgaXQuDQoNCldoaWxlIEkgZG9uJ3Qg a25vdyB3aGF0IGFuc3dlciB0aGUgd29ya2luZyBncm91cCB3aWxsIGFkb3B0LCBteQ0KaW5jbGlu YXRpb24gaXMgdG8gc2F5IHRoYXQgc3VjaCBwYWNrZXQgZ2VuZXJhdGlvbiBuZWVkcyBhIGNsYXNz aWZpZXIuDQpUaGUgc2VydmljZSBmdW5jdGlvbiBnZW5lcmF0ZXMgdGhlIHBhY2tldCB3aXRoIHdo YXRldmVyIG1ldGFkYXRhIGl0DQp3YW50cyB0byBhdHRhY2gsIGFuZCB0aGVuIGhhbmRzIGl0IHRv IGEgY2xhc3NpZmllciB0byBkZXRlcm1pbmUgd2hhdCB0bw0KZG8gd2l0aCBpdC4NCg0KU2VwYXJh dGVseSwgSSB3b3VsZCBub3RlIHRoYXQgZXZlbiBpZiB3ZSBhZG9wdCBhbiBTRlAtc3RhdGVmdWwg c29sdXRpb24NCmZvciBzdWNoIHNlcnZpY2UgZnVuY3Rpb25zLCBJIHdvdWxkIG5vdCB3YW50IHRo ZSBtZXRhZGF0YSBoYW5kbGluZyB0bw0KZHJpdmUgYSByZXF1aXJlbWVudCBmb3Igc3VjaCBzdGF0 ZSBpbiBhbGwgc2VydmljZSBmdW5jdGlvbnMgaW4gb3JkZXIgdG8NCnVuZGVyc3RhbmQgdGhlIG1l dGFkYXRhLg0KQmVmb3JlIHNvbWVvbmUgYXJndWVzIHRoYXQgdGhpcyB3b3VsZCBvbmx5IGJlIG5l ZWRlZCBpbiBoeWJyaWQNCmRlcGxveW1lbnRzLCBJIHdvdWxkIG9ic2VydmUgdGhhdCBJIGV4cGVj dCBzZXJ2aWNlIGZ1bmN0aW9ucyB0byBiZQ0KZGVzaWduZWQgYW5kIGJ1aWx0IHRvIHdvcmsgaW4g Ym90aCBkZWRpY2F0ZWQgYW5kIGh5YnJpZCBkZXBsb3ltZW50cy4NCkFuZCBpZiBNRC0xIGlzIGEg TVVTVCAoYXMgaXQgY3VycmVudGx5IGlzIHdyaXR0ZW4pIHRoZW4gdGhleSBhbGwgaGF2ZSB0bw0K aGF2ZSB0aGlzIGNhcGFiaWxpdHkuDQoNCllvdXJzLA0KSm9lbA0KDQpPbiA5LzIxLzE1IDE6NDAg UE0sIERhdmUgRG9sc29uIHdyb3RlOg0KSSBtaWdodCBiZSBtaXNzaW5nIHNvbWV0aGluZywgYnV0 IGxldCdzIHRha2UgYSB2ZXJ5IHNpbXBsZSBjYXNlOiBhIHByb3h5IFNGIG5lZWRzIHRvIHJlc3Bv bmQgdG8gYSBTWU4gcGFja2V0IHJlY2VpdmVkIG9uIGEgU0ZQIHdpdGggYSBTWU4tQUNLLiBXaGlj aCBTRlAgc2hvdWxkIHRoZSBTWU4tQUNLIGJlIHBsYWNlZCBvbj8NCg0KSSd2ZSBiZWVuIGFzc3Vt aW5nIHRoZXJlIG5lZWRzIHRvIGJlIGEgY29uZmlndXJhdGlvbiB0byBwYWlyIHVwIGxlZnQtdG8t cmlnaHQgd2l0aCByaWdodC10by1sZWZ0IFNGUHMsIGFuZCB0aGF0IHRoZSBDMyBpbnRlcmZhY2Ug d291bGQgZXZlbnR1YWxseSBwcm92aWRlIHRoaXMuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21d DQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAyMSwgMjAxNSAxOjMyIFBNDQpUbzogRGF2ZSBEb2xz b247IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKTsgd2FuZy5jdWkxQHp0ZS5jb20uY248bWFp bHRvOndhbmcuY3VpMUB6dGUuY29tLmNuPg0KQ2M6IFdlaSBNZW5nOyBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2ZjXSBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNzdWVzLTAwLnR4dA0KDQpVbmxlc3Mg d2UgYXJlIHVzaW5nIHBlci1zdWJzY3JpYmVyIFNGUHMgKHdoaWNoIHNjYWxlc3ZlcnkgYmFkbHks IGJ1dCB5b3UNCmNhbiBkbyBpdCkgSSB3b3VsZCBleHBlY3QgdGhhdCBhc3NvY2lhdGlvbiB0byBi ZSBtYWRlIG9uIHRoZSBiYXNpcyBvZg0Kc3Vic2NyaWJlciBtZXRhZGF0YS4gIEluIG5vcm1hbCBj aXJjdW1zdGFuY2VzLCB0aGUgcGF0aCBJRCBpcyBuZWl0aGVyDQpuZWNlc3Nhcnkgbm9yIHN1ZmZp Y2llbnQgZm9yIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIHRvIGVuYWJsZSBzeW1tZXRyeS4NCg0KRXZl biBpZiB0aGUgU0ZQcyBhcmUgYXQgYSBncmFudWxhcml0eSBzbyB0aGF0IHRoZXJlIGFyZSBzZXBh cmF0ZSBTRlAgSURzDQpmb3IgaGVscGluZyBlbmZvcmNlIHBhdGggc3ltbWV0cnksIHRoYXQgd2ls bCBub3QgcHJvdmlkZSB0aGUgc3RhdGUNCm5lZWRlZCBmb3IgdGhlIHNlcnZpY2UgZnVuY3Rpb25z LiAgQW5kIHRoZSBzdGF0ZSB0aGF0IGlzIG5lZWRlZCBmb3IgdGhlDQpzZXJ2aWNlIGZ1bmN0aW9u cyBpcywgaW4gYWxsIGNhc2VzIEkgY2FuIHNlZSwgc3VmZmljZWludCB3aXRob3V0DQpleGFtaW5p bmcgdGhlIFNGUCBJRC4NCg0KWW91cnMsDQpKb2VsDQoNCk9uIDkvMjEvMTUgMToxMSBQTSwgRGF2 ZSBEb2xzb24gd3JvdGU6DQpBdCBsZWFzdCBzb21lIHNlcnZpY2UgZnVuY3Rpb25zIHJlcXVpcmUg cGVyLVNGUCBzdGF0ZSB0byBhc3NvY2lhdGUgYmlkaXJlY3Rpb25hbCBwYXRocyB0byBlYWNoIG90 aGVyLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpz ZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybg0KU2VudDog TW9uZGF5LCBTZXB0ZW1iZXIgMjEsIDIwMTUgMTI6NTYgUE0NClRvOiBDYXJsb3MgUGlnbmF0YXJv IChjcGlnbmF0YSk7IHdhbmcuY3VpMUB6dGUuY29tLmNuPG1haWx0bzp3YW5nLmN1aTFAenRlLmNv bS5jbj4NCkNjOiBXZWkgTWVuZzsgc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW3NmY10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13YW5n LXNmYy1tZC10eXBlLWlzc3Vlcy0wMC50eHQNCg0KRmlyc3QsIGlmIHdlIGFyZSBkb2luZyB0byBh c3N1bWUgdGhhdCBTZXJ2aWNlIEZ1bmN0aW9ucyB3aWxsIHVzZSB0aGUNClNGUC1JRCB0byBkaXNh bWJpZ3VhdGUgdHlwZS0xIG1ldGFkYXRhIGluIG1peGVkIGVudmlyb25tZW50cywgd2Ugc2hvdWxk DQpzYXkgdGhhdCBpbiB0aGUgZHJhZnQuDQoNClNlY29uZCwgSSBhbSBhIGJpdCBjb25jZXJuZWQg YnkgdGhpcyBwcm9wb3NlZCBiZWhhdmlvciwgYmVjYXVzZSB3ZSBoYXZlDQpiZWVuIGNhcmVmdWwg dXAgdGlsbCBub3cgdG8gaGF2ZSB0aGUgU2VydmljZSBGdW5jdGlvbnMgYWN0IG9uIG1ldGFkYXRh DQp3aXRob3V0IHJlcXVpcmluZyBwZXItU0ZQIHN0YXRlLiAgVGhpcyB3b3VsZCBtYXJrIGEgc2ln bmlmaWNhbnQgc2hpZnQuDQoNCnlvdXJzLA0KSm9lbA0KDQpPbiA5LzIxLzE1IDY6MzYgQU0sIENh cmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSB3cm90ZToNCkxpbmRhLA0KDQpJdCBzZWVtcyB0aGUg aXNzdWUgdGhhdCB0aGlzIGRyYWZ0IGF0dGVtcHRzIHRvIHJhaXNlIGNhbiBiZSBzdW1tYXJpemVk DQp3aXRoIHRoaXMgcXVlc3Rpb246DQoNCiJXaGVuIHRyYWZmaWMgaXMgc3RlZXJlZCB0byBTRjMs IGhvdyBTRjMgdG8gY29ycmVjdGx5IGFuYWx5emUgdGhlDQpNYW5kYXRvcnkgQ29udGV4dCBIZWFk ZXJzIGluIE5TSCB3aXRoaW4gdGhlIGFycml2aW5nIHRyYWZmaWM/Ig0KDQoNClRoZSBzb2x1dGlv biB0byB0aGlzLCBob3dldmVyLCBpcyBuZWl0aGVyIG9mIHdoYXQncyBwcmVzZW50ZWQgaW4NClNl Y3Rpb25zIDQuMSBhbmQgNC4yLiBUaGUgYW5zd2VyIGlzIG11Y2ggc2ltcGxlciBhbmQgYWxyZWFk eSB0aGVyZTogdGhlDQpTRlAgKGJ5IHdheSBvZiB0aGUgU0ZQIElEKSBwcm92aWRlcyBjb250ZXh0 IHRvIHVuZGVyc3RhbmQgdGhlIGZvcm1hdCBvZg0KdGhlIG1ldGFkYXRhLiBJbiBvdGhlciB3b3Jk cywgYSBnaXZlbiBTRlAgSUQgd2lsbCB1c2Ugb25lIG9mIHRoZSBNRA0KZm9ybWF0cy9zeW50YXgg KERDLCBNb2JpbGl0eSwgc29tZXRoaW5nIGVsc2UpLg0KDQpUaGFua3MsDQoNClRodW1iIHR5cGVk IGJ5IENhcmxvcyBQaWduYXRhcm8uDQpFeGN1emUgdHlwb2ZyYXBoaWNhayBlcnJvd3MNCg0KT24g U2VwIDIxLCAyMDE1LCBhdCAwNDoyNiwgIndhbmcuY3VpMUB6dGUuY29tLmNuPG1haWx0bzp3YW5n LmN1aTFAenRlLmNvbS5jbj4NCjxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24+PG1haWx0bzp3 YW5nLmN1aTFAenRlLmNvbS5jbiUzZT4iIDx3YW5nLmN1aTFAenRlLmNvbS5jbjxtYWlsdG86d2Fu Zy5jdWkxQHp0ZS5jb20uY24+DQo8bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuPjxtYWlsdG86 d2FuZy5jdWkxQHp0ZS5jb20uY24lM2U+PiB3cm90ZToNCg0KDQpEZWFyIGFsbCwNCg0KICAgICAg SGVyZSBpcyBhIG5ldyBkcmFmdCBwcm9wb3NlZCB0byByYWlzZSBhbiBpc3N1ZSB3aGljaCBtYXkg ZXhpc3Qgd2hlbg0KTUQgVHlwZT0weDAxIGlzIG1hbmRhdG9yeS4NCkFuZCB0byBtb3RpdmF0ZSB0 aGUgZnVydGhlciBkaXNjdXNzaW9uIGFib3V0IE1EIFR5cGUuIFdpc2ggeW91IGNhbiBwYXkNCmF0 dGVudGlvbiB0byB0aGlzIHRvDQpjb250aW51ZSB0aGUgZGlzY3Vzc2lvbiBhbmQgbWFrZSBhIGNv bnNlbnN1cyA7KQ0KDQogICAgIFRoYW5rcy4uDQoNCkJlc3QgV2lzaGVzLA0KTGluZGEgV2FuZw0K DQoNCg0KDQppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZz4gPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+INC009oNCjIwMTUvMDkv MjEgMTY6MTM6NTc6DQoNCmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPiA8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCjIwMTUv MDkvMjEgMTY6MTMNCg0KytW8/sjLDQoNCiJDdWkgV2FuZyIgPHdhbmcuY3VpMUB6dGUuY29tLmNu PG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj4gPG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5j bj48bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuJTNlPj4sDQoiV2VpIE1lbmciDQo8bWVuZy53 ZWkyQHp0ZS5jb20uY248bWFpbHRvOm1lbmcud2VpMkB6dGUuY29tLmNuPiA8bWFpbHRvOm1lbmcu d2VpMkB6dGUuY29tLmNuPjxtYWlsdG86bWVuZy53ZWkyQHp0ZS5jb20uY24lM2U+PiwgIkN1aSBX YW5nIg0KPHdhbmcuY3VpMUB6dGUuY29tLmNuPG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj4g PG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj48bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNu JTNlPj4sICJXZWkNCk1lbmciIDxtZW5nLndlaTJAenRlLmNvbS5jbjxtYWlsdG86bWVuZy53ZWky QHp0ZS5jb20uY24+IDxtYWlsdG86bWVuZy53ZWkyQHp0ZS5jb20uY24+PG1haWx0bzptZW5nLndl aTJAenRlLmNvbS5jbiUzZT4+LA0KDQqzrcvNDQoNCtb3zOINCg0KTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC13YW5nLXNmYy1tZC10eXBlLWlzc3Vlcy0wMC50eHQNCg0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd2FuZy1zZmMtbWQtdHlwZS1pc3N1ZXMtMDAudHh0DQpo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEN1aSBXYW5nIGFuZCBwb3N0ZWQgdG8g dGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgZHJhZnQtd2FuZy1zZmMtbWQtdHlw ZS1pc3N1ZXMNClJldmlzaW9uOiAgIDAwDQpUaXRsZTogICAgICBNZXRhZGF0YSBUeXBlIElzc3Vl cw0KRG9jdW1lbnQgZGF0ZTogICAyMDE1LTA5LTIxDQpHcm91cDogICAgICBJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NClBhZ2VzOiAgICAgIDE0DQpVUkw6IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC13YW5nLXNmYy0NCm1kLXR5cGUtaXNzdWVzLTAwLnR4dA0KU3RhdHVz OiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13YW5nLXNmYy1tZC0NCnR5 cGUtaXNzdWVzLw0KSHRtbGl6ZWQ6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13 YW5nLXNmYy1tZC10eXBlLWlzc3Vlcy0wMA0KDQoNCkFic3RyYWN0Og0KICAgICAgU2VydmljZSBm dW5jdGlvbiBjaGFpbiBpcyB0aGUgZGVmaW5pdGlvbiBvZiBhbiBvcmRlcmVkIHNldCBvZiBzZXJ2 aWNlDQogICAgICBmdW5jdGlvbnMuICBBZnRlciBpbnN0YW50aWF0ZWQsIHRoZSBzZXJ2aWNlIGZ1 bmN0aW9uIHBhdGggaXMgY3JlYXRlZA0KICAgICAgYW5kIHRoZSBjbGFzc2lmaWVkIHRyYWZmaWMg aXMgc3RlZXJlZCB0aHJvdWdoIHRoZSBjb3JyZXNwb25kaW5nDQogICAgICBzZXJ2aWNlIGZ1bmN0 aW9uIHBhdGggYW5kIHRoZW4gZm9yd2FyZGVkIHRvIHRoZSBmaW5hbCBkZXN0aW5hdGlvbi4NCiAg ICAgIE1ldGFkYXRhIChNRCkgaXMgY29udmV5ZWQgaW4gU0ZDIGRhdGEgcGxhbmUgd2hpY2ggcHJv dmlkZXMgdGhlDQogICAgICBhYmlsaXR5IHRvIGV4Y2hhbmdlIGNvbnRleHQgaW5mb3JtYXRpb24g YmV0d2VlbiBjbGFzc2lmaWVycyBhbmQgU0ZzLA0KICAgICAgYW1vbmcgU0ZzLCBhbmQgYmV0d2Vl biBleHRlcm5hbCBzeXN0ZW1zIGFuZCBTRnMuICBUaGlzIGRvY3VtZW50IGlzDQogICAgICBtb3Rp dmF0ZWQgdG8gc3RhdGUgYW4gaXNzdWUgd2hlbiBNRCBUeXBlID0gMHgxIGFuZCBkaXNjdXNzIHdo aWNoDQogICAgICBNZXRhZGF0YSBUeXBlIGluIG1vcmUgYXBwcm9wcmlhdGUgdG8gYmUgbWFuZGF0 ZSBpbiBTRkMgZGF0YSBwbGFuZS4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCnN1Ym1pc3Npb24NCnVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmc8aHR0cDovL3Rvb2xzLmlldGYub3JnPg0KPGh0dHA6Ly90b29scy5pZXRmLm9yZzxodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvPj4uDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0 DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0 DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86 c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBt YWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYu b3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= --_000_E5E4D9DB1D4A40799E688932579465CBciscocom_ Content-Type: text/html; charset="gb2312" Content-ID: <4DBF31E9D221CD4B853FE45E078E137A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On Sep 24, 2015, at 12:53 AM, Reinaldo Penno (repenno) <repenno@cisco.com> wrote:

Inline with [RP]

From: Linda Dunbar <linda.dunbar@huawei.com>
Date: Monday, September 21, 2015 at= 2:51 PM
To: Reinaldo Penno <repenno@cisco.com>, "Joel M. Halpern&q= uot; <jmh@joelhalpern.com>= , Dave Dolson <ddolson@sandvine.= com>
Cc: "sfc@ietf.org" <sfc@ietf.= org>
Subject: RE: [sfc] in-path packet g= eneration

Penno,
 
That is an interesting problem. T= hanks for documenting it.
 
I have a couple of questions:
 

-          When a packet, which ca= n be encapsulated in various outer headers (VxLAN, SFC=A1=AFs NSH, or other= header), arrives at the FW ingress port, which Source Address will FW send  the =A1=B0generated packets=A1=B1 = to? Is it the most outer header=A1=AFs Source address?

[RP] Not necessarily although is an option.  The SF might have re= ceived a packet from a SFF that is not part of the reverse path.  Gene= rated packets received by this SFF would be dropped or punted somewhere unl= ess the SFF has access to all RSPs.  There are other techniques to solve this problem.  I will discuss a few in = the upcoming revisions of the document.

-          What kind of events can= trigger a FW to generate packets to the source?

[RP] Anything that violates a firewall policy. 


Here are some examples (driven by policy violation or a regular policy= action):

   o  "Web Proxy" inserts an HTTP page challe= nging the client to login,
      in order to obtain the client's identity.  This i= s in response to
      a packet (likely HTTP Request) but in the opposite dir= ection of
      the flow.

   o  "Firewall" checks an idle TCP connection by = sending TCP keepalives
      to the client and/or server (known as "TCP dead c= onnection
      detection").  This is on existing flows but = not responding to a
      prior packet.

   o  "Firewall" sends ICMP error message after dr= opping a packet.  This
      is in response to the prior packet but on a new flow.<= br>
BTW, I just submitted a draft describing this and other network security re= lated use cases.


Regards,
-Eric 




-          If the sequence of the = Service Functions is: Web Optimization -> FW, what kind of circumstances= will require the FW to generate message to traverse the =A1=B0Web Optimization=A1=B1?

[RP] Right, not all reverse paths are symmetric paths.  If revers= e packets should not cross web optimization it means the reverse paths is a= symmetric.  Generated reverse packets follow the regular path resposes= would take. If responses would bypass web optimization so will generated packets.

 
Thank you very much.
 
Linda
 
 
 
From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, September 21, 2015 1:06 PM
To: Joel M. Halpern; Dave Dolson
Cc: sfc@ietf.org
Subject: Re: [sfc] in-path packet generation
 
We studied this issue considerably and documented the solutions we = implemented here:
 
 
 
 
Abstract:
   Service Functions (e.g., Firewall, NAT, Proxies and In= trusion
   Prevention Systems) generate packets in the reverse fl= ow direction to
   the source of the current in-process packet/flow. = ; In this document
   we discuss and propose how to support this required fu= nctionality
   within the SFC framework.
 
 
 
 
On 9/21/15, 10:59 AM, "sfc on behalf of Joel M. Halper= n" <sfc-bounces@ietf.org on behalf of jmh@joelhalpern.com> wrote:
 
That is an aspect that I had not considered in asking your = question.
That is not about symmetry of SFPs, but about the behavior = of service
functions which generate extra packets in each direction.
 
Over all, that is seriously under-specified, and we should = address it.
 
While I don't know what answer the working group will adopt= , my
inclination is to say that such packet generation needs a c= lassifier.
The service function generates the packet with whatever met= adata it
wants to attach, and then hands it to a classifier to deter= mine what to
do with it.
 
Separately, I would note that even if we adopt an SFP-state= ful solution
for such service functions, I would not want the metadata h= andling to
drive a requirement for such state in all service functions= in order to
understand the metadata.
Before someone argues that this would only be needed in hyb= rid
deployments, I would observe that I expect service function= s to be
designed and built to work in both dedicated and hybrid dep= loyments.
And if MD-1 is a MUST (as it currently is written) then the= y all have to
have this capability.
 
Yours,
Joel
 
On 9/21/15 1:40 PM, Dave Dolson wrote:
I might be missing something, but let's take a very simple = case: a proxy SF needs to respond to a SYN packet received on a SFP with a = SYN-ACK. Which SFP should the SYN-ACK be placed on?
 
I've been assuming there needs to be a configuration to pai= r up left-to-right with right-to-left SFPs, and that the C3 interface would= eventually provide this.
 
 
-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Monday, September 21, 2015 1:32 PM<= /div>
To: Dave Dolson; Carlos Pignataro (cpignata); wang.cui1@zte.com.cn=
Cc: Wei Meng; sfc@ietf.org
Subject: Re: [sfc] New Version Notification for draft-wang-= sfc-md-type-issues-00.txt
 
Unless we are using per-subscriber SFPs (which scalesvery b= adly, but you
can do it) I would expect that association to be made on th= e basis of
subscriber metadata.  In normal circumstances, th= e path ID is neither
necessary nor sufficient for the service function to enable= symmetry.
 
Even if the SFPs are at a granularity so that there are sep= arate SFP IDs
for helping enforce path symmetry, that will not provide th= e state
needed for the service functions.  And the state = that is needed for the
service functions is, in all cases I can see, sufficeint wi= thout
examining the SFP ID.
 
Yours,
Joel
 
On 9/21/15 1:11 PM, Dave Dolson wrote:
At least some service functions require per-SFP state to as= sociate bidirectional paths to each other.
 
 
-----Original Message-----
From: sfc [mailto:s= fc-bounces@ietf.org] On Behalf Of Joel M. Halpern
Sent: Monday, September 21, 2015 12:56 PM=
To: Carlos Pignataro (cpignata); wang.cui1@zte.com.cn=
Cc: Wei Meng; sfc@ietf.org
Subject: Re: [sfc] New Version Notification for draft-wang-= sfc-md-type-issues-00.txt
 
First, if we are doing to assume that Service Functions wil= l use the
SFP-ID to disambiguate type-1 metadata in mixed environment= s, we should
say that in the draft.
 
Second, I am a bit concerned by this proposed behavior, bec= ause we have
been careful up till now to have the Service Functions act = on metadata
without requiring per-SFP state.  This would mark= a significant shift.
 
yours,
Joel
 
On 9/21/15 6:36 AM, Carlos Pignataro (cpignata) wrote:=
Linda,
 
It seems the issue that this draft attempts to raise can be= summarized
with this question:
 
"When traffic is steered to SF3, how SF3 to correctly = analyze the
Mandatory Context Headers in NSH within the arriving traffi= c?"
 
 
The solution to this, however, is neither of what's present= ed in
Sections 4.1 and 4.2. The answer is much simpler and alread= y there: the
SFP (by way of the SFP ID) provides context to understand t= he format of
the metadata. In other words, a given SFP ID will use one o= f the MD
formats/syntax (DC, Mobility, something else).
 
Thanks,
 
Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows
 
On Sep 21, 2015, at 04:26, "wang.cui1@zte.com.cn
 
 
Dear all,
 
      Here is a new draft pro= posed to raise an issue which may exist when
MD Type=3D0x01 is mandatory.
And to motivate the further discussion about MD Type. Wish = you can pay
attention to this to
continue the discussion and make a consensus ;)<= /span>
 
     Thanks..
 
Best Wishes,
Linda Wang
 
 
 
 
2015/09/21 16:13:57:
 
2015/09/21 16:13
 
=CA= =D5=BC=FE=C8=CB
 
"Wei Meng"
 
=B3= =AD=CB=CD
 
=D6= =F7=CC=E2
 
New Version Notification for draft-wang-sfc-md-type-issues-= 00.txt
 
 
A new version of I-D, draft-wang-sfc-md-type-issues-00.txt<= o:p>
has been successfully submitted by Cui Wang and posted to t= he
IETF repository.
 
Name:      draft-wang-sfc-md-= type-issues
Revision:   00
Title:      Metadata Type Iss= ues
Document date:   2015-09-21
Group:      Individual Submis= sion
Pages:      14
md-type-issues-00.txt
type-issues/
 
 
Abstract:
      Service function chain = is the definition of an ordered set of service
      functions.  A= fter instantiated, the service function path is created
      and the classified traf= fic is steered through the corresponding
      service function path a= nd then forwarded to the final destination.
      Metadata (MD) is convey= ed in SFC data plane which provides the
      ability to exchange con= text information between classifiers and SFs,
      among SFs, and between = external systems and SFs.  This document is
      motivated to state an i= ssue when MD Type =3D 0x1 and discuss which
      Metadata Type in more a= ppropriate to be mandate in SFC data plane.
 
 
 
 
Please note that it may take a couple of minutes from the t= ime of
submission
until the htmlized version and diff are available at tools.ietf.org
 
The IETF Secretariat
 
_______________________________________________<= /span>
sfc mailing list
 
 
_______________________________________________<= /span>
sfc mailing list
 
 
_______________________________________________<= /span>
sfc mailing list
 
_______________________________________________<= /span>
sfc mailing list
 
 
_______________________________________________<= /span>
sfc mailing list
 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--_000_E5E4D9DB1D4A40799E688932579465CBciscocom_-- From nobody Thu Sep 24 12:51:01 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 C1A3D1A9245 for ; Thu, 24 Sep 2015 12:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.159 X-Spam-Level: X-Spam-Status: No, score=-0.159 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, 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 i20xroyKvW_Q for ; Thu, 24 Sep 2015 12:50:55 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 719A81A9241 for ; Thu, 24 Sep 2015 12:50:54 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by wtl-exchp-1.sandvine.com (192.168.194.176) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 24 Sep 2015 15:50:49 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Thu, 24 Sep 2015 15:50:49 -0400 From: Dave Dolson To: "Eric Wang (ejwang)" , "Reinaldo Penno (repenno)" Thread-Topic: [sfc] in-path packet generation Thread-Index: AQHQ9JdBq4jkPQokAEeBbu3/CXahJ55HilKAgAA+84CAA8zfAIAAproA///d9jA= Date: Thu, 24 Sep 2015 19:50:54 +0000 Message-ID: References: <20150921081357.8630.47947.idtracker@ietfa.amsl.com> <6C7D9374-9A11-4D22-9E3C-7FA1EF2B9A95@cisco.com> <560036AB.1030001@joelhalpern.com> <56003F0B.9040002@joelhalpern.com> <5600457E.90604@joelhalpern.com> <4A95BA014132FF49AE685FAB4B9F17F657D59743@dfweml701-chm> In-Reply-To: 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: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830D2A648wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Cc: "Joel M. Halpern" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] in-path packet generation 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, 24 Sep 2015 19:51:00 -0000 --_000_E8355113905631478EFF04F5AA706E9830D2A648wtlexchp2sandvi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QW5vdGhlciBleGFtcGxlIG9mIGFuIFNGIGdlbmVyYXRpbmcgYSBwYWNrZXQgaXMgYSB0cmFuc3Bh cmVudCBIVFRQIGNhY2hlLCB3aGljaCBzZW5kcyBjb250ZW50IHRvIHRoZSBjbGllbnQgd2l0aG91 dCBoYXZpbmcgcmVjZWl2ZWQgaXQgZnJvbSB0aGUgc2VydmVyIChpdCB3YXMgc3RvcmVkIGxvY2Fs bHkpLg0KDQoNCkZyb206IEVyaWMgV2FuZyAoZWp3YW5nKSBbbWFpbHRvOmVqd2FuZ0BjaXNjby5j b21dDQpTZW50OiBUaHVyc2RheSwgU2VwdGVtYmVyIDI0LCAyMDE1IDE6NTAgUE0NClRvOiBSZWlu YWxkbyBQZW5ubyAocmVwZW5ubykNCkNjOiBMaW5kYSBEdW5iYXI7IEpvZWwgTS4gSGFscGVybjsg RGF2ZSBEb2xzb247IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIGluLXBhdGggcGFj a2V0IGdlbmVyYXRpb24NCg0KDQpPbiBTZXAgMjQsIDIwMTUsIGF0IDEyOjUzIEFNLCBSZWluYWxk byBQZW5ubyAocmVwZW5ubykgPHJlcGVubm9AY2lzY28uY29tPG1haWx0bzpyZXBlbm5vQGNpc2Nv LmNvbT4+IHdyb3RlOg0KDQoNCklubGluZSB3aXRoIFtSUF0NCg0KRnJvbTogTGluZGEgRHVuYmFy IDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbTxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+ Pg0KRGF0ZTogTW9uZGF5LCBTZXB0ZW1iZXIgMjEsIDIwMTUgYXQgMjo1MSBQTQ0KVG86IFJlaW5h bGRvIFBlbm5vIDxyZXBlbm5vQGNpc2NvLmNvbTxtYWlsdG86cmVwZW5ub0BjaXNjby5jb20+Piwg IkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFs cGVybi5jb20+PiwgRGF2ZSBEb2xzb24gPGRkb2xzb25Ac2FuZHZpbmUuY29tPG1haWx0bzpkZG9s c29uQHNhbmR2aW5lLmNvbT4+DQpDYzogInNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3Jn PiIgPHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbc2Zj XSBpbi1wYXRoIHBhY2tldCBnZW5lcmF0aW9uDQoNClBlbm5vLA0KDQpUaGF0IGlzIGFuIGludGVy ZXN0aW5nIHByb2JsZW0uIFRoYW5rcyBmb3IgZG9jdW1lbnRpbmcgaXQuDQoNCkkgaGF2ZSBhIGNv dXBsZSBvZiBxdWVzdGlvbnM6DQoNCg0KLSAgICAgICAgICBXaGVuIGEgcGFja2V0LCB3aGljaCBj YW4gYmUgZW5jYXBzdWxhdGVkIGluIHZhcmlvdXMgb3V0ZXIgaGVhZGVycyAoVnhMQU4sIFNGQ6Gv cyBOU0gsIG9yIG90aGVyIGhlYWRlciksIGFycml2ZXMgYXQgdGhlIEZXIGluZ3Jlc3MgcG9ydCwg d2hpY2ggU291cmNlIEFkZHJlc3Mgd2lsbCBGVyBzZW5kICB0aGUgobBnZW5lcmF0ZWQgcGFja2V0 c6GxIHRvPyBJcyBpdCB0aGUgbW9zdCBvdXRlciBoZWFkZXKhr3MgU291cmNlIGFkZHJlc3M/DQoN CltSUF0gTm90IG5lY2Vzc2FyaWx5IGFsdGhvdWdoIGlzIGFuIG9wdGlvbi4gIFRoZSBTRiBtaWdo dCBoYXZlIHJlY2VpdmVkIGEgcGFja2V0IGZyb20gYSBTRkYgdGhhdCBpcyBub3QgcGFydCBvZiB0 aGUgcmV2ZXJzZSBwYXRoLiAgR2VuZXJhdGVkIHBhY2tldHMgcmVjZWl2ZWQgYnkgdGhpcyBTRkYg d291bGQgYmUgZHJvcHBlZCBvciBwdW50ZWQgc29tZXdoZXJlIHVubGVzcyB0aGUgU0ZGIGhhcyBh Y2Nlc3MgdG8gYWxsIFJTUHMuICBUaGVyZSBhcmUgb3RoZXIgdGVjaG5pcXVlcyB0byBzb2x2ZSB0 aGlzIHByb2JsZW0uICBJIHdpbGwgZGlzY3VzcyBhIGZldyBpbiB0aGUgdXBjb21pbmcgcmV2aXNp b25zIG9mIHRoZSBkb2N1bWVudC4NCg0KDQotICAgICAgICAgIFdoYXQga2luZCBvZiBldmVudHMg Y2FuIHRyaWdnZXIgYSBGVyB0byBnZW5lcmF0ZSBwYWNrZXRzIHRvIHRoZSBzb3VyY2U/DQoNCltS UF0gQW55dGhpbmcgdGhhdCB2aW9sYXRlcyBhIGZpcmV3YWxsIHBvbGljeS4NCg0KDQpIZXJlIGFy ZSBzb21lIGV4YW1wbGVzIChkcml2ZW4gYnkgcG9saWN5IHZpb2xhdGlvbiBvciBhIHJlZ3VsYXIg cG9saWN5IGFjdGlvbik6DQoNCiAgIG8gICJXZWIgUHJveHkiIGluc2VydHMgYW4gSFRUUCBwYWdl IGNoYWxsZW5naW5nIHRoZSBjbGllbnQgdG8gbG9naW4sDQogICAgICBpbiBvcmRlciB0byBvYnRh aW4gdGhlIGNsaWVudCdzIGlkZW50aXR5LiAgVGhpcyBpcyBpbiByZXNwb25zZSB0bw0KICAgICAg YSBwYWNrZXQgKGxpa2VseSBIVFRQIFJlcXVlc3QpIGJ1dCBpbiB0aGUgb3Bwb3NpdGUgZGlyZWN0 aW9uIG9mDQogICAgICB0aGUgZmxvdy4NCg0KICAgbyAgIkZpcmV3YWxsIiBjaGVja3MgYW4gaWRs ZSBUQ1AgY29ubmVjdGlvbiBieSBzZW5kaW5nIFRDUCBrZWVwYWxpdmVzDQogICAgICB0byB0aGUg Y2xpZW50IGFuZC9vciBzZXJ2ZXIgKGtub3duIGFzICJUQ1AgZGVhZCBjb25uZWN0aW9uDQogICAg ICBkZXRlY3Rpb24iKS4gIFRoaXMgaXMgb24gZXhpc3RpbmcgZmxvd3MgYnV0IG5vdCByZXNwb25k aW5nIHRvIGENCiAgICAgIHByaW9yIHBhY2tldC4NCg0KICAgbyAgIkZpcmV3YWxsIiBzZW5kcyBJ Q01QIGVycm9yIG1lc3NhZ2UgYWZ0ZXIgZHJvcHBpbmcgYSBwYWNrZXQuICBUaGlzDQogICAgICBp cyBpbiByZXNwb25zZSB0byB0aGUgcHJpb3IgcGFja2V0IGJ1dCBvbiBhIG5ldyBmbG93Lg0KDQpC VFcsIEkganVzdCBzdWJtaXR0ZWQgYSBkcmFmdCBkZXNjcmliaW5nIHRoaXMgYW5kIG90aGVyIG5l dHdvcmsgc2VjdXJpdHkgcmVsYXRlZCB1c2UgY2FzZXMuDQpodHRwczovL3d3dy5pZXRmLm9yZy9p ZC9kcmFmdC13YW5nLXNmYy1ucy11c2UtY2FzZXMtMDAudHh0DQoNCg0KUmVnYXJkcywNCi1Fcmlj DQoNCg0KDQoNCg0KDQotICAgICAgICAgIElmIHRoZSBzZXF1ZW5jZSBvZiB0aGUgU2VydmljZSBG dW5jdGlvbnMgaXM6IFdlYiBPcHRpbWl6YXRpb24gLT4gRlcsIHdoYXQga2luZCBvZiBjaXJjdW1z dGFuY2VzIHdpbGwgcmVxdWlyZSB0aGUgRlcgdG8gZ2VuZXJhdGUgbWVzc2FnZSB0byB0cmF2ZXJz ZSB0aGUgobBXZWIgT3B0aW1pemF0aW9uobE/DQoNCltSUF0gUmlnaHQsIG5vdCBhbGwgcmV2ZXJz ZSBwYXRocyBhcmUgc3ltbWV0cmljIHBhdGhzLiAgSWYgcmV2ZXJzZSBwYWNrZXRzIHNob3VsZCBu b3QgY3Jvc3Mgd2ViIG9wdGltaXphdGlvbiBpdCBtZWFucyB0aGUgcmV2ZXJzZSBwYXRocyBpcyBh c3ltbWV0cmljLiAgR2VuZXJhdGVkIHJldmVyc2UgcGFja2V0cyBmb2xsb3cgdGhlIHJlZ3VsYXIg cGF0aCByZXNwb3NlcyB3b3VsZCB0YWtlLiBJZiByZXNwb25zZXMgd291bGQgYnlwYXNzIHdlYiBv cHRpbWl6YXRpb24gc28gd2lsbCBnZW5lcmF0ZWQgcGFja2V0cy4NCg0KVGhhbmsgeW91IHZlcnkg bXVjaC4NCg0KTGluZGENCg0KDQoNCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pDQpTZW50OiBNb25kYXks IFNlcHRlbWJlciAyMSwgMjAxNSAxOjA2IFBNDQpUbzogSm9lbCBNLiBIYWxwZXJuOyBEYXZlIERv bHNvbg0KQ2M6IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtzZmNdIGluLXBhdGggcGFja2V0IGdlbmVyYXRpb24NCg0KV2Ugc3R1ZGllZCB0aGlzIGlzc3Vl IGNvbnNpZGVyYWJseSBhbmQgZG9jdW1lbnRlZCB0aGUgc29sdXRpb25zIHdlIGltcGxlbWVudGVk IGhlcmU6DQoNCg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1wZW5uby1zZmMtcGFja2V0LTAwLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXBlbm5vLXNmYy1wYWNrZXQvDQpI dG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBlbm5vLXNm Yy1wYWNrZXQtMDANCg0KDQpBYnN0cmFjdDoNCiAgIFNlcnZpY2UgRnVuY3Rpb25zIChlLmcuLCBG aXJld2FsbCwgTkFULCBQcm94aWVzIGFuZCBJbnRydXNpb24NCiAgIFByZXZlbnRpb24gU3lzdGVt cykgZ2VuZXJhdGUgcGFja2V0cyBpbiB0aGUgcmV2ZXJzZSBmbG93IGRpcmVjdGlvbiB0bw0KICAg dGhlIHNvdXJjZSBvZiB0aGUgY3VycmVudCBpbi1wcm9jZXNzIHBhY2tldC9mbG93LiAgSW4gdGhp cyBkb2N1bWVudA0KICAgd2UgZGlzY3VzcyBhbmQgcHJvcG9zZSBob3cgdG8gc3VwcG9ydCB0aGlz IHJlcXVpcmVkIGZ1bmN0aW9uYWxpdHkNCiAgIHdpdGhpbiB0aGUgU0ZDIGZyYW1ld29yay4NCg0K DQoNCg0KT24gOS8yMS8xNSwgMTA6NTkgQU0sICJzZmMgb24gYmVoYWxmIG9mIEpvZWwgTS4gSGFs cGVybiIgPHNmYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIGptaEBqb2VsaGFscGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5j b20+PiB3cm90ZToNCg0KVGhhdCBpcyBhbiBhc3BlY3QgdGhhdCBJIGhhZCBub3QgY29uc2lkZXJl ZCBpbiBhc2tpbmcgeW91ciBxdWVzdGlvbi4NClRoYXQgaXMgbm90IGFib3V0IHN5bW1ldHJ5IG9m IFNGUHMsIGJ1dCBhYm91dCB0aGUgYmVoYXZpb3Igb2Ygc2VydmljZQ0KZnVuY3Rpb25zIHdoaWNo IGdlbmVyYXRlIGV4dHJhIHBhY2tldHMgaW4gZWFjaCBkaXJlY3Rpb24uDQoNCk92ZXIgYWxsLCB0 aGF0IGlzIHNlcmlvdXNseSB1bmRlci1zcGVjaWZpZWQsIGFuZCB3ZSBzaG91bGQgYWRkcmVzcyBp dC4NCg0KV2hpbGUgSSBkb24ndCBrbm93IHdoYXQgYW5zd2VyIHRoZSB3b3JraW5nIGdyb3VwIHdp bGwgYWRvcHQsIG15DQppbmNsaW5hdGlvbiBpcyB0byBzYXkgdGhhdCBzdWNoIHBhY2tldCBnZW5l cmF0aW9uIG5lZWRzIGEgY2xhc3NpZmllci4NClRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGdlbmVyYXRl cyB0aGUgcGFja2V0IHdpdGggd2hhdGV2ZXIgbWV0YWRhdGEgaXQNCndhbnRzIHRvIGF0dGFjaCwg YW5kIHRoZW4gaGFuZHMgaXQgdG8gYSBjbGFzc2lmaWVyIHRvIGRldGVybWluZSB3aGF0IHRvDQpk byB3aXRoIGl0Lg0KDQpTZXBhcmF0ZWx5LCBJIHdvdWxkIG5vdGUgdGhhdCBldmVuIGlmIHdlIGFk b3B0IGFuIFNGUC1zdGF0ZWZ1bCBzb2x1dGlvbg0KZm9yIHN1Y2ggc2VydmljZSBmdW5jdGlvbnMs IEkgd291bGQgbm90IHdhbnQgdGhlIG1ldGFkYXRhIGhhbmRsaW5nIHRvDQpkcml2ZSBhIHJlcXVp cmVtZW50IGZvciBzdWNoIHN0YXRlIGluIGFsbCBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBvcmRlciB0 bw0KdW5kZXJzdGFuZCB0aGUgbWV0YWRhdGEuDQpCZWZvcmUgc29tZW9uZSBhcmd1ZXMgdGhhdCB0 aGlzIHdvdWxkIG9ubHkgYmUgbmVlZGVkIGluIGh5YnJpZA0KZGVwbG95bWVudHMsIEkgd291bGQg b2JzZXJ2ZSB0aGF0IEkgZXhwZWN0IHNlcnZpY2UgZnVuY3Rpb25zIHRvIGJlDQpkZXNpZ25lZCBh bmQgYnVpbHQgdG8gd29yayBpbiBib3RoIGRlZGljYXRlZCBhbmQgaHlicmlkIGRlcGxveW1lbnRz Lg0KQW5kIGlmIE1ELTEgaXMgYSBNVVNUIChhcyBpdCBjdXJyZW50bHkgaXMgd3JpdHRlbikgdGhl biB0aGV5IGFsbCBoYXZlIHRvDQpoYXZlIHRoaXMgY2FwYWJpbGl0eS4NCg0KWW91cnMsDQpKb2Vs DQoNCk9uIDkvMjEvMTUgMTo0MCBQTSwgRGF2ZSBEb2xzb24gd3JvdGU6DQpJIG1pZ2h0IGJlIG1p c3Npbmcgc29tZXRoaW5nLCBidXQgbGV0J3MgdGFrZSBhIHZlcnkgc2ltcGxlIGNhc2U6IGEgcHJv eHkgU0YgbmVlZHMgdG8gcmVzcG9uZCB0byBhIFNZTiBwYWNrZXQgcmVjZWl2ZWQgb24gYSBTRlAg d2l0aCBhIFNZTi1BQ0suIFdoaWNoIFNGUCBzaG91bGQgdGhlIFNZTi1BQ0sgYmUgcGxhY2VkIG9u Pw0KDQpJJ3ZlIGJlZW4gYXNzdW1pbmcgdGhlcmUgbmVlZHMgdG8gYmUgYSBjb25maWd1cmF0aW9u IHRvIHBhaXIgdXAgbGVmdC10by1yaWdodCB3aXRoIHJpZ2h0LXRvLWxlZnQgU0ZQcywgYW5kIHRo YXQgdGhlIEMzIGludGVyZmFjZSB3b3VsZCBldmVudHVhbGx5IHByb3ZpZGUgdGhpcy4NCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86 am1oQGpvZWxoYWxwZXJuLmNvbV0NClNlbnQ6IE1vbmRheSwgU2VwdGVtYmVyIDIxLCAyMDE1IDE6 MzIgUE0NClRvOiBEYXZlIERvbHNvbjsgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpOyB3YW5n LmN1aTFAenRlLmNvbS5jbjxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24+DQpDYzogV2VpIE1l bmc7IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzZmNd IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FuZy1zZmMtbWQtdHlwZS1pc3N1 ZXMtMDAudHh0DQoNClVubGVzcyB3ZSBhcmUgdXNpbmcgcGVyLXN1YnNjcmliZXIgU0ZQcyAod2hp Y2ggc2NhbGVzdmVyeSBiYWRseSwgYnV0IHlvdQ0KY2FuIGRvIGl0KSBJIHdvdWxkIGV4cGVjdCB0 aGF0IGFzc29jaWF0aW9uIHRvIGJlIG1hZGUgb24gdGhlIGJhc2lzIG9mDQpzdWJzY3JpYmVyIG1l dGFkYXRhLiAgSW4gbm9ybWFsIGNpcmN1bXN0YW5jZXMsIHRoZSBwYXRoIElEIGlzIG5laXRoZXIN Cm5lY2Vzc2FyeSBub3Igc3VmZmljaWVudCBmb3IgdGhlIHNlcnZpY2UgZnVuY3Rpb24gdG8gZW5h YmxlIHN5bW1ldHJ5Lg0KDQpFdmVuIGlmIHRoZSBTRlBzIGFyZSBhdCBhIGdyYW51bGFyaXR5IHNv IHRoYXQgdGhlcmUgYXJlIHNlcGFyYXRlIFNGUCBJRHMNCmZvciBoZWxwaW5nIGVuZm9yY2UgcGF0 aCBzeW1tZXRyeSwgdGhhdCB3aWxsIG5vdCBwcm92aWRlIHRoZSBzdGF0ZQ0KbmVlZGVkIGZvciB0 aGUgc2VydmljZSBmdW5jdGlvbnMuICBBbmQgdGhlIHN0YXRlIHRoYXQgaXMgbmVlZGVkIGZvciB0 aGUNCnNlcnZpY2UgZnVuY3Rpb25zIGlzLCBpbiBhbGwgY2FzZXMgSSBjYW4gc2VlLCBzdWZmaWNl aW50IHdpdGhvdXQNCmV4YW1pbmluZyB0aGUgU0ZQIElELg0KDQpZb3VycywNCkpvZWwNCg0KT24g OS8yMS8xNSAxOjExIFBNLCBEYXZlIERvbHNvbiB3cm90ZToNCkF0IGxlYXN0IHNvbWUgc2Vydmlj ZSBmdW5jdGlvbnMgcmVxdWlyZSBwZXItU0ZQIHN0YXRlIHRvIGFzc29jaWF0ZSBiaWRpcmVjdGlv bmFsIHBhdGhzIHRvIGVhY2ggb3RoZXIuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9l bCBNLiBIYWxwZXJuDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciAyMSwgMjAxNSAxMjo1NiBQTQ0K VG86IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKTsgd2FuZy5jdWkxQHp0ZS5jb20uY248bWFp bHRvOndhbmcuY3VpMUB6dGUuY29tLmNuPg0KQ2M6IFdlaSBNZW5nOyBzZmNAaWV0Zi5vcmc8bWFp bHRvOnNmY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2ZjXSBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNzdWVzLTAwLnR4dA0KDQpGaXJzdCwg aWYgd2UgYXJlIGRvaW5nIHRvIGFzc3VtZSB0aGF0IFNlcnZpY2UgRnVuY3Rpb25zIHdpbGwgdXNl IHRoZQ0KU0ZQLUlEIHRvIGRpc2FtYmlndWF0ZSB0eXBlLTEgbWV0YWRhdGEgaW4gbWl4ZWQgZW52 aXJvbm1lbnRzLCB3ZSBzaG91bGQNCnNheSB0aGF0IGluIHRoZSBkcmFmdC4NCg0KU2Vjb25kLCBJ IGFtIGEgYml0IGNvbmNlcm5lZCBieSB0aGlzIHByb3Bvc2VkIGJlaGF2aW9yLCBiZWNhdXNlIHdl IGhhdmUNCmJlZW4gY2FyZWZ1bCB1cCB0aWxsIG5vdyB0byBoYXZlIHRoZSBTZXJ2aWNlIEZ1bmN0 aW9ucyBhY3Qgb24gbWV0YWRhdGENCndpdGhvdXQgcmVxdWlyaW5nIHBlci1TRlAgc3RhdGUuICBU aGlzIHdvdWxkIG1hcmsgYSBzaWduaWZpY2FudCBzaGlmdC4NCg0KeW91cnMsDQpKb2VsDQoNCk9u IDkvMjEvMTUgNjozNiBBTSwgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIHdyb3RlOg0KTGlu ZGEsDQoNCkl0IHNlZW1zIHRoZSBpc3N1ZSB0aGF0IHRoaXMgZHJhZnQgYXR0ZW1wdHMgdG8gcmFp c2UgY2FuIGJlIHN1bW1hcml6ZWQNCndpdGggdGhpcyBxdWVzdGlvbjoNCg0KIldoZW4gdHJhZmZp YyBpcyBzdGVlcmVkIHRvIFNGMywgaG93IFNGMyB0byBjb3JyZWN0bHkgYW5hbHl6ZSB0aGUNCk1h bmRhdG9yeSBDb250ZXh0IEhlYWRlcnMgaW4gTlNIIHdpdGhpbiB0aGUgYXJyaXZpbmcgdHJhZmZp Yz8iDQoNCg0KVGhlIHNvbHV0aW9uIHRvIHRoaXMsIGhvd2V2ZXIsIGlzIG5laXRoZXIgb2Ygd2hh dCdzIHByZXNlbnRlZCBpbg0KU2VjdGlvbnMgNC4xIGFuZCA0LjIuIFRoZSBhbnN3ZXIgaXMgbXVj aCBzaW1wbGVyIGFuZCBhbHJlYWR5IHRoZXJlOiB0aGUNClNGUCAoYnkgd2F5IG9mIHRoZSBTRlAg SUQpIHByb3ZpZGVzIGNvbnRleHQgdG8gdW5kZXJzdGFuZCB0aGUgZm9ybWF0IG9mDQp0aGUgbWV0 YWRhdGEuIEluIG90aGVyIHdvcmRzLCBhIGdpdmVuIFNGUCBJRCB3aWxsIHVzZSBvbmUgb2YgdGhl IE1EDQpmb3JtYXRzL3N5bnRheCAoREMsIE1vYmlsaXR5LCBzb21ldGhpbmcgZWxzZSkuDQoNClRo YW5rcywNCg0KVGh1bWIgdHlwZWQgYnkgQ2FybG9zIFBpZ25hdGFyby4NCkV4Y3V6ZSB0eXBvZnJh cGhpY2FrIGVycm93cw0KDQpPbiBTZXAgMjEsIDIwMTUsIGF0IDA0OjI2LCAid2FuZy5jdWkxQHp0 ZS5jb20uY248bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuPg0KPG1haWx0bzp3YW5nLmN1aTFA enRlLmNvbS5jbj48bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuJTNlPiIgPHdhbmcuY3VpMUB6 dGUuY29tLmNuPG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbj4NCjxtYWlsdG86d2FuZy5jdWkx QHp0ZS5jb20uY24+PG1haWx0bzp3YW5nLmN1aTFAenRlLmNvbS5jbiUzZT4+IHdyb3RlOg0KDQoN CkRlYXIgYWxsLA0KDQogICAgICBIZXJlIGlzIGEgbmV3IGRyYWZ0IHByb3Bvc2VkIHRvIHJhaXNl IGFuIGlzc3VlIHdoaWNoIG1heSBleGlzdCB3aGVuDQpNRCBUeXBlPTB4MDEgaXMgbWFuZGF0b3J5 Lg0KQW5kIHRvIG1vdGl2YXRlIHRoZSBmdXJ0aGVyIGRpc2N1c3Npb24gYWJvdXQgTUQgVHlwZS4g V2lzaCB5b3UgY2FuIHBheQ0KYXR0ZW50aW9uIHRvIHRoaXMgdG8NCmNvbnRpbnVlIHRoZSBkaXNj dXNzaW9uIGFuZCBtYWtlIGEgY29uc2Vuc3VzIDspDQoNCiAgICAgVGhhbmtzLi4NCg0KQmVzdCBX aXNoZXMsDQpMaW5kYSBXYW5nDQoNCg0KDQoNCmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiA8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZz4g0LTT2g0KMjAxNS8wOS8yMSAxNjoxMzo1NzoNCg0KaW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IDxtYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPg0KMjAxNS8wOS8yMSAxNjoxMw0KDQrK1bz+yMsNCg0KIkN1aSBXYW5nIiA8 d2FuZy5jdWkxQHp0ZS5jb20uY248bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuPiA8bWFpbHRv OndhbmcuY3VpMUB6dGUuY29tLmNuPjxtYWlsdG86d2FuZy5jdWkxQHp0ZS5jb20uY24lM2U+PiwN CiJXZWkgTWVuZyINCjxtZW5nLndlaTJAenRlLmNvbS5jbjxtYWlsdG86bWVuZy53ZWkyQHp0ZS5j b20uY24+IDxtYWlsdG86bWVuZy53ZWkyQHp0ZS5jb20uY24+PG1haWx0bzptZW5nLndlaTJAenRl LmNvbS5jbiUzZT4+LCAiQ3VpIFdhbmciDQo8d2FuZy5jdWkxQHp0ZS5jb20uY248bWFpbHRvOndh bmcuY3VpMUB6dGUuY29tLmNuPiA8bWFpbHRvOndhbmcuY3VpMUB6dGUuY29tLmNuPjxtYWlsdG86 d2FuZy5jdWkxQHp0ZS5jb20uY24lM2U+PiwgIldlaQ0KTWVuZyIgPG1lbmcud2VpMkB6dGUuY29t LmNuPG1haWx0bzptZW5nLndlaTJAenRlLmNvbS5jbj4gPG1haWx0bzptZW5nLndlaTJAenRlLmNv bS5jbj48bWFpbHRvOm1lbmcud2VpMkB6dGUuY29tLmNuJTNlPj4sDQoNCrOty80NCg0K1vfM4g0K DQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNz dWVzLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13YW5nLXNmYy1tZC10 eXBlLWlzc3Vlcy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQ3Vp IFdhbmcgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICBk cmFmdC13YW5nLXNmYy1tZC10eXBlLWlzc3Vlcw0KUmV2aXNpb246ICAgMDANClRpdGxlOiAgICAg IE1ldGFkYXRhIFR5cGUgSXNzdWVzDQpEb2N1bWVudCBkYXRlOiAgIDIwMTUtMDktMjENCkdyb3Vw OiAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6ICAgICAgMTQNClVSTDogaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdhbmctc2ZjLQ0KbWQtdHlwZS1p c3N1ZXMtMDAudHh0DQpTdGF0dXM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LXdhbmctc2ZjLW1kLQ0KdHlwZS1pc3N1ZXMvDQpIdG1saXplZDogaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNzdWVzLTAwDQoNCg0KQWJzdHJh Y3Q6DQogICAgICBTZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGlzIHRoZSBkZWZpbml0aW9uIG9mIGFu IG9yZGVyZWQgc2V0IG9mIHNlcnZpY2UNCiAgICAgIGZ1bmN0aW9ucy4gIEFmdGVyIGluc3RhbnRp YXRlZCwgdGhlIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBpcyBjcmVhdGVkDQogICAgICBhbmQgdGhl IGNsYXNzaWZpZWQgdHJhZmZpYyBpcyBzdGVlcmVkIHRocm91Z2ggdGhlIGNvcnJlc3BvbmRpbmcN CiAgICAgIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBhbmQgdGhlbiBmb3J3YXJkZWQgdG8gdGhlIGZp bmFsIGRlc3RpbmF0aW9uLg0KICAgICAgTWV0YWRhdGEgKE1EKSBpcyBjb252ZXllZCBpbiBTRkMg ZGF0YSBwbGFuZSB3aGljaCBwcm92aWRlcyB0aGUNCiAgICAgIGFiaWxpdHkgdG8gZXhjaGFuZ2Ug Y29udGV4dCBpbmZvcm1hdGlvbiBiZXR3ZWVuIGNsYXNzaWZpZXJzIGFuZCBTRnMsDQogICAgICBh bW9uZyBTRnMsIGFuZCBiZXR3ZWVuIGV4dGVybmFsIHN5c3RlbXMgYW5kIFNGcy4gIFRoaXMgZG9j dW1lbnQgaXMNCiAgICAgIG1vdGl2YXRlZCB0byBzdGF0ZSBhbiBpc3N1ZSB3aGVuIE1EIFR5cGUg PSAweDEgYW5kIGRpc2N1c3Mgd2hpY2gNCiAgICAgIE1ldGFkYXRhIFR5cGUgaW4gbW9yZSBhcHBy b3ByaWF0ZSB0byBiZSBtYW5kYXRlIGluIFNGQyBkYXRhIHBsYW5lLg0KDQoNCg0KDQpQbGVhc2Ug bm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBv Zg0Kc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+DQo8aHR0cDov L3Rvb2xzLmlldGYub3JnPGh0dHA6Ly90b29scy5pZXRmLm9yZy8+Pi4NCg0KVGhlIElFVEYgU2Vj cmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPiA8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnNmYyBtYWlsaW5nIGxpc3QNCnNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0K c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0bzpzZmNA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFp bGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmc8 bWFpbHRvOnNmY0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQoNCg== --_000_E8355113905631478EFF04F5AA706E9830D2A648wtlexchp2sandvi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Another example of an SF = generating a packet is a transparent HTTP cache, which sends content to the= client without having received it from the server (it was stored locally).

 <= /p>

 <= /p>

From: Eric Wan= g (ejwang) [mailto:ejwang@cisco.com]
Sent: Thursday, September 24, 2015 1:50 PM
To: Reinaldo Penno (repenno)
Cc: Linda Dunbar; Joel M. Halpern; Dave Dolson; sfc@ietf.org
Subject: Re: [sfc] in-path packet generation

 

 

On Sep 24, 2015, at 12:53 AM, Reinaldo Penno (repenn= o) <repenno@cisco.com> wrote= :



Inline with [RP]

 

From: Linda Dunbar <linda.dunbar@huawei.com>
Date: Monday, September 21, 2015 at 2:51 PM
To: Reinaldo Penno <repenno@= cisco.com>, "Joel M. Halpern" <jmh@joelhalpern.com>, Dave Dolson <ddolson@sandvine.com>
Cc: "sfc@ietf.org" <= ;sfc@ietf.org>
Subject: RE: [sfc] in-path packet generation

 

Penno,

 <= /p>

That is an interesting pr= oblem. Thanks for documenting it.

 <= /p>

I have a couple of questi= ons:

 <= /p>

-      &= nbsp;   When a packet, wh= ich can be encapsulated in various outer headers (VxLAN, SFC=A1=AFs NSH, or= other header), arrives at the FW ingress port, which Source Address will FW send  the =A1=B0generated packets=A1=B1 to? Is it the= most outer header=A1=AFs Source address?

 

[RP] Not necessarily although is an opt= ion.  The SF might have received a packet from a SFF that is not part = of the reverse path.  Generated packets received by this SFF would be dropped or punted somewhere unless the SFF has access to all RSPs= .  There are other techniques to solve this problem.  I will disc= uss a few in the upcoming revisions of the document.

 

-      &= nbsp;   What kind of even= ts can trigger a FW to generate packets to the source?

 

[RP] Anything that violates a firewall = policy. 

 

 

Here are some examples (driven by policy violation o= r a regular policy action):

 

   o  "Web Proxy" inserts a= n HTTP page challenging the client to login,
      in order to obtain the client's identity.  This i= s in response to
      a packet (likely HTTP Request) but in the opposite dir= ection of
      the flow.

   o  "Firewall" checks an idle TCP connection by = sending TCP keepalives
      to the client and/or server (known as "TCP dead c= onnection
      detection").  This is on existing flows but = not responding to a
      prior packet.

   o  "Firewall" sends ICMP error message after dr= opping a packet.  This
      is in response to the prior packet but on a new flow.<= br>
BTW, I just submitted a draft describing this and other network security re= lated use cases.

 

 

Regards,

-Eric 

 

 



 

-      &= nbsp;   If the sequence o= f the Service Functions is: Web Optimization -> FW, what kind of circums= tances will require the FW to generate message to traverse the =A1=B0Web Optimization=A1=B1?

 

[RP] Right, not all reverse paths are s= ymmetric paths.  If reverse packets should not cross web optimization = it means the reverse paths is asymmetric.  Generated reverse packets follow the regular path resposes would take. If responses would by= pass web optimization so will generated packets.

 <= /p>

Thank you very much.

 <= /p>

Linda

 <= /p>

 <= /p>

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Reinaldo Penno (repenno)
Sent: Monday, September 21, 2015 1:06 PM
To: Joel M. Halpern; Dave Dolson
Cc: sfc@ietf.org
Subject: Re: [sfc] in-path packet generation

 

We studied this issue considerably and documented the solutions we implem= ented here:

 

 

 

 

Abstract:

   Service Functions (e.g., Firewall, NAT, Proxies and Intrusio= n

   Prevention Systems) generate packets in the reverse flow dir= ection to

   the source of the current in-process packet/flow.  = ;In this document

   we discuss and propose how to support this required function= ality

   within the SFC framework.

 

 

 

 

On 9/21/15, 10:59 AM, "sfc on behal= f of Joel M. Halpern" <sfc-= bounces@ietf.org on behalf of jmh@joelhalpern.com> wrote:

 

That is an aspect that I had not conside= red in asking your question.

That is not about symmetry of SFPs, but = about the behavior of service

functions which generate extra packets i= n each direction.

 

Over all, that is seriously under-specif= ied, and we should address it.

 

While I don't know what answer the worki= ng group will adopt, my

inclination is to say that such packet g= eneration needs a classifier.

The service function generates the packe= t with whatever metadata it

wants to attach, and then hands it to a = classifier to determine what to

do with it.

 

Separately, I would note that even if we= adopt an SFP-stateful solution

for such service functions, I would not = want the metadata handling to

drive a requirement for such state in al= l service functions in order to

understand the metadata.

Before someone argues that this would on= ly be needed in hybrid

deployments, I would observe that I expe= ct service functions to be

designed and built to work in both dedic= ated and hybrid deployments.

And if MD-1 is a MUST (as it currently i= s written) then they all have to

have this capability.<= /p>

 

Yours,

Joel

 

On 9/21/15 1:40 PM, Dave Dolson wrote:

I might be missing something, but let's = take a very simple case: a proxy SF needs to respond to a SYN packet receiv= ed on a SFP with a SYN-ACK. Which SFP should the SYN-ACK be placed on?

 

I've been assuming there needs to be a c= onfiguration to pair up left-to-right with right-to-left SFPs, and that the= C3 interface would eventually provide this.

 

 

-----Original Message-----

From: Joel M. Halpern [mailto:jmh@joelhalpern.com]

Sent: Monday, September 21, 2015 1:32 PM=

To: Dave Dolson; Carlos Pignataro (cpign= ata); wang.cui1@zte.com.cn

Cc: Wei Meng; sfc@ietf.org

Subject: Re: [sfc] New Version Notificat= ion for draft-wang-sfc-md-type-issues-00.txt

 

Unless we are using per-subscriber SFPs = (which scalesvery badly, but you

can do it) I would expect that associati= on to be made on the basis of

subscriber metadata.  In norma= l circumstances, the path ID is neither

necessary nor sufficient for the service= function to enable symmetry.

 

Even if the SFPs are at a granularity so= that there are separate SFP IDs

for helping enforce path symmetry, that = will not provide the state

needed for the service functions. &= nbsp;And the state that is needed for the

service functions is, in all cases I can= see, sufficeint without

examining the SFP ID.<= /p>

 

Yours,

Joel

 

On 9/21/15 1:11 PM, Dave Dolson wrote:

At least some service functions require = per-SFP state to associate bidirectional paths to each other.

 

 

-----Original Message-----

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern

Sent: Monday, September 21, 2015 12:56 P= M

To: Carlos Pignataro (cpignata); wang.cui1@zte.com.cn

Cc: Wei Meng; sfc@ietf.org

Subject: Re: [sfc] New Version Notificat= ion for draft-wang-sfc-md-type-issues-00.txt

 

First, if we are doing to assume that Se= rvice Functions will use the

SFP-ID to disambiguate type-1 metadata i= n mixed environments, we should

say that in the draft.=

 

Second, I am a bit concerned by this pro= posed behavior, because we have

been careful up till now to have the Ser= vice Functions act on metadata

without requiring per-SFP state. &n= bsp;This would mark a significant shift.

 

yours,

Joel

 

On 9/21/15 6:36 AM, Carlos Pignataro (cp= ignata) wrote:

Linda,

 

It seems the issue that this draft attem= pts to raise can be summarized

with this question:

 

"When traffic is steered to SF3, ho= w SF3 to correctly analyze the

Mandatory Context Headers in NSH within = the arriving traffic?"

 

 

The solution to this, however, is neithe= r of what's presented in

Sections 4.1 and 4.2. The answer is much= simpler and already there: the

SFP (by way of the SFP ID) provides cont= ext to understand the format of

the metadata. In other words, a given SF= P ID will use one of the MD

formats/syntax (DC, Mobility, something = else).

 

Thanks,

 

Thumb typed by Carlos Pignataro.<= o:p>

Excuze typofraphicak errows<= /o:p>

 

On Sep 21, 2015, at 04:26, "wang.cui1@zte.com.cn=

 

 

Dear all,

 

      Here= is a new draft proposed to raise an issue which may exist when=

MD Type=3D0x01 is mandatory.=

And to motivate the further discussion a= bout MD Type. Wish you can pay

attention to this to

continue the discussion and make a conse= nsus ;)

 

     Thanks..=

 

Best Wishes,

Linda Wang

 

 

 

 

2015/09/21 16:13:57:

 

2015/09/21 16:13

 

=CA= =D5=BC=FE=C8=CB

 

"Wei Meng"

 

=B3= =AD=CB=CD

 

=D6= =F7=CC=E2

 

New Version Notification for draft-wang-= sfc-md-type-issues-00.txt

 

 

A new version of I-D, draft-wang-sfc-md-= type-issues-00.txt

has been successfully submitted by Cui W= ang and posted to the

IETF repository.

 

Name:      = ;draft-wang-sfc-md-type-issues

Revision:   00

Title:     &nbs= p;Metadata Type Issues

Document date:   2015-09-21

Group:     &nbs= p;Individual Submission

Pages:     &nbs= p;14

md-type-issues-00.txt<= /p>

type-issues/

 

 

Abstract:

      Serv= ice function chain is the definition of an ordered set of service

      func= tions.  After instantiated, the service function path is created<= /span>

      and = the classified traffic is steered through the corresponding

      serv= ice function path and then forwarded to the final destination.<= /o:p>

      Meta= data (MD) is conveyed in SFC data plane which provides the

      abil= ity to exchange context information between classifiers and SFs,

      amon= g SFs, and between external systems and SFs.  This document is

      moti= vated to state an issue when MD Type =3D 0x1 and discuss which<= /o:p>

      Meta= data Type in more appropriate to be mandate in SFC data plane.<= /o:p>

 

 

 

 

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 mailing list

 

 

________________________________________= _______

sfc mailing list

 

________________________________________= _______

sfc mailing list

 

 

________________________________________= _______

sfc mailing list

 

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

 

--_000_E8355113905631478EFF04F5AA706E9830D2A648wtlexchp2sandvi_-- From nobody Fri Sep 25 00:01: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 1CB561A010F; Fri, 25 Sep 2015 00:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -81.16 X-Spam-Level: X-Spam-Status: No, score=-81.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLACK=20, USER_IN_WHITELIST=-100] 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 YpI46R49GJNJ; Fri, 25 Sep 2015 00:01:49 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 10F971A0111; Fri, 25 Sep 2015 00:01:48 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 41D904066907B; Fri, 25 Sep 2015 15:01:43 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t8P71WjR099061; Fri, 25 Sep 2015 15:01:32 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn) In-Reply-To: <6C7D9374-9A11-4D22-9E3C-7FA1EF2B9A95@cisco.com> To: "Carlos Pignataro (cpignata)" , "Joel M. Halpern" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: meng.wei2@zte.com.cn Date: Fri, 25 Sep 2015 15:01:26 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-09-25 15:01:32, Serialize complete at 2015-09-25 15:01:32 Content-Type: multipart/alternative; boundary="=_alternative 002697CA48257ECB_=" X-MAIL: mse01.zte.com.cn t8P71WjR099061 Archived-At: Cc: "wang.cui1@zte.com.cn" , sfc , "sfc@ietf.org" Subject: Re: [sfc] New Version Notification for draft-wang-sfc-md-type-issues-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, 25 Sep 2015 07:01:52 -0000 This is a multipart message in MIME format. --=_alternative 002697CA48257ECB_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQ2FybG9zLCBKb2VsLA0KDQogIERvIHlvdSBtZWFuIGEgZ2l2ZW4gU0ZQIElEIGNvcnJlc3Bv bmRzIHRvIG9uZSB0eXBlKERDLCBtb2JpbGl0eaGtKT8NCklmIG15IHVuZGVyc3RhbmRpbmcgaXMg Y29ycmVjdCwgaXMgdGhhdCBhIHdhc3RlIG9mIFNGUCBJRHM/DQoNCiAgRm9yIGV4YW1wbGUsIHBs ZWFzZSBhbGxvdyBtZSBtYWtlIGEgYm9sZCBhc3N1bXB0aW9uLCBTRlAgQS0+Qi0+QyANCm1pZ2h0 IGJlIGFzc2lnbmVkIGZvciBEQyAmIG1vYmlsaXR5ICYgYnJvYWRiYW5kIGluIEZpeGVkIE1vYmls ZSANCkNvbnZlcmdlbmNlLA0KQXNzaWduaW5nIG9uZSBTRlAgSUQgaXMgZW5vdWdoLiBIb3dldmVy LCBpZiBvbmUgU0ZQIElEIGluZGljYXRlcyBvbmUgdHlwZSwgDQoNCnRoZXJlIHdpbGwgYmUgdGhy ZWUgU0ZQIElEcyBBc3NpZ25lZC4NCg0KQ2hlZXJzLA0KV2VpDQoNCg0KDQoic2ZjIiA8c2ZjLWJv dW5jZXNAaWV0Zi5vcmc+INC009ogMjAxNS8wOS8yMSAxODozNjo1NDoNCg0KPiBMaW5kYSwNCj4g DQo+IEl0IHNlZW1zIHRoZSBpc3N1ZSB0aGF0IHRoaXMgZHJhZnQgYXR0ZW1wdHMgdG8gcmFpc2Ug Y2FuIGJlIA0KPiBzdW1tYXJpemVkIHdpdGggdGhpcyBxdWVzdGlvbjoNCj4gDQo+ICJXaGVuIHRy YWZmaWMgaXMgc3RlZXJlZCB0byBTRjMsIGhvdyBTRjMgdG8gY29ycmVjdGx5IGFuYWx5emUgdGhl DQo+ICAgIE1hbmRhdG9yeSBDb250ZXh0IEhlYWRlcnMgaW4gTlNIIHdpdGhpbiB0aGUgYXJyaXZp bmcgdHJhZmZpYz8iDQo+IA0KPiBUaGUgc29sdXRpb24gdG8gdGhpcywgaG93ZXZlciwgaXMgbmVp dGhlciBvZiB3aGF0J3MgcHJlc2VudGVkIGluIA0KPiBTZWN0aW9ucyA0LjEgYW5kIDQuMi4gVGhl IGFuc3dlciBpcyBtdWNoIHNpbXBsZXIgYW5kIGFscmVhZHkgdGhlcmU6IA0KPiB0aGUgU0ZQIChi eSB3YXkgb2YgdGhlIFNGUCBJRCkgcHJvdmlkZXMgY29udGV4dCB0byB1bmRlcnN0YW5kIHRoZSAN Cj4gZm9ybWF0IG9mIHRoZSBtZXRhZGF0YS4gSW4gb3RoZXIgd29yZHMsIGEgZ2l2ZW4gU0ZQIElE IHdpbGwgdXNlIG9uZSANCj4gb2YgdGhlIE1EIGZvcm1hdHMvc3ludGF4IChEQywgTW9iaWxpdHks IHNvbWV0aGluZyBlbHNlKS4gDQo+IA0KPiBUaGFua3MsDQo+IA0KPiBUaHVtYiB0eXBlZCBieSBD YXJsb3MgUGlnbmF0YXJvLiANCj4gRXhjdXplIHR5cG9mcmFwaGljYWsgZXJyb3dzDQo+IA0KPiBP biBTZXAgMjEsIDIwMTUsIGF0IDA0OjI2LCAid2FuZy5jdWkxQHp0ZS5jb20uY24iIDx3YW5nLmN1 aTFAenRlLmNvbS5jbg0KPiA+IHdyb3RlOg0KDQo+IA0KPiBEZWFyIGFsbCwgDQo+IA0KPiAgICBI ZXJlIGlzIGEgbmV3IGRyYWZ0IHByb3Bvc2VkIHRvIHJhaXNlIGFuIGlzc3VlIHdoaWNoIG1heSBl eGlzdCANCj4gd2hlbiBNRCBUeXBlPTB4MDEgaXMgbWFuZGF0b3J5LiANCj4gQW5kIHRvIG1vdGl2 YXRlIHRoZSBmdXJ0aGVyIGRpc2N1c3Npb24gYWJvdXQgTUQgVHlwZS4gV2lzaCB5b3UgY2FuIA0K PiBwYXkgYXR0ZW50aW9uIHRvIHRoaXMgdG8gDQo+IGNvbnRpbnVlIHRoZSBkaXNjdXNzaW9uIGFu ZCBtYWtlIGEgY29uc2Vuc3VzIDspIA0KPiANCj4gICBUaGFua3MuLiANCj4gDQo+IEJlc3QgV2lz aGVzLCANCj4gTGluZGEgV2FuZyANCj4gDQo+IA0KPiANCj4gDQo+IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyDQtNPaIDIwMTUvMDkvMjEgMTY6MTM6NTc6DQo+IA0KPiA+IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyANCj4gPiAyMDE1LzA5LzIxIDE2OjEzIA0KPiA+IA0KPiA+IMrVvP7IyyANCj4g PiANCj4gPiAiQ3VpIFdhbmciIDx3YW5nLmN1aTFAenRlLmNvbS5jbj4sICJXZWkgTWVuZyIgDQo+ ID4gPG1lbmcud2VpMkB6dGUuY29tLmNuPiwgIkN1aSBXYW5nIiA8d2FuZy5jdWkxQHp0ZS5jb20u Y24+LCAiV2VpIA0KPiA+IE1lbmciIDxtZW5nLndlaTJAenRlLmNvbS5jbj4sIA0KPiA+IA0KPiA+ ILOty80gDQo+ID4gDQo+ID4g1vfM4iANCj4gPiANCj4gPiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNzdWVzLTAwLnR4dCANCj4gPiANCj4gPiAN Cj4gPiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd2FuZy1zZmMtbWQtdHlwZS1pc3N1ZXMt MDAudHh0DQo+ID4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBDdWkgV2FuZyBh bmQgcG9zdGVkIHRvIHRoZQ0KPiA+IElFVEYgcmVwb3NpdG9yeS4NCj4gPiANCj4gPiBOYW1lOiAg ICAgIGRyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNzdWVzDQo+ID4gUmV2aXNpb246ICAgMDANCj4g PiBUaXRsZTogICAgICBNZXRhZGF0YSBUeXBlIElzc3Vlcw0KPiA+IERvY3VtZW50IGRhdGU6ICAg MjAxNS0wOS0yMQ0KPiA+IEdyb3VwOiAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiA+IFBh Z2VzOiAgICAgIDE0DQo+ID4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC13YW5nLXNmYy0NCj4gPiBtZC10eXBlLWlzc3Vlcy0wMC50eHQN Cj4gPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtd2FuZy1zZmMtbWQtDQo+ID4gdHlwZS1pc3N1ZXMvDQo+ID4gSHRtbGl6ZWQ6IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13YW5nLXNmYy1tZC10eXBlLWlzc3Vlcy0wMA0KPiA+ IA0KPiA+IA0KPiA+IEFic3RyYWN0Og0KPiA+ICAgIFNlcnZpY2UgZnVuY3Rpb24gY2hhaW4gaXMg dGhlIGRlZmluaXRpb24gb2YgYW4gb3JkZXJlZCBzZXQgb2YgDQpzZXJ2aWNlDQo+ID4gICAgZnVu Y3Rpb25zLiAgQWZ0ZXIgaW5zdGFudGlhdGVkLCB0aGUgc2VydmljZSBmdW5jdGlvbiBwYXRoIGlz IA0KY3JlYXRlZA0KPiA+ICAgIGFuZCB0aGUgY2xhc3NpZmllZCB0cmFmZmljIGlzIHN0ZWVyZWQg dGhyb3VnaCB0aGUgY29ycmVzcG9uZGluZw0KPiA+ICAgIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCBh bmQgdGhlbiBmb3J3YXJkZWQgdG8gdGhlIGZpbmFsIGRlc3RpbmF0aW9uLg0KPiA+ICAgIE1ldGFk YXRhIChNRCkgaXMgY29udmV5ZWQgaW4gU0ZDIGRhdGEgcGxhbmUgd2hpY2ggcHJvdmlkZXMgdGhl DQo+ID4gICAgYWJpbGl0eSB0byBleGNoYW5nZSBjb250ZXh0IGluZm9ybWF0aW9uIGJldHdlZW4g Y2xhc3NpZmllcnMgYW5kIA0KU0ZzLA0KPiA+ICAgIGFtb25nIFNGcywgYW5kIGJldHdlZW4gZXh0 ZXJuYWwgc3lzdGVtcyBhbmQgU0ZzLiAgVGhpcyBkb2N1bWVudCBpcw0KPiA+ICAgIG1vdGl2YXRl ZCB0byBzdGF0ZSBhbiBpc3N1ZSB3aGVuIE1EIFR5cGUgPSAweDEgYW5kIGRpc2N1c3Mgd2hpY2gN Cj4gPiAgICBNZXRhZGF0YSBUeXBlIGluIG1vcmUgYXBwcm9wcmlhdGUgdG8gYmUgbWFuZGF0ZSBp biBTRkMgZGF0YSBwbGFuZS4NCj4gPiANCj4gPiAgDQo+ID4gDQo+ID4gDQo+ID4gUGxlYXNlIG5v dGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Yg DQpzdWJtaXNzaW9uDQo+ID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPiANCj4gPiBUaGUgSUVURiBTZWNyZXRh cmlhdA0KPiA+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= --=_alternative 002697CA48257ECB_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIENhcmxvcywgSm9lbCw8L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBEbyB5 b3UgbWVhbiBhIDwvZm9udD48Zm9udCBzaXplPTI+PHR0PmdpdmVuDQpTRlAgSUQ8L3R0PjwvZm9u dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+IDwvZm9udD48Zm9udCBzaXplPTE+Y29y cmVzcG9uZHMNCnRvIDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+b25lIHR5 cGUoREMsIG1vYmlsaXR5oa0pPzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+SWYgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0LCBpcyB0aGF0DQphIHdhc3RlIG9m IFNGUCBJRHM/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgRm9yIGV4YW1wbGUsIHBsZWFzZSBhbGxvdyBtZQ0KbWFrZSBhIGJvbGQgYXNzdW1w dGlvbiwgU0ZQIEEtJmd0O0ItJmd0O0MgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5taWdodCBiZSBhc3NpZ25lZCBmb3IgREMgJmFtcDsgbW9iaWxpdHkNCiZhbXA7 IGJyb2FkYmFuZCBpbiBGaXhlZCBNb2JpbGUgQ29udmVyZ2VuY2UsPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Bc3NpZ25pbmcgb25lIFNGUCBJRCBpcyBlbm91Z2gu IEhvd2V2ZXIsDQppZiBvbmUgPC9mb250Pjxmb250IHNpemU9Mj48dHQ+U0ZQIElEIGluZGljYXRl cyBvbmUgdHlwZSwgPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD50aGVyZSB3aWxs IGJlIHRocmVlIFNGUCBJRHMgPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkFzc2lnbmVkLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Q2hlZXJzLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ V2VpPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+JnF1b3Q7 c2ZjJnF1b3Q7ICZsdDtzZmMtYm91bmNlc0BpZXRmLm9yZyZndDsg0LTT2g0KMjAxNS8wOS8yMSAx ODozNjo1NDo8YnI+DQo8YnI+DQomZ3Q7IExpbmRhLDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNp emU9Mj48dHQ+Jmd0OyA8YnI+DQomZ3Q7IEl0IHNlZW1zIHRoZSBpc3N1ZSB0aGF0IHRoaXMgZHJh ZnQgYXR0ZW1wdHMgdG8gcmFpc2UgY2FuIGJlIDxicj4NCiZndDsgc3VtbWFyaXplZCB3aXRoIHRo aXMgcXVlc3Rpb246PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IDxicj4N CiZndDsgJnF1b3Q7V2hlbiB0cmFmZmljIGlzIHN0ZWVyZWQgdG8gU0YzLCBob3cgU0YzIHRvIGNv cnJlY3RseSBhbmFseXplDQp0aGU8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtNYW5kYXRvcnkgQ29u dGV4dCBIZWFkZXJzIGluIE5TSCB3aXRoaW4gdGhlIGFycml2aW5nDQp0cmFmZmljPyZxdW90Ozwv dHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyA8YnI+DQomZ3Q7IFRoZSBzb2x1 dGlvbiB0byB0aGlzLCBob3dldmVyLCBpcyBuZWl0aGVyIG9mIHdoYXQncyBwcmVzZW50ZWQgaW4g PGJyPg0KJmd0OyBTZWN0aW9ucyA0LjEgYW5kIDQuMi4gVGhlIGFuc3dlciBpcyBtdWNoIHNpbXBs ZXIgYW5kIGFscmVhZHkgdGhlcmU6DQo8YnI+DQomZ3Q7IHRoZSBTRlAgKGJ5IHdheSBvZiB0aGUg U0ZQIElEKSBwcm92aWRlcyBjb250ZXh0IHRvIHVuZGVyc3RhbmQgdGhlDQo8YnI+DQomZ3Q7IGZv cm1hdCBvZiB0aGUgbWV0YWRhdGEuIEluIG90aGVyIHdvcmRzLCBhIGdpdmVuIFNGUCBJRCB3aWxs IHVzZSBvbmUNCjxicj4NCiZndDsgb2YgdGhlIE1EIGZvcm1hdHMvc3ludGF4IChEQywgTW9iaWxp dHksIHNvbWV0aGluZyBlbHNlKS4gPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4m Z3Q7IDxicj4NCiZndDsgVGhhbmtzLDwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+ Jmd0OyA8YnI+DQomZ3Q7IFRodW1iIHR5cGVkIGJ5IENhcmxvcyBQaWduYXRhcm8uIDwvdHQ+PC9m b250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Jmd0OyBFeGN1emUgdHlwb2ZyYXBoaWNhayBlcnJv d3M8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZndDsgPGJyPg0KJmd0OyBPbiBT ZXAgMjEsIDIwMTUsIGF0IDA0OjI2LCAmcXVvdDt3YW5nLmN1aTFAenRlLmNvbS5jbiZxdW90OyAm bHQ7d2FuZy5jdWkxQHp0ZS5jb20uY248YnI+DQomZ3Q7ICZndDsgd3JvdGU6PGJyPg0KPC90dD48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IDxicj4NCiZndDsgRGVhciBhbGwsIDxi cj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7SGVyZSBpcyBhIG5ldyBkcmFmdCBwcm9w b3NlZCB0byByYWlzZSBhbiBpc3N1ZSB3aGljaA0KbWF5IGV4aXN0IDxicj4NCiZndDsgd2hlbiBN RCBUeXBlPTB4MDEgaXMgbWFuZGF0b3J5LiA8YnI+DQomZ3Q7IEFuZCB0byBtb3RpdmF0ZSB0aGUg ZnVydGhlciBkaXNjdXNzaW9uIGFib3V0IE1EIFR5cGUuIFdpc2ggeW91IGNhbg0KPGJyPg0KJmd0 OyBwYXkgYXR0ZW50aW9uIHRvIHRoaXMgdG8gPGJyPg0KJmd0OyBjb250aW51ZSB0aGUgZGlzY3Vz c2lvbiBhbmQgbWFrZSBhIGNvbnNlbnN1cyA7KSA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7 IFRoYW5rcy4uIDxicj4NCiZndDsgPGJyPg0KJmd0OyBCZXN0IFdpc2hlcywgPGJyPg0KJmd0OyBM aW5kYSBXYW5nIDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IDxicj4NCiZndDsgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnINC009ogMjAxNS8wOS8yMSAx NjoxMzo1Nzo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcgPGJyPg0KJmd0OyAmZ3Q7IDIwMTUvMDkvMjEgMTY6MTMgPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyDK1bz+yMsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmcXVvdDtD dWkgV2FuZyZxdW90OyAmbHQ7d2FuZy5jdWkxQHp0ZS5jb20uY24mZ3Q7LCAmcXVvdDtXZWkNCk1l bmcmcXVvdDsgPGJyPg0KJmd0OyAmZ3Q7ICZsdDttZW5nLndlaTJAenRlLmNvbS5jbiZndDssICZx dW90O0N1aSBXYW5nJnF1b3Q7ICZsdDt3YW5nLmN1aTFAenRlLmNvbS5jbiZndDssDQomcXVvdDtX ZWkgPGJyPg0KJmd0OyAmZ3Q7IE1lbmcmcXVvdDsgJmx0O21lbmcud2VpMkB6dGUuY29tLmNuJmd0 OywgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyCzrcvNIDxicj4NCiZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsg1vfM4iA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE5ldyBW ZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtd2FuZy1zZmMtbWQtdHlwZS1pc3N1ZXMtMDAu dHh0DQo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtd2FuZy1zZmMtbWQtdHlwZS1pc3N1ZXMtMDAudHh0PGJy Pg0KJmd0OyAmZ3Q7IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQ3VpIFdhbmcg YW5kIHBvc3RlZCB0byB0aGU8YnI+DQomZ3Q7ICZndDsgSUVURiByZXBvc2l0b3J5Ljxicj4NCiZn dDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC13 YW5nLXNmYy1tZC10eXBlLWlzc3Vlczxicj4NCiZndDsgJmd0OyBSZXZpc2lvbjogJm5ic3A7IDAw PGJyPg0KJmd0OyAmZ3Q7IFRpdGxlOiAmbmJzcDsgJm5ic3A7ICZuYnNwO01ldGFkYXRhIFR5cGUg SXNzdWVzPGJyPg0KJmd0OyAmZ3Q7IERvY3VtZW50IGRhdGU6ICZuYnNwOyAyMDE1LTA5LTIxPGJy Pg0KJmd0OyAmZ3Q7IEdyb3VwOiAmbmJzcDsgJm5ic3A7ICZuYnNwO0luZGl2aWR1YWwgU3VibWlz c2lvbjxicj4NCiZndDsgJmd0OyBQYWdlczogJm5ic3A7ICZuYnNwOyAmbmJzcDsxNDxicj4NCiZn dDsgJmd0OyBVUkw6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXdhbmctc2ZjLTxicj4NCiZn dDsgJmd0OyBtZC10eXBlLWlzc3Vlcy0wMC50eHQ8YnI+DQomZ3Q7ICZndDsgU3RhdHVzOiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtd2FuZy1zZmMtbWQtPGJyPg0KJmd0OyAmZ3Q7IHR5cGUtaXNzdWVzLzxicj4NCiZndDsg Jmd0OyBIdG1saXplZDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXdhbmctc2ZjLW1kLXR5cGUtaXNzdWVzLTAwPGJyPg0KJmd0OyAmZ3Q7IDxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOyAmbmJzcDtTZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGlzIHRoZSBkZWZpbml0aW9uIG9mIGFu IG9yZGVyZWQNCnNldCBvZiBzZXJ2aWNlPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtmdW5j dGlvbnMuICZuYnNwO0FmdGVyIGluc3RhbnRpYXRlZCwgdGhlIHNlcnZpY2UNCmZ1bmN0aW9uIHBh dGggaXMgY3JlYXRlZDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7YW5kIHRoZSBjbGFzc2lm aWVkIHRyYWZmaWMgaXMgc3RlZXJlZCB0aHJvdWdoIHRoZQ0KY29ycmVzcG9uZGluZzxicj4NCiZn dDsgJmd0OyAmbmJzcDsgJm5ic3A7c2VydmljZSBmdW5jdGlvbiBwYXRoIGFuZCB0aGVuIGZvcndh cmRlZCB0byB0aGUNCmZpbmFsIGRlc3RpbmF0aW9uLjxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5i c3A7TWV0YWRhdGEgKE1EKSBpcyBjb252ZXllZCBpbiBTRkMgZGF0YSBwbGFuZSB3aGljaA0KcHJv dmlkZXMgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDthYmlsaXR5IHRvIGV4Y2hhbmdl IGNvbnRleHQgaW5mb3JtYXRpb24gYmV0d2Vlbg0KY2xhc3NpZmllcnMgYW5kIFNGcyw8YnI+DQom Z3Q7ICZndDsgJm5ic3A7ICZuYnNwO2Ftb25nIFNGcywgYW5kIGJldHdlZW4gZXh0ZXJuYWwgc3lz dGVtcyBhbmQgU0ZzLg0KJm5ic3A7VGhpcyBkb2N1bWVudCBpczxicj4NCiZndDsgJmd0OyAmbmJz cDsgJm5ic3A7bW90aXZhdGVkIHRvIHN0YXRlIGFuIGlzc3VlIHdoZW4gTUQgVHlwZSA9IDB4MSBh bmQNCmRpc2N1c3Mgd2hpY2g8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO01ldGFkYXRhIFR5 cGUgaW4gbW9yZSBhcHByb3ByaWF0ZSB0byBiZSBtYW5kYXRlDQppbiBTRkMgZGF0YSBwbGFuZS48 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJv bSB0aGUgdGltZQ0Kb2Ygc3VibWlzc2lvbjxicj4NCiZndDsgJmd0OyB1bnRpbCB0aGUgaHRtbGl6 ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQomZ3Q7 ICZndDsgPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBzZmMgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyBzZmNAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgc2ZjIG1haWxpbmcgbGlzdDxicj4N CiZndDsgc2ZjQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYzxicj4NCjwvdHQ+PC9mb250Pg0K --=_alternative 002697CA48257ECB_=--