From nobody Sun Feb 1 09:11: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 B87181A89B1 for ; Sun, 1 Feb 2015 09:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 Dr6O8ehRnazC for ; Sun, 1 Feb 2015 09:11:40 -0800 (PST) Received: from mc30.lon.server.colt.net (mc30.lon.server.colt.net [212.74.77.110]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9651A898B for ; Sun, 1 Feb 2015 09:11:35 -0800 (PST) Received: from mc30.lon.server.colt.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 2BB2C1C9B7E for ; Sun, 1 Feb 2015 17:11:03 +0000 (UTC) Received: from mx3.qosmos.com (unknown [195.68.92.43]) by mc30.lon.server.colt.net (Postfix) with ESMTP id F07551C9B6B for ; Sun, 1 Feb 2015 17:11:02 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.09,503,1418079600"; d="scan'208";a="1508493" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 01 Feb 2015 18:10:50 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.51]) with mapi id 14.01.0438.000; Sun, 1 Feb 2015 18:10:50 +0100 From: Nicolas BOUTHORS To: Sumandra Majee , Cathy Zhang , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQO/5DH/wTNyDwgkS9ydl+3/sIXZzYeC9AgAC+I4CAAtMZEA== Date: Sun, 1 Feb 2015 17:10:49 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D7D2279@LILAS.jungle.qosmos.com> References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> In-Reply-To: Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.0.22] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSVA-8.2.0.1679-7.5.0.1018-21298.001 X-TM-AS-Result: No--24.018-5.0-31-10 X-imss-scan-details: No--24.018-5.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-Version: IMSVA-8.2.0.1679-7.5.1018-21298.001 X-TMASE-Result: 10--24.017900-5.000000 X-TMASE-MatchedRID: l4bxV8Hot0EpwNTiG5IsEkNTnAhL0/m38GRhP/nTHNacQD4tKz3tFBwz 72zDzvkOu9+S5+1x5tEge8lbIoY9eGC+RjBytve0K1XEgm57RQMS12tj9Zvd87cQnRHvf/mNH3j 6hipTSlxXXYsgXwp4e/WSyMFfxH7wN6IarY2VLsWVUcz8XpiS9PioIsi7Sa0gbSY2Z5sxPQWd8Y 64luJmv9bzShoyDjXd2TLNiDAt5rXBJZasgTmkhpmug812qIbzrqUopAyOL/FmlZul6HIRR5lfI IoJIzJ5c3pJPFc1+6Psb0+zy01B1XUNieXVE/Y/q32frrMnhEiMs7LXcKBvj6q9wgXVNwtga6Rs XYU1kJf+VYvioZB9r5uvP4QC51HNTnDUd82lsjip4G6k2AuBh8BZPOJYZoM81RDgJ182y9OKM+G 2mYtQK6c2gnzlqFWKL953ZAONQnJXSN89RTJnt6fXIl6Cf6Vr7h2RrsKOiu0zc2UF06t7Ds+SFM sGp5848zPb2eJ9rZTl2n9WUWIBWnj7PwsdQyXdbBu6+EIezdw2vbWaKPnQ21S+oHmj8upzkqO2A bVSuPwHXE5t+qNveT/U4p7KPAQXpF+0lJVCjVWJQ9k+Ypk5CQsE9gx+4jJuX5FedY/aPL+x2Ck8 ZZWeBZjAvfdWGGfo1Wk2rKkiW+nAGgDPslfCUNOEZs/2oH3cfkuZtv/FS5oJ/KT4ih4XXJOuv4L VY2bFBnKJvu9CwU6CiGs4uOTQthZK05xEkCkC84dsinZ5e1jb2fgL9ZXgQ0xK6xoTojC4eWBYAg SFkCuY6Po8e0HdM72I9owvW2Cch3MOJCC8OhqeAiCmPx4NwMFrpUbb72MU1B0Hk1Q1KyJGNS8BP La+j7ew1twePJJB3QfwsVk0UbslCGssfkpInQ== Archived-At: Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 01 Feb 2015 17:11:45 -0000 SSBjYW4gdW5kZXJzdGFuZCB0aGF0IGluIG1hbnkgY2FzZXMgYSBsb2NhbCBTRkYgYXBwZWFycyBi ZXN0IHN1aXRlZCB0byB0YWtlIGxvYWQgYmFsYW5jaW5nL3Jlcm91dGluZyBkZWNpc2lvbnMuDQoN ClN0aWxsIHdlIHNob3VsZCBhbGxvdyBmb3IgdGhlIGNhc2Ugd2hlcmUgYSByZW1vdGUgU0ZGLCBz dWNoIGFzIHRoZSBDbGFzc2lmaWVyIGF0IHRoZSBlbnRyYW5jZSBwb2ludCBvZiB0aGUgbmV0d29y aywgZm9yIGV4YW1wbGUgYmFzZWQgb24gRFBJIG9yIHN1YnNjcmliZXIgYXdhcmVuZXNzLCBwZXJm b3JtcyByZW1vdGUgbG9hZCBiYWxhbmNpbmcgZGVjaXNpb24gdGhhbmtzIHRvIHRoZSB0cmFuc21p c3Npb24gb2YgdGhlIFJlbmRlcmVkIFNlcnZpY2UgUGF0aCBpZGVudGlmaWVyLiBEUEkgY2FwYWJp bGl0eSBtYXkgbm90IGJlIGF2YWlsYWJsZSBpbiBhbGwgU0ZGIGZvciBleGFtcGxlLg0KDQpJbiBh ZGRpdGlvbiB0aGUgUmVuZGVyZWQgU2VydmljZSBQYXRoIGlkZW50aWZpZXIgY2FuIGJlIHVzZWQg YXMgYSBoYXNoIGtleSBieSAgU0ZGKHkpIGxvYWQgYmFsYW5jaW5nIGRlY2lzaW9uLiBTbyBpdCBp cyBhbHNvIGNvbXBhdGlibGUgd2l0aCB0aGUgbm90aW9uIG9mIGxvY2FsIGxvYWQgYmFsYW5jZXIu DQpSZWdhcmRzLA0KDQpOaWNvbGFzDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IFN1bWFuZHJhIE1hamVlIFttYWlsdG86Uy5NYWplZUBGNS5jb21dDQpTZW50OiB2ZW5kcmVk aSAzMCBqYW52aWVyIDIwMTUgMjM6NTMNClRvOiBOaWNvbGFzIEJPVVRIT1JTOyBDYXRoeSBaaGFu ZzsgJ3NmY0BpZXRmLm9yZycNCkNjOiBKZXJvbWUgVE9MTEVUDQpTdWJqZWN0OiBSZTogW3NmY10g Q29tbWVudHMgb24gU0NIIERyYWZ0IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt emhhbmctc2ZjLXNjaC0wMikNCg0KSGVsbG8sDQoNClRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgZGlz Y3Vzc2lvbiBhbmQgSSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQgdGhlIG1vdGl2YXRpb24gb2Yg YmV0dGVyLiBUaGUgdHJvdWJsZSB3aXRoIGEgcHJvdG9jb2wgZG9jdW1lbnQgaXMgdGhhdCBpdCBp cyB0eXBpY2FsbHkgaGFzIGluYWRlcXVhdGUgZGV0YWlsIGFib3V0IHRoZSBsb2dpYy4gU28gdG8g Y2FzdCB0aGlzIGludG8gc29tZXdoYXQgb2YgYSBjb25jcmV0ZSB0ZXJtcywgY29uc2lkZXIgdGhl IGZvbGxvd2luZy4NCg0KDQoNCiAgICAgICBTRkYoeCkgIHsgU2Z4KDEpIFNmeCgyKeKAplNmeChu KSB9ICAg4oCU4oCU4oCU4oCUPiAgIFNGRih5KSB7IFNmeSgxKSBTZnkoMikNCuKApi4gU2Z5KG0p IH0gICA6OiBMb2dpY2FsIENoYWluIGluIE9ORSBkaXJlY3Rpb24gb25seS4NCg0KICAgICAgIFBI WVNJQ0FMIFdPUkxEOg0KICAgICAgICAgIEEpIHRoZSBTRkYgY291bGQgYmUgYQ0KICAgICAgICAg ICAgLSBjb21wb25lbnQgb2YgVlNXSVRDSCAocGljayB5b3VyIGZhdiBwcm90b2NvbCBmb3IgY29u ZmlndXJpbmcgdGhvc2UgZW50aXRpZXMgfQ0KICAgICAgICAgICAgLSBBIGxvYWQgYmFsYW5jZXIN CiAgICAgICAgICAgIC0gQSBIVyBzd2l0Y2gvcm91dGVyIHNvbWUgTDIvTDMgY29tYm8NCg0KICAg ICAgICAgIEIpIFNmIGluc3RhbmNlIGNvdWxkIGJlLA0KICAgICAgICAgICAgICAgLSBWaXJ0dWFs IG1hY2hpbmUsICNOIG9mIHRob3NlDQogICAgICAgICAgICAgICAtIHBoeXNpY2FsDQogICAgICAg ICAgICAgICAtIENvbnRhaW5lciAjTSB3aGljaCBpcyBvZnRlbiA1IG9yIG1vcmUgeCAjTg0KICAg ICAgICAgICAgICAgLSBDbHVzdGVyIHRoYXQgd2UgZG9u4oCZdCBrbm93DQoNCkl0IGlzIHBvc3Np YmxlIHRvIGhhdmUgbXVsdGlwbGUgcGh5c2ljYWwgU0ZGKHgpIGFsc28uDQoNCkEgc2VsZWN0aW9u IG9mIGEgZ2l2ZW4gU0YgKHNlcnZpY2UpKGluc3RhbmNlKSBpcyBhIGNhbiBiZSBzaW1wbGUgb3Ig Y29tcGxleC4gRm9yIGV4YW1wbGUgU0ZGKHgpIG1heSBoYXZlIHRoZSBiZXN0IGtub3dsZWRnZSB0 byBzZWxlY3QgU2Z4KDEpIGJhZWQgb24gYSBnaXZlbiBjcml0ZXJpb24gKHdoaWNoIGNvdWxkIGJl IHBhcnQgb2YgdGhlIHBvbGljeSkuICBUaGVuIEkgZG9u4oCZdCBzZWUgYSByZWFzb24gdG8gaGF2 ZSBSU1AuDQoNCkl0IGlzIHBvc3NpYmxlIHRoYXQgbG9va3VwIChwYXRoKSBAIFNGRih4KSBwcm9k dWNlcyBhIHNwZWNpZmljIGluc3RhbmNlIG9mIFNmeSBhbmQgeWVzIHRoZW4gc29tZXRoaW5nIGxp a2UgUlNQIHdvdWxkIGJlIHJlcXVpcmVkLiBCdXQgSSB3b3VsZCBhcmd1ZSB0aGF0IGpvYiBTRkYo eSkgY2FuIGFsc28gYmUgc3Vic3VtZWQgYnkgU0ZGKHgpLg0KDQpJcyBpdCBwb3NzaWJsZSBmb3Ig YSBjZW50cmFsIGNvbnRyb2xsZXIgdG8gcGljayBlYWNoIGluc3RhbmNlIG9mIHNlcnZpY2UsIGJ1 dCBzdWNoIGFuIGltcGxlbWVudGF0aW9uIHRlbmRzIHRvIHNjYWxlIHBvb3JseS4gVGhlIGFtb3Vu dCBvZiBzdGF0ZSwgcHJvYmFiaWxpdHkgb2YgYSBpbnN0YW5jZSBnb2luZyBkb3duIGJldHdlZW4g c2VsZWN0aW9uIGFuZCBmbG93IGFycml2YWwgZ29lcyB1cC4NCg0KUmVnYXJkcy4NCg0KU3VtYW5k cmENCg0KDQoNCk9uIDEvMzAvMTUsIDM6MzggQU0sICJOaWNvbGFzIEJPVVRIT1JTIiA8Tmljb2xh cy5CT1VUSE9SU0Bxb3Ntb3MuY29tPg0Kd3JvdGU6DQoNCj5IZWxsbyBDYXRoeSwNCj4NCj5JbmRl ZWQgdGhlIG5vdGlvbiBvZiAicmVuZGVyZWQgc2VydmljZSBwYXRoIElEIihSU1AgSUQpIHNlZW1z IHJlbGV2YW50DQo+YXMgdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBzdGlwdWxhdGVzIHRoYXQg dGhlIFNlcnZpY2UgRnVuY3Rpb24gUGF0aA0KPihTRlApIHByb3ZpZGVzIGFuIGFic3RyYWN0IG5v dGlvbiBvZiBhIHNlcnZpY2UgY2hhaW4sIHdoaWxlIHRoZSBSU1AgaXMNCj5hIGNvbnN0cmFpbmVk IGxpc3Qgb2YgbG9jYXRpb25zLg0KPg0KPlNGQyBoZWFkZXIgIlNlcnZpY2UgUGF0aCBJZGVudGlm aWVyIiAoU1BJKSAgaXMgdXNlZCBpbiBib3RoIE5TSCBhbmQgU0NIDQo+cHJvdG9jb2wgYW5kIGlu IGJvdGggY2FzZSBzZWVtIHRvIGlkZW50aWZ5IHRvIGEgcGFydGljdWxhciBTRlAuDQo+DQo+TlNI KHY1KSBmb3IgZXhhbXBsZSBzdGF0ZXMgdGhhdA0KPiIgQXMgZGVzY3JpYmVkIGFib3ZlLCBOU0gg Y29udGFpbnMgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciAoU1BJKSBhbmQNCj4gICBhIHNlcnZp Y2UgaW5kZXggKFNJKS4gIFRoZSBTUEkgaXMsIGFzIHBlciBpdHMgbmFtZSwgYW4gaWRlbnRpZmll ci4NCj4gICBUaGUgU1BJIGFsb25lIGNhbm5vdCBiZSB1c2VkIHRvIGZvcndhcmQgcGFja2V0cyBh bG9uZyBhIHNlcnZpY2UgcGF0aC4NCj4gICBSYXRoZXIgdGhlIFNQSSBwcm92aWRlIGEgbGV2ZWwg b2YgaW5kaXJlY3Rpb24gYmV0d2VlbiB0aGUgc2VydmljZQ0KPiAgIHBhdGgvdG9wb2xvZ3kgYW5k IHRoZSB0aGUgbmV0d29yayB0cmFuc3BvcnQuICBGdXJ0aGVybW9yZSwgdGhlcmUgaXMNCj4gICBu byByZXF1aXJlbWVudCwgb3IgZXhwZWN0YXRpb24gb2YgYW4gU1BJIGJlaW5nIGJvdW5kIHRvIGEg cHJlLQ0KPiAgIGRldGVybWluZWQgb3Igc3RhdGljIG5ldHdvcmsgcGF0aC4iDQo+DQo+U3RpbGwg TlNIKHY1KSAgc2hvd3MgdGhhdCBTUEkgKG5vdCBhIFJTUCBJRCkgIHNob3VsZCBiZSBwYXJ0IG9m IHRoZSBrZXkNCj5lbGVtZW50IG9mIGFuIFNGRiB0byBsb29rdXAgb24gZm9yd2FyZGluZyB0YWJs ZXMuICBCdXQgSSBjb3VsZCBub3QgZmluZA0KPmluIE5TSCAgaG93IHRvIHVzZSB0aGUgbm90aW9u IG9mIFJlbmRlcmVkIHNlcnZpY2UgcGF0aCB3aGljaCB3YXMNCj5kZWZpbmVkIGluIHRoZSBhcmNo aXRlY3R1cmUgZG9jdW1lbnQuDQo+DQo+WW91IHByb3Bvc2FsIHNlZW1zIHRvIG1lIHZlcnkgdXNl ZnVsLA0KPg0KPkFuIFJTUCBJRCAoaW5kZXBlbmRlbnQgb2YgdGhlIFNQSSBidXQgcGFydCBvZiB0 aGUgc2FtZSBuYW1lIHNwYWNlKQ0KPmNvdWxkIGJlIHVzZWQgdGhlIHNhbWUgd2F5IGFzIFNQSSBi eSBTRkYgZm9yIGV4YW1wbGUsIGFsbG93aW5nIGENCj5TZXJ2aWNlIENsYXNzaWZpZXIgdG8gY29u dHJvbCByZW1vdGUgbG9hZCBiYWxhbmNpbmcgZm9yIGV4YW1wbGUuDQo+DQo+VGhpcyBzYWlkIHRo ZSBSU1AgSUQgdmFsdWVzIGNvdWxkIGJlIHJlbGF0aXZlIHRvIGEgcGFydGljdWxhciBTZXJ2aWNl DQo+UGF0aCwgd2hpY2ggd291bGQgcHJldmVudCB1c2luZyB0aGVtIGFzIHdlIGRvIGZvciBTUEkg aW4gU0ZGIGZvcndhcmRpbmcNCj50YWJsZXMuDQo+DQo+V2UgbWF5IHdhbnQgdG8gcHJlY2lzZSBp ZiB0aGUgUlNQIElEIGlzIHRvIGJlIHJlbGF0aXZlIG9mIGFic29sdXRlLCBhcw0KPml0IHNob3Vs ZCBoYXZlIGFuIGltcGFjdCBvbiBmb3J3YXJkaW5nIHRhYmxlIHN0cnVjdHVyZSBpZiB3ZSBkZWNp ZGUgdG8NCj51c2UgdGhpcyBjb25jZXB0Lg0KPg0KPlBlcnNvbmFsbHkgSSBsaWtlIHRoZSBub3Rp b24gb2YgYSByZWxhdGl2ZSBSU1AgSUQsIGFzIHdlIGNvdWxkIHRoZW4gdXNlDQo+c29tZSBjb252 ZW50aW9ucywgc3RydWN0dXJlIGl0LCBwb3NzaWJseSBleHRlbmRpbmcgaXRzIHVzZS4NCj4NCj5O aWNvbGFzDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBDYXRoeSBaaGFu ZyBbbWFpbHRvOkNhdGh5LkguWmhhbmdAaHVhd2VpLmNvbV0NCj5TZW50OiBqZXVkaSAyOSBqYW52 aWVyIDIwMTUgMjA6NDQNCj5UbzogQ2F0aHkgWmhhbmc7IFNyaW5pIEFkZGVwYWxsaTsgUmVpbmFs ZG8gUGVubm8gKHJlcGVubm8pOyBKb2VsIE0uDQo+SGFscGVybjsgJ3NmY0BpZXRmLm9yZycNCj5D YzogbnNtdXJ0aHlAZnJlZXNjYWxlLmNvbQ0KPlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBv biBTQ0ggRHJhZnQNCj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNm Yy1zY2gtMDIpDQo+DQo+SGkgZXZlcnlvbmUsDQo+DQo+V2UgaGF2ZSB1cGxvYWRlZCBhIG5ldyBT Q0ggdmVyc2lvbiAoMykgd2hpY2ggYWRkcyBkZWZpbml0aW9uIG9mIGEgbmV3DQo+bWV0YWRhdGEg dHlwZSBmb3IgdGhlIGZsb3cgSUQgdG8gc3VwcG9ydCBsb2FkIGJhbGFuY2luZyBhbW9uZyBTRg0K Pmluc3RhbmNlcyBhbmQgbWl0aWdhdGUgdGhlIHBvdGVudGlhbCBpc3N1ZSBvZiAibm90IGVub3Vn aCBwYXRoIElEIi4gVGhlDQo+ZmxvdyBJRCBpcyBuYW1lZCAicmVuZGVyZWQgc2VydmljZSBwYXRo IElEIiBpbiB0aGUgZHJhZnQuIFBsZWFzZSByZWZlcg0KPnRvIHNlY3Rpb24gNC4zLjIgb2YNCj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1zZmMtc2NoLw0KPmZv ciBkZXRhaWwgZGVzY3JpcHRpb24uDQo+DQo+SW4gaXRzIHByZXZpb3VzIHZlcnNpb24sIFNDSCBk ZWZpbmVzIGEgIkJ5cGFzcyBiaXQiIGluIHRoZSBiYXNlIGhlYWRlci4NCj5UaGlzIGJpdCBlbmFi bGVzIHRoZSBTRiB0byBwcm92aWRlIGZlZWRiYWNrL25vdGlmaWNhdGlvbiB2aWEgdGhlIGRhdGEN Cj5wYXRoIHRvIGl0cyBjb25uZWN0aW5nIFNGRiBhYm91dCB3aGV0aGVyIHRoZSByZW1haW5pbmcg cGFja2V0cyBvZiB0aGUNCj5TRkMgc2hvdWxkIGJ5cGFzcyB0aGF0IFNGLiBUaGlzIGlzIHVzZWZ1 bCBpbiB0aGUgY2FzZSB0aGF0IG9ubHkgdGhlDQo+Zmlyc3QgZmV3IHBhY2tldHMgb2YgYSBmbG93 IG5lZWQgdG8gZ28gdG8gYSBTRiAoc3VjaCBhcyBhIERQSSBvciBGVyBvcg0KPklEUykgYW5kIHJl bWFpbmluZyBwYWNrZXRzIGNhbiBieXBhc3MgdGhhdCBTRiwgdGh1cyBzYXZpbmcgdGhlDQo+ZXhw ZW5zaXZlIFNGIHJlc291cmNlIGFuZCByZWR1Y2luZyBkYXRhIHBhdGggbGF0ZW5jeS4NCj4NCj5C IGJpdDogVGhlIEIgKEJ5cGFzcykgYml0LCB3aGVuIHNldCB0byAxLCBpdCBpcyB1c2VkIGJ5IGEg U2VydmljZQ0KPiAgICAgICBGdW5jdGlvbiB0byBzaWduYWwgdG8gaXRzIFNlcnZpY2UgRnVuY3Rp b24gRm9yd2FyZGVyIHRoYXQgbm8NCj4gICAgICAgZnVydGhlciBwYWNrZXRzIGFyZSB0byBiZSBz ZW50IHRvIGl0IGZvciB0aGUgZmxvdyBzcGVjaWZpZWQgaW4NCj5lbmNhcHN1bGF0ZWQgcGFja2V0 Lg0KPg0KPkluIGFkZGl0aW9uLCBTQ0ggZGVmaW5lcyBhIG1ldGFkYXRhIHR5cGUgZm9yIEdlbmVy aWMgQ29udGV4dCBCbG9jaywNCj53aGljaCBpcyBvcHRpb25hbCBhbmQgY2FuIGJlIHVzZWQgaWYg bmVlZGVkIHRvIGNhcnJ5IGFueSB2ZW5kb3Incw0KPnNwZWNpZmljICJDb250ZXh0IEhlYWRlciIu DQo+DQo+QW55IGNvbW1lbnRzIG9uIHRoZXNlIG5ldyBhZGRpdGlvbnM/DQo+DQo+VGhhbmtzLA0K PkNhdGh5DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBzZmMgW21haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhdGh5IFpoYW5nDQo+U2VudDog RnJpZGF5LCBEZWNlbWJlciAwNSwgMjAxNCAxMTo0NyBBTQ0KPlRvOiBTcmluaSBBZGRlcGFsbGk7 IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgSm9lbCBNLiBIYWxwZXJuOw0KPidzZmNAaWV0Zi5v cmcnDQo+Q2M6IG5zbXVydGh5QGZyZWVzY2FsZS5jb20NCj5TdWJqZWN0OiBSZTogW3NmY10gQ29t bWVudHMgb24gU0NIIERyYWZ0DQo+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16 aGFuZy1zZmMtc2NoLTAyKQ0KPg0KPlJvbiwgTG91aXMsIE15byBhbmQgSSBoYXZlIGJlZW4gZGlz Y3Vzc2luZyBvZmYgbGluZSBsYXN0IGZldyB3ZWVrcw0KPmFib3V0IGRlZmluaW5nIGEgbWV0YWRh dGEgdHlwZSBmb3IgZmxvdyBJRCBpbiBhZGRpdGlvbiB0byB0aGUgcGF0aCBJRA0KPm9mIHRoZSBt YWluIGhlYWRlciB0byBzdXBwb3J0IGxvYWQgYmFsYW5jaW5nIGFtb25nIFNGIGluc3RhbmNlcy4g V2UNCj53aWxsIGRlZmluZSBhIFRMViB0eXBlIGZvciB0aGUgZmxvdyBJRC4gVGhlIGNvbWJpbmF0 aW9uIG9mICJwYXRoIElEICsgZmxvdyBJRCINCj5zcGVjaWZpZXMgYSByZWFsaXplZCBzZXJ2aWNl IGNoYWluIGluc3RhbmNlIHBhdGguIEl0IGlzIGxlZnQgdG8gdGhlDQo+ZGVzaWduL2ltcGxlbWVu dGF0aW9uIHdoZXRoZXIgdG8gdXNlIGEgY2VudHJhbGl6ZWQgbWV0aG9kIG9yIGENCj5kaXN0cmli dXRlZCBtZXRob2QgdG8gYmluZCB0aGUgZmxvdyBJRCB0byBhIHJlYWxpemVkIHNlcnZpY2UgaW5z dGFuY2UNCj5wYXRoIGFsdGhvdWdoIG91ciBvcmlnaW5hbCB0aG91Z2h0IGlzIGZvciBkaXN0cmli dXRlZCBMQiB1c2FnZS4gSSBhbQ0KPm5vdCBzdXJlIGlmIHdlIG5lZWQgYSBiaXQgaW4gdGhlIGhl YWRlciB0byBkZW5vdGUgd2hldGhlciB0aGVyZSBhcmUNCj5tb3JlIHBhdGggSUQgYml0cyAod2Ug Y2FsbCBpdCBmbG93IElEKSBpbiB0aGUgbWV0YWRhdGEgZmllbGRzIHNpbmNlDQo+d2hlbiB5b3Ug cGFyc2UgdGhlIFRMViBtZXRhZGF0YSwgeW91IHdpbGwga25vdyB3aGV0aGVyIHRoZXJlIGFyZSBm bG93IElEIGJpdHMgb3Igbm90Lg0KPk5vdGUgdGhhdCBpZiBtdWx0aXBsZSBzZXNzaW9ucyBzaGFy ZSB0aGUgc2FtZSByZWFsaXplZCBzZXJ2aWNlIGluc3RhbmNlDQo+cGF0aCwgdGhleSB3aWxsIHNo YXJlIHRoZSBzYW1lICJwYXRoIElEKyBmbG93IElEIi4gIFdlIGNhbiBhbHNvDQo+Y29uc2lkZXIg ZXh0ZW5kaW5nIHRoZSBudW1iZXIgb2YgYml0cyB0byAzMiBpZiB0aGF0IGlzIHRoZSBjb25zZW5z dXMuDQo+V2Ugd2lsbCBwb3N0IGFuIHVwZGF0ZWQgZHJhZnQgZGVzY3JpYmluZyB0aGVzZSBzb29u Lg0KPg0KPlRoYW5rcywNCj5DYXRoeQ0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTcmlu aSBBZGRlcGFsbGkNCj5TZW50OiBGcmlkYXksIERlY2VtYmVyIDA1LCAyMDE0IDc6MTcgQU0NCj5U bzogUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBKb2VsIE0uIEhhbHBlcm47ICdzZmNAaWV0Zi5v cmcnDQo+Q2M6IG5zbXVydGh5QGZyZWVzY2FsZS5jb20NCj5TdWJqZWN0OiBSZTogW3NmY10gQ29t bWVudHMgb24gU0NIIERyYWZ0DQo+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16 aGFuZy1zZmMtc2NoLTAyKQ0KPg0KPg0KPltSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5Lg0KPg0K PlNSSU5JPiBJIGFtIG5vdCBzbyBzdXJlIGFib3V0IGRhdGEgcGxhbmUgZWZmaWNpZW5jeS4gIE1v c3Qgb2YgdGhlDQo+cHJvY2Vzc29ycyB3b3JrIGdvb2QgaWYgdGhlIG51bWJlciBvZiBiaXRzIGFy ZSBlaXRoZXIgMzIgb3IgNjQuICBJZiBpdA0KPmlzDQo+MjQgYml0cywgdGhlbiBvbmUgbmVlZHMg dG8gZG8gbWFza2luZyBhbmQgc2hpZnRpbmcgYmVmb3JlIHRoZSB2YWx1ZSBpcw0KPnVzZWQgdG8g ZG8gYW55IGxvb2t1cC4gICBCdXQsIHRoaXMgZGlzY3Vzc2lvbiBjYW4gZ28gaW50byBkaWZmZXJl bnQNCj5kaXJlY3Rpb24gOi0pLCBpdCBtYXkgbm90IGJlIGdvb2QgdG8gZ28gaW4gdGhhdCBkaXJl Y3Rpb24uDQo+DQo+V2hlcmUgZG8gd2UgZHJhdyB0aGUgbGluZT8gMzItYml0cywgNjQtYml0cywN Cj4xMjggYml0cz8gSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRo ZSBTZXJ2aWNlIFBhdGgNCj5oZWFkZXIgYW5kIGlmIHlvdSBuZWVkIHRvIGNvbnZleSBtb3JlIGJp dHMgeW91IG5lZWQgdG8gdXNlIHRoZSBjb250ZXh0DQo+aGVhZGVycy4NCj4NCj5TUklOST4gVGhp cyBpcyBhIGdvb2QgcG9pbnQuICBUaGlzIHNob3VsZCB3b3JrIGZpbmUgYXMgbG9uZyBhcyB0aGVy ZSBpcw0KPndheSB0byBjb252ZXkgaW4gdGhlIG1haW4gaGVhZGVyIHRoYXQgdGhlIGV4dGVuc2lv biB0byBwYXRoIElEIGlzDQo+YXZhaWxhYmxlIGluIHNvIGFuZCBzbyBUTFYgZmllbGQuICBUaGF0 IHNob3VsZCB3b3JrIHRvby4NCj4NCj5UaGFua3MNCj5TcmluaQ0KPg0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Gcm9tOiBSZWluYWxkbyBQZW5ubyAocmVwZW5u bykgPHJlcGVubm9AY2lzY28uY29tPg0KPlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgNSwgMjAxNCA3 OjA4IEFNDQo+VG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IEpvZWwgTS4gSGFscGVybjsgJ3Nm Y0BpZXRmLm9yZycNCj5DYzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDANCj5TdWJqZWN0OiBS ZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPg0KPk9uIDEyLzUvMTQsIDY6NTQgQU0sICJT cmluaSBBZGRlcGFsbGkiIDxzYWRkZXBhbGxpQGZyZWVzY2FsZS5jb20+IHdyb3RlOg0KPg0KPj4N Cj4+SW4gcmVhbCBkZXBsb3ltZW50cywgbnVtYmVyIG9mIGFjdGl2ZSBwYXRoIElEcyBhcmUgdmVy eSBsZXNzZXIgdGhhbg0KPj4yXjY0LCBidXQgdGhlcmUgaXMgYSBnb29kIHBvc3NpYmlsaXR5IG9m IHRoZSBudW1iZXIgYmVpbmcgbW9yZSB0aGFuDQo+PjJeMjQgKDE2TSkuDQo+PiBJIHRoaW5rIGJp Z2dlciBwb2ludCBpcyB0aGF0IHdoeSByZXN0cmljdCB0aGlzIGluIHRoZSBzdGFuZGFyZHM/IFdo YXQNCj4+YWR2YW50YWdlIGRvIHdlIGhhdmUgcmVzdHJpY3RpbmcgdGhpcyBzaXplIHRvIDI0IGJp dHM/DQo+DQo+W1JQXSBEYXRhIHBsYW5lIGVmZmljaWVuY3kuIFdoZXJlIGRvIHdlIGRyYXcgdGhl IGxpbmU/IDMyLWJpdHMsDQo+NjQtYml0cywNCj4xMjggYml0cz8gSSB0aGluayB3ZSBzaG91bGQg aGF2ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRoZSBTZXJ2aWNlIFBhdGgNCj5oZWFkZXIgYW5kIGlm IHlvdSBuZWVkIHRvIGNvbnZleSBtb3JlIGJpdHMgeW91IG5lZWQgdG8gdXNlIHRoZSBjb250ZXh0 DQo+aGVhZGVycy4NCj4NCj4NCj4+DQo+PlRoZXJlIGNhbiBiZSBkZXBsb3ltZW50cywgd2hlcmUg U0ZDIGNvbnRyb2xsZXIgKExvZ2ljYWxseSBjZW50cmFsLCBidXQNCj4+ZGlzdHJpYnV0ZWQpICBp dHNlbGYgY2FuIGRvIHRoZSBTRiBpbnN0YW5jZSBzZWxlY3Rpb24gb24gcGVyDQo+PmNvbm5lY3Rp b24vc2Vzc2lvbiBiYXNpcywgdGhlcmVieSBhdm9pZGluZyB0aGUgTEJzIGZvciBzZXJ2aWNlcy4g ICBJbiBteQ0KPj52aWV3LCBhc3N1bXB0aW9uIHRoYXQgdGhlcmUgd2lsbCBiZSBMQiBTRiBmb3Ig ZWFjaCBzY2FsZS1vdXQgc2VydmljZQ0KPj5pbiB0aGUgY2hhaW4gaXMgbm90IHZhbGlkIGluIGFs bCBjYXNlcy4NCj4+DQo+PlRoYW5rcw0KPj5TcmluaQ0KPj4NCj4+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj5Gcm9tOiBSZWluYWxkbyBQZW5ubyAocmVwZW5ubykg PHJlcGVubm9AY2lzY28uY29tPg0KPj5TZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgNCwgMjAxNCAx OjE3IFBNDQo+PlRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47IHNm Y0BpZXRmLm9yZw0KPj5DYzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDANCj4+U3ViamVjdDog UmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4oaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+Pg0KPj5JZiBJIHVuZGVyc3Rvb2QgeW91 LCBJIGRvIG5vdCB0aGluayB0aGlzIGlzIHJlYWxpc3RpYy4gQXJlIHlvdSBzYXlpbmcNCj4+eW91 IG5lZWQgNjQtYml0cyBvZiBwYXRocyBhbmQgdGhlbiB3aWxsIG1vbml0b3IgdGhlbSBhbGw/IERv IGZhdWx0DQo+PnRvbGVyYW5jZSBhbmQgT0FNIGZvciAyXjY0LWJpdHMgd29ydGggb2YgcGF0aHM/ IEp1c3QgZm9yIGNvbXBhcmlzb24sDQo+Pml0wrlzIGxpa2UgbWFuYWdpbmcgYW5kIG1vbml0b3Jp bmcgdGhlIGVudGlyZSBJUHY2IGhvc3QgcmFuZ2UsIG9uZS1ieS1vbmUuDQo+Pg0KPj5Bbnl3YXks IEkgZG8gbm90IGV4cGVjdCBldmVyeSBzaW5nbGUgcGVybXV0YXRpb25zIHRvIGJlIGEgZGlmZmVy ZW50IHBhdGguDQo+Pg0KPj5JZiBlYWNoIHNlcnZpY2UgaGFzIDI1NiBkZXZpY2VzIHByb3ZpZGlu ZyBzaW1pbGFyIHNlcnZpY2UsIHlvdSBzaG91bGQNCj4+bW9zdCBsaWtlbHkgdXNlIGxvYWQtYmFs YW5jaW5nIGFuZCB0aGVuIHlvdSB3b3VsZCBoYXZlIGEgc2luZ2xlIChvciBhDQo+PmZldykgcGF0 aHMuIFRoZXJlIGlzIHNvbWUgZGlzY3Vzc2lvbiBnb2luZyBvbiBMQi4NCj4+DQo+PkZyb20gYSBk YXRhIHBsYW5lIHBlcnNwZWN0aXZlLCB0aGUgcGF0aCBpcyB1bHRpbWF0ZWx5IGRlZmluZWQgYnkg dGhlDQo+PlNGRnMgdHJhdmVyc2VkIGFuZCBzZXJ2aWNlcyBwcm92aWRlZCwgbm90IGJ5IGEgc3Bl Y2lmaWMgSVA6cG9ydCB0aGF0DQo+PnRoZSBkZXZpY2UgcHJvdmlkaW5nIHRoZSBzZXJ2aWNlIHNp dHMgb24uIFdlbGwsIGF0IGxlYXN0IGZyb20gYQ0KPj5HUEUrTlNIIHBlcnNwZWN0aXZlLg0KPj4N Cj4+DQo+Pk9uIDEyLzQvMTQsIDEyOjU3IFBNLCAiU3JpbmkgQWRkZXBhbGxpIiA8c2FkZGVwYWxs aUBmcmVlc2NhbGUuY29tPiB3cm90ZToNCj4+DQo+Pj5JZiBJIHRha2UgYSBjaGFpbiB3aXRoIDUg c2VydmljZXMgd2l0aCBlYWNoIHNlcnZpY2UgIHNheSBoYXZpbmcgMjU2DQo+Pj5pbnN0YW5jZXMg Zm9yIHNjYWxlLW91dCwgcG9zc2libGUgbnVtYmVyIG9mIHBhdGhzIGFyZQ0KPj4+MjU2KjI1Nioy NTYqMjU2KjI1NiA9IDB4RkYgRkYgRkYgRkYgRkYuIE9uZSByZXF1aXJlcyAzMyBiaXRzIGluIHRo aXMNCj4+PmNhc2UuICBJZiB0aGVyZSBhcmUgbW9yZSBzZXJ2aWNlcyBpbiB0aGUgY2hhaW4gb3Ig bW9yZSBjaGFpbnMgb3IgbW9yZQ0KPj4+aW5zdGFuY2VzIGZvciBzY2FsZS1vdXQsIHRoZW4gaXQg Y291bGQgZ28gdG8gYmlnIG51bWJlciB2ZXJ5IGZhc3QuDQo+Pj4NCj4+PkFzIEkgbWVudGlvbmVk IG15IHByZWZlcmVuY2UgaXMgdG8gbWFrZSB0aGUgcGF0aCBJRCBzaXplIGZsZXhpYmxlIGZvcg0K Pj4+ZnV0dXJlIGdyb3d0aC4gSWYgdGhhdCBpcyBwZXJjZWl2ZWQgYXMgY29tcGxleCwgdGhlbiBn b2luZyBmb3IgNjRiaXQNCj4+PmlzIHNhZmVyIGJldC4NCj4+Pg0KPj4+VGhhbmtzDQo+Pj5Tcmlu aQ0KPj4+DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBKb2Vs IE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPj4+U2VudDogVGh1cnNk YXksIERlY2VtYmVyIDA0LCAyMDE0IDEyOjA1IFBNDQo+Pj5UbzogQWRkZXBhbGxpIFNyaW5pLUIy MjE2MDsgSm9lbCBNLiBIYWxwZXJuOyBzZmNAaWV0Zi5vcmcNCj4+PkNjOiBOUyBTcmluaXZhc2Eg TXVydGh5LUIzNzg0MA0KPj4+U3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFm dA0KPj4+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAy KQ0KPj4+DQo+Pj5BIGNvbnRyb2xsZXIgKG9yIG90aGVyIGRlY2lzaW9uIGxvZ2ljKSBjYW4gY2Vy dGFpbmx5IGJlIGF3YXJlIG9mIHN1Y2gNCj4+PmNvbmNlcm5zLg0KPj4+QnV0IHRoZSBudW1iZXIg b2Ygc2VydmljZSBmdW5jdGlvbiBwYXRocyBpcyBub3QgcmVsYXRlZCB0byB0aGUgbnVtYmVyDQo+ Pj5vZiBmbG93cyBvciB0aGUgbnVtYmVyIG9mIHRlbmFudHMuICBJdCBpcyByZWxhdGVkIHRvIHRo ZSBudW1iZXIgb2YNCj4+PmNvbWJpbmF0aW9ucyBvZiBzZXJ2aWNlcyBhbmQgdGhlIHBvbGljaWVz IGZvciBzZXJ2aWNlIGZ1bmN0aW9uDQo+Pj5zZWxlY3Rpb24uDQo+Pj4gV2hpbGUgdGhhdCBjYW4g YmUgYSBsYXJnZSBudW1iZXIsIEkgc3VyZSBob3BlIGl0IGRvZXMgbm90IGNvbWUgY2xvc2UNCj4+ PnRvIHNhdHVyYXRpbmcgMjQgYml0cy4NCj4+Pg0KPj4+SGF2aW5nIHNhaWQgdGhhdCwgaWYgd2Ug dGhpbmsgdGhhdCAyNCBiaXRzIGlzIG9ubHkganVzdCBlbm91Z2gsIHRoZW4NCj4+PndlIG91Z2h0 IHRvIHVzZSAzMi4gIEZyb20gd2hlcmUgSSBzaXQsIEkgd291bGQgbm9ybWFsbHkgZXhwZWN0IDE2 DQo+Pj5iaXRzIHRvIGJlIG1vcmUgdGhhbiBzdWZmaWNpZW50LCB3aGljaCBpcyB3aHkgSSBhbSBj b21mb3J0YWJsZSB3aXRoIDI0Lg0KPj4+SGF2aW5nIHNhaWQgdGhhdCwgdGhlIGZpZWxkIHNpemUg aXMgbm90IGEgYmlnIGRlYWwgdG8gbWUuDQo+Pj4NCj4+PllvdXJzLA0KPj4+Sm9lbA0KPj4+DQo+ Pj5PbiAxMi80LzE0LCAyOjAxIFBNLCBTcmluaSBBZGRlcGFsbGkgd3JvdGU6DQo+Pj4+DQo+Pj4+ IEkgd2FzIG5vdCBpbXBseWluZyB0aGF0IHBhdGggSUQgc2hvdWxkIGhhdmUgaW5mb3JtYXRpb24g aW4gcmVnYXJkcw0KPj4+PnRvIHRlbmFudC9jb250cm9sbGVyL2Zsb3cvc2NhbGUtb3V0LiAgQnV0 IFNGQyBjb250cm9sbGVycyBzaG91bGQNCj4+Pj5rZWVwIHRoZXNlDQo+Pj4+aW4gbWluZCB0byBh c3NpZ24gdGhlIHBhdGggSUQuICAgIEEgZGVwbG95bWVudCBjYW4gaGF2ZSBtdWx0aXBsZQ0KPj4+ PnRlbmFudHMsIGVhY2ggdGVuYW50IGNhbiBoYXZlIG11bHRpcGxlIG5ldHdvcmtzLCAgdGhlcmUg Y291bGQgYmUNCj4+Pj5taWxsaW9ucyBvZiBmbG93cyBpbiBlYWNoIG9mIHRob3NlIG5ldHdvcmtz LiAgQW5kIGNvbnNpZGVyaW5nIGFsbA0KPj4+PnRoZXNlLA0KPj4+PiAyNCBiaXQgcGF0aCBJRCBt YXkgbm90IGJlIGFibGUgdG8gcmVwcmVzZW50IHBhdGhzIGZvciB0aGVzZSBmbG93cy4NCj4+Pj5I ZW5jZSwgSSB3YXMgd29uZGVyaW5nIHdoZXRoZXIgcGF0aCBJRCBjYW4gYmUgZXh0ZW5kZWQgdG8g NjQgYml0cyBvcg0KPj4+Pm1ha2UgaXQgZmxleGlibGUuDQo+Pj4+DQo+Pj4+IFRoYW5rcw0KPj4+ PiBTcmluaQ0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+IEZyb206IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+ Pj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDQsIDIwMTQgNzo0MiBBTQ0KPj4+PiBUbzogQWRk ZXBhbGxpIFNyaW5pLUIyMjE2MDsgc2ZjQGlldGYub3JnDQo+Pj4+IENjOiBOUyBTcmluaXZhc2Eg TXVydGh5LUIzNzg0MA0KPj4+PiBTdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERy YWZ0DQo+Pj4+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNj aC0wMikNCj4+Pj4NCj4+Pj4gVGhlIEluZGV4IGlzIG5vdCBqdXN0IGZvciBsb29wIHByZXZlbnRp b24uICBJbiB0aGUgY2FzZSBvZg0KPj4+PmFtYmlndWl0eSwgdGhlIGluZGV4IHRlbGxzIHRoZSBT RkYgd2hlcmUgaW4gdGhlIHBhdGggdGhlIHBhY2tldA0KPj4+PmN1cnJlbnRseSByZXNpZGVzLg0K Pj4+PiAgICBUaGVyZSBhcmUgbXVsdGlwbGUgd2F5cyBzdWNoIGFtYmlndWl0eSBjYW4gb2NjdXIu DQo+Pj4+DQo+Pj4+IFRoZSBQYXRoIElkZW50aWZpZXIgaXMgc3BlY2lmaWNhbGx5IG5vdCBleHBl Y3RlZCB0byBpbmNsdWRlDQo+Pj4+IGNvbnRyb2xsZXIgSUQgb3IgVGVuYW50IElELiAgV2hpbGUg YSBkZXBsb3llciBjYW4gaGF2ZSBhIHBhdGggcGVyDQo+Pj4+IHRlbmFudCwgdGhlIGFyY2hpdGVj dHVyZSBzdGlsbCBkb2VzIG5vdCB0cmVhdCB0aGUgcGF0aCBJRCBhcyBhDQo+Pj4+IHRlbmFudCBJ RC4gIFRlbmFudCBJRCwgY29udHJvbGxlciBJRCwgYW5kIG90aGVyIG5vbi1wYXRoLXNwZWNpZnlp bmcNCj4+Pj4gaW5mb3JtYXRpb24gaXMgdG8gYmUgY2FycmllZCBpbiBtZXRhZGF0YS4NCj4+Pj4N Cj4+Pj4gWW91cnMsDQo+Pj4+IEpvZWwNCj4+Pj4NCj4+Pj4gT24gMTIvNC8xNCwgMTA6MDIgQU0s IFNyaW5pIEFkZGVwYWxsaSB3cm90ZToNCj4+Pj4+IFR3byBjb21tZW50cyA6DQo+Pj4+Pg0KPj4+ Pj4NCj4+Pj4+IDEuICBTRiBJbmRleCA6ICBTaW5jZSBpdCBpcyBtZWFudCBmb3IgbG9vcCBkZXRl Y3Rpb24sICB3b3VsZG4ndA0KPj4+Pj4gYmV0dGVyIHRvIHJlbmFtZSB0aGlzIGFzICJUVEwiPw0K Pj4+Pj4NCj4+Pj4+IDIuICBQYXRoIElkZW50aWZpZXIgOiAgICAyNCBiaXQgcGF0aCBpZGVudGlm aWVyIHNlZW1zIHRvIGJlIHRvbyBsZXNzLg0KPj4+Pj4gQmFzZWQgb24gb3VyIGV4cGVyaWVuY2Ug aW4gdHJhZmZpYyBzdGVlcmluZywgIHRoaXMgcGF0aCBpZGVudGlmaWVyDQo+Pj4+Pm5lZWRzIHRv IGVuY29kZSBnb29kIGFtb3VudCBvZiBpbmZvcm1hdGlvbiB0byBtYWtlIGl0IHVuaXF1ZS4gIEZv cg0KPj4+Pj5leGFtcGxlLA0KPj4+Pj4gICAgdGhpcyBpZGVudGlmaWVyIG5lZWRzIHRvIGVuY29k ZSAoaW4gb3VyIGNhc2UpIHNvbWUgaW5mb3JtYXRpb24NCj4+Pj4+cmVwcmVzZW50aW5nIHRoZSBk aXN0cmlidXRlZCBjb250cm9sbGVyIElELCAgdGVuYW50IElELCAgZmxvdyBJRCwNCj4+Pj4+ICAg IFNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2UgKGluIGNhc2Ugb2Ygc2NhbGUtb3V0KSBhbmQgZmV3 IG1vcmUuLg0KPj4+Pj4gT25lIHN1Z2dlc3Rpb24gaXMgdG8gbWFrZSBpdCA2NCBiaXRzIHZhbHVl ICBvciB0byBtYWtlIGl0IGV2ZW4NCj4+Pj4+ZXh0ZW5kYWJsZSwNCj4+Pj4+ICAgIGl0IGlzIGdv b2QgaWYgcGF0aCBpZGVudGlmaWVyIGlzIGFsc28gcmVwcmVzZW50ZWQgaW4gVExWIGZvcm0uDQo+ Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFRoYW5rcw0KPj4+Pj4NCj4+Pj4+IFNyaW5pDQo+Pj4+Pg0KPj4+ Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0BpZXRmLm9y Zw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+ DQo+Pj4NCj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj5zZmMgbWFpbGluZyBsaXN0DQo+Pj5zZmNAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pg0KPg0KPg0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0Bp ZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zZmMgbWFp bGluZyBsaXN0DQo+c2ZjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMNCj4NCj4NCj5UaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyAodGhl ICJtZXNzYWdlIikgYXJlIGNvbmZpZGVudGlhbCwNCj5pbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBh ZGRyZXNzZWVzLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCj5yZWNpcGllbnQsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZQ0KPnRo aXMgbWVzc2FnZSBmcm9tIHlvdXIgc3lzdGVtLiBJbiB0aGlzIGNhc2UsIHlvdSBhcmUgbm90IGF1 dGhvcml6ZWQgdG8NCj51c2UsIGNvcHkgdGhpcyBtZXNzYWdlIGFuZC9vciBkaXNjbG9zZSB0aGUg Y29udGVudCB0byBhbnkgb3RoZXIgcGVyc29uLg0KPkUtbWFpbHMgYXJlIHN1c2NlcHRpYmxlIHRv IGFsdGVyYXRpb24uIE5laXRoZXIgUW9zbW9zIG5vciBhbnkgb2YgaXRzDQo+c3Vic2lkaWFyaWVz IG9yIGFmZmlsaWF0ZXMgc2hhbGwgYmUgbGlhYmxlIGZvciB0aGUgbWVzc2FnZSBpZiBhbHRlcmVk LA0KPmNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPg0KPkNlIG1lc3NhZ2UgZXQgdG91dGVzIHNlcyBw acOoY2VzIGpvaW50ZXMgKGNpLWFwcsOocyBsZSAibWVzc2FnZSIpc29udA0KPmNvbmZpZGVudGll bHMgZXQgw6l0YWJsaXMgw6AgbCdpbnRlbnRpb24gZXhjbHVzaXZlIGRlIHNlcyBkZXN0aW5hdGFp cmVzLg0KPlNpIHZvdXMgYXZleiByZcOndSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIG1lcmNpIGTi gJllbiBpbmZvcm1lcg0KPmltbcOpZGlhdGVtZW50IHNvbiDDqW1ldHRldXIgcGFyIGNvdXJyaWVy IMOpbGVjdHJvbmlxdWUgZXQgZOKAmWVmZmFjZXIgY2UNCj5tZXNzYWdlIGRlIHZvdHJlIHN5c3TD qG1lLiBEYW5zIGNldHRlIGh5cG90aMOoc2UsIHZvdXMgbuKAmcOqdGVzIHBhcw0KPmF1dG9yaXPD qSDDoCB1dGlsaXNlciwgY29waWVyIGNlIG1lc3NhZ2UgZXQvb3UgZW4gZGl2dWxndWVyIGxlIGNv bnRlbnUgw6ANCj51biB0aWVycy4gVG91dCBtZXNzYWdlIMOpbGVjdHJvbmlxdWUgZXN0IHN1c2Nl cHRpYmxlIGQnYWx0w6lyYXRpb24uDQo+UW9zbW9zIGV0IHNlcyBmaWxpYWxlcyBkw6ljbGluZW50 IHRvdXRlIHJlc3BvbnNhYmlsaXTDqSBhdSB0aXRyZSBkZSBjZQ0KPm1lc3NhZ2UgcydpbCBhIMOp dMOpIGFsdMOpcsOpLCBkw6lmb3Jtw6kgb3UgZmFsc2lmacOpLg0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0Bp ZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNClRo aXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzICh0aGUgIm1lc3NhZ2UiKSBhcmUgY29uZmlk ZW50aWFsLCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWVzLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGZyb20geW91ciBzeXN0ZW0u IEluIHRoaXMgY2FzZSwgeW91IGFyZSBub3QgYXV0aG9yaXplZCB0byB1c2UsIGNvcHkgdGhpcyBt ZXNzYWdlIGFuZC9vciBkaXNjbG9zZSB0aGUgY29udGVudCB0byBhbnkgb3RoZXIgcGVyc29uLiBF LW1haWxzIGFyZSBzdXNjZXB0aWJsZSB0byBhbHRlcmF0aW9uLiBOZWl0aGVyIFFvc21vcyBub3Ig YW55IG9mIGl0cyBzdWJzaWRpYXJpZXMgb3IgYWZmaWxpYXRlcyBzaGFsbCBiZSBsaWFibGUgZm9y IHRoZSBtZXNzYWdlIGlmIGFsdGVyZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpDZSBtZXNz YWdlIGV0IHRvdXRlcyBzZXMgcGnDqGNlcyBqb2ludGVzIChjaS1hcHLDqHMgbGUgIm1lc3NhZ2Ui KXNvbnQgY29uZmlkZW50aWVscyBldCDDqXRhYmxpcyDDoCBsJ2ludGVudGlvbiBleGNsdXNpdmUg ZGUgc2VzIGRlc3RpbmF0YWlyZXMuIFNpIHZvdXMgYXZleiByZcOndSBjZSBtZXNzYWdlIHBhciBl cnJldXIsIG1lcmNpIGTigJllbiBpbmZvcm1lciBpbW3DqWRpYXRlbWVudCBzb24gw6ltZXR0ZXVy IHBhciBjb3VycmllciDDqWxlY3Ryb25pcXVlIGV0IGTigJllZmZhY2VyIGNlIG1lc3NhZ2UgZGUg dm90cmUgc3lzdMOobWUuIERhbnMgY2V0dGUgaHlwb3Row6hzZSwgdm91cyBu4oCZw6p0ZXMgcGFz IGF1dG9yaXPDqSDDoCB1dGlsaXNlciwgY29waWVyIGNlIG1lc3NhZ2UgZXQvb3UgZW4gZGl2dWxn dWVyIGxlIGNvbnRlbnUgw6AgdW4gdGllcnMuIFRvdXQgbWVzc2FnZSDDqWxlY3Ryb25pcXVlIGVz dCBzdXNjZXB0aWJsZSBkJ2FsdMOpcmF0aW9uLiBRb3Ntb3MgZXQgc2VzIGZpbGlhbGVzIGTDqWNs aW5lbnQgdG91dGUgcmVzcG9uc2FiaWxpdMOpIGF1IHRpdHJlIGRlIGNlIG1lc3NhZ2UgcydpbCBh IMOpdMOpIGFsdMOpcsOpLCBkw6lmb3Jtw6kgb3UgZmFsc2lmacOpLg0K From nobody Sun Feb 1 12:21:34 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3621A8A5F for ; Sun, 1 Feb 2015 12:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TRACKER_ID=1.306] 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 5tihJ_ktGov6 for ; Sun, 1 Feb 2015 12:21:27 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0116.outbound.protection.outlook.com [65.55.169.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F9391A1AF4 for ; Sun, 1 Feb 2015 12:21:27 -0800 (PST) Received: from DM2PR0301MB0861.namprd03.prod.outlook.com (25.160.215.147) by DM2PR0301MB0621.namprd03.prod.outlook.com (25.160.95.25) with Microsoft SMTP Server (TLS) id 15.1.75.20; Sun, 1 Feb 2015 20:21:26 +0000 Received: from DM2PR0301MB0862.namprd03.prod.outlook.com (25.160.215.148) by DM2PR0301MB0861.namprd03.prod.outlook.com (25.160.215.147) with Microsoft SMTP Server (TLS) id 15.1.65.19; Sun, 1 Feb 2015 20:21:24 +0000 Received: from DM2PR0301MB0862.namprd03.prod.outlook.com ([25.160.215.148]) by DM2PR0301MB0862.namprd03.prod.outlook.com ([25.160.215.148]) with mapi id 15.01.0065.013; Sun, 1 Feb 2015 20:21:24 +0000 From: Srini Addepalli To: Sumandra Majee , Nicolas BOUTHORS , Cathy Zhang , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZx/klKAgAA1pTGAABNtAIAADGxAgAAH7ICAASQ+x4AAByMAgAABINiAAEx9AIBWb4+AgAEKegCAALysgIAC8PdA Date: Sun, 1 Feb 2015 20:21:23 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.88.158.1] authentication-results: F5.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0861;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0861; x-forefront-prvs: 04740D25F1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(479174004)(164054003)(53754006)(24454002)(13464003)(52314003)(377454003)(54206007)(76176999)(50986999)(19580395003)(54606007)(54356999)(230783001)(46102003)(19580405001)(99286002)(92566002)(86362001)(2656002)(87936001)(561944003)(33656002)(77156002)(62966003)(66066001)(74316001)(76576001)(40100003)(106116001)(102836002)(15975445007)(122556002)(2900100001)(2950100001)(491001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0861; H:DM2PR0301MB0862.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2015 20:21:23.9104 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0861 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0621; X-OriginatorOrg: freescale.com Archived-At: Cc: "nsmurthy@freescale.com" , Jerome TOLLET , Rajesh Kumar Madabushi , Bharat Mota Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 01 Feb 2015 20:21:31 -0000 SGkgU3VtYW5kcmEsDQoNCkkgYWdyZWUgd2l0aCB5b3UgdGhhdCBtb3JlIGluZm9ybWF0aW9uIGNh biBiZSBhZGRlZCB0byB0aGUgcHJvdG9jb2wgZG9jdW1lbnQgb24gc29tZSB1c2UgY2FzZSBzY2Vu YXJpb3MgdG8gbWFrZSBpdCBjbGVhciBvbiB0aGUgdXNhZ2Ugb2YgUlNQLUlEIGFuZCBQYXRoLUlE Lg0KDQpKdXN0IHRvIG1ha2UgdGhlIHJlYWxpc3RpYyBhbmQgY29tcGxleCBzY2VuYXJpbw0KDQpJ bmdyZXNzU0ZGLS0tLS1TRkYxLS0tLS1TRkYyLS0tLS1FZ3Jlc3NTRkYNCg0KSW4gdmlydHVhbCB3 b3JsZCwgU0ZGMSBjb3VsZCBiZSBmcm9udGVuZGluZyBTRngtMSwgU0Z4LTIsIFNGeS0xIGFuZCBT RkYyIGNvdWxkIGJlIGZyb250IGVuZGluZyBTRngtMywgU0Z5LTIsIFNGei0xDQpGb3Igc2ltcGxp Y2l0eSwgYXNzdW1lIHRoYXQgSW5ncmVzc1NGRiBpcyBhIGVkZ2Ugcm91dGVyIChlZy4gT3BlbnN0 YWNrIE5ldHdvcmsgTm9kZSkNCkVncmVzc1NGRiBpcyBhIHZpcnR1YWwgc3dpdGNoIGhvc3Rpbmcg c2V0IG9mIFdlYiBTZXJ2ZXIgVk1zLg0KU0ZGMSBhbmQgU0ZGMiBhcmUgYWxzbyB2aXJ0dWFsIHN3 aXRjaGVzIGhvc3RpbmcgU0Z4LCBTRnkgYW5kIFNGeiBTZXJ2aWNlIFZNcy4NCg0KQXNzdW1pbmcg dGhhdCBjaGFpbiByZXF1aXJlcyBwYWNrZXRzIGdvIHRvIFNGeCwgU0Z5IGFuZCBTRnosICBJbmdy ZXNzU0ZGICh3aXRoIHRoZSBoZWxwIG9mIFNGRiBjb250cm9sbGVyKSBuZWVkcyBzZW5kIHRoZSB0 cmFmZmljIHRvIG9uZSBvZiBTRngtMSwgU0Z4LTIgYW5kIFNGeC0zLiBCYXNlZCBvbiBTRi14IHNl bGVjdGlvbiwgaW5ncmVzcyBTRkYgc2VuZHMgdGhlIHRyYWZmaWMgdG8gY29ycmVzcG9uZGluZyBT RkYuICBJZiBTRngtMSBvciBTRngtMiBpcyBjaG9zZW4sIHRoZW4gdGhlIHRyYWZmaWMgaXMgc2Vu dCB0byBTRkYxLiAgSWYgU0Z4LTMgaXMgY2hvc2VuLCB0aGVuIHRoZSB0cmFmZmljIGlzIHNlbnQg dG8gdGhlIFNGRjIuIE5leHQgaW4gdGhlIGNoYWluLCBzZWxlY3Rpb24gbmVlZHMgdG8gaGFwcGVu IGJldHdlZW4gU0Z5MSBhbmQgU0Z5Mi4gIFNpbWlsYXJseSBmb3IgbmV4dCBzZXJ2aWNlIGluIHRo ZSBjaGFpbiwgICBlaXRoZXIgU0ZGMSBvciBTRkYyICh3aXRoIHRoZSBoZWxwIG9mIGNvbnRyb2xs ZXIpIHdpbGwgc2VuZCB0aGUgdHJhZmZpYyB0byBTRi15LiBJdCBkb2VzIHRoaXMgYnkgc2VuZGlu ZyB0aGUgdHJhZmZpYyB0byBTRkYyIHRoYXQgaXMgaG9zdGluZyB0aGUgU0Ytei4gQW5kIGZpbmFs bHkgdHJhZmZpYyBuZWVkcyB0byBnbyB0byBFZ3Jlc3NTRkYgdG8gZGVsaXZlciB0byBkZXN0aW5h dGlvbiB3ZWItc2VydmVyIFZNLg0KDQpFc3NlbnRpYWxseSwgYSBnaXZlbiBTRkYgd291bGQgbmVl ZCB0byBiZSBwcm9ncmFtbWVkIHdpdGggdGhlIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gbmV4dCBT Ri4gIFRoYXQgaXMgd2hlcmUgcGF0aCBJRCwgUlNQLUlEIGFuZCBPdmVybGF5IG5ldHdvcmtzIHdv dWxkIGhlbHAgLSBQYXRoIElEIGluZGljYXRpbmcgdGhlIGNoYWluIGFuZCBSU1AtSUQgaW5kaWNh dGluZyB0aGUgU0YgaW5zdGFuY2UgQU5EICBWeExBTiBkZXN0aW5hdGlvbiBJUCBpbmRpY2F0aW5n IHRoZSBuZXh0IFNGRi4gU0ZGIENvbnRyb2xsZXIgaGF2aW5nIHRoZSBuZXR3b3JrIHdpZGUgdmlz aWJpbGl0eSB3b3VsZCBwcm9ncmFtIHRoZSBTRkZzIGFwcHJvcHJpYXRlbHkuIA0KDQpGb3IgZXhh bXBsZSwgb24gaW5ncmVzc1NGRiwgZmxvd3MgYXJlIHByb2dyYW1tZWQgd2l0aCBSU1AtSUQgcmVs YXRlZCB0byBTRnggc2VydmljZSBpbnN0YW5jZXMuICBJbmdyZXNzU0ZGLCBhcyBwYXJ0IG9mIHBh Y2tldCBwcm9jZXNzaW5nLCBhZGRzIHRoZSBSU1AtSUQsIFBhdGhfSUQgdG8gdGhlIFNDSCBoZWFk ZXIgYW5kIGVuY2Fwc3VsYXRlcyBpbiBWeExBTi4gIFNGRjEgYW5kL29yIFNGRjIgYXJlIHByb2dy YW1tZWQgd2l0aCBmbG93cyB0aGF0IG1hdGNoIG9uIFBBVEgtSUQgYW5kIFJTUC1JRCB0byBzZW5k IHRoZSB0cmFmZmljIHRvIHJpZ2h0IFNGeCBpbnN0YW5jZS4gRXNzZW50aWFsbHksIHByZXZpb3Vz IFNGRiBhZGRzIHRoZSBTQ0ggaGVhZGVyIHJlbGF0ZWQgdG8gbmV4dCBTRiBpbnN0YW5jZXMgYW5k IGhvc3RpbmcgU0ZGIHVzZXMgdGhhdCBpbmZvcm1hdGlvbiB0byByb3V0ZSB0aGUgdHJhZmZpYyB0 byByaWdodCBTRiBpbnN0YW5jZS4NCg0KT24geW91ciBjb25jZXJuIGFib3V0IHBvb3Igc2NhbGFi aWxpdHkgOiAgU0ZGIGNvbnRyb2xsZXIgbmVlZCBub3QgYmUgYSBzaW5nbGUgZW50aXR5LiAgSXQg Y291bGQgYmUgZGlzdHJpYnV0ZWQgYW5kIHNjYWxlLW91dCBlbnRpdHkgZm9yIHBlcmZvcm1hbmNl IHNjYWxpbmcuICAgQWxzbywgY29udHJvbGxlcnMgbmVlZCBub3QgYmUgaW5mb3JtZWQgb2YgZXZl cnkgZmluZSBncmFudWxhciBmbG93LiBJdCBjb3VsZCBiZSBiYXNlZCBvbiA0LXR1cGxlIG9yIDMt dHVwbGUgZmxvd3MsIHRoZXJlYnkgcmVkdWNpbmcgdGhlIG51bWJlciBvZiBkZWNpc2lvbnMgbG9n aWNhbCBjb250cm9sbGVyIG5lZWQgdG8gbWFrZS4gIA0KDQpJIGRpZCBub3QgdW5kZXJzdGFuZCAg eW91ciBjb25jZXJuIG9uICIgVGhlIGFtb3VudCBvZiBzdGF0ZSwgcHJvYmFiaWxpdHkgb2YgYSBp bnN0YW5jZSBnb2luZyBkb3duIGJldHdlZW4gc2VsZWN0aW9uIGFuZCBmbG93IGFycml2YWwgZ29l cyB1cC4iICBUaGlzIHNlZW1zIHRvIGJlIGltcG9ydGFudCBhbmQgY2FuIHlvdSBlbGFib3JhdGU/ DQoNCg0KVGhhbmtzDQpTcmluaQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3VtYW5k cmEgTWFqZWUNClNlbnQ6IEZyaWRheSwgSmFudWFyeSAzMCwgMjAxNSAyOjUzIFBNDQpUbzogTmlj b2xhcyBCT1VUSE9SUzsgQ2F0aHkgWmhhbmc7ICdzZmNAaWV0Zi5vcmcnDQpDYzogSmVyb21lIFRP TExFVA0KU3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdCAoaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQoNCkhlbGxvLA0KDQpU aGlzIGlzIGFuIGludGVyZXN0aW5nIGRpc2N1c3Npb24gYW5kIEkgd291bGQgbGlrZSB0byB1bmRl cnN0YW5kIHRoZSBtb3RpdmF0aW9uIG9mIGJldHRlci4gVGhlIHRyb3VibGUgd2l0aCBhIHByb3Rv Y29sIGRvY3VtZW50IGlzIHRoYXQgaXQgaXMgdHlwaWNhbGx5IGhhcyBpbmFkZXF1YXRlIGRldGFp bCBhYm91dCB0aGUgbG9naWMuIFNvIHRvIGNhc3QgdGhpcyBpbnRvIHNvbWV3aGF0IG9mIGEgY29u Y3JldGUgdGVybXMsIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcuDQoNCg0KICAgIA0KICAgICAgIFNG Rih4KSAgeyBTZngoMSkgU2Z4KDIp4oCmU2Z4KG4pIH0gICDigJTigJTigJTigJQ+ICAgU0ZGKHkp IHsgU2Z5KDEpIFNmeSgyKQ0K4oCmLiBTZnkobSkgfSAgIDo6IExvZ2ljYWwgQ2hhaW4gaW4gT05F IGRpcmVjdGlvbiBvbmx5Lg0KICAgICAgIA0KICAgICAgIFBIWVNJQ0FMIFdPUkxEOg0KICAgICAg ICAgIEEpIHRoZSBTRkYgY291bGQgYmUgYQ0KICAgICAgICAgICAgLSBjb21wb25lbnQgb2YgVlNX SVRDSCAocGljayB5b3VyIGZhdiBwcm90b2NvbCBmb3IgY29uZmlndXJpbmcgdGhvc2UgZW50aXRp ZXMgfQ0KICAgICAgICAgICAgLSBBIGxvYWQgYmFsYW5jZXINCiAgICAgICAgICAgIC0gQSBIVyBz d2l0Y2gvcm91dGVyIHNvbWUgTDIvTDMgY29tYm8NCg0KICAgICAgICAgIEIpIFNmIGluc3RhbmNl IGNvdWxkIGJlLA0KICAgICAgICAgICAgICAgLSBWaXJ0dWFsIG1hY2hpbmUsICNOIG9mIHRob3Nl DQogICAgICAgICAgICAgICAtIHBoeXNpY2FsDQogICAgICAgICAgICAgICAtIENvbnRhaW5lciAj TSB3aGljaCBpcyBvZnRlbiA1IG9yIG1vcmUgeCAjTg0KICAgICAgICAgICAgICAgLSBDbHVzdGVy IHRoYXQgd2UgZG9u4oCZdCBrbm93DQoNCkl0IGlzIHBvc3NpYmxlIHRvIGhhdmUgbXVsdGlwbGUg cGh5c2ljYWwgU0ZGKHgpIGFsc28uDQoNCkEgc2VsZWN0aW9uIG9mIGEgZ2l2ZW4gU0YgKHNlcnZp Y2UpKGluc3RhbmNlKSBpcyBhIGNhbiBiZSBzaW1wbGUgb3IgY29tcGxleC4gRm9yIGV4YW1wbGUg U0ZGKHgpIG1heSBoYXZlIHRoZSBiZXN0IGtub3dsZWRnZSB0byBzZWxlY3QgU2Z4KDEpIGJhZWQg b24gYSBnaXZlbiBjcml0ZXJpb24gKHdoaWNoIGNvdWxkIGJlIHBhcnQgb2YgdGhlIHBvbGljeSku ICBUaGVuIEkgZG9u4oCZdCBzZWUgYSByZWFzb24gdG8gaGF2ZSBSU1AuDQoNCkl0IGlzIHBvc3Np YmxlIHRoYXQgbG9va3VwIChwYXRoKSBAIFNGRih4KSBwcm9kdWNlcyBhIHNwZWNpZmljIGluc3Rh bmNlIG9mIFNmeSBhbmQgeWVzIHRoZW4gc29tZXRoaW5nIGxpa2UgUlNQIHdvdWxkIGJlIHJlcXVp cmVkLiBCdXQgSSB3b3VsZCBhcmd1ZSB0aGF0IGpvYiBTRkYoeSkgY2FuIGFsc28gYmUgc3Vic3Vt ZWQgYnkgU0ZGKHgpLg0KDQpJcyBpdCBwb3NzaWJsZSBmb3IgYSBjZW50cmFsIGNvbnRyb2xsZXIg dG8gcGljayBlYWNoIGluc3RhbmNlIG9mIHNlcnZpY2UsIGJ1dCBzdWNoIGFuIGltcGxlbWVudGF0 aW9uIHRlbmRzIHRvIHNjYWxlIHBvb3JseS4gVGhlIGFtb3VudCBvZiBzdGF0ZSwgcHJvYmFiaWxp dHkgb2YgYSBpbnN0YW5jZSBnb2luZyBkb3duIGJldHdlZW4gc2VsZWN0aW9uIGFuZCBmbG93IGFy cml2YWwgZ29lcyB1cC4gDQoNClJlZ2FyZHMuDQoNClN1bWFuZHJhDQoNCg0KDQpPbiAxLzMwLzE1 LCAzOjM4IEFNLCAiTmljb2xhcyBCT1VUSE9SUyIgPE5pY29sYXMuQk9VVEhPUlNAcW9zbW9zLmNv bT4NCndyb3RlOg0KDQo+SGVsbG8gQ2F0aHksDQo+DQo+SW5kZWVkIHRoZSBub3Rpb24gb2YgInJl bmRlcmVkIHNlcnZpY2UgcGF0aCBJRCIoUlNQIElEKSBzZWVtcyByZWxldmFudCANCj5hcyB0aGUg YXJjaGl0ZWN0dXJlIGRvY3VtZW50IHN0aXB1bGF0ZXMgdGhhdCB0aGUgU2VydmljZSBGdW5jdGlv biBQYXRoIA0KPihTRlApIHByb3ZpZGVzIGFuIGFic3RyYWN0IG5vdGlvbiBvZiBhIHNlcnZpY2Ug Y2hhaW4sIHdoaWxlIHRoZSBSU1AgaXMgDQo+YSBjb25zdHJhaW5lZCBsaXN0IG9mIGxvY2F0aW9u cy4NCj4NCj5TRkMgaGVhZGVyICJTZXJ2aWNlIFBhdGggSWRlbnRpZmllciIgKFNQSSkgIGlzIHVz ZWQgaW4gYm90aCBOU0ggYW5kIFNDSCANCj5wcm90b2NvbCBhbmQgaW4gYm90aCBjYXNlIHNlZW0g dG8gaWRlbnRpZnkgdG8gYSBwYXJ0aWN1bGFyIFNGUC4NCj4NCj5OU0godjUpIGZvciBleGFtcGxl IHN0YXRlcyB0aGF0DQo+IiBBcyBkZXNjcmliZWQgYWJvdmUsIE5TSCBjb250YWlucyBhIHNlcnZp Y2UgcGF0aCBpZGVudGlmaWVyIChTUEkpIGFuZA0KPiAgIGEgc2VydmljZSBpbmRleCAoU0kpLiAg VGhlIFNQSSBpcywgYXMgcGVyIGl0cyBuYW1lLCBhbiBpZGVudGlmaWVyLg0KPiAgIFRoZSBTUEkg YWxvbmUgY2Fubm90IGJlIHVzZWQgdG8gZm9yd2FyZCBwYWNrZXRzIGFsb25nIGEgc2VydmljZSBw YXRoLg0KPiAgIFJhdGhlciB0aGUgU1BJIHByb3ZpZGUgYSBsZXZlbCBvZiBpbmRpcmVjdGlvbiBi ZXR3ZWVuIHRoZSBzZXJ2aWNlDQo+ICAgcGF0aC90b3BvbG9neSBhbmQgdGhlIHRoZSBuZXR3b3Jr IHRyYW5zcG9ydC4gIEZ1cnRoZXJtb3JlLCB0aGVyZSBpcw0KPiAgIG5vIHJlcXVpcmVtZW50LCBv ciBleHBlY3RhdGlvbiBvZiBhbiBTUEkgYmVpbmcgYm91bmQgdG8gYSBwcmUtDQo+ICAgZGV0ZXJt aW5lZCBvciBzdGF0aWMgbmV0d29yayBwYXRoLiINCj4NCj5TdGlsbCBOU0godjUpICBzaG93cyB0 aGF0IFNQSSAobm90IGEgUlNQIElEKSAgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGtleSANCj5lbGVt ZW50IG9mIGFuIFNGRiB0byBsb29rdXAgb24gZm9yd2FyZGluZyB0YWJsZXMuICBCdXQgSSBjb3Vs ZCBub3QgZmluZCANCj5pbiBOU0ggIGhvdyB0byB1c2UgdGhlIG5vdGlvbiBvZiBSZW5kZXJlZCBz ZXJ2aWNlIHBhdGggd2hpY2ggd2FzIA0KPmRlZmluZWQgaW4gdGhlIGFyY2hpdGVjdHVyZSBkb2N1 bWVudC4NCj4NCj5Zb3UgcHJvcG9zYWwgc2VlbXMgdG8gbWUgdmVyeSB1c2VmdWwsDQo+DQo+QW4g UlNQIElEIChpbmRlcGVuZGVudCBvZiB0aGUgU1BJIGJ1dCBwYXJ0IG9mIHRoZSBzYW1lIG5hbWUg c3BhY2UpIA0KPmNvdWxkIGJlIHVzZWQgdGhlIHNhbWUgd2F5IGFzIFNQSSBieSBTRkYgZm9yIGV4 YW1wbGUsIGFsbG93aW5nIGEgDQo+U2VydmljZSBDbGFzc2lmaWVyIHRvIGNvbnRyb2wgcmVtb3Rl IGxvYWQgYmFsYW5jaW5nIGZvciBleGFtcGxlLg0KPg0KPlRoaXMgc2FpZCB0aGUgUlNQIElEIHZh bHVlcyBjb3VsZCBiZSByZWxhdGl2ZSB0byBhIHBhcnRpY3VsYXIgU2VydmljZSANCj5QYXRoLCB3 aGljaCB3b3VsZCBwcmV2ZW50IHVzaW5nIHRoZW0gYXMgd2UgZG8gZm9yIFNQSSBpbiBTRkYgZm9y d2FyZGluZyANCj50YWJsZXMuDQo+DQo+V2UgbWF5IHdhbnQgdG8gcHJlY2lzZSBpZiB0aGUgUlNQ IElEIGlzIHRvIGJlIHJlbGF0aXZlIG9mIGFic29sdXRlLCBhcyANCj5pdCBzaG91bGQgaGF2ZSBh biBpbXBhY3Qgb24gZm9yd2FyZGluZyB0YWJsZSBzdHJ1Y3R1cmUgaWYgd2UgZGVjaWRlIHRvIA0K PnVzZSB0aGlzIGNvbmNlcHQuDQo+DQo+UGVyc29uYWxseSBJIGxpa2UgdGhlIG5vdGlvbiBvZiBh IHJlbGF0aXZlIFJTUCBJRCwgYXMgd2UgY291bGQgdGhlbiB1c2UgDQo+c29tZSBjb252ZW50aW9u cywgc3RydWN0dXJlIGl0LCBwb3NzaWJseSBleHRlbmRpbmcgaXRzIHVzZS4NCj4NCj5OaWNvbGFz DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBDYXRoeSBaaGFuZyBbbWFp bHRvOkNhdGh5LkguWmhhbmdAaHVhd2VpLmNvbV0NCj5TZW50OiBqZXVkaSAyOSBqYW52aWVyIDIw MTUgMjA6NDQNCj5UbzogQ2F0aHkgWmhhbmc7IFNyaW5pIEFkZGVwYWxsaTsgUmVpbmFsZG8gUGVu bm8gKHJlcGVubm8pOyBKb2VsIE0uDQo+SGFscGVybjsgJ3NmY0BpZXRmLm9yZycNCj5DYzogbnNt dXJ0aHlAZnJlZXNjYWxlLmNvbQ0KPlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0gg RHJhZnQNCj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gt MDIpDQo+DQo+SGkgZXZlcnlvbmUsDQo+DQo+V2UgaGF2ZSB1cGxvYWRlZCBhIG5ldyBTQ0ggdmVy c2lvbiAoMykgd2hpY2ggYWRkcyBkZWZpbml0aW9uIG9mIGEgbmV3IA0KPm1ldGFkYXRhIHR5cGUg Zm9yIHRoZSBmbG93IElEIHRvIHN1cHBvcnQgbG9hZCBiYWxhbmNpbmcgYW1vbmcgU0YgDQo+aW5z dGFuY2VzIGFuZCBtaXRpZ2F0ZSB0aGUgcG90ZW50aWFsIGlzc3VlIG9mICJub3QgZW5vdWdoIHBh dGggSUQiLiBUaGUgDQo+ZmxvdyBJRCBpcyBuYW1lZCAicmVuZGVyZWQgc2VydmljZSBwYXRoIElE IiBpbiB0aGUgZHJhZnQuIFBsZWFzZSByZWZlciANCj50byBzZWN0aW9uIDQuMy4yIG9mIA0KPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLXNmYy1zY2gvDQo+Zm9y IGRldGFpbCBkZXNjcmlwdGlvbi4NCj4NCj5JbiBpdHMgcHJldmlvdXMgdmVyc2lvbiwgU0NIIGRl ZmluZXMgYSAiQnlwYXNzIGJpdCIgaW4gdGhlIGJhc2UgaGVhZGVyLg0KPlRoaXMgYml0IGVuYWJs ZXMgdGhlIFNGIHRvIHByb3ZpZGUgZmVlZGJhY2svbm90aWZpY2F0aW9uIHZpYSB0aGUgZGF0YSAN Cj5wYXRoIHRvIGl0cyBjb25uZWN0aW5nIFNGRiBhYm91dCB3aGV0aGVyIHRoZSByZW1haW5pbmcg cGFja2V0cyBvZiB0aGUgDQo+U0ZDIHNob3VsZCBieXBhc3MgdGhhdCBTRi4gVGhpcyBpcyB1c2Vm dWwgaW4gdGhlIGNhc2UgdGhhdCBvbmx5IHRoZSANCj5maXJzdCBmZXcgcGFja2V0cyBvZiBhIGZs b3cgbmVlZCB0byBnbyB0byBhIFNGIChzdWNoIGFzIGEgRFBJIG9yIEZXIG9yIA0KPklEUykgYW5k IHJlbWFpbmluZyBwYWNrZXRzIGNhbiBieXBhc3MgdGhhdCBTRiwgdGh1cyBzYXZpbmcgdGhlIA0K PmV4cGVuc2l2ZSBTRiByZXNvdXJjZSBhbmQgcmVkdWNpbmcgZGF0YSBwYXRoIGxhdGVuY3kuDQo+ DQo+QiBiaXQ6IFRoZSBCIChCeXBhc3MpIGJpdCwgd2hlbiBzZXQgdG8gMSwgaXQgaXMgdXNlZCBi eSBhIFNlcnZpY2UNCj4gICAgICAgRnVuY3Rpb24gdG8gc2lnbmFsIHRvIGl0cyBTZXJ2aWNlIEZ1 bmN0aW9uIEZvcndhcmRlciB0aGF0IG5vDQo+ICAgICAgIGZ1cnRoZXIgcGFja2V0cyBhcmUgdG8g YmUgc2VudCB0byBpdCBmb3IgdGhlIGZsb3cgc3BlY2lmaWVkIGluIA0KPmVuY2Fwc3VsYXRlZCBw YWNrZXQuDQo+DQo+SW4gYWRkaXRpb24sIFNDSCBkZWZpbmVzIGEgbWV0YWRhdGEgdHlwZSBmb3Ig R2VuZXJpYyBDb250ZXh0IEJsb2NrLCANCj53aGljaCBpcyBvcHRpb25hbCBhbmQgY2FuIGJlIHVz ZWQgaWYgbmVlZGVkIHRvIGNhcnJ5IGFueSB2ZW5kb3IncyANCj5zcGVjaWZpYyAiQ29udGV4dCBI ZWFkZXIiLg0KPg0KPkFueSBjb21tZW50cyBvbiB0aGVzZSBuZXcgYWRkaXRpb25zPw0KPg0KPlRo YW5rcywNCj5DYXRoeQ0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogc2Zj IFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDYXRoeSBaaGFuZw0K PlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDUsIDIwMTQgMTE6NDcgQU0NCj5UbzogU3JpbmkgQWRk ZXBhbGxpOyBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4gSGFscGVybjsgDQo+J3Nm Y0BpZXRmLm9yZycNCj5DYzogbnNtdXJ0aHlAZnJlZXNjYWxlLmNvbQ0KPlN1YmplY3Q6IFJlOiBb c2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+DQo+Um9uLCBMb3VpcywgTXlvIGFuZCBJIGhhdmUg YmVlbiBkaXNjdXNzaW5nIG9mZiBsaW5lIGxhc3QgZmV3IHdlZWtzIA0KPmFib3V0IGRlZmluaW5n IGEgbWV0YWRhdGEgdHlwZSBmb3IgZmxvdyBJRCBpbiBhZGRpdGlvbiB0byB0aGUgcGF0aCBJRCAN Cj5vZiB0aGUgbWFpbiBoZWFkZXIgdG8gc3VwcG9ydCBsb2FkIGJhbGFuY2luZyBhbW9uZyBTRiBp bnN0YW5jZXMuIFdlIA0KPndpbGwgZGVmaW5lIGEgVExWIHR5cGUgZm9yIHRoZSBmbG93IElELiBU aGUgY29tYmluYXRpb24gb2YgInBhdGggSUQgKyBmbG93IElEIg0KPnNwZWNpZmllcyBhIHJlYWxp emVkIHNlcnZpY2UgY2hhaW4gaW5zdGFuY2UgcGF0aC4gSXQgaXMgbGVmdCB0byB0aGUgDQo+ZGVz aWduL2ltcGxlbWVudGF0aW9uIHdoZXRoZXIgdG8gdXNlIGEgY2VudHJhbGl6ZWQgbWV0aG9kIG9y IGEgDQo+ZGlzdHJpYnV0ZWQgbWV0aG9kIHRvIGJpbmQgdGhlIGZsb3cgSUQgdG8gYSByZWFsaXpl ZCBzZXJ2aWNlIGluc3RhbmNlIA0KPnBhdGggYWx0aG91Z2ggb3VyIG9yaWdpbmFsIHRob3VnaHQg aXMgZm9yIGRpc3RyaWJ1dGVkIExCIHVzYWdlLiBJIGFtIA0KPm5vdCBzdXJlIGlmIHdlIG5lZWQg YSBiaXQgaW4gdGhlIGhlYWRlciB0byBkZW5vdGUgd2hldGhlciB0aGVyZSBhcmUgDQo+bW9yZSBw YXRoIElEIGJpdHMgKHdlIGNhbGwgaXQgZmxvdyBJRCkgaW4gdGhlIG1ldGFkYXRhIGZpZWxkcyBz aW5jZSANCj53aGVuIHlvdSBwYXJzZSB0aGUgVExWIG1ldGFkYXRhLCB5b3Ugd2lsbCBrbm93IHdo ZXRoZXIgdGhlcmUgYXJlIGZsb3cgSUQgYml0cyBvciBub3QuDQo+Tm90ZSB0aGF0IGlmIG11bHRp cGxlIHNlc3Npb25zIHNoYXJlIHRoZSBzYW1lIHJlYWxpemVkIHNlcnZpY2UgaW5zdGFuY2UgDQo+ cGF0aCwgdGhleSB3aWxsIHNoYXJlIHRoZSBzYW1lICJwYXRoIElEKyBmbG93IElEIi4gIFdlIGNh biBhbHNvIA0KPmNvbnNpZGVyIGV4dGVuZGluZyB0aGUgbnVtYmVyIG9mIGJpdHMgdG8gMzIgaWYg dGhhdCBpcyB0aGUgY29uc2Vuc3VzLiANCj5XZSB3aWxsIHBvc3QgYW4gdXBkYXRlZCBkcmFmdCBk ZXNjcmliaW5nIHRoZXNlIHNvb24uDQo+DQo+VGhhbmtzLA0KPkNhdGh5DQo+DQo+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIFNyaW5pIEFkZGVwYWxsaQ0KPlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIg MDUsIDIwMTQgNzoxNyBBTQ0KPlRvOiBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4g SGFscGVybjsgJ3NmY0BpZXRmLm9yZycNCj5DYzogbnNtdXJ0aHlAZnJlZXNjYWxlLmNvbQ0KPlN1 YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4oaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+DQo+DQo+W1JQXSBEYXRhIHBs YW5lIGVmZmljaWVuY3kuDQo+DQo+U1JJTkk+IEkgYW0gbm90IHNvIHN1cmUgYWJvdXQgZGF0YSBw bGFuZSBlZmZpY2llbmN5LiAgTW9zdCBvZiB0aGUNCj5wcm9jZXNzb3JzIHdvcmsgZ29vZCBpZiB0 aGUgbnVtYmVyIG9mIGJpdHMgYXJlIGVpdGhlciAzMiBvciA2NC4gIElmIGl0IA0KPmlzDQo+MjQg Yml0cywgdGhlbiBvbmUgbmVlZHMgdG8gZG8gbWFza2luZyBhbmQgc2hpZnRpbmcgYmVmb3JlIHRo ZSB2YWx1ZSBpcw0KPnVzZWQgdG8gZG8gYW55IGxvb2t1cC4gICBCdXQsIHRoaXMgZGlzY3Vzc2lv biBjYW4gZ28gaW50byBkaWZmZXJlbnQNCj5kaXJlY3Rpb24gOi0pLCBpdCBtYXkgbm90IGJlIGdv b2QgdG8gZ28gaW4gdGhhdCBkaXJlY3Rpb24uDQo+DQo+V2hlcmUgZG8gd2UgZHJhdyB0aGUgbGlu ZT8gMzItYml0cywgNjQtYml0cywNCj4xMjggYml0cz8gSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBh IHNlbnNpYmxlIHZhbHVlIGluIHRoZSBTZXJ2aWNlIFBhdGggDQo+aGVhZGVyIGFuZCBpZiB5b3Ug bmVlZCB0byBjb252ZXkgbW9yZSBiaXRzIHlvdSBuZWVkIHRvIHVzZSB0aGUgY29udGV4dCANCj5o ZWFkZXJzLg0KPg0KPlNSSU5JPiBUaGlzIGlzIGEgZ29vZCBwb2ludC4gIFRoaXMgc2hvdWxkIHdv cmsgZmluZSBhcyBsb25nIGFzIHRoZXJlIGlzDQo+d2F5IHRvIGNvbnZleSBpbiB0aGUgbWFpbiBo ZWFkZXIgdGhhdCB0aGUgZXh0ZW5zaW9uIHRvIHBhdGggSUQgaXMgDQo+YXZhaWxhYmxlIGluIHNv IGFuZCBzbyBUTFYgZmllbGQuICBUaGF0IHNob3VsZCB3b3JrIHRvby4NCj4NCj5UaGFua3MNCj5T cmluaQ0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Gcm9t OiBSZWluYWxkbyBQZW5ubyAocmVwZW5ubykgPHJlcGVubm9AY2lzY28uY29tPg0KPlNlbnQ6IEZy aWRheSwgRGVjZW1iZXIgNSwgMjAxNCA3OjA4IEFNDQo+VG86IEFkZGVwYWxsaSBTcmluaS1CMjIx NjA7IEpvZWwgTS4gSGFscGVybjsgJ3NmY0BpZXRmLm9yZycNCj5DYzogTlMgU3Jpbml2YXNhIE11 cnRoeS1CMzc4NDANCj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+ KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPg0K Pk9uIDEyLzUvMTQsIDY6NTQgQU0sICJTcmluaSBBZGRlcGFsbGkiIDxzYWRkZXBhbGxpQGZyZWVz Y2FsZS5jb20+IHdyb3RlOg0KPg0KPj4NCj4+SW4gcmVhbCBkZXBsb3ltZW50cywgbnVtYmVyIG9m IGFjdGl2ZSBwYXRoIElEcyBhcmUgdmVyeSBsZXNzZXIgdGhhbiANCj4+Ml42NCwgYnV0IHRoZXJl IGlzIGEgZ29vZCBwb3NzaWJpbGl0eSBvZiB0aGUgbnVtYmVyIGJlaW5nIG1vcmUgdGhhbiANCj4+ Ml4yNCAoMTZNKS4NCj4+IEkgdGhpbmsgYmlnZ2VyIHBvaW50IGlzIHRoYXQgd2h5IHJlc3RyaWN0 IHRoaXMgaW4gdGhlIHN0YW5kYXJkcz8gV2hhdCANCj4+YWR2YW50YWdlIGRvIHdlIGhhdmUgcmVz dHJpY3RpbmcgdGhpcyBzaXplIHRvIDI0IGJpdHM/DQo+DQo+W1JQXSBEYXRhIHBsYW5lIGVmZmlj aWVuY3kuIFdoZXJlIGRvIHdlIGRyYXcgdGhlIGxpbmU/IDMyLWJpdHMsIA0KPjY0LWJpdHMsDQo+ MTI4IGJpdHM/IEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgYSBzZW5zaWJsZSB2YWx1ZSBpbiB0aGUg U2VydmljZSBQYXRoIA0KPmhlYWRlciBhbmQgaWYgeW91IG5lZWQgdG8gY29udmV5IG1vcmUgYml0 cyB5b3UgbmVlZCB0byB1c2UgdGhlIGNvbnRleHQgDQo+aGVhZGVycy4NCj4NCj4NCj4+DQo+PlRo ZXJlIGNhbiBiZSBkZXBsb3ltZW50cywgd2hlcmUgU0ZDIGNvbnRyb2xsZXIgKExvZ2ljYWxseSBj ZW50cmFsLCBidXQNCj4+ZGlzdHJpYnV0ZWQpICBpdHNlbGYgY2FuIGRvIHRoZSBTRiBpbnN0YW5j ZSBzZWxlY3Rpb24gb24gcGVyDQo+PmNvbm5lY3Rpb24vc2Vzc2lvbiBiYXNpcywgdGhlcmVieSBh dm9pZGluZyB0aGUgTEJzIGZvciBzZXJ2aWNlcy4gICBJbiBteQ0KPj52aWV3LCBhc3N1bXB0aW9u IHRoYXQgdGhlcmUgd2lsbCBiZSBMQiBTRiBmb3IgZWFjaCBzY2FsZS1vdXQgc2VydmljZSANCj4+ aW4gdGhlIGNoYWluIGlzIG5vdCB2YWxpZCBpbiBhbGwgY2FzZXMuDQo+Pg0KPj5UaGFua3MNCj4+ U3JpbmkNCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ RnJvbTogUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pIDxyZXBlbm5vQGNpc2NvLmNvbT4NCj4+U2Vu dDogVGh1cnNkYXksIERlY2VtYmVyIDQsIDIwMTQgMToxNyBQTQ0KPj5UbzogQWRkZXBhbGxpIFNy aW5pLUIyMjE2MDsgSm9lbCBNLiBIYWxwZXJuOyBzZmNAaWV0Zi5vcmcNCj4+Q2M6IE5TIFNyaW5p dmFzYSBNdXJ0aHktQjM3ODQwDQo+PlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0gg RHJhZnQNCj4+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2No LTAyKQ0KPj4NCj4+SWYgSSB1bmRlcnN0b29kIHlvdSwgSSBkbyBub3QgdGhpbmsgdGhpcyBpcyBy ZWFsaXN0aWMuIEFyZSB5b3Ugc2F5aW5nIA0KPj55b3UgbmVlZCA2NC1iaXRzIG9mIHBhdGhzIGFu ZCB0aGVuIHdpbGwgbW9uaXRvciB0aGVtIGFsbD8gRG8gZmF1bHQgDQo+PnRvbGVyYW5jZSBhbmQg T0FNIGZvciAyXjY0LWJpdHMgd29ydGggb2YgcGF0aHM/IEp1c3QgZm9yIGNvbXBhcmlzb24sIA0K Pj5pdMK5cyBsaWtlIG1hbmFnaW5nIGFuZCBtb25pdG9yaW5nIHRoZSBlbnRpcmUgSVB2NiBob3N0 IHJhbmdlLCBvbmUtYnktb25lLg0KPj4NCj4+QW55d2F5LCBJIGRvIG5vdCBleHBlY3QgZXZlcnkg c2luZ2xlIHBlcm11dGF0aW9ucyB0byBiZSBhIGRpZmZlcmVudCBwYXRoLg0KPj4NCj4+SWYgZWFj aCBzZXJ2aWNlIGhhcyAyNTYgZGV2aWNlcyBwcm92aWRpbmcgc2ltaWxhciBzZXJ2aWNlLCB5b3Ug c2hvdWxkIA0KPj5tb3N0IGxpa2VseSB1c2UgbG9hZC1iYWxhbmNpbmcgYW5kIHRoZW4geW91IHdv dWxkIGhhdmUgYSBzaW5nbGUgKG9yIGENCj4+ZmV3KSBwYXRocy4gVGhlcmUgaXMgc29tZSBkaXNj dXNzaW9uIGdvaW5nIG9uIExCLg0KPj4NCj4+RnJvbSBhIGRhdGEgcGxhbmUgcGVyc3BlY3RpdmUs IHRoZSBwYXRoIGlzIHVsdGltYXRlbHkgZGVmaW5lZCBieSB0aGUgDQo+PlNGRnMgdHJhdmVyc2Vk IGFuZCBzZXJ2aWNlcyBwcm92aWRlZCwgbm90IGJ5IGEgc3BlY2lmaWMgSVA6cG9ydCB0aGF0IA0K Pj50aGUgZGV2aWNlIHByb3ZpZGluZyB0aGUgc2VydmljZSBzaXRzIG9uLiBXZWxsLCBhdCBsZWFz dCBmcm9tIGEgDQo+PkdQRStOU0ggcGVyc3BlY3RpdmUuDQo+Pg0KPj4NCj4+T24gMTIvNC8xNCwg MTI6NTcgUE0sICJTcmluaSBBZGRlcGFsbGkiIDxzYWRkZXBhbGxpQGZyZWVzY2FsZS5jb20+IHdy b3RlOg0KPj4NCj4+PklmIEkgdGFrZSBhIGNoYWluIHdpdGggNSBzZXJ2aWNlcyB3aXRoIGVhY2gg c2VydmljZSAgc2F5IGhhdmluZyAyNTYgDQo+Pj5pbnN0YW5jZXMgZm9yIHNjYWxlLW91dCwgcG9z c2libGUgbnVtYmVyIG9mIHBhdGhzIGFyZQ0KPj4+MjU2KjI1NioyNTYqMjU2KjI1NiA9IDB4RkYg RkYgRkYgRkYgRkYuIE9uZSByZXF1aXJlcyAzMyBiaXRzIGluIHRoaXMgDQo+Pj5jYXNlLiAgSWYg dGhlcmUgYXJlIG1vcmUgc2VydmljZXMgaW4gdGhlIGNoYWluIG9yIG1vcmUgY2hhaW5zIG9yIG1v cmUgDQo+Pj5pbnN0YW5jZXMgZm9yIHNjYWxlLW91dCwgdGhlbiBpdCBjb3VsZCBnbyB0byBiaWcg bnVtYmVyIHZlcnkgZmFzdC4NCj4+Pg0KPj4+QXMgSSBtZW50aW9uZWQgbXkgcHJlZmVyZW5jZSBp cyB0byBtYWtlIHRoZSBwYXRoIElEIHNpemUgZmxleGlibGUgZm9yIA0KPj4+ZnV0dXJlIGdyb3d0 aC4gSWYgdGhhdCBpcyBwZXJjZWl2ZWQgYXMgY29tcGxleCwgdGhlbiBnb2luZyBmb3IgNjRiaXQg DQo+Pj5pcyBzYWZlciBiZXQuDQo+Pj4NCj4+PlRoYW5rcw0KPj4+U3JpbmkNCj4+Pg0KPj4+DQo+ Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+RnJvbTogSm9lbCBNLiBIYWxwZXJuIFtt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0NCj4+PlNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAw NCwgMjAxNCAxMjowNSBQTQ0KPj4+VG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IEpvZWwgTS4g SGFscGVybjsgc2ZjQGlldGYub3JnDQo+Pj5DYzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDAN Cj4+PlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4+PihodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4+Pg0KPj4+QSBj b250cm9sbGVyIChvciBvdGhlciBkZWNpc2lvbiBsb2dpYykgY2FuIGNlcnRhaW5seSBiZSBhd2Fy ZSBvZiBzdWNoIA0KPj4+Y29uY2VybnMuDQo+Pj5CdXQgdGhlIG51bWJlciBvZiBzZXJ2aWNlIGZ1 bmN0aW9uIHBhdGhzIGlzIG5vdCByZWxhdGVkIHRvIHRoZSBudW1iZXIgDQo+Pj5vZiBmbG93cyBv ciB0aGUgbnVtYmVyIG9mIHRlbmFudHMuICBJdCBpcyByZWxhdGVkIHRvIHRoZSBudW1iZXIgb2Yg DQo+Pj5jb21iaW5hdGlvbnMgb2Ygc2VydmljZXMgYW5kIHRoZSBwb2xpY2llcyBmb3Igc2Vydmlj ZSBmdW5jdGlvbiANCj4+PnNlbGVjdGlvbi4NCj4+PiBXaGlsZSB0aGF0IGNhbiBiZSBhIGxhcmdl IG51bWJlciwgSSBzdXJlIGhvcGUgaXQgZG9lcyBub3QgY29tZSBjbG9zZSANCj4+PnRvIHNhdHVy YXRpbmcgMjQgYml0cy4NCj4+Pg0KPj4+SGF2aW5nIHNhaWQgdGhhdCwgaWYgd2UgdGhpbmsgdGhh dCAyNCBiaXRzIGlzIG9ubHkganVzdCBlbm91Z2gsIHRoZW4gDQo+Pj53ZSBvdWdodCB0byB1c2Ug MzIuICBGcm9tIHdoZXJlIEkgc2l0LCBJIHdvdWxkIG5vcm1hbGx5IGV4cGVjdCAxNiANCj4+PmJp dHMgdG8gYmUgbW9yZSB0aGFuIHN1ZmZpY2llbnQsIHdoaWNoIGlzIHdoeSBJIGFtIGNvbWZvcnRh YmxlIHdpdGggMjQuDQo+Pj5IYXZpbmcgc2FpZCB0aGF0LCB0aGUgZmllbGQgc2l6ZSBpcyBub3Qg YSBiaWcgZGVhbCB0byBtZS4NCj4+Pg0KPj4+WW91cnMsDQo+Pj5Kb2VsDQo+Pj4NCj4+Pk9uIDEy LzQvMTQsIDI6MDEgUE0sIFNyaW5pIEFkZGVwYWxsaSB3cm90ZToNCj4+Pj4NCj4+Pj4gSSB3YXMg bm90IGltcGx5aW5nIHRoYXQgcGF0aCBJRCBzaG91bGQgaGF2ZSBpbmZvcm1hdGlvbiBpbiByZWdh cmRzIA0KPj4+PnRvIHRlbmFudC9jb250cm9sbGVyL2Zsb3cvc2NhbGUtb3V0LiAgQnV0IFNGQyBj b250cm9sbGVycyBzaG91bGQgDQo+Pj4+a2VlcCB0aGVzZQ0KPj4+PmluIG1pbmQgdG8gYXNzaWdu IHRoZSBwYXRoIElELiAgICBBIGRlcGxveW1lbnQgY2FuIGhhdmUgbXVsdGlwbGUNCj4+Pj50ZW5h bnRzLCBlYWNoIHRlbmFudCBjYW4gaGF2ZSBtdWx0aXBsZSBuZXR3b3JrcywgIHRoZXJlIGNvdWxk IGJlIA0KPj4+Pm1pbGxpb25zIG9mIGZsb3dzIGluIGVhY2ggb2YgdGhvc2UgbmV0d29ya3MuICBB bmQgY29uc2lkZXJpbmcgYWxsIA0KPj4+PnRoZXNlLA0KPj4+PiAyNCBiaXQgcGF0aCBJRCBtYXkg bm90IGJlIGFibGUgdG8gcmVwcmVzZW50IHBhdGhzIGZvciB0aGVzZSBmbG93cy4NCj4+Pj5IZW5j ZSwgSSB3YXMgd29uZGVyaW5nIHdoZXRoZXIgcGF0aCBJRCBjYW4gYmUgZXh0ZW5kZWQgdG8gNjQg Yml0cyBvciANCj4+Pj5tYWtlIGl0IGZsZXhpYmxlLg0KPj4+Pg0KPj4+PiBUaGFua3MNCj4+Pj4g U3JpbmkNCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+PiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+DQo+Pj4+ IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciA0LCAyMDE0IDc6NDIgQU0NCj4+Pj4gVG86IEFkZGVw YWxsaSBTcmluaS1CMjIxNjA7IHNmY0BpZXRmLm9yZw0KPj4+PiBDYzogTlMgU3Jpbml2YXNhIE11 cnRoeS1CMzc4NDANCj4+Pj4gU3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFm dA0KPj4+PiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gt MDIpDQo+Pj4+DQo+Pj4+IFRoZSBJbmRleCBpcyBub3QganVzdCBmb3IgbG9vcCBwcmV2ZW50aW9u LiAgSW4gdGhlIGNhc2Ugb2YgIA0KPj4+PmFtYmlndWl0eSwgdGhlIGluZGV4IHRlbGxzIHRoZSBT RkYgd2hlcmUgaW4gdGhlIHBhdGggdGhlIHBhY2tldCANCj4+Pj5jdXJyZW50bHkgcmVzaWRlcy4N Cj4+Pj4gICAgVGhlcmUgYXJlIG11bHRpcGxlIHdheXMgc3VjaCBhbWJpZ3VpdHkgY2FuIG9jY3Vy Lg0KPj4+Pg0KPj4+PiBUaGUgUGF0aCBJZGVudGlmaWVyIGlzIHNwZWNpZmljYWxseSBub3QgZXhw ZWN0ZWQgdG8gaW5jbHVkZSANCj4+Pj4gY29udHJvbGxlciBJRCBvciBUZW5hbnQgSUQuICBXaGls ZSBhIGRlcGxveWVyIGNhbiBoYXZlIGEgcGF0aCBwZXIgDQo+Pj4+IHRlbmFudCwgdGhlIGFyY2hp dGVjdHVyZSBzdGlsbCBkb2VzIG5vdCB0cmVhdCB0aGUgcGF0aCBJRCBhcyBhIA0KPj4+PiB0ZW5h bnQgSUQuICBUZW5hbnQgSUQsIGNvbnRyb2xsZXIgSUQsIGFuZCBvdGhlciBub24tcGF0aC1zcGVj aWZ5aW5nIA0KPj4+PiBpbmZvcm1hdGlvbiBpcyB0byBiZSBjYXJyaWVkIGluIG1ldGFkYXRhLg0K Pj4+Pg0KPj4+PiBZb3VycywNCj4+Pj4gSm9lbA0KPj4+Pg0KPj4+PiBPbiAxMi80LzE0LCAxMDow MiBBTSwgU3JpbmkgQWRkZXBhbGxpIHdyb3RlOg0KPj4+Pj4gVHdvIGNvbW1lbnRzIDoNCj4+Pj4+ DQo+Pj4+Pg0KPj4+Pj4gMS4gIFNGIEluZGV4IDogIFNpbmNlIGl0IGlzIG1lYW50IGZvciBsb29w IGRldGVjdGlvbiwgIHdvdWxkbid0IA0KPj4+Pj4gYmV0dGVyIHRvIHJlbmFtZSB0aGlzIGFzICJU VEwiPw0KPj4+Pj4NCj4+Pj4+IDIuICBQYXRoIElkZW50aWZpZXIgOiAgICAyNCBiaXQgcGF0aCBp ZGVudGlmaWVyIHNlZW1zIHRvIGJlIHRvbyBsZXNzLg0KPj4+Pj4gQmFzZWQgb24gb3VyIGV4cGVy aWVuY2UgaW4gdHJhZmZpYyBzdGVlcmluZywgIHRoaXMgcGF0aCBpZGVudGlmaWVyIA0KPj4+Pj5u ZWVkcyB0byBlbmNvZGUgZ29vZCBhbW91bnQgb2YgaW5mb3JtYXRpb24gdG8gbWFrZSBpdCB1bmlx dWUuICBGb3IgDQo+Pj4+PmV4YW1wbGUsDQo+Pj4+PiAgICB0aGlzIGlkZW50aWZpZXIgbmVlZHMg dG8gZW5jb2RlIChpbiBvdXIgY2FzZSkgc29tZSBpbmZvcm1hdGlvbiANCj4+Pj4+cmVwcmVzZW50 aW5nIHRoZSBkaXN0cmlidXRlZCBjb250cm9sbGVyIElELCAgdGVuYW50IElELCAgZmxvdyBJRCwN Cj4+Pj4+ICAgIFNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2UgKGluIGNhc2Ugb2Ygc2NhbGUtb3V0 KSBhbmQgZmV3IG1vcmUuLg0KPj4+Pj4gT25lIHN1Z2dlc3Rpb24gaXMgdG8gbWFrZSBpdCA2NCBi aXRzIHZhbHVlICBvciB0byBtYWtlIGl0IGV2ZW4gDQo+Pj4+PmV4dGVuZGFibGUsDQo+Pj4+PiAg ICBpdCBpcyBnb29kIGlmIHBhdGggaWRlbnRpZmllciBpcyBhbHNvIHJlcHJlc2VudGVkIGluIFRM ViBmb3JtLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBUaGFua3MNCj4+Pj4+DQo+Pj4+PiBTcmluaQ0K Pj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+PiBz ZmNAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQo+Pj4+Pg0KPj4+DQo+Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+c2ZjIG1haWxpbmcgbGlzdA0KPj4+c2ZjQGlldGYub3JnDQo+Pj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCj4NCj4NCj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBtYWlsaW5nIGxp c3QNCj5zZmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+DQo+VGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNo bWVudHMgKHRoZSAibWVzc2FnZSIpIGFyZSBjb25maWRlbnRpYWwsIA0KPmludGVuZGVkIHNvbGVs eSBmb3IgdGhlIGFkZHJlc3NlZXMuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCANCj5yZWNp cGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5k IGRlbGV0ZSANCj50aGlzIG1lc3NhZ2UgZnJvbSB5b3VyIHN5c3RlbS4gSW4gdGhpcyBjYXNlLCB5 b3UgYXJlIG5vdCBhdXRob3JpemVkIHRvIA0KPnVzZSwgY29weSB0aGlzIG1lc3NhZ2UgYW5kL29y IGRpc2Nsb3NlIHRoZSBjb250ZW50IHRvIGFueSBvdGhlciBwZXJzb24uDQo+RS1tYWlscyBhcmUg c3VzY2VwdGlibGUgdG8gYWx0ZXJhdGlvbi4gTmVpdGhlciBRb3Ntb3Mgbm9yIGFueSBvZiBpdHMg DQo+c3Vic2lkaWFyaWVzIG9yIGFmZmlsaWF0ZXMgc2hhbGwgYmUgbGlhYmxlIGZvciB0aGUgbWVz c2FnZSBpZiBhbHRlcmVkLCANCj5jaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4NCj5DZSBtZXNzYWdl IGV0IHRvdXRlcyBzZXMgcGnDqGNlcyBqb2ludGVzIChjaS1hcHLDqHMgbGUgIm1lc3NhZ2UiKXNv bnQgDQo+Y29uZmlkZW50aWVscyBldCDDqXRhYmxpcyDDoCBsJ2ludGVudGlvbiBleGNsdXNpdmUg ZGUgc2VzIGRlc3RpbmF0YWlyZXMuIA0KPlNpIHZvdXMgYXZleiByZcOndSBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIG1lcmNpIGTigJllbiBpbmZvcm1lciANCj5pbW3DqWRpYXRlbWVudCBzb24gw6lt ZXR0ZXVyIHBhciBjb3VycmllciDDqWxlY3Ryb25pcXVlIGV0IGTigJllZmZhY2VyIGNlIA0KPm1l c3NhZ2UgZGUgdm90cmUgc3lzdMOobWUuIERhbnMgY2V0dGUgaHlwb3Row6hzZSwgdm91cyBu4oCZ w6p0ZXMgcGFzIA0KPmF1dG9yaXPDqSDDoCB1dGlsaXNlciwgY29waWVyIGNlIG1lc3NhZ2UgZXQv b3UgZW4gZGl2dWxndWVyIGxlIGNvbnRlbnUgw6AgDQo+dW4gdGllcnMuIFRvdXQgbWVzc2FnZSDD qWxlY3Ryb25pcXVlIGVzdCBzdXNjZXB0aWJsZSBkJ2FsdMOpcmF0aW9uLiANCj5Rb3Ntb3MgZXQg c2VzIGZpbGlhbGVzIGTDqWNsaW5lbnQgdG91dGUgcmVzcG9uc2FiaWxpdMOpIGF1IHRpdHJlIGRl IGNlIA0KPm1lc3NhZ2UgcydpbCBhIMOpdMOpIGFsdMOpcsOpLCBkw6lmb3Jtw6kgb3UgZmFsc2lm acOpLg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Sun Feb 1 13:55: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 357781A1AD3 for ; Sun, 1 Feb 2015 13:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, SPF_HELO_PASS=-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 f4Da_Sz_TyOA for ; Sun, 1 Feb 2015 13:55:02 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0752.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:752]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CD461A1AC1 for ; Sun, 1 Feb 2015 13:55:01 -0800 (PST) Received: from DM2PR0301MB0862.namprd03.prod.outlook.com (25.160.215.148) by DM2PR0301MB0862.namprd03.prod.outlook.com (25.160.215.148) with Microsoft SMTP Server (TLS) id 15.1.65.19; Sun, 1 Feb 2015 21:54:33 +0000 Received: from DM2PR0301MB0862.namprd03.prod.outlook.com ([25.160.215.148]) by DM2PR0301MB0862.namprd03.prod.outlook.com ([25.160.215.148]) with mapi id 15.01.0065.013; Sun, 1 Feb 2015 21:54:33 +0000 From: Srini Addepalli To: Nicolas BOUTHORS , Sumandra Majee , Cathy Zhang , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZx/klKAgAA1pTGAABNtAIAADGxAgAAH7ICAASQ+x4AAByMAgAABINiAAEx9AIBWb4+AgAEKegCAALysgIACxPqAgABOQ3A= Date: Sun, 1 Feb 2015 21:54:32 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> <76B41B8FACE1514795D30EC137FF391D7D2279@LILAS.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D7D2279@LILAS.jungle.qosmos.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.88.158.1] authentication-results: qosmos.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0862; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0862; x-forefront-prvs: 04740D25F1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(377454003)(53754006)(52314003)(24454002)(13464003)(51704005)(479174004)(561944003)(92566002)(106116001)(33656002)(99286002)(19580405001)(46102003)(19580395003)(86362001)(230783001)(76176999)(54606007)(50986999)(54206007)(54356999)(74316001)(87936001)(2656002)(15975445007)(102836002)(2950100001)(2900100001)(122556002)(76576001)(40100003)(66066001)(62966003)(77156002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0862; H:DM2PR0301MB0862.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: freescale.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2015 21:54:32.1371 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0862 Archived-At: Cc: "nsmurthy@freescale.com" , Rajesh Kumar Madabushi , Bharat Mota Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 01 Feb 2015 21:55:06 -0000 SGksDQoNCkkgc2VudCBhbiByZXNwb25zZSBlbWFpbCBmZXcgbWludXRlcyBiYWNrLiBSU1AtSUQg YW5kIGNlbnRyYWxpemVkIGxvZ2ljYWwgY29udHJvbGxlciBhcmUgcmVhbGx5IGdvaW5nIHRvIGhl bHAgaW4gY2FzZXMgd2hlcmUgYSBnaXZlbiBTRiBpbnN0YW5jZXMgYXJlIG5vdCBmcm9udCBlbmRl ZCBieSBvbmUgU0ZGLg0KDQpJbiBORlYgd29ybGQsIFNGRiBpcyBhIHZpcnR1YWwgc3dpdGNoIGlu IHNlcnZlcnMuICBJdCBzaG91bGQgbm90IGJlIGFzc3VtZWQgdGhhdCBhbGwgU0YgaW5zdGFuY2Vz IGZvciBhIGdpdmVuIFNGIHdvdWxkIGJlIGhvc3RlZCBpbiBvbmUgc2VydmVyLg0KDQpUaGFua3MN ClNyaW5pDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNmYyBbbWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTmljb2xhcyBCT1VUSE9SUw0KU2Vu dDogU3VuZGF5LCBGZWJydWFyeSAwMSwgMjAxNSA5OjExIEFNDQpUbzogU3VtYW5kcmEgTWFqZWU7 IENhdGh5IFpoYW5nOyAnc2ZjQGlldGYub3JnJw0KU3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRz IG9uIFNDSCBEcmFmdCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNm Yy1zY2gtMDIpDQoNCkkgY2FuIHVuZGVyc3RhbmQgdGhhdCBpbiBtYW55IGNhc2VzIGEgbG9jYWwg U0ZGIGFwcGVhcnMgYmVzdCBzdWl0ZWQgdG8gdGFrZSBsb2FkIGJhbGFuY2luZy9yZXJvdXRpbmcg ZGVjaXNpb25zLg0KDQpTdGlsbCB3ZSBzaG91bGQgYWxsb3cgZm9yIHRoZSBjYXNlIHdoZXJlIGEg cmVtb3RlIFNGRiwgc3VjaCBhcyB0aGUgQ2xhc3NpZmllciBhdCB0aGUgZW50cmFuY2UgcG9pbnQg b2YgdGhlIG5ldHdvcmssIGZvciBleGFtcGxlIGJhc2VkIG9uIERQSSBvciBzdWJzY3JpYmVyIGF3 YXJlbmVzcywgcGVyZm9ybXMgcmVtb3RlIGxvYWQgYmFsYW5jaW5nIGRlY2lzaW9uIHRoYW5rcyB0 byB0aGUgdHJhbnNtaXNzaW9uIG9mIHRoZSBSZW5kZXJlZCBTZXJ2aWNlIFBhdGggaWRlbnRpZmll ci4gRFBJIGNhcGFiaWxpdHkgbWF5IG5vdCBiZSBhdmFpbGFibGUgaW4gYWxsIFNGRiBmb3IgZXhh bXBsZS4NCg0KSW4gYWRkaXRpb24gdGhlIFJlbmRlcmVkIFNlcnZpY2UgUGF0aCBpZGVudGlmaWVy IGNhbiBiZSB1c2VkIGFzIGEgaGFzaCBrZXkgYnkgIFNGRih5KSBsb2FkIGJhbGFuY2luZyBkZWNp c2lvbi4gU28gaXQgaXMgYWxzbyBjb21wYXRpYmxlIHdpdGggdGhlIG5vdGlvbiBvZiBsb2NhbCBs b2FkIGJhbGFuY2VyLg0KUmVnYXJkcywNCg0KTmljb2xhcw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBTdW1hbmRyYSBNYWplZSBbbWFpbHRvOlMuTWFqZWVARjUuY29tXQ0K U2VudDogdmVuZHJlZGkgMzAgamFudmllciAyMDE1IDIzOjUzDQpUbzogTmljb2xhcyBCT1VUSE9S UzsgQ2F0aHkgWmhhbmc7ICdzZmNAaWV0Zi5vcmcnDQpDYzogSmVyb21lIFRPTExFVA0KU3ViamVj dDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdCAoaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQoNCkhlbGxvLA0KDQpUaGlzIGlzIGFuIGlu dGVyZXN0aW5nIGRpc2N1c3Npb24gYW5kIEkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIHRoZSBt b3RpdmF0aW9uIG9mIGJldHRlci4gVGhlIHRyb3VibGUgd2l0aCBhIHByb3RvY29sIGRvY3VtZW50 IGlzIHRoYXQgaXQgaXMgdHlwaWNhbGx5IGhhcyBpbmFkZXF1YXRlIGRldGFpbCBhYm91dCB0aGUg bG9naWMuIFNvIHRvIGNhc3QgdGhpcyBpbnRvIHNvbWV3aGF0IG9mIGEgY29uY3JldGUgdGVybXMs IGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcuDQoNCg0KDQogICAgICAgU0ZGKHgpICB7IFNmeCgxKSBT ZngoMinigKZTZngobikgfSAgIOKAlOKAlOKAlOKAlD4gICBTRkYoeSkgeyBTZnkoMSkgU2Z5KDIp DQrigKYuIFNmeShtKSB9ICAgOjogTG9naWNhbCBDaGFpbiBpbiBPTkUgZGlyZWN0aW9uIG9ubHku DQoNCiAgICAgICBQSFlTSUNBTCBXT1JMRDoNCiAgICAgICAgICBBKSB0aGUgU0ZGIGNvdWxkIGJl IGENCiAgICAgICAgICAgIC0gY29tcG9uZW50IG9mIFZTV0lUQ0ggKHBpY2sgeW91ciBmYXYgcHJv dG9jb2wgZm9yIGNvbmZpZ3VyaW5nIHRob3NlIGVudGl0aWVzIH0NCiAgICAgICAgICAgIC0gQSBs b2FkIGJhbGFuY2VyDQogICAgICAgICAgICAtIEEgSFcgc3dpdGNoL3JvdXRlciBzb21lIEwyL0wz IGNvbWJvDQoNCiAgICAgICAgICBCKSBTZiBpbnN0YW5jZSBjb3VsZCBiZSwNCiAgICAgICAgICAg ICAgIC0gVmlydHVhbCBtYWNoaW5lLCAjTiBvZiB0aG9zZQ0KICAgICAgICAgICAgICAgLSBwaHlz aWNhbA0KICAgICAgICAgICAgICAgLSBDb250YWluZXIgI00gd2hpY2ggaXMgb2Z0ZW4gNSBvciBt b3JlIHggI04NCiAgICAgICAgICAgICAgIC0gQ2x1c3RlciB0aGF0IHdlIGRvbuKAmXQga25vdw0K DQpJdCBpcyBwb3NzaWJsZSB0byBoYXZlIG11bHRpcGxlIHBoeXNpY2FsIFNGRih4KSBhbHNvLg0K DQpBIHNlbGVjdGlvbiBvZiBhIGdpdmVuIFNGIChzZXJ2aWNlKShpbnN0YW5jZSkgaXMgYSBjYW4g YmUgc2ltcGxlIG9yIGNvbXBsZXguIEZvciBleGFtcGxlIFNGRih4KSBtYXkgaGF2ZSB0aGUgYmVz dCBrbm93bGVkZ2UgdG8gc2VsZWN0IFNmeCgxKSBiYWVkIG9uIGEgZ2l2ZW4gY3JpdGVyaW9uICh3 aGljaCBjb3VsZCBiZSBwYXJ0IG9mIHRoZSBwb2xpY3kpLiAgVGhlbiBJIGRvbuKAmXQgc2VlIGEg cmVhc29uIHRvIGhhdmUgUlNQLg0KDQpJdCBpcyBwb3NzaWJsZSB0aGF0IGxvb2t1cCAocGF0aCkg QCBTRkYoeCkgcHJvZHVjZXMgYSBzcGVjaWZpYyBpbnN0YW5jZSBvZiBTZnkgYW5kIHllcyB0aGVu IHNvbWV0aGluZyBsaWtlIFJTUCB3b3VsZCBiZSByZXF1aXJlZC4gQnV0IEkgd291bGQgYXJndWUg dGhhdCBqb2IgU0ZGKHkpIGNhbiBhbHNvIGJlIHN1YnN1bWVkIGJ5IFNGRih4KS4NCg0KSXMgaXQg cG9zc2libGUgZm9yIGEgY2VudHJhbCBjb250cm9sbGVyIHRvIHBpY2sgZWFjaCBpbnN0YW5jZSBv ZiBzZXJ2aWNlLCBidXQgc3VjaCBhbiBpbXBsZW1lbnRhdGlvbiB0ZW5kcyB0byBzY2FsZSBwb29y bHkuIFRoZSBhbW91bnQgb2Ygc3RhdGUsIHByb2JhYmlsaXR5IG9mIGEgaW5zdGFuY2UgZ29pbmcg ZG93biBiZXR3ZWVuIHNlbGVjdGlvbiBhbmQgZmxvdyBhcnJpdmFsIGdvZXMgdXAuDQoNClJlZ2Fy ZHMuDQoNClN1bWFuZHJhDQoNCg0KDQpPbiAxLzMwLzE1LCAzOjM4IEFNLCAiTmljb2xhcyBCT1VU SE9SUyIgPE5pY29sYXMuQk9VVEhPUlNAcW9zbW9zLmNvbT4NCndyb3RlOg0KDQo+SGVsbG8gQ2F0 aHksDQo+DQo+SW5kZWVkIHRoZSBub3Rpb24gb2YgInJlbmRlcmVkIHNlcnZpY2UgcGF0aCBJRCIo UlNQIElEKSBzZWVtcyByZWxldmFudCANCj5hcyB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IHN0 aXB1bGF0ZXMgdGhhdCB0aGUgU2VydmljZSBGdW5jdGlvbiBQYXRoDQo+KFNGUCkgcHJvdmlkZXMg YW4gYWJzdHJhY3Qgbm90aW9uIG9mIGEgc2VydmljZSBjaGFpbiwgd2hpbGUgdGhlIFJTUCBpcyAN Cj5hIGNvbnN0cmFpbmVkIGxpc3Qgb2YgbG9jYXRpb25zLg0KPg0KPlNGQyBoZWFkZXIgIlNlcnZp Y2UgUGF0aCBJZGVudGlmaWVyIiAoU1BJKSAgaXMgdXNlZCBpbiBib3RoIE5TSCBhbmQgU0NIIA0K PnByb3RvY29sIGFuZCBpbiBib3RoIGNhc2Ugc2VlbSB0byBpZGVudGlmeSB0byBhIHBhcnRpY3Vs YXIgU0ZQLg0KPg0KPk5TSCh2NSkgZm9yIGV4YW1wbGUgc3RhdGVzIHRoYXQNCj4iIEFzIGRlc2Ny aWJlZCBhYm92ZSwgTlNIIGNvbnRhaW5zIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgKFNQSSkg YW5kDQo+ICAgYSBzZXJ2aWNlIGluZGV4IChTSSkuICBUaGUgU1BJIGlzLCBhcyBwZXIgaXRzIG5h bWUsIGFuIGlkZW50aWZpZXIuDQo+ICAgVGhlIFNQSSBhbG9uZSBjYW5ub3QgYmUgdXNlZCB0byBm b3J3YXJkIHBhY2tldHMgYWxvbmcgYSBzZXJ2aWNlIHBhdGguDQo+ICAgUmF0aGVyIHRoZSBTUEkg cHJvdmlkZSBhIGxldmVsIG9mIGluZGlyZWN0aW9uIGJldHdlZW4gdGhlIHNlcnZpY2UNCj4gICBw YXRoL3RvcG9sb2d5IGFuZCB0aGUgdGhlIG5ldHdvcmsgdHJhbnNwb3J0LiAgRnVydGhlcm1vcmUs IHRoZXJlIGlzDQo+ICAgbm8gcmVxdWlyZW1lbnQsIG9yIGV4cGVjdGF0aW9uIG9mIGFuIFNQSSBi ZWluZyBib3VuZCB0byBhIHByZS0NCj4gICBkZXRlcm1pbmVkIG9yIHN0YXRpYyBuZXR3b3JrIHBh dGguIg0KPg0KPlN0aWxsIE5TSCh2NSkgIHNob3dzIHRoYXQgU1BJIChub3QgYSBSU1AgSUQpICBz aG91bGQgYmUgcGFydCBvZiB0aGUga2V5IA0KPmVsZW1lbnQgb2YgYW4gU0ZGIHRvIGxvb2t1cCBv biBmb3J3YXJkaW5nIHRhYmxlcy4gIEJ1dCBJIGNvdWxkIG5vdCBmaW5kIA0KPmluIE5TSCAgaG93 IHRvIHVzZSB0aGUgbm90aW9uIG9mIFJlbmRlcmVkIHNlcnZpY2UgcGF0aCB3aGljaCB3YXMgDQo+ ZGVmaW5lZCBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50Lg0KPg0KPllvdSBwcm9wb3NhbCBz ZWVtcyB0byBtZSB2ZXJ5IHVzZWZ1bCwNCj4NCj5BbiBSU1AgSUQgKGluZGVwZW5kZW50IG9mIHRo ZSBTUEkgYnV0IHBhcnQgb2YgdGhlIHNhbWUgbmFtZSBzcGFjZSkgDQo+Y291bGQgYmUgdXNlZCB0 aGUgc2FtZSB3YXkgYXMgU1BJIGJ5IFNGRiBmb3IgZXhhbXBsZSwgYWxsb3dpbmcgYSANCj5TZXJ2 aWNlIENsYXNzaWZpZXIgdG8gY29udHJvbCByZW1vdGUgbG9hZCBiYWxhbmNpbmcgZm9yIGV4YW1w bGUuDQo+DQo+VGhpcyBzYWlkIHRoZSBSU1AgSUQgdmFsdWVzIGNvdWxkIGJlIHJlbGF0aXZlIHRv IGEgcGFydGljdWxhciBTZXJ2aWNlIA0KPlBhdGgsIHdoaWNoIHdvdWxkIHByZXZlbnQgdXNpbmcg dGhlbSBhcyB3ZSBkbyBmb3IgU1BJIGluIFNGRiBmb3J3YXJkaW5nIA0KPnRhYmxlcy4NCj4NCj5X ZSBtYXkgd2FudCB0byBwcmVjaXNlIGlmIHRoZSBSU1AgSUQgaXMgdG8gYmUgcmVsYXRpdmUgb2Yg YWJzb2x1dGUsIGFzIA0KPml0IHNob3VsZCBoYXZlIGFuIGltcGFjdCBvbiBmb3J3YXJkaW5nIHRh YmxlIHN0cnVjdHVyZSBpZiB3ZSBkZWNpZGUgdG8gDQo+dXNlIHRoaXMgY29uY2VwdC4NCj4NCj5Q ZXJzb25hbGx5IEkgbGlrZSB0aGUgbm90aW9uIG9mIGEgcmVsYXRpdmUgUlNQIElELCBhcyB3ZSBj b3VsZCB0aGVuIHVzZSANCj5zb21lIGNvbnZlbnRpb25zLCBzdHJ1Y3R1cmUgaXQsIHBvc3NpYmx5 IGV4dGVuZGluZyBpdHMgdXNlLg0KPg0KPk5pY29sYXMNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPkZyb206IENhdGh5IFpoYW5nIFttYWlsdG86Q2F0aHkuSC5aaGFuZ0BodWF3ZWku Y29tXQ0KPlNlbnQ6IGpldWRpIDI5IGphbnZpZXIgMjAxNSAyMDo0NA0KPlRvOiBDYXRoeSBaaGFu ZzsgU3JpbmkgQWRkZXBhbGxpOyBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4NCj5I YWxwZXJuOyAnc2ZjQGlldGYub3JnJw0KPkNjOiBuc211cnRoeUBmcmVlc2NhbGUuY29tDQo+U3Vi amVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPihodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4NCj5IaSBldmVyeW9uZSwNCj4N Cj5XZSBoYXZlIHVwbG9hZGVkIGEgbmV3IFNDSCB2ZXJzaW9uICgzKSB3aGljaCBhZGRzIGRlZmlu aXRpb24gb2YgYSBuZXcgDQo+bWV0YWRhdGEgdHlwZSBmb3IgdGhlIGZsb3cgSUQgdG8gc3VwcG9y dCBsb2FkIGJhbGFuY2luZyBhbW9uZyBTRiANCj5pbnN0YW5jZXMgYW5kIG1pdGlnYXRlIHRoZSBw b3RlbnRpYWwgaXNzdWUgb2YgIm5vdCBlbm91Z2ggcGF0aCBJRCIuIFRoZSANCj5mbG93IElEIGlz IG5hbWVkICJyZW5kZXJlZCBzZXJ2aWNlIHBhdGggSUQiIGluIHRoZSBkcmFmdC4gUGxlYXNlIHJl ZmVyIA0KPnRvIHNlY3Rpb24gNC4zLjIgb2YgDQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtemhhbmctc2ZjLXNjaC8NCj5mb3IgZGV0YWlsIGRlc2NyaXB0aW9uLg0KPg0K PkluIGl0cyBwcmV2aW91cyB2ZXJzaW9uLCBTQ0ggZGVmaW5lcyBhICJCeXBhc3MgYml0IiBpbiB0 aGUgYmFzZSBoZWFkZXIuDQo+VGhpcyBiaXQgZW5hYmxlcyB0aGUgU0YgdG8gcHJvdmlkZSBmZWVk YmFjay9ub3RpZmljYXRpb24gdmlhIHRoZSBkYXRhIA0KPnBhdGggdG8gaXRzIGNvbm5lY3Rpbmcg U0ZGIGFib3V0IHdoZXRoZXIgdGhlIHJlbWFpbmluZyBwYWNrZXRzIG9mIHRoZSANCj5TRkMgc2hv dWxkIGJ5cGFzcyB0aGF0IFNGLiBUaGlzIGlzIHVzZWZ1bCBpbiB0aGUgY2FzZSB0aGF0IG9ubHkg dGhlIA0KPmZpcnN0IGZldyBwYWNrZXRzIG9mIGEgZmxvdyBuZWVkIHRvIGdvIHRvIGEgU0YgKHN1 Y2ggYXMgYSBEUEkgb3IgRlcgb3INCj5JRFMpIGFuZCByZW1haW5pbmcgcGFja2V0cyBjYW4gYnlw YXNzIHRoYXQgU0YsIHRodXMgc2F2aW5nIHRoZSANCj5leHBlbnNpdmUgU0YgcmVzb3VyY2UgYW5k IHJlZHVjaW5nIGRhdGEgcGF0aCBsYXRlbmN5Lg0KPg0KPkIgYml0OiBUaGUgQiAoQnlwYXNzKSBi aXQsIHdoZW4gc2V0IHRvIDEsIGl0IGlzIHVzZWQgYnkgYSBTZXJ2aWNlDQo+ICAgICAgIEZ1bmN0 aW9uIHRvIHNpZ25hbCB0byBpdHMgU2VydmljZSBGdW5jdGlvbiBGb3J3YXJkZXIgdGhhdCBubw0K PiAgICAgICBmdXJ0aGVyIHBhY2tldHMgYXJlIHRvIGJlIHNlbnQgdG8gaXQgZm9yIHRoZSBmbG93 IHNwZWNpZmllZCBpbiANCj5lbmNhcHN1bGF0ZWQgcGFja2V0Lg0KPg0KPkluIGFkZGl0aW9uLCBT Q0ggZGVmaW5lcyBhIG1ldGFkYXRhIHR5cGUgZm9yIEdlbmVyaWMgQ29udGV4dCBCbG9jaywgDQo+ d2hpY2ggaXMgb3B0aW9uYWwgYW5kIGNhbiBiZSB1c2VkIGlmIG5lZWRlZCB0byBjYXJyeSBhbnkg dmVuZG9yJ3MgDQo+c3BlY2lmaWMgIkNvbnRleHQgSGVhZGVyIi4NCj4NCj5BbnkgY29tbWVudHMg b24gdGhlc2UgbmV3IGFkZGl0aW9ucz8NCj4NCj5UaGFua3MsDQo+Q2F0aHkNCj4NCj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQ2F0aHkgWmhhbmcNCj5TZW50OiBGcmlkYXksIERlY2VtYmVyIDA1 LCAyMDE0IDExOjQ3IEFNDQo+VG86IFNyaW5pIEFkZGVwYWxsaTsgUmVpbmFsZG8gUGVubm8gKHJl cGVubm8pOyBKb2VsIE0uIEhhbHBlcm47IA0KPidzZmNAaWV0Zi5vcmcnDQo+Q2M6IG5zbXVydGh5 QGZyZWVzY2FsZS5jb20NCj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0 DQo+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0K Pg0KPlJvbiwgTG91aXMsIE15byBhbmQgSSBoYXZlIGJlZW4gZGlzY3Vzc2luZyBvZmYgbGluZSBs YXN0IGZldyB3ZWVrcyANCj5hYm91dCBkZWZpbmluZyBhIG1ldGFkYXRhIHR5cGUgZm9yIGZsb3cg SUQgaW4gYWRkaXRpb24gdG8gdGhlIHBhdGggSUQgDQo+b2YgdGhlIG1haW4gaGVhZGVyIHRvIHN1 cHBvcnQgbG9hZCBiYWxhbmNpbmcgYW1vbmcgU0YgaW5zdGFuY2VzLiBXZSANCj53aWxsIGRlZmlu ZSBhIFRMViB0eXBlIGZvciB0aGUgZmxvdyBJRC4gVGhlIGNvbWJpbmF0aW9uIG9mICJwYXRoIElE ICsgZmxvdyBJRCINCj5zcGVjaWZpZXMgYSByZWFsaXplZCBzZXJ2aWNlIGNoYWluIGluc3RhbmNl IHBhdGguIEl0IGlzIGxlZnQgdG8gdGhlIA0KPmRlc2lnbi9pbXBsZW1lbnRhdGlvbiB3aGV0aGVy IHRvIHVzZSBhIGNlbnRyYWxpemVkIG1ldGhvZCBvciBhIA0KPmRpc3RyaWJ1dGVkIG1ldGhvZCB0 byBiaW5kIHRoZSBmbG93IElEIHRvIGEgcmVhbGl6ZWQgc2VydmljZSBpbnN0YW5jZSANCj5wYXRo IGFsdGhvdWdoIG91ciBvcmlnaW5hbCB0aG91Z2h0IGlzIGZvciBkaXN0cmlidXRlZCBMQiB1c2Fn ZS4gSSBhbSANCj5ub3Qgc3VyZSBpZiB3ZSBuZWVkIGEgYml0IGluIHRoZSBoZWFkZXIgdG8gZGVu b3RlIHdoZXRoZXIgdGhlcmUgYXJlIA0KPm1vcmUgcGF0aCBJRCBiaXRzICh3ZSBjYWxsIGl0IGZs b3cgSUQpIGluIHRoZSBtZXRhZGF0YSBmaWVsZHMgc2luY2UgDQo+d2hlbiB5b3UgcGFyc2UgdGhl IFRMViBtZXRhZGF0YSwgeW91IHdpbGwga25vdyB3aGV0aGVyIHRoZXJlIGFyZSBmbG93IElEIGJp dHMgb3Igbm90Lg0KPk5vdGUgdGhhdCBpZiBtdWx0aXBsZSBzZXNzaW9ucyBzaGFyZSB0aGUgc2Ft ZSByZWFsaXplZCBzZXJ2aWNlIGluc3RhbmNlIA0KPnBhdGgsIHRoZXkgd2lsbCBzaGFyZSB0aGUg c2FtZSAicGF0aCBJRCsgZmxvdyBJRCIuICBXZSBjYW4gYWxzbyANCj5jb25zaWRlciBleHRlbmRp bmcgdGhlIG51bWJlciBvZiBiaXRzIHRvIDMyIGlmIHRoYXQgaXMgdGhlIGNvbnNlbnN1cy4NCj5X ZSB3aWxsIHBvc3QgYW4gdXBkYXRlZCBkcmFmdCBkZXNjcmliaW5nIHRoZXNlIHNvb24uDQo+DQo+ VGhhbmtzLA0KPkNhdGh5DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBz ZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNyaW5pIEFkZGVw YWxsaQ0KPlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDUsIDIwMTQgNzoxNyBBTQ0KPlRvOiBSZWlu YWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4gSGFscGVybjsgJ3NmY0BpZXRmLm9yZycNCj5D YzogbnNtdXJ0aHlAZnJlZXNjYWxlLmNvbQ0KPlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBv biBTQ0ggRHJhZnQNCj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNm Yy1zY2gtMDIpDQo+DQo+DQo+W1JQXSBEYXRhIHBsYW5lIGVmZmljaWVuY3kuDQo+DQo+U1JJTkk+ IEkgYW0gbm90IHNvIHN1cmUgYWJvdXQgZGF0YSBwbGFuZSBlZmZpY2llbmN5LiAgTW9zdCBvZiB0 aGUNCj5wcm9jZXNzb3JzIHdvcmsgZ29vZCBpZiB0aGUgbnVtYmVyIG9mIGJpdHMgYXJlIGVpdGhl ciAzMiBvciA2NC4gIElmIGl0IA0KPmlzDQo+MjQgYml0cywgdGhlbiBvbmUgbmVlZHMgdG8gZG8g bWFza2luZyBhbmQgc2hpZnRpbmcgYmVmb3JlIHRoZSB2YWx1ZSBpcw0KPnVzZWQgdG8gZG8gYW55 IGxvb2t1cC4gICBCdXQsIHRoaXMgZGlzY3Vzc2lvbiBjYW4gZ28gaW50byBkaWZmZXJlbnQNCj5k aXJlY3Rpb24gOi0pLCBpdCBtYXkgbm90IGJlIGdvb2QgdG8gZ28gaW4gdGhhdCBkaXJlY3Rpb24u DQo+DQo+V2hlcmUgZG8gd2UgZHJhdyB0aGUgbGluZT8gMzItYml0cywgNjQtYml0cywNCj4xMjgg Yml0cz8gSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRoZSBTZXJ2 aWNlIFBhdGggDQo+aGVhZGVyIGFuZCBpZiB5b3UgbmVlZCB0byBjb252ZXkgbW9yZSBiaXRzIHlv dSBuZWVkIHRvIHVzZSB0aGUgY29udGV4dCANCj5oZWFkZXJzLg0KPg0KPlNSSU5JPiBUaGlzIGlz IGEgZ29vZCBwb2ludC4gIFRoaXMgc2hvdWxkIHdvcmsgZmluZSBhcyBsb25nIGFzIHRoZXJlIGlz DQo+d2F5IHRvIGNvbnZleSBpbiB0aGUgbWFpbiBoZWFkZXIgdGhhdCB0aGUgZXh0ZW5zaW9uIHRv IHBhdGggSUQgaXMgDQo+YXZhaWxhYmxlIGluIHNvIGFuZCBzbyBUTFYgZmllbGQuICBUaGF0IHNo b3VsZCB3b3JrIHRvby4NCj4NCj5UaGFua3MNCj5TcmluaQ0KPg0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5Gcm9tOiBSZWluYWxkbyBQZW5ubyAocmVwZW5ubykg PHJlcGVubm9AY2lzY28uY29tPg0KPlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgNSwgMjAxNCA3OjA4 IEFNDQo+VG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IEpvZWwgTS4gSGFscGVybjsgJ3NmY0Bp ZXRmLm9yZycNCj5DYzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDANCj5TdWJqZWN0OiBSZTog W3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPg0KPk9uIDEyLzUvMTQsIDY6NTQgQU0sICJTcmlu aSBBZGRlcGFsbGkiIDxzYWRkZXBhbGxpQGZyZWVzY2FsZS5jb20+IHdyb3RlOg0KPg0KPj4NCj4+ SW4gcmVhbCBkZXBsb3ltZW50cywgbnVtYmVyIG9mIGFjdGl2ZSBwYXRoIElEcyBhcmUgdmVyeSBs ZXNzZXIgdGhhbiANCj4+Ml42NCwgYnV0IHRoZXJlIGlzIGEgZ29vZCBwb3NzaWJpbGl0eSBvZiB0 aGUgbnVtYmVyIGJlaW5nIG1vcmUgdGhhbg0KPj4yXjI0ICgxNk0pLg0KPj4gSSB0aGluayBiaWdn ZXIgcG9pbnQgaXMgdGhhdCB3aHkgcmVzdHJpY3QgdGhpcyBpbiB0aGUgc3RhbmRhcmRzPyBXaGF0 IA0KPj5hZHZhbnRhZ2UgZG8gd2UgaGF2ZSByZXN0cmljdGluZyB0aGlzIHNpemUgdG8gMjQgYml0 cz8NCj4NCj5bUlBdIERhdGEgcGxhbmUgZWZmaWNpZW5jeS4gV2hlcmUgZG8gd2UgZHJhdyB0aGUg bGluZT8gMzItYml0cywgDQo+NjQtYml0cywNCj4xMjggYml0cz8gSSB0aGluayB3ZSBzaG91bGQg aGF2ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRoZSBTZXJ2aWNlIFBhdGggDQo+aGVhZGVyIGFuZCBp ZiB5b3UgbmVlZCB0byBjb252ZXkgbW9yZSBiaXRzIHlvdSBuZWVkIHRvIHVzZSB0aGUgY29udGV4 dCANCj5oZWFkZXJzLg0KPg0KPg0KPj4NCj4+VGhlcmUgY2FuIGJlIGRlcGxveW1lbnRzLCB3aGVy ZSBTRkMgY29udHJvbGxlciAoTG9naWNhbGx5IGNlbnRyYWwsIGJ1dA0KPj5kaXN0cmlidXRlZCkg IGl0c2VsZiBjYW4gZG8gdGhlIFNGIGluc3RhbmNlIHNlbGVjdGlvbiBvbiBwZXINCj4+Y29ubmVj dGlvbi9zZXNzaW9uIGJhc2lzLCB0aGVyZWJ5IGF2b2lkaW5nIHRoZSBMQnMgZm9yIHNlcnZpY2Vz LiAgIEluIG15DQo+PnZpZXcsIGFzc3VtcHRpb24gdGhhdCB0aGVyZSB3aWxsIGJlIExCIFNGIGZv ciBlYWNoIHNjYWxlLW91dCBzZXJ2aWNlIA0KPj5pbiB0aGUgY2hhaW4gaXMgbm90IHZhbGlkIGlu IGFsbCBjYXNlcy4NCj4+DQo+PlRoYW5rcw0KPj5TcmluaQ0KPj4NCj4+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5Gcm9tOiBSZWluYWxkbyBQZW5ubyAocmVwZW5u bykgPHJlcGVubm9AY2lzY28uY29tPg0KPj5TZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgNCwgMjAx NCAxOjE3IFBNDQo+PlRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47 IHNmY0BpZXRmLm9yZw0KPj5DYzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDANCj4+U3ViamVj dDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4oaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+Pg0KPj5JZiBJIHVuZGVyc3Rvb2Qg eW91LCBJIGRvIG5vdCB0aGluayB0aGlzIGlzIHJlYWxpc3RpYy4gQXJlIHlvdSBzYXlpbmcgDQo+ PnlvdSBuZWVkIDY0LWJpdHMgb2YgcGF0aHMgYW5kIHRoZW4gd2lsbCBtb25pdG9yIHRoZW0gYWxs PyBEbyBmYXVsdCANCj4+dG9sZXJhbmNlIGFuZCBPQU0gZm9yIDJeNjQtYml0cyB3b3J0aCBvZiBw YXRocz8gSnVzdCBmb3IgY29tcGFyaXNvbiwgDQo+Pml0wrlzIGxpa2UgbWFuYWdpbmcgYW5kIG1v bml0b3JpbmcgdGhlIGVudGlyZSBJUHY2IGhvc3QgcmFuZ2UsIG9uZS1ieS1vbmUuDQo+Pg0KPj5B bnl3YXksIEkgZG8gbm90IGV4cGVjdCBldmVyeSBzaW5nbGUgcGVybXV0YXRpb25zIHRvIGJlIGEg ZGlmZmVyZW50IHBhdGguDQo+Pg0KPj5JZiBlYWNoIHNlcnZpY2UgaGFzIDI1NiBkZXZpY2VzIHBy b3ZpZGluZyBzaW1pbGFyIHNlcnZpY2UsIHlvdSBzaG91bGQgDQo+Pm1vc3QgbGlrZWx5IHVzZSBs b2FkLWJhbGFuY2luZyBhbmQgdGhlbiB5b3Ugd291bGQgaGF2ZSBhIHNpbmdsZSAob3IgYQ0KPj5m ZXcpIHBhdGhzLiBUaGVyZSBpcyBzb21lIGRpc2N1c3Npb24gZ29pbmcgb24gTEIuDQo+Pg0KPj5G cm9tIGEgZGF0YSBwbGFuZSBwZXJzcGVjdGl2ZSwgdGhlIHBhdGggaXMgdWx0aW1hdGVseSBkZWZp bmVkIGJ5IHRoZSANCj4+U0ZGcyB0cmF2ZXJzZWQgYW5kIHNlcnZpY2VzIHByb3ZpZGVkLCBub3Qg YnkgYSBzcGVjaWZpYyBJUDpwb3J0IHRoYXQgDQo+PnRoZSBkZXZpY2UgcHJvdmlkaW5nIHRoZSBz ZXJ2aWNlIHNpdHMgb24uIFdlbGwsIGF0IGxlYXN0IGZyb20gYQ0KPj5HUEUrTlNIIHBlcnNwZWN0 aXZlLg0KPj4NCj4+DQo+Pk9uIDEyLzQvMTQsIDEyOjU3IFBNLCAiU3JpbmkgQWRkZXBhbGxpIiA8 c2FkZGVwYWxsaUBmcmVlc2NhbGUuY29tPiB3cm90ZToNCj4+DQo+Pj5JZiBJIHRha2UgYSBjaGFp biB3aXRoIDUgc2VydmljZXMgd2l0aCBlYWNoIHNlcnZpY2UgIHNheSBoYXZpbmcgMjU2IA0KPj4+ aW5zdGFuY2VzIGZvciBzY2FsZS1vdXQsIHBvc3NpYmxlIG51bWJlciBvZiBwYXRocyBhcmUNCj4+ PjI1NioyNTYqMjU2KjI1NioyNTYgPSAweEZGIEZGIEZGIEZGIEZGLiBPbmUgcmVxdWlyZXMgMzMg Yml0cyBpbiB0aGlzIA0KPj4+Y2FzZS4gIElmIHRoZXJlIGFyZSBtb3JlIHNlcnZpY2VzIGluIHRo ZSBjaGFpbiBvciBtb3JlIGNoYWlucyBvciBtb3JlIA0KPj4+aW5zdGFuY2VzIGZvciBzY2FsZS1v dXQsIHRoZW4gaXQgY291bGQgZ28gdG8gYmlnIG51bWJlciB2ZXJ5IGZhc3QuDQo+Pj4NCj4+PkFz IEkgbWVudGlvbmVkIG15IHByZWZlcmVuY2UgaXMgdG8gbWFrZSB0aGUgcGF0aCBJRCBzaXplIGZs ZXhpYmxlIGZvciANCj4+PmZ1dHVyZSBncm93dGguIElmIHRoYXQgaXMgcGVyY2VpdmVkIGFzIGNv bXBsZXgsIHRoZW4gZ29pbmcgZm9yIDY0Yml0IA0KPj4+aXMgc2FmZXIgYmV0Lg0KPj4+DQo+Pj5U aGFua3MNCj4+PlNyaW5pDQo+Pj4NCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+PkZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+ Pj5TZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMDQsIDIwMTQgMTI6MDUgUE0NCj4+PlRvOiBBZGRl cGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47IHNmY0BpZXRmLm9yZw0KPj4+Q2M6 IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+Pj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVu dHMgb24gU0NIIERyYWZ0DQo+Pj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpo YW5nLXNmYy1zY2gtMDIpDQo+Pj4NCj4+PkEgY29udHJvbGxlciAob3Igb3RoZXIgZGVjaXNpb24g bG9naWMpIGNhbiBjZXJ0YWlubHkgYmUgYXdhcmUgb2Ygc3VjaCANCj4+PmNvbmNlcm5zLg0KPj4+ QnV0IHRoZSBudW1iZXIgb2Ygc2VydmljZSBmdW5jdGlvbiBwYXRocyBpcyBub3QgcmVsYXRlZCB0 byB0aGUgbnVtYmVyIA0KPj4+b2YgZmxvd3Mgb3IgdGhlIG51bWJlciBvZiB0ZW5hbnRzLiAgSXQg aXMgcmVsYXRlZCB0byB0aGUgbnVtYmVyIG9mIA0KPj4+Y29tYmluYXRpb25zIG9mIHNlcnZpY2Vz IGFuZCB0aGUgcG9saWNpZXMgZm9yIHNlcnZpY2UgZnVuY3Rpb24gDQo+Pj5zZWxlY3Rpb24uDQo+ Pj4gV2hpbGUgdGhhdCBjYW4gYmUgYSBsYXJnZSBudW1iZXIsIEkgc3VyZSBob3BlIGl0IGRvZXMg bm90IGNvbWUgY2xvc2UgDQo+Pj50byBzYXR1cmF0aW5nIDI0IGJpdHMuDQo+Pj4NCj4+Pkhhdmlu ZyBzYWlkIHRoYXQsIGlmIHdlIHRoaW5rIHRoYXQgMjQgYml0cyBpcyBvbmx5IGp1c3QgZW5vdWdo LCB0aGVuIA0KPj4+d2Ugb3VnaHQgdG8gdXNlIDMyLiAgRnJvbSB3aGVyZSBJIHNpdCwgSSB3b3Vs ZCBub3JtYWxseSBleHBlY3QgMTYgDQo+Pj5iaXRzIHRvIGJlIG1vcmUgdGhhbiBzdWZmaWNpZW50 LCB3aGljaCBpcyB3aHkgSSBhbSBjb21mb3J0YWJsZSB3aXRoIDI0Lg0KPj4+SGF2aW5nIHNhaWQg dGhhdCwgdGhlIGZpZWxkIHNpemUgaXMgbm90IGEgYmlnIGRlYWwgdG8gbWUuDQo+Pj4NCj4+Pllv dXJzLA0KPj4+Sm9lbA0KPj4+DQo+Pj5PbiAxMi80LzE0LCAyOjAxIFBNLCBTcmluaSBBZGRlcGFs bGkgd3JvdGU6DQo+Pj4+DQo+Pj4+IEkgd2FzIG5vdCBpbXBseWluZyB0aGF0IHBhdGggSUQgc2hv dWxkIGhhdmUgaW5mb3JtYXRpb24gaW4gcmVnYXJkcyANCj4+Pj50byB0ZW5hbnQvY29udHJvbGxl ci9mbG93L3NjYWxlLW91dC4gIEJ1dCBTRkMgY29udHJvbGxlcnMgc2hvdWxkIA0KPj4+PmtlZXAg dGhlc2UNCj4+Pj5pbiBtaW5kIHRvIGFzc2lnbiB0aGUgcGF0aCBJRC4gICAgQSBkZXBsb3ltZW50 IGNhbiBoYXZlIG11bHRpcGxlDQo+Pj4+dGVuYW50cywgZWFjaCB0ZW5hbnQgY2FuIGhhdmUgbXVs dGlwbGUgbmV0d29ya3MsICB0aGVyZSBjb3VsZCBiZSANCj4+Pj5taWxsaW9ucyBvZiBmbG93cyBp biBlYWNoIG9mIHRob3NlIG5ldHdvcmtzLiAgQW5kIGNvbnNpZGVyaW5nIGFsbCANCj4+Pj50aGVz ZSwNCj4+Pj4gMjQgYml0IHBhdGggSUQgbWF5IG5vdCBiZSBhYmxlIHRvIHJlcHJlc2VudCBwYXRo cyBmb3IgdGhlc2UgZmxvd3MuDQo+Pj4+SGVuY2UsIEkgd2FzIHdvbmRlcmluZyB3aGV0aGVyIHBh dGggSUQgY2FuIGJlIGV4dGVuZGVkIHRvIDY0IGJpdHMgb3IgDQo+Pj4+bWFrZSBpdCBmbGV4aWJs ZS4NCj4+Pj4NCj4+Pj4gVGhhbmtzDQo+Pj4+IFNyaW5pDQo+Pj4+DQo+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJu IDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4+PiBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgNCwg MjAxNCA3OjQyIEFNDQo+Pj4+IFRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBzZmNAaWV0Zi5v cmcNCj4+Pj4gQ2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+Pj4+IFN1YmplY3Q6IFJl OiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4+Pj4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4+Pg0KPj4+PiBUaGUgSW5kZXggaXMg bm90IGp1c3QgZm9yIGxvb3AgcHJldmVudGlvbi4gIEluIHRoZSBjYXNlIG9mIA0KPj4+PmFtYmln dWl0eSwgdGhlIGluZGV4IHRlbGxzIHRoZSBTRkYgd2hlcmUgaW4gdGhlIHBhdGggdGhlIHBhY2tl dCANCj4+Pj5jdXJyZW50bHkgcmVzaWRlcy4NCj4+Pj4gICAgVGhlcmUgYXJlIG11bHRpcGxlIHdh eXMgc3VjaCBhbWJpZ3VpdHkgY2FuIG9jY3VyLg0KPj4+Pg0KPj4+PiBUaGUgUGF0aCBJZGVudGlm aWVyIGlzIHNwZWNpZmljYWxseSBub3QgZXhwZWN0ZWQgdG8gaW5jbHVkZSANCj4+Pj4gY29udHJv bGxlciBJRCBvciBUZW5hbnQgSUQuICBXaGlsZSBhIGRlcGxveWVyIGNhbiBoYXZlIGEgcGF0aCBw ZXIgDQo+Pj4+IHRlbmFudCwgdGhlIGFyY2hpdGVjdHVyZSBzdGlsbCBkb2VzIG5vdCB0cmVhdCB0 aGUgcGF0aCBJRCBhcyBhIA0KPj4+PiB0ZW5hbnQgSUQuICBUZW5hbnQgSUQsIGNvbnRyb2xsZXIg SUQsIGFuZCBvdGhlciBub24tcGF0aC1zcGVjaWZ5aW5nIA0KPj4+PiBpbmZvcm1hdGlvbiBpcyB0 byBiZSBjYXJyaWVkIGluIG1ldGFkYXRhLg0KPj4+Pg0KPj4+PiBZb3VycywNCj4+Pj4gSm9lbA0K Pj4+Pg0KPj4+PiBPbiAxMi80LzE0LCAxMDowMiBBTSwgU3JpbmkgQWRkZXBhbGxpIHdyb3RlOg0K Pj4+Pj4gVHdvIGNvbW1lbnRzIDoNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gMS4gIFNGIEluZGV4IDog IFNpbmNlIGl0IGlzIG1lYW50IGZvciBsb29wIGRldGVjdGlvbiwgIHdvdWxkbid0IA0KPj4+Pj4g YmV0dGVyIHRvIHJlbmFtZSB0aGlzIGFzICJUVEwiPw0KPj4+Pj4NCj4+Pj4+IDIuICBQYXRoIElk ZW50aWZpZXIgOiAgICAyNCBiaXQgcGF0aCBpZGVudGlmaWVyIHNlZW1zIHRvIGJlIHRvbyBsZXNz Lg0KPj4+Pj4gQmFzZWQgb24gb3VyIGV4cGVyaWVuY2UgaW4gdHJhZmZpYyBzdGVlcmluZywgIHRo aXMgcGF0aCBpZGVudGlmaWVyIA0KPj4+Pj5uZWVkcyB0byBlbmNvZGUgZ29vZCBhbW91bnQgb2Yg aW5mb3JtYXRpb24gdG8gbWFrZSBpdCB1bmlxdWUuICBGb3IgDQo+Pj4+PmV4YW1wbGUsDQo+Pj4+ PiAgICB0aGlzIGlkZW50aWZpZXIgbmVlZHMgdG8gZW5jb2RlIChpbiBvdXIgY2FzZSkgc29tZSBp bmZvcm1hdGlvbiANCj4+Pj4+cmVwcmVzZW50aW5nIHRoZSBkaXN0cmlidXRlZCBjb250cm9sbGVy IElELCAgdGVuYW50IElELCAgZmxvdyBJRCwNCj4+Pj4+ICAgIFNlcnZpY2UgZnVuY3Rpb24gaW5z dGFuY2UgKGluIGNhc2Ugb2Ygc2NhbGUtb3V0KSBhbmQgZmV3IG1vcmUuLg0KPj4+Pj4gT25lIHN1 Z2dlc3Rpb24gaXMgdG8gbWFrZSBpdCA2NCBiaXRzIHZhbHVlICBvciB0byBtYWtlIGl0IGV2ZW4g DQo+Pj4+PmV4dGVuZGFibGUsDQo+Pj4+PiAgICBpdCBpcyBnb29kIGlmIHBhdGggaWRlbnRpZmll ciBpcyBhbHNvIHJlcHJlc2VudGVkIGluIFRMViBmb3JtLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBU aGFua3MNCj4+Pj4+DQo+Pj4+PiBTcmluaQ0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+ PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+Pg0KPj4+DQo+Pj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+c2ZjIG1haWxpbmcgbGlz dA0KPj4+c2ZjQGlldGYub3JnDQo+Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPj4NCj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPnNmYyBtYWlsaW5nIGxpc3QNCj5zZmNAaWV0Zi5vcmcNCj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRm Lm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+DQo+ VGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgKHRoZSAibWVzc2FnZSIpIGFyZSBjb25m aWRlbnRpYWwsIA0KPmludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZXMuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCANCj5yZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSANCj50aGlzIG1lc3NhZ2UgZnJvbSB5 b3VyIHN5c3RlbS4gSW4gdGhpcyBjYXNlLCB5b3UgYXJlIG5vdCBhdXRob3JpemVkIHRvIA0KPnVz ZSwgY29weSB0aGlzIG1lc3NhZ2UgYW5kL29yIGRpc2Nsb3NlIHRoZSBjb250ZW50IHRvIGFueSBv dGhlciBwZXJzb24uDQo+RS1tYWlscyBhcmUgc3VzY2VwdGlibGUgdG8gYWx0ZXJhdGlvbi4gTmVp dGhlciBRb3Ntb3Mgbm9yIGFueSBvZiBpdHMgDQo+c3Vic2lkaWFyaWVzIG9yIGFmZmlsaWF0ZXMg c2hhbGwgYmUgbGlhYmxlIGZvciB0aGUgbWVzc2FnZSBpZiBhbHRlcmVkLCANCj5jaGFuZ2VkIG9y IGZhbHNpZmllZC4NCj4NCj5DZSBtZXNzYWdlIGV0IHRvdXRlcyBzZXMgcGnDqGNlcyBqb2ludGVz IChjaS1hcHLDqHMgbGUgIm1lc3NhZ2UiKXNvbnQgDQo+Y29uZmlkZW50aWVscyBldCDDqXRhYmxp cyDDoCBsJ2ludGVudGlvbiBleGNsdXNpdmUgZGUgc2VzIGRlc3RpbmF0YWlyZXMuDQo+U2kgdm91 cyBhdmV6IHJlw6d1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgbWVyY2kgZOKAmWVuIGluZm9ybWVy IA0KPmltbcOpZGlhdGVtZW50IHNvbiDDqW1ldHRldXIgcGFyIGNvdXJyaWVyIMOpbGVjdHJvbmlx dWUgZXQgZOKAmWVmZmFjZXIgY2UgDQo+bWVzc2FnZSBkZSB2b3RyZSBzeXN0w6htZS4gRGFucyBj ZXR0ZSBoeXBvdGjDqHNlLCB2b3VzIG7igJnDqnRlcyBwYXMgDQo+YXV0b3Jpc8OpIMOgIHV0aWxp c2VyLCBjb3BpZXIgY2UgbWVzc2FnZSBldC9vdSBlbiBkaXZ1bGd1ZXIgbGUgY29udGVudSDDoCAN Cj51biB0aWVycy4gVG91dCBtZXNzYWdlIMOpbGVjdHJvbmlxdWUgZXN0IHN1c2NlcHRpYmxlIGQn YWx0w6lyYXRpb24uDQo+UW9zbW9zIGV0IHNlcyBmaWxpYWxlcyBkw6ljbGluZW50IHRvdXRlIHJl c3BvbnNhYmlsaXTDqSBhdSB0aXRyZSBkZSBjZSANCj5tZXNzYWdlIHMnaWwgYSDDqXTDqSBhbHTD qXLDqSwgZMOpZm9ybcOpIG91IGZhbHNpZmnDqS4NCj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBtYWlsaW5nIGxpc3QNCj5zZmNAaWV0Zi5vcmcN Cj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQpUaGlzIG1lc3Nh Z2UgYW5kIGFueSBhdHRhY2htZW50cyAodGhlICJtZXNzYWdlIikgYXJlIGNvbmZpZGVudGlhbCwg aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2Vlcy4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5 IGUtbWFpbCBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBmcm9tIHlvdXIgc3lzdGVtLiBJbiB0aGlz IGNhc2UsIHlvdSBhcmUgbm90IGF1dGhvcml6ZWQgdG8gdXNlLCBjb3B5IHRoaXMgbWVzc2FnZSBh bmQvb3IgZGlzY2xvc2UgdGhlIGNvbnRlbnQgdG8gYW55IG90aGVyIHBlcnNvbi4gRS1tYWlscyBh cmUgc3VzY2VwdGlibGUgdG8gYWx0ZXJhdGlvbi4gTmVpdGhlciBRb3Ntb3Mgbm9yIGFueSBvZiBp dHMgc3Vic2lkaWFyaWVzIG9yIGFmZmlsaWF0ZXMgc2hhbGwgYmUgbGlhYmxlIGZvciB0aGUgbWVz c2FnZSBpZiBhbHRlcmVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KQ2UgbWVzc2FnZSBldCB0 b3V0ZXMgc2VzIHBpw6hjZXMgam9pbnRlcyAoY2ktYXByw6hzIGxlICJtZXNzYWdlIilzb250IGNv bmZpZGVudGllbHMgZXQgw6l0YWJsaXMgw6AgbCdpbnRlbnRpb24gZXhjbHVzaXZlIGRlIHNlcyBk ZXN0aW5hdGFpcmVzLiBTaSB2b3VzIGF2ZXogcmXDp3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCBt ZXJjaSBk4oCZZW4gaW5mb3JtZXIgaW1tw6lkaWF0ZW1lbnQgc29uIMOpbWV0dGV1ciBwYXIgY291 cnJpZXIgw6lsZWN0cm9uaXF1ZSBldCBk4oCZZWZmYWNlciBjZSBtZXNzYWdlIGRlIHZvdHJlIHN5 c3TDqG1lLiBEYW5zIGNldHRlIGh5cG90aMOoc2UsIHZvdXMgbuKAmcOqdGVzIHBhcyBhdXRvcmlz w6kgw6AgdXRpbGlzZXIsIGNvcGllciBjZSBtZXNzYWdlIGV0L291IGVuIGRpdnVsZ3VlciBsZSBj b250ZW51IMOgIHVuIHRpZXJzLiBUb3V0IG1lc3NhZ2Ugw6lsZWN0cm9uaXF1ZSBlc3Qgc3VzY2Vw dGlibGUgZCdhbHTDqXJhdGlvbi4gUW9zbW9zIGV0IHNlcyBmaWxpYWxlcyBkw6ljbGluZW50IHRv dXRlIHJlc3BvbnNhYmlsaXTDqSBhdSB0aXRyZSBkZSBjZSBtZXNzYWdlIHMnaWwgYSDDqXTDqSBh bHTDqXLDqSwgZMOpZm9ybcOpIG91IGZhbHNpZmnDqS4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Mon Feb 2 11:13: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 E60371A1A5F for ; Mon, 2 Feb 2015 11:13:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, 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 5QEJae0mgBIc for ; Mon, 2 Feb 2015 11:12:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4DA1A1A42 for ; Mon, 2 Feb 2015 11:12:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSA05914; Mon, 02 Feb 2015 19:12:55 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Feb 2015 19:12:54 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.133]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0158.001; Mon, 2 Feb 2015 11:12:43 -0800 From: Henry Fourie To: Srini Addepalli , Cathy Zhang , "Reinaldo Penno (repenno)" , "Joel M. Halpern" , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZyAGG+AgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgD//7j7oIBVIj4ggAV7CICAAhlRkA== Date: Mon, 2 Feb 2015 19:12:42 +0000 Message-ID: <0F8583BBE82FA449A8B78417CC07559A091958F9@SJCEML701-CHM.china.huawei.com> References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com>, <1417792592229.41970@freescale.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.69] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "nsmurthy@freescale.com" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 02 Feb 2015 19:13:08 -0000 Srini, The RSP Identifier refers to the Rendered Service Path (RSP) as defined= in Section 1.3 of the SFC architecture draft: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ The RSP is a constrained SFP. The RSP ID is 32 bits. See section 4.3.2 Rendered Service Path Identifier in https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ - Louis -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Srini Addepalli Sent: Saturday, January 31, 2015 6:49 PM To: Cathy Zhang; Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf.org' Cc: nsmurthy@freescale.com Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) Hi Cathy, I went through RSP section of the document. RSP-ID can be used to represen= t the service function instance whereas "path identifier' can be used to re= present the chain. New RSP-ID avoids overloading path ID with the SFIs. Th= at is good. Was there any specific reason to call this as 'RSP-ID', instead of calling = it as SFI-ID? You have mentioned that RSP-ID as 2 bytes. Could we leave the size be flex= ible instead of limiting the size to 2 bytes? Thanks Srini -----Original Message----- From: Cathy Zhang [mailto:Cathy.H.Zhang@huawei.com] Sent: Thursday, January 29, 2015 11:44 AM To: Cathy Zhang; Addepalli Srini-B22160; Reinaldo Penno (repenno); Joel M. = Halpern; 'sfc@ietf.org' Cc: NS Srinivasa Murthy-B37840 Subject: RE: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) Hi everyone, We have uploaded a new SCH version (3) which adds definition of a new metad= ata type for the flow ID to support load balancing among SF instances and m= itigate the potential issue of "not enough path ID". The flow ID is named "= rendered service path ID" in the draft. Please refer to section 4.3.2 of ht= tps://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ for detail description.= =20 In its previous version, SCH defines a "Bypass bit" in the base header. Thi= s bit enables the SF to provide feedback/notification via the data path to = its connecting SFF about whether the remaining packets of the SFC should by= pass that SF. This is useful in the case that only the first few packets of= a flow need to go to a SF (such as a DPI or FW or IDS) and remaining packe= ts can bypass that SF, thus saving the expensive SF resource and reducing d= ata path latency. =20 B bit: The B (Bypass) bit, when set to 1, it is used by a Service=20 Function to signal to its Service Function Forwarder that no further packets are to be sent to it for the flow specified in encap= sulated packet. In addition, SCH defines a metadata type for Generic Context Block, which i= s optional and can be used if needed to carry any vendor's specific "Contex= t Header".=20 Any comments on these new additions?=20 Thanks, Cathy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Cathy Zhang Sent: Friday, December 05, 2014 11:47 AM To: Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf.o= rg' Cc: nsmurthy@freescale.com Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) Ron, Louis, Myo and I have been discussing off line last few weeks about de= fining a metadata type for flow ID in addition to the path ID of the main h= eader to support load balancing among SF instances. We will define a TLV ty= pe for the flow ID. The combination of "path ID + flow ID" specifies a real= ized service chain instance path. It is left to the design/implementation w= hether to use a centralized method or a distributed method to bind the flow= ID to a realized service instance path although our original thought is fo= r distributed LB usage. I am not sure if we need a bit in the header to den= ote whether there are more path ID bits (we call it flow ID) in the metadat= a fields since when you parse the TLV metadata, you will know whether there= are flow ID bits or not. Note that if multiple sessions share the same rea= lized service instance path, they will share the same "path ID+ flow ID". = We can also consider extending the number of bits to 32 if that is the cons= ensus. We will post an updated draft describing these soon.=20 Thanks, Cathy -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Srini Addepalli Sent: Friday, December 05, 2014 7:17 AM To: Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf.org' Cc: nsmurthy@freescale.com Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) [RP] Data plane efficiency.=20 SRINI> I am not so sure about data plane efficiency. Most of the processor= s work good if the number of bits are either 32 or 64. If it is 24 bits, t= hen one needs to do masking and shifting before the value is used to do any= lookup. But, this discussion can go into different direction :-), it may= not be good to go in that direction. Where do we draw the line? 32-bits, 64-bits, 128 bits? I think we should have a sensible value in the Service Path heade= r and if you need to convey more bits you need to use the context headers. SRINI> This is a good point. This should work fine as long as there is way= to convey in the main header that the extension to path ID is available in= so and so TLV field. That should work too. Thanks Srini ________________________________________ From: Reinaldo Penno (repenno) Sent: Friday, December 5, 2014 7:08 AM To: Addepalli Srini-B22160; Joel M. Halpern; 'sfc@ietf.org' Cc: NS Srinivasa Murthy-B37840 Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) On 12/5/14, 6:54 AM, "Srini Addepalli" wrote: > >In real deployments, number of active path IDs are very lesser than=20 >2^64, but there is a good possibility of the number being more than 2^24 (= 16M). > I think bigger point is that why restrict this in the standards? What=20 >advantage do we have restricting this size to 24 bits? [RP] Data plane efficiency. Where do we draw the line? 32-bits, 64-bits, 128 bits? I think we should have a sensible value in the Service Path heade= r and if you need to convey more bits you need to use the context headers. > >There can be deployments, where SFC controller (Logically central, but >distributed) itself can do the SF instance selection on per >connection/session basis, thereby avoiding the LBs for services. In my >view, assumption that there will be LB SF for each scale-out service in=20 >the chain is not valid in all cases. > >Thanks >Srini > >________________________________________ >From: Reinaldo Penno (repenno) >Sent: Thursday, December 4, 2014 1:17 PM >To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org >Cc: NS Srinivasa Murthy-B37840 >Subject: Re: [sfc] Comments on SCH Draft >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > >If I understood you, I do not think this is realistic. Are you saying=20 >you need 64-bits of paths and then will monitor them all? Do fault=20 >tolerance and OAM for 2^64-bits worth of paths? Just for comparison,=20 >it=B9s like managing and monitoring the entire IPv6 host range, one-by-one= . > >Anyway, I do not expect every single permutations to be a different path. > >If each service has 256 devices providing similar service, you should=20 >most likely use load-balancing and then you would have a single (or a >few) paths. There is some discussion going on LB. > >From a data plane perspective, the path is ultimately defined by the=20 >SFFs traversed and services provided, not by a specific IP:port that=20 >the device providing the service sits on. Well, at least from a GPE+NSH pe= rspective. > > >On 12/4/14, 12:57 PM, "Srini Addepalli" wrote: > >>If I take a chain with 5 services with each service say having 256=20 >>instances for scale-out, possible number of paths are >>256*256*256*256*256 =3D 0xFF FF FF FF FF. One requires 33 bits in this=20 >>case. If there are more services in the chain or more chains or more=20 >>instances for scale-out, then it could go to big number very fast. >> >>As I mentioned my preference is to make the path ID size flexible for=20 >>future growth. If that is perceived as complex, then going for 64bit=20 >>is safer bet. >> >>Thanks >>Srini >> >> >>-----Original Message----- >>From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>Sent: Thursday, December 04, 2014 12:05 PM >>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org >>Cc: NS Srinivasa Murthy-B37840 >>Subject: Re: [sfc] Comments on SCH Draft >>(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >> >>A controller (or other decision logic) can certainly be aware of such=20 >>concerns. >>But the number of service function paths is not related to the number=20 >>of flows or the number of tenants. It is related to the number of=20 >>combinations of services and the policies for service function selection. >> While that can be a large number, I sure hope it does not come close=20 >>to saturating 24 bits. >> >>Having said that, if we think that 24 bits is only just enough, then=20 >>we ought to use 32. From where I sit, I would normally expect 16 bits=20 >>to be more than sufficient, which is why I am comfortable with 24. >>Having said that, the field size is not a big deal to me. >> >>Yours, >>Joel >> >>On 12/4/14, 2:01 PM, Srini Addepalli wrote: >>> >>> I was not implying that path ID should have information in regards=20 >>>to tenant/controller/flow/scale-out. But SFC controllers should keep th= ese >>>in mind to assign the path ID. A deployment can have multiple >>>tenants, each tenant can have multiple networks, there could be=20 >>>millions of flows in each of those networks. And considering all=20 >>>these, >>> 24 bit path ID may not be able to represent paths for these flows. >>>Hence, I was wondering whether path ID can be extended to 64 bits or=20 >>>make it flexible. >>> >>> Thanks >>> Srini >>> >>> ________________________________________ >>> From: Joel M. Halpern >>> Sent: Thursday, December 4, 2014 7:42 AM >>> To: Addepalli Srini-B22160; sfc@ietf.org >>> Cc: NS Srinivasa Murthy-B37840 >>> Subject: Re: [sfc] Comments on SCH Draft >>> (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >>> >>> The Index is not just for loop prevention. In the case of=20 >>> ambiguity, the index tells the SFF where in the path the packet current= ly resides. >>> There are multiple ways such ambiguity can occur. >>> >>> The Path Identifier is specifically not expected to include=20 >>> controller ID or Tenant ID. While a deployer can have a path per=20 >>> tenant, the architecture still does not treat the path ID as a=20 >>> tenant ID. Tenant ID, controller ID, and other non-path-specifying=20 >>> information is to be carried in metadata. >>> >>> Yours, >>> Joel >>> >>> On 12/4/14, 10:02 AM, Srini Addepalli wrote: >>>> Two comments : >>>> >>>> >>>> 1. SF Index : Since it is meant for loop detection, wouldn't=20 >>>> better to rename this as "TTL"? >>>> >>>> 2. Path Identifier : 24 bit path identifier seems to be too less. >>>> Based on our experience in traffic steering, this path identifier=20 >>>>needs to encode good amount of information to make it unique. For=20 >>>>example, >>>> this identifier needs to encode (in our case) some information=20 >>>>representing the distributed controller ID, tenant ID, flow ID, >>>> Service function instance (in case of scale-out) and few more.. >>>> One suggestion is to make it 64 bits value or to make it even=20 >>>>extendable, >>>> it is good if path identifier is also represented in TLV form. >>>> >>>> >>>> Thanks >>>> >>>> Srini >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 Feb 2 13:57: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 5C3E21A90FD for ; Mon, 2 Feb 2015 13:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, 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 5cYiAm1cloHE for ; Mon, 2 Feb 2015 13:57:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30821A037A for ; Mon, 2 Feb 2015 13:57:46 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSA14083; Mon, 02 Feb 2015 21:57:45 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Feb 2015 21:57:44 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.133]) by SJCEML703-CHM.china.huawei.com ([169.254.5.223]) with mapi id 14.03.0158.001; Mon, 2 Feb 2015 13:57:37 -0800 From: Cathy Zhang To: Nicolas BOUTHORS , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZyAGG+AgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgD//7j7oIBVIj4ggALqPwCABNzMsA== Date: Mon, 2 Feb 2015 21:57:37 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com>, <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.78] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Jerome TOLLET Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 02 Feb 2015 21:57:53 -0000 SGkgTmljb2xhcywNCg0KVGhhbmsgeW91IGZvciB5b3VyIGNvbW1lbnQuIFBsZWFzZSBzZWUgaW5s aW5lIGZvciBteSByZXBseS4NCg0KQ2F0aHkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IE5pY29sYXMgQk9VVEhPUlMgW21haWx0bzpOaWNvbGFzLkJPVVRIT1JTQHFvc21vcy5j b21dIA0KU2VudDogRnJpZGF5LCBKYW51YXJ5IDMwLCAyMDE1IDM6MzggQU0NClRvOiBDYXRoeSBa aGFuZzsgJ3NmY0BpZXRmLm9yZycNCkNjOiBKZXJvbWUgVE9MTEVUDQpTdWJqZWN0OiBSRTogW3Nm Y10gQ29tbWVudHMgb24gU0NIIERyYWZ0IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtemhhbmctc2ZjLXNjaC0wMikNCg0KSGVsbG8gQ2F0aHksDQoNCkluZGVlZCB0aGUgbm90aW9u IG9mICJyZW5kZXJlZCBzZXJ2aWNlIHBhdGggSUQiKFJTUCBJRCkgc2VlbXMgcmVsZXZhbnQgYXMg dGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBzdGlwdWxhdGVzIHRoYXQgdGhlIFNlcnZpY2UgRnVu Y3Rpb24gUGF0aCAoU0ZQKSBwcm92aWRlcyBhbiBhYnN0cmFjdCBub3Rpb24gb2YgYSBzZXJ2aWNl IGNoYWluLCB3aGlsZSB0aGUgUlNQIGlzIGEgY29uc3RyYWluZWQgbGlzdCBvZiBsb2NhdGlvbnMu DQoNClNGQyBoZWFkZXIgIlNlcnZpY2UgUGF0aCBJZGVudGlmaWVyIiAoU1BJKSAgaXMgdXNlZCBp biBib3RoIE5TSCBhbmQgU0NIIHByb3RvY29sIGFuZCBpbiBib3RoIGNhc2Ugc2VlbSB0byBpZGVu dGlmeSB0byBhIHBhcnRpY3VsYXIgU0ZQLg0KDQpOU0godjUpIGZvciBleGFtcGxlIHN0YXRlcyB0 aGF0DQoiIEFzIGRlc2NyaWJlZCBhYm92ZSwgTlNIIGNvbnRhaW5zIGEgc2VydmljZSBwYXRoIGlk ZW50aWZpZXIgKFNQSSkgYW5kDQogICBhIHNlcnZpY2UgaW5kZXggKFNJKS4gIFRoZSBTUEkgaXMs IGFzIHBlciBpdHMgbmFtZSwgYW4gaWRlbnRpZmllci4NCiAgIFRoZSBTUEkgYWxvbmUgY2Fubm90 IGJlIHVzZWQgdG8gZm9yd2FyZCBwYWNrZXRzIGFsb25nIGEgc2VydmljZSBwYXRoLg0KICAgUmF0 aGVyIHRoZSBTUEkgcHJvdmlkZSBhIGxldmVsIG9mIGluZGlyZWN0aW9uIGJldHdlZW4gdGhlIHNl cnZpY2UNCiAgIHBhdGgvdG9wb2xvZ3kgYW5kIHRoZSB0aGUgbmV0d29yayB0cmFuc3BvcnQuICBG dXJ0aGVybW9yZSwgdGhlcmUgaXMNCiAgIG5vIHJlcXVpcmVtZW50LCBvciBleHBlY3RhdGlvbiBv ZiBhbiBTUEkgYmVpbmcgYm91bmQgdG8gYSBwcmUtDQogICBkZXRlcm1pbmVkIG9yIHN0YXRpYyBu ZXR3b3JrIHBhdGguIg0KDQpTdGlsbCBOU0godjUpICBzaG93cyB0aGF0IFNQSSAobm90IGEgUlNQ IElEKSAgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGtleSAgZWxlbWVudCBvZiBhbiBTRkYgdG8gbG9v a3VwIG9uIGZvcndhcmRpbmcgdGFibGVzLiAgQnV0IEkgY291bGQgbm90IGZpbmQgaW4gTlNIICBo b3cgdG8gdXNlIHRoZSBub3Rpb24gb2YNClJlbmRlcmVkIHNlcnZpY2UgcGF0aCB3aGljaCB3YXMg ZGVmaW5lZCBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50Lg0KDQpZb3UgcHJvcG9zYWwgc2Vl bXMgdG8gbWUgdmVyeSB1c2VmdWwsDQoNCkFuIFJTUCBJRCAoaW5kZXBlbmRlbnQgb2YgdGhlIFNQ SSBidXQgcGFydCBvZiB0aGUgc2FtZSBuYW1lIHNwYWNlKSBjb3VsZCBiZSB1c2VkIHRoZSBzYW1l IHdheSBhcyBTUEkgYnkgU0ZGIGZvciBleGFtcGxlLCBhbGxvd2luZyBhIFNlcnZpY2UgQ2xhc3Np ZmllciB0byBjb250cm9sIHJlbW90ZSBsb2FkIGJhbGFuY2luZyBmb3IgZXhhbXBsZS4NCg0KVGhp cyBzYWlkIHRoZSBSU1AgSUQgdmFsdWVzIGNvdWxkIGJlIHJlbGF0aXZlIHRvIGEgcGFydGljdWxh ciBTZXJ2aWNlIFBhdGgsIHdoaWNoIHdvdWxkIHByZXZlbnQgdXNpbmcgdGhlbSBhcyB3ZSBkbyBm b3IgU1BJIGluIFNGRiBmb3J3YXJkaW5nIHRhYmxlcy4NCg0KV2UgbWF5IHdhbnQgdG8gcHJlY2lz ZSBpZiB0aGUgUlNQIElEIGlzIHRvIGJlIHJlbGF0aXZlIG9mIGFic29sdXRlLCBhcyBpdCBzaG91 bGQgaGF2ZSBhbiBpbXBhY3Qgb24gZm9yd2FyZGluZyB0YWJsZSBzdHJ1Y3R1cmUgaWYgd2UgZGVj aWRlIHRvIHVzZSB0aGlzIGNvbmNlcHQuDQoNClBlcnNvbmFsbHkgSSBsaWtlIHRoZSBub3Rpb24g b2YgYSByZWxhdGl2ZSBSU1AgSUQsIGFzIHdlIGNvdWxkIHRoZW4gdXNlIHNvbWUgY29udmVudGlv bnMsIHN0cnVjdHVyZSBpdCwgcG9zc2libHkgZXh0ZW5kaW5nIGl0cyB1c2UuDQoNCg0KQ2F0aHk+ IFllcywgUlNQIElEIGlzIHVuaXF1ZWx5IHNjb3BlZCB3aXRoaW4gdGhlIHNlcnZpY2UgcGF0aCBJ RC4gV2Ugd2lsbCB1cGRhdGUgdGhpcyBpbiB0aGUgbmV4dCB2ZXJzaW9uLiANCg0KDQpOaWNvbGFz DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDYXRoeSBaaGFuZyBbbWFpbHRv OkNhdGh5LkguWmhhbmdAaHVhd2VpLmNvbV0NClNlbnQ6IGpldWRpIDI5IGphbnZpZXIgMjAxNSAy MDo0NA0KVG86IENhdGh5IFpoYW5nOyBTcmluaSBBZGRlcGFsbGk7IFJlaW5hbGRvIFBlbm5vIChy ZXBlbm5vKTsgSm9lbCBNLiBIYWxwZXJuOyAnc2ZjQGlldGYub3JnJw0KQ2M6IG5zbXVydGh5QGZy ZWVzY2FsZS5jb20NClN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQgKGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KDQpIaSBl dmVyeW9uZSwNCg0KV2UgaGF2ZSB1cGxvYWRlZCBhIG5ldyBTQ0ggdmVyc2lvbiAoMykgd2hpY2gg YWRkcyBkZWZpbml0aW9uIG9mIGEgbmV3IG1ldGFkYXRhIHR5cGUgZm9yIHRoZSBmbG93IElEIHRv IHN1cHBvcnQgbG9hZCBiYWxhbmNpbmcgYW1vbmcgU0YgaW5zdGFuY2VzIGFuZCBtaXRpZ2F0ZSB0 aGUgcG90ZW50aWFsIGlzc3VlIG9mICJub3QgZW5vdWdoIHBhdGggSUQiLiBUaGUgZmxvdyBJRCBp cyBuYW1lZCAicmVuZGVyZWQgc2VydmljZSBwYXRoIElEIiBpbiB0aGUgZHJhZnQuIFBsZWFzZSBy ZWZlciB0byBzZWN0aW9uIDQuMy4yIG9mIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXpoYW5nLXNmYy1zY2gvIGZvciBkZXRhaWwgZGVzY3JpcHRpb24uDQoNCkluIGl0cyBw cmV2aW91cyB2ZXJzaW9uLCBTQ0ggZGVmaW5lcyBhICJCeXBhc3MgYml0IiBpbiB0aGUgYmFzZSBo ZWFkZXIuIFRoaXMgYml0IGVuYWJsZXMgdGhlIFNGIHRvIHByb3ZpZGUgZmVlZGJhY2svbm90aWZp Y2F0aW9uIHZpYSB0aGUgZGF0YSBwYXRoIHRvIGl0cyBjb25uZWN0aW5nIFNGRiBhYm91dCB3aGV0 aGVyIHRoZSByZW1haW5pbmcgcGFja2V0cyBvZiB0aGUgU0ZDIHNob3VsZCBieXBhc3MgdGhhdCBT Ri4gVGhpcyBpcyB1c2VmdWwgaW4gdGhlIGNhc2UgdGhhdCBvbmx5IHRoZSBmaXJzdCBmZXcgcGFj a2V0cyBvZiBhIGZsb3cgbmVlZCB0byBnbyB0byBhIFNGIChzdWNoIGFzIGEgRFBJIG9yIEZXIG9y IElEUykgYW5kIHJlbWFpbmluZyBwYWNrZXRzIGNhbiBieXBhc3MgdGhhdCBTRiwgdGh1cyBzYXZp bmcgdGhlIGV4cGVuc2l2ZSBTRiByZXNvdXJjZSBhbmQgcmVkdWNpbmcgZGF0YSBwYXRoIGxhdGVu Y3kuDQoNCkIgYml0OiBUaGUgQiAoQnlwYXNzKSBiaXQsIHdoZW4gc2V0IHRvIDEsIGl0IGlzIHVz ZWQgYnkgYSBTZXJ2aWNlDQogICAgICAgRnVuY3Rpb24gdG8gc2lnbmFsIHRvIGl0cyBTZXJ2aWNl IEZ1bmN0aW9uIEZvcndhcmRlciB0aGF0IG5vDQogICAgICAgZnVydGhlciBwYWNrZXRzIGFyZSB0 byBiZSBzZW50IHRvIGl0IGZvciB0aGUgZmxvdyBzcGVjaWZpZWQgaW4gZW5jYXBzdWxhdGVkIHBh Y2tldC4NCg0KSW4gYWRkaXRpb24sIFNDSCBkZWZpbmVzIGEgbWV0YWRhdGEgdHlwZSBmb3IgR2Vu ZXJpYyBDb250ZXh0IEJsb2NrLCB3aGljaCBpcyBvcHRpb25hbCBhbmQgY2FuIGJlIHVzZWQgaWYg bmVlZGVkIHRvIGNhcnJ5IGFueSB2ZW5kb3IncyBzcGVjaWZpYyAiQ29udGV4dCBIZWFkZXIiLg0K DQpBbnkgY29tbWVudHMgb24gdGhlc2UgbmV3IGFkZGl0aW9ucz8NCg0KVGhhbmtzLA0KQ2F0aHkN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2F0aHkgWmhhbmcNClNlbnQ6IEZyaWRheSwgRGVj ZW1iZXIgMDUsIDIwMTQgMTE6NDcgQU0NClRvOiBTcmluaSBBZGRlcGFsbGk7IFJlaW5hbGRvIFBl bm5vIChyZXBlbm5vKTsgSm9lbCBNLiBIYWxwZXJuOyAnc2ZjQGlldGYub3JnJw0KQ2M6IG5zbXVy dGh5QGZyZWVzY2FsZS5jb20NClN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJh ZnQgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0K DQpSb24sIExvdWlzLCBNeW8gYW5kIEkgaGF2ZSBiZWVuIGRpc2N1c3Npbmcgb2ZmIGxpbmUgbGFz dCBmZXcgd2Vla3MgYWJvdXQgZGVmaW5pbmcgYSBtZXRhZGF0YSB0eXBlIGZvciBmbG93IElEIGlu IGFkZGl0aW9uIHRvIHRoZSBwYXRoIElEIG9mIHRoZSBtYWluIGhlYWRlciB0byBzdXBwb3J0IGxv YWQgYmFsYW5jaW5nIGFtb25nIFNGIGluc3RhbmNlcy4gV2Ugd2lsbCBkZWZpbmUgYSBUTFYgdHlw ZSBmb3IgdGhlIGZsb3cgSUQuIFRoZSBjb21iaW5hdGlvbiBvZiAicGF0aCBJRCArIGZsb3cgSUQi IHNwZWNpZmllcyBhIHJlYWxpemVkIHNlcnZpY2UgY2hhaW4gaW5zdGFuY2UgcGF0aC4gSXQgaXMg bGVmdCB0byB0aGUgZGVzaWduL2ltcGxlbWVudGF0aW9uIHdoZXRoZXIgdG8gdXNlIGEgY2VudHJh bGl6ZWQgbWV0aG9kIG9yIGEgZGlzdHJpYnV0ZWQgbWV0aG9kIHRvIGJpbmQgdGhlIGZsb3cgSUQg dG8gYSByZWFsaXplZCBzZXJ2aWNlIGluc3RhbmNlIHBhdGggYWx0aG91Z2ggb3VyIG9yaWdpbmFs IHRob3VnaHQgaXMgZm9yIGRpc3RyaWJ1dGVkIExCIHVzYWdlLiBJIGFtIG5vdCBzdXJlIGlmIHdl IG5lZWQgYSBiaXQgaW4gdGhlIGhlYWRlciB0byBkZW5vdGUgd2hldGhlciB0aGVyZSBhcmUgbW9y ZSBwYXRoIElEIGJpdHMgKHdlIGNhbGwgaXQgZmxvdyBJRCkgaW4gdGhlIG1ldGFkYXRhIGZpZWxk cyBzaW5jZSB3aGVuIHlvdSBwYXJzZSB0aGUgVExWIG1ldGFkYXRhLCB5b3Ugd2lsbCBrbm93IHdo ZXRoZXIgdGhlcmUgYXJlIGZsb3cgSUQgYml0cyBvciBub3QuIE5vdGUgdGhhdCBpZiBtdWx0aXBs ZSBzZXNzaW9ucyBzaGFyZSB0aGUgc2FtZSByZWFsaXplZCBzZXJ2aWNlIGluc3RhbmNlIHBhdGgs IHRoZXkgd2lsbCBzaGFyZSB0aGUgc2FtZSAicGF0aCBJRCsgZmxvdyBJRCIuICBXZSBjYW4gYWxz byBjb25zaWRlciBleHRlbmRpbmcgdGhlIG51bWJlciBvZiBiaXRzIHRvIDMyIGlmIHRoYXQgaXMg dGhlIGNvbnNlbnN1cy4gV2Ugd2lsbCBwb3N0IGFuIHVwZGF0ZWQgZHJhZnQgZGVzY3JpYmluZyB0 aGVzZSBzb29uLg0KDQpUaGFua3MsDQpDYXRoeQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBT cmluaSBBZGRlcGFsbGkNClNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDUsIDIwMTQgNzoxNyBBTQ0K VG86IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgSm9lbCBNLiBIYWxwZXJuOyAnc2ZjQGlldGYu b3JnJw0KQ2M6IG5zbXVydGh5QGZyZWVzY2FsZS5jb20NClN1YmplY3Q6IFJlOiBbc2ZjXSBDb21t ZW50cyBvbiBTQ0ggRHJhZnQgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFu Zy1zZmMtc2NoLTAyKQ0KDQoNCltSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5Lg0KDQpTUklOST4g SSBhbSBub3Qgc28gc3VyZSBhYm91dCBkYXRhIHBsYW5lIGVmZmljaWVuY3kuICBNb3N0IG9mIHRo ZSBwcm9jZXNzb3JzIHdvcmsgZ29vZCBpZiB0aGUgbnVtYmVyIG9mIGJpdHMgYXJlIGVpdGhlciAz MiBvciA2NC4gIElmIGl0IGlzIDI0IGJpdHMsIHRoZW4gb25lIG5lZWRzIHRvIGRvIG1hc2tpbmcg YW5kIHNoaWZ0aW5nIGJlZm9yZSB0aGUgdmFsdWUgaXMgdXNlZCB0byBkbyBhbnkgbG9va3VwLiAg IEJ1dCwgdGhpcyBkaXNjdXNzaW9uIGNhbiBnbyBpbnRvIGRpZmZlcmVudCBkaXJlY3Rpb24gOi0p LCBpdCBtYXkgbm90IGJlIGdvb2QgdG8gZ28gaW4gdGhhdCBkaXJlY3Rpb24uDQoNCldoZXJlIGRv IHdlIGRyYXcgdGhlIGxpbmU/IDMyLWJpdHMsIDY0LWJpdHMsDQoxMjggYml0cz8gSSB0aGluayB3 ZSBzaG91bGQgaGF2ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRoZSBTZXJ2aWNlIFBhdGggaGVhZGVy IGFuZCBpZiB5b3UgbmVlZCB0byBjb252ZXkgbW9yZSBiaXRzIHlvdSBuZWVkIHRvIHVzZSB0aGUg Y29udGV4dCBoZWFkZXJzLg0KDQpTUklOST4gVGhpcyBpcyBhIGdvb2QgcG9pbnQuICBUaGlzIHNo b3VsZCB3b3JrIGZpbmUgYXMgbG9uZyBhcyB0aGVyZSBpcyB3YXkgdG8gY29udmV5IGluIHRoZSBt YWluIGhlYWRlciB0aGF0IHRoZSBleHRlbnNpb24gdG8gcGF0aCBJRCBpcyBhdmFpbGFibGUgaW4g c28gYW5kIHNvIFRMViBmaWVsZC4gIFRoYXQgc2hvdWxkIHdvcmsgdG9vLg0KDQpUaGFua3MNClNy aW5pDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IFJl aW5hbGRvIFBlbm5vIChyZXBlbm5vKSA8cmVwZW5ub0BjaXNjby5jb20+DQpTZW50OiBGcmlkYXks IERlY2VtYmVyIDUsIDIwMTQgNzowOCBBTQ0KVG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IEpv ZWwgTS4gSGFscGVybjsgJ3NmY0BpZXRmLm9yZycNCkNjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIz Nzg0MA0KU3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdCAoaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQoNCk9uIDEyLzUvMTQs IDY6NTQgQU0sICJTcmluaSBBZGRlcGFsbGkiIDxzYWRkZXBhbGxpQGZyZWVzY2FsZS5jb20+IHdy b3RlOg0KDQo+DQo+SW4gcmVhbCBkZXBsb3ltZW50cywgbnVtYmVyIG9mIGFjdGl2ZSBwYXRoIElE cyBhcmUgdmVyeSBsZXNzZXIgdGhhbg0KPjJeNjQsIGJ1dCB0aGVyZSBpcyBhIGdvb2QgcG9zc2li aWxpdHkgb2YgdGhlIG51bWJlciBiZWluZyBtb3JlIHRoYW4gMl4yNCAoMTZNKS4NCj4gSSB0aGlu ayBiaWdnZXIgcG9pbnQgaXMgdGhhdCB3aHkgcmVzdHJpY3QgdGhpcyBpbiB0aGUgc3RhbmRhcmRz PyBXaGF0DQo+YWR2YW50YWdlIGRvIHdlIGhhdmUgcmVzdHJpY3RpbmcgdGhpcyBzaXplIHRvIDI0 IGJpdHM/DQoNCltSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5LiBXaGVyZSBkbyB3ZSBkcmF3IHRo ZSBsaW5lPyAzMi1iaXRzLCA2NC1iaXRzLA0KMTI4IGJpdHM/IEkgdGhpbmsgd2Ugc2hvdWxkIGhh dmUgYSBzZW5zaWJsZSB2YWx1ZSBpbiB0aGUgU2VydmljZSBQYXRoIGhlYWRlciBhbmQgaWYgeW91 IG5lZWQgdG8gY29udmV5IG1vcmUgYml0cyB5b3UgbmVlZCB0byB1c2UgdGhlIGNvbnRleHQgaGVh ZGVycy4NCg0KDQo+DQo+VGhlcmUgY2FuIGJlIGRlcGxveW1lbnRzLCB3aGVyZSBTRkMgY29udHJv bGxlciAoTG9naWNhbGx5IGNlbnRyYWwsIGJ1dA0KPmRpc3RyaWJ1dGVkKSAgaXRzZWxmIGNhbiBk byB0aGUgU0YgaW5zdGFuY2Ugc2VsZWN0aW9uIG9uIHBlcg0KPmNvbm5lY3Rpb24vc2Vzc2lvbiBi YXNpcywgdGhlcmVieSBhdm9pZGluZyB0aGUgTEJzIGZvciBzZXJ2aWNlcy4gICBJbiBteQ0KPnZp ZXcsIGFzc3VtcHRpb24gdGhhdCB0aGVyZSB3aWxsIGJlIExCIFNGIGZvciBlYWNoIHNjYWxlLW91 dCBzZXJ2aWNlIGluDQo+dGhlIGNoYWluIGlzIG5vdCB2YWxpZCBpbiBhbGwgY2FzZXMuDQo+DQo+ VGhhbmtzDQo+U3JpbmkNCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+RnJvbTogUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pIDxyZXBlbm5vQGNpc2NvLmNvbT4N Cj5TZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgNCwgMjAxNCAxOjE3IFBNDQo+VG86IEFkZGVwYWxs aSBTcmluaS1CMjIxNjA7IEpvZWwgTS4gSGFscGVybjsgc2ZjQGlldGYub3JnDQo+Q2M6IE5TIFNy aW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+U3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFND SCBEcmFmdA0KPihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNj aC0wMikNCj4NCj5JZiBJIHVuZGVyc3Rvb2QgeW91LCBJIGRvIG5vdCB0aGluayB0aGlzIGlzIHJl YWxpc3RpYy4gQXJlIHlvdSBzYXlpbmcNCj55b3UgbmVlZCA2NC1iaXRzIG9mIHBhdGhzIGFuZCB0 aGVuIHdpbGwgbW9uaXRvciB0aGVtIGFsbD8gRG8gZmF1bHQNCj50b2xlcmFuY2UgYW5kIE9BTSBm b3IgMl42NC1iaXRzIHdvcnRoIG9mIHBhdGhzPyBKdXN0IGZvciBjb21wYXJpc29uLA0KPml0wrlz IGxpa2UgbWFuYWdpbmcgYW5kIG1vbml0b3JpbmcgdGhlIGVudGlyZSBJUHY2IGhvc3QgcmFuZ2Us IG9uZS1ieS1vbmUuDQo+DQo+QW55d2F5LCBJIGRvIG5vdCBleHBlY3QgZXZlcnkgc2luZ2xlIHBl cm11dGF0aW9ucyB0byBiZSBhIGRpZmZlcmVudCBwYXRoLg0KPg0KPklmIGVhY2ggc2VydmljZSBo YXMgMjU2IGRldmljZXMgcHJvdmlkaW5nIHNpbWlsYXIgc2VydmljZSwgeW91IHNob3VsZA0KPm1v c3QgbGlrZWx5IHVzZSBsb2FkLWJhbGFuY2luZyBhbmQgdGhlbiB5b3Ugd291bGQgaGF2ZSBhIHNp bmdsZSAob3IgYQ0KPmZldykgcGF0aHMuIFRoZXJlIGlzIHNvbWUgZGlzY3Vzc2lvbiBnb2luZyBv biBMQi4NCj4NCj5Gcm9tIGEgZGF0YSBwbGFuZSBwZXJzcGVjdGl2ZSwgdGhlIHBhdGggaXMgdWx0 aW1hdGVseSBkZWZpbmVkIGJ5IHRoZQ0KPlNGRnMgdHJhdmVyc2VkIGFuZCBzZXJ2aWNlcyBwcm92 aWRlZCwgbm90IGJ5IGEgc3BlY2lmaWMgSVA6cG9ydCB0aGF0DQo+dGhlIGRldmljZSBwcm92aWRp bmcgdGhlIHNlcnZpY2Ugc2l0cyBvbi4gV2VsbCwgYXQgbGVhc3QgZnJvbSBhIEdQRStOU0ggcGVy c3BlY3RpdmUuDQo+DQo+DQo+T24gMTIvNC8xNCwgMTI6NTcgUE0sICJTcmluaSBBZGRlcGFsbGki IDxzYWRkZXBhbGxpQGZyZWVzY2FsZS5jb20+IHdyb3RlOg0KPg0KPj5JZiBJIHRha2UgYSBjaGFp biB3aXRoIDUgc2VydmljZXMgd2l0aCBlYWNoIHNlcnZpY2UgIHNheSBoYXZpbmcgMjU2DQo+Pmlu c3RhbmNlcyBmb3Igc2NhbGUtb3V0LCBwb3NzaWJsZSBudW1iZXIgb2YgcGF0aHMgYXJlDQo+PjI1 NioyNTYqMjU2KjI1NioyNTYgPSAweEZGIEZGIEZGIEZGIEZGLiBPbmUgcmVxdWlyZXMgMzMgYml0 cyBpbiB0aGlzDQo+PmNhc2UuICBJZiB0aGVyZSBhcmUgbW9yZSBzZXJ2aWNlcyBpbiB0aGUgY2hh aW4gb3IgbW9yZSBjaGFpbnMgb3IgbW9yZQ0KPj5pbnN0YW5jZXMgZm9yIHNjYWxlLW91dCwgdGhl biBpdCBjb3VsZCBnbyB0byBiaWcgbnVtYmVyIHZlcnkgZmFzdC4NCj4+DQo+PkFzIEkgbWVudGlv bmVkIG15IHByZWZlcmVuY2UgaXMgdG8gbWFrZSB0aGUgcGF0aCBJRCBzaXplIGZsZXhpYmxlIGZv cg0KPj5mdXR1cmUgZ3Jvd3RoLiBJZiB0aGF0IGlzIHBlcmNlaXZlZCBhcyBjb21wbGV4LCB0aGVu IGdvaW5nIGZvciA2NGJpdA0KPj5pcyBzYWZlciBiZXQuDQo+Pg0KPj5UaGFua3MNCj4+U3JpbmkN Cj4+DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBKb2VsIE0uIEhh bHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPj5TZW50OiBUaHVyc2RheSwgRGVj ZW1iZXIgMDQsIDIwMTQgMTI6MDUgUE0NCj4+VG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IEpv ZWwgTS4gSGFscGVybjsgc2ZjQGlldGYub3JnDQo+PkNjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIz Nzg0MA0KPj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+PihodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4+DQo+PkEg Y29udHJvbGxlciAob3Igb3RoZXIgZGVjaXNpb24gbG9naWMpIGNhbiBjZXJ0YWlubHkgYmUgYXdh cmUgb2Ygc3VjaA0KPj5jb25jZXJucy4NCj4+QnV0IHRoZSBudW1iZXIgb2Ygc2VydmljZSBmdW5j dGlvbiBwYXRocyBpcyBub3QgcmVsYXRlZCB0byB0aGUgbnVtYmVyDQo+Pm9mIGZsb3dzIG9yIHRo ZSBudW1iZXIgb2YgdGVuYW50cy4gIEl0IGlzIHJlbGF0ZWQgdG8gdGhlIG51bWJlciBvZg0KPj5j b21iaW5hdGlvbnMgb2Ygc2VydmljZXMgYW5kIHRoZSBwb2xpY2llcyBmb3Igc2VydmljZSBmdW5j dGlvbiBzZWxlY3Rpb24uDQo+PiBXaGlsZSB0aGF0IGNhbiBiZSBhIGxhcmdlIG51bWJlciwgSSBz dXJlIGhvcGUgaXQgZG9lcyBub3QgY29tZSBjbG9zZQ0KPj50byBzYXR1cmF0aW5nIDI0IGJpdHMu DQo+Pg0KPj5IYXZpbmcgc2FpZCB0aGF0LCBpZiB3ZSB0aGluayB0aGF0IDI0IGJpdHMgaXMgb25s eSBqdXN0IGVub3VnaCwgdGhlbg0KPj53ZSBvdWdodCB0byB1c2UgMzIuICBGcm9tIHdoZXJlIEkg c2l0LCBJIHdvdWxkIG5vcm1hbGx5IGV4cGVjdCAxNiBiaXRzDQo+PnRvIGJlIG1vcmUgdGhhbiBz dWZmaWNpZW50LCB3aGljaCBpcyB3aHkgSSBhbSBjb21mb3J0YWJsZSB3aXRoIDI0Lg0KPj5IYXZp bmcgc2FpZCB0aGF0LCB0aGUgZmllbGQgc2l6ZSBpcyBub3QgYSBiaWcgZGVhbCB0byBtZS4NCj4+ DQo+PllvdXJzLA0KPj5Kb2VsDQo+Pg0KPj5PbiAxMi80LzE0LCAyOjAxIFBNLCBTcmluaSBBZGRl cGFsbGkgd3JvdGU6DQo+Pj4NCj4+PiBJIHdhcyBub3QgaW1wbHlpbmcgdGhhdCBwYXRoIElEIHNo b3VsZCBoYXZlIGluZm9ybWF0aW9uIGluIHJlZ2FyZHMNCj4+PnRvIHRlbmFudC9jb250cm9sbGVy L2Zsb3cvc2NhbGUtb3V0LiAgQnV0IFNGQyBjb250cm9sbGVycyBzaG91bGQga2VlcCB0aGVzZQ0K Pj4+aW4gbWluZCB0byBhc3NpZ24gdGhlIHBhdGggSUQuICAgIEEgZGVwbG95bWVudCBjYW4gaGF2 ZSBtdWx0aXBsZQ0KPj4+dGVuYW50cywgZWFjaCB0ZW5hbnQgY2FuIGhhdmUgbXVsdGlwbGUgbmV0 d29ya3MsICB0aGVyZSBjb3VsZCBiZQ0KPj4+bWlsbGlvbnMgb2YgZmxvd3MgaW4gZWFjaCBvZiB0 aG9zZSBuZXR3b3Jrcy4gIEFuZCBjb25zaWRlcmluZyBhbGwNCj4+PnRoZXNlLA0KPj4+IDI0IGJp dCBwYXRoIElEIG1heSBub3QgYmUgYWJsZSB0byByZXByZXNlbnQgcGF0aHMgZm9yIHRoZXNlIGZs b3dzLg0KPj4+SGVuY2UsIEkgd2FzIHdvbmRlcmluZyB3aGV0aGVyIHBhdGggSUQgY2FuIGJlIGV4 dGVuZGVkIHRvIDY0IGJpdHMgb3INCj4+Pm1ha2UgaXQgZmxleGlibGUuDQo+Pj4NCj4+PiBUaGFu a3MNCj4+PiBTcmluaQ0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+IEZyb206IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4N Cj4+PiBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgNCwgMjAxNCA3OjQyIEFNDQo+Pj4gVG86IEFk ZGVwYWxsaSBTcmluaS1CMjIxNjA7IHNmY0BpZXRmLm9yZw0KPj4+IENjOiBOUyBTcmluaXZhc2Eg TXVydGh5LUIzNzg0MA0KPj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJh ZnQNCj4+PiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gt MDIpDQo+Pj4NCj4+PiBUaGUgSW5kZXggaXMgbm90IGp1c3QgZm9yIGxvb3AgcHJldmVudGlvbi4g IEluIHRoZSBjYXNlIG9mDQo+Pj4gYW1iaWd1aXR5LCB0aGUgaW5kZXggdGVsbHMgdGhlIFNGRiB3 aGVyZSBpbiB0aGUgcGF0aCB0aGUgcGFja2V0IGN1cnJlbnRseSByZXNpZGVzLg0KPj4+ICAgIFRo ZXJlIGFyZSBtdWx0aXBsZSB3YXlzIHN1Y2ggYW1iaWd1aXR5IGNhbiBvY2N1ci4NCj4+Pg0KPj4+ IFRoZSBQYXRoIElkZW50aWZpZXIgaXMgc3BlY2lmaWNhbGx5IG5vdCBleHBlY3RlZCB0byBpbmNs dWRlDQo+Pj4gY29udHJvbGxlciBJRCBvciBUZW5hbnQgSUQuICBXaGlsZSBhIGRlcGxveWVyIGNh biBoYXZlIGEgcGF0aCBwZXINCj4+PiB0ZW5hbnQsIHRoZSBhcmNoaXRlY3R1cmUgc3RpbGwgZG9l cyBub3QgdHJlYXQgdGhlIHBhdGggSUQgYXMgYQ0KPj4+IHRlbmFudCBJRC4gIFRlbmFudCBJRCwg Y29udHJvbGxlciBJRCwgYW5kIG90aGVyIG5vbi1wYXRoLXNwZWNpZnlpbmcNCj4+PiBpbmZvcm1h dGlvbiBpcyB0byBiZSBjYXJyaWVkIGluIG1ldGFkYXRhLg0KPj4+DQo+Pj4gWW91cnMsDQo+Pj4g Sm9lbA0KPj4+DQo+Pj4gT24gMTIvNC8xNCwgMTA6MDIgQU0sIFNyaW5pIEFkZGVwYWxsaSB3cm90 ZToNCj4+Pj4gVHdvIGNvbW1lbnRzIDoNCj4+Pj4NCj4+Pj4NCj4+Pj4gMS4gIFNGIEluZGV4IDog IFNpbmNlIGl0IGlzIG1lYW50IGZvciBsb29wIGRldGVjdGlvbiwgIHdvdWxkbid0DQo+Pj4+IGJl dHRlciB0byByZW5hbWUgdGhpcyBhcyAiVFRMIj8NCj4+Pj4NCj4+Pj4gMi4gIFBhdGggSWRlbnRp ZmllciA6ICAgIDI0IGJpdCBwYXRoIGlkZW50aWZpZXIgc2VlbXMgdG8gYmUgdG9vIGxlc3MuDQo+ Pj4+IEJhc2VkIG9uIG91ciBleHBlcmllbmNlIGluIHRyYWZmaWMgc3RlZXJpbmcsICB0aGlzIHBh dGggaWRlbnRpZmllcg0KPj4+Pm5lZWRzIHRvIGVuY29kZSBnb29kIGFtb3VudCBvZiBpbmZvcm1h dGlvbiB0byBtYWtlIGl0IHVuaXF1ZS4gIEZvcg0KPj4+PmV4YW1wbGUsDQo+Pj4+ICAgIHRoaXMg aWRlbnRpZmllciBuZWVkcyB0byBlbmNvZGUgKGluIG91ciBjYXNlKSBzb21lIGluZm9ybWF0aW9u DQo+Pj4+cmVwcmVzZW50aW5nIHRoZSBkaXN0cmlidXRlZCBjb250cm9sbGVyIElELCAgdGVuYW50 IElELCAgZmxvdyBJRCwNCj4+Pj4gICAgU2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZSAoaW4gY2Fz ZSBvZiBzY2FsZS1vdXQpIGFuZCBmZXcgbW9yZS4uDQo+Pj4+IE9uZSBzdWdnZXN0aW9uIGlzIHRv IG1ha2UgaXQgNjQgYml0cyB2YWx1ZSAgb3IgdG8gbWFrZSBpdCBldmVuDQo+Pj4+ZXh0ZW5kYWJs ZSwNCj4+Pj4gICAgaXQgaXMgZ29vZCBpZiBwYXRoIGlkZW50aWZpZXIgaXMgYWxzbyByZXByZXNl bnRlZCBpbiBUTFYgZm9ybS4NCj4+Pj4NCj4+Pj4NCj4+Pj4gVGhhbmtzDQo+Pj4+DQo+Pj4+IFNy aW5pDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4gc2Zj QGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo+Pj4+DQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj5zZmMgbWFpbGluZyBsaXN0DQo+PnNmY0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0 DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgKHRoZSAibWVzc2FnZSIpIGFy ZSBjb25maWRlbnRpYWwsIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZXMuIElmIHlv dSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgZnJvbSB5b3Vy IHN5c3RlbS4gSW4gdGhpcyBjYXNlLCB5b3UgYXJlIG5vdCBhdXRob3JpemVkIHRvIHVzZSwgY29w eSB0aGlzIG1lc3NhZ2UgYW5kL29yIGRpc2Nsb3NlIHRoZSBjb250ZW50IHRvIGFueSBvdGhlciBw ZXJzb24uIEUtbWFpbHMgYXJlIHN1c2NlcHRpYmxlIHRvIGFsdGVyYXRpb24uIE5laXRoZXIgUW9z bW9zIG5vciBhbnkgb2YgaXRzIHN1YnNpZGlhcmllcyBvciBhZmZpbGlhdGVzIHNoYWxsIGJlIGxp YWJsZSBmb3IgdGhlIG1lc3NhZ2UgaWYgYWx0ZXJlZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoN CkNlIG1lc3NhZ2UgZXQgdG91dGVzIHNlcyBwacOoY2VzIGpvaW50ZXMgKGNpLWFwcsOocyBsZSAi bWVzc2FnZSIpc29udCBjb25maWRlbnRpZWxzIGV0IMOpdGFibGlzIMOgIGwnaW50ZW50aW9uIGV4 Y2x1c2l2ZSBkZSBzZXMgZGVzdGluYXRhaXJlcy4gU2kgdm91cyBhdmV6IHJlw6d1IGNlIG1lc3Nh Z2UgcGFyIGVycmV1ciwgbWVyY2kgZOKAmWVuIGluZm9ybWVyIGltbcOpZGlhdGVtZW50IHNvbiDD qW1ldHRldXIgcGFyIGNvdXJyaWVyIMOpbGVjdHJvbmlxdWUgZXQgZOKAmWVmZmFjZXIgY2UgbWVz c2FnZSBkZSB2b3RyZSBzeXN0w6htZS4gRGFucyBjZXR0ZSBoeXBvdGjDqHNlLCB2b3VzIG7igJnD qnRlcyBwYXMgYXV0b3Jpc8OpIMOgIHV0aWxpc2VyLCBjb3BpZXIgY2UgbWVzc2FnZSBldC9vdSBl biBkaXZ1bGd1ZXIgbGUgY29udGVudSDDoCB1biB0aWVycy4gVG91dCBtZXNzYWdlIMOpbGVjdHJv bmlxdWUgZXN0IHN1c2NlcHRpYmxlIGQnYWx0w6lyYXRpb24uIFFvc21vcyBldCBzZXMgZmlsaWFs ZXMgZMOpY2xpbmVudCB0b3V0ZSByZXNwb25zYWJpbGl0w6kgYXUgdGl0cmUgZGUgY2UgbWVzc2Fn ZSBzJ2lsIGEgw6l0w6kgYWx0w6lyw6ksIGTDqWZvcm3DqSBvdSBmYWxzaWZpw6kuDQo= From nobody Mon Feb 2 14:40:55 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECA81A1AF4 for ; Mon, 2 Feb 2015 14:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, TRACKER_ID=1.306, 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 Juz991JFz2Cc for ; Mon, 2 Feb 2015 14:40:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28BCF1A1AAC for ; Mon, 2 Feb 2015 14:40:44 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSA16075; Mon, 02 Feb 2015 22:40:42 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Feb 2015 22:40:40 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.133]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0158.001; Mon, 2 Feb 2015 14:40:33 -0800 From: Cathy Zhang To: Srini Addepalli , Sumandra Majee , Nicolas BOUTHORS , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZyAGG+AgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgD//7j7oIBVIj4ggALqPwCAADaLgIADgFqAgAExvRA= Date: Mon, 2 Feb 2015 22:40:33 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.78] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "nsmurthy@freescale.com" , Jerome TOLLET , Rajesh Kumar Madabushi , Bharat Mota Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 02 Feb 2015 22:40:50 -0000 SGkgU3JpbmksDQoNCllvdSBnYXZlIGEgdmVyeSBnb29kIGV4YW1wbGUgb2YgaG93IHRvIHVzZSBS U1AgSUQgd2hpY2ggaXMgaW4gbGluZSB3aXRoIG91ciB0aG91Z2h0IHdoZW4gd2UgYWRkZWQgdGhl IFJTUCBJRCBpbnRvIHRoZSBzZXJ2aWNlIGNoYWluIGhlYWRlci4gDQoNClRoYW5rcywNCkNhdGh5 DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTcmluaSBBZGRlcGFsbGkgW21h aWx0bzpzYWRkZXBhbGxpQGZyZWVzY2FsZS5jb21dIA0KU2VudDogU3VuZGF5LCBGZWJydWFyeSAw MSwgMjAxNSAxMjoyMSBQTQ0KVG86IFN1bWFuZHJhIE1hamVlOyBOaWNvbGFzIEJPVVRIT1JTOyBD YXRoeSBaaGFuZzsgJ3NmY0BpZXRmLm9yZycNCkNjOiBKZXJvbWUgVE9MTEVUOyBuc211cnRoeUBm cmVlc2NhbGUuY29tOyBCaGFyYXQgTW90YTsgUmFqZXNoIEt1bWFyIE1hZGFidXNoaQ0KU3ViamVj dDogUkU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdCAoaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQoNCkhpIFN1bWFuZHJhLA0KDQpJIGFncmVl IHdpdGggeW91IHRoYXQgbW9yZSBpbmZvcm1hdGlvbiBjYW4gYmUgYWRkZWQgdG8gdGhlIHByb3Rv Y29sIGRvY3VtZW50IG9uIHNvbWUgdXNlIGNhc2Ugc2NlbmFyaW9zIHRvIG1ha2UgaXQgY2xlYXIg b24gdGhlIHVzYWdlIG9mIFJTUC1JRCBhbmQgUGF0aC1JRC4NCg0KSnVzdCB0byBtYWtlIHRoZSBy ZWFsaXN0aWMgYW5kIGNvbXBsZXggc2NlbmFyaW8NCg0KSW5ncmVzc1NGRi0tLS0tU0ZGMS0tLS0t U0ZGMi0tLS0tRWdyZXNzU0ZGDQoNCkluIHZpcnR1YWwgd29ybGQsIFNGRjEgY291bGQgYmUgZnJv bnRlbmRpbmcgU0Z4LTEsIFNGeC0yLCBTRnktMSBhbmQgU0ZGMiBjb3VsZCBiZSBmcm9udCBlbmRp bmcgU0Z4LTMsIFNGeS0yLCBTRnotMQ0KRm9yIHNpbXBsaWNpdHksIGFzc3VtZSB0aGF0IEluZ3Jl c3NTRkYgaXMgYSBlZGdlIHJvdXRlciAoZWcuIE9wZW5zdGFjayBOZXR3b3JrIE5vZGUpDQpFZ3Jl c3NTRkYgaXMgYSB2aXJ0dWFsIHN3aXRjaCBob3N0aW5nIHNldCBvZiBXZWIgU2VydmVyIFZNcy4N ClNGRjEgYW5kIFNGRjIgYXJlIGFsc28gdmlydHVhbCBzd2l0Y2hlcyBob3N0aW5nIFNGeCwgU0Z5 IGFuZCBTRnogU2VydmljZSBWTXMuDQoNCkFzc3VtaW5nIHRoYXQgY2hhaW4gcmVxdWlyZXMgcGFj a2V0cyBnbyB0byBTRngsIFNGeSBhbmQgU0Z6LCAgSW5ncmVzc1NGRiAod2l0aCB0aGUgaGVscCBv ZiBTRkYgY29udHJvbGxlcikgbmVlZHMgc2VuZCB0aGUgdHJhZmZpYyB0byBvbmUgb2YgU0Z4LTEs IFNGeC0yIGFuZCBTRngtMy4gQmFzZWQgb24gU0YteCBzZWxlY3Rpb24sIGluZ3Jlc3MgU0ZGIHNl bmRzIHRoZSB0cmFmZmljIHRvIGNvcnJlc3BvbmRpbmcgU0ZGLiAgSWYgU0Z4LTEgb3IgU0Z4LTIg aXMgY2hvc2VuLCB0aGVuIHRoZSB0cmFmZmljIGlzIHNlbnQgdG8gU0ZGMS4gIElmIFNGeC0zIGlz IGNob3NlbiwgdGhlbiB0aGUgdHJhZmZpYyBpcyBzZW50IHRvIHRoZSBTRkYyLiBOZXh0IGluIHRo ZSBjaGFpbiwgc2VsZWN0aW9uIG5lZWRzIHRvIGhhcHBlbiBiZXR3ZWVuIFNGeTEgYW5kIFNGeTIu ICBTaW1pbGFybHkgZm9yIG5leHQgc2VydmljZSBpbiB0aGUgY2hhaW4sICAgZWl0aGVyIFNGRjEg b3IgU0ZGMiAod2l0aCB0aGUgaGVscCBvZiBjb250cm9sbGVyKSB3aWxsIHNlbmQgdGhlIHRyYWZm aWMgdG8gU0YteS4gSXQgZG9lcyB0aGlzIGJ5IHNlbmRpbmcgdGhlIHRyYWZmaWMgdG8gU0ZGMiB0 aGF0IGlzIGhvc3RpbmcgdGhlIFNGLXouIEFuZCBmaW5hbGx5IHRyYWZmaWMgbmVlZHMgdG8gZ28g dG8gRWdyZXNzU0ZGIHRvIGRlbGl2ZXIgdG8gZGVzdGluYXRpb24gd2ViLXNlcnZlciBWTS4NCg0K RXNzZW50aWFsbHksIGEgZ2l2ZW4gU0ZGIHdvdWxkIG5lZWQgdG8gYmUgcHJvZ3JhbW1lZCB3aXRo IHRoZSBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIG5leHQgU0YuICBUaGF0IGlzIHdoZXJlIHBhdGgg SUQsIFJTUC1JRCBhbmQgT3ZlcmxheSBuZXR3b3JrcyB3b3VsZCBoZWxwIC0gUGF0aCBJRCBpbmRp Y2F0aW5nIHRoZSBjaGFpbiBhbmQgUlNQLUlEIGluZGljYXRpbmcgdGhlIFNGIGluc3RhbmNlIEFO RCAgVnhMQU4gZGVzdGluYXRpb24gSVAgaW5kaWNhdGluZyB0aGUgbmV4dCBTRkYuIFNGRiBDb250 cm9sbGVyIGhhdmluZyB0aGUgbmV0d29yayB3aWRlIHZpc2liaWxpdHkgd291bGQgcHJvZ3JhbSB0 aGUgU0ZGcyBhcHByb3ByaWF0ZWx5LiANCg0KRm9yIGV4YW1wbGUsIG9uIGluZ3Jlc3NTRkYsIGZs b3dzIGFyZSBwcm9ncmFtbWVkIHdpdGggUlNQLUlEIHJlbGF0ZWQgdG8gU0Z4IHNlcnZpY2UgaW5z dGFuY2VzLiAgSW5ncmVzc1NGRiwgYXMgcGFydCBvZiBwYWNrZXQgcHJvY2Vzc2luZywgYWRkcyB0 aGUgUlNQLUlELCBQYXRoX0lEIHRvIHRoZSBTQ0ggaGVhZGVyIGFuZCBlbmNhcHN1bGF0ZXMgaW4g VnhMQU4uICBTRkYxIGFuZC9vciBTRkYyIGFyZSBwcm9ncmFtbWVkIHdpdGggZmxvd3MgdGhhdCBt YXRjaCBvbiBQQVRILUlEIGFuZCBSU1AtSUQgdG8gc2VuZCB0aGUgdHJhZmZpYyB0byByaWdodCBT RnggaW5zdGFuY2UuIEVzc2VudGlhbGx5LCBwcmV2aW91cyBTRkYgYWRkcyB0aGUgU0NIIGhlYWRl ciByZWxhdGVkIHRvIG5leHQgU0YgaW5zdGFuY2VzIGFuZCBob3N0aW5nIFNGRiB1c2VzIHRoYXQg aW5mb3JtYXRpb24gdG8gcm91dGUgdGhlIHRyYWZmaWMgdG8gcmlnaHQgU0YgaW5zdGFuY2UuDQoN Ck9uIHlvdXIgY29uY2VybiBhYm91dCBwb29yIHNjYWxhYmlsaXR5IDogIFNGRiBjb250cm9sbGVy IG5lZWQgbm90IGJlIGEgc2luZ2xlIGVudGl0eS4gIEl0IGNvdWxkIGJlIGRpc3RyaWJ1dGVkIGFu ZCBzY2FsZS1vdXQgZW50aXR5IGZvciBwZXJmb3JtYW5jZSBzY2FsaW5nLiAgIEFsc28sIGNvbnRy b2xsZXJzIG5lZWQgbm90IGJlIGluZm9ybWVkIG9mIGV2ZXJ5IGZpbmUgZ3JhbnVsYXIgZmxvdy4g SXQgY291bGQgYmUgYmFzZWQgb24gNC10dXBsZSBvciAzLXR1cGxlIGZsb3dzLCB0aGVyZWJ5IHJl ZHVjaW5nIHRoZSBudW1iZXIgb2YgZGVjaXNpb25zIGxvZ2ljYWwgY29udHJvbGxlciBuZWVkIHRv IG1ha2UuICANCg0KSSBkaWQgbm90IHVuZGVyc3RhbmQgIHlvdXIgY29uY2VybiBvbiAiIFRoZSBh bW91bnQgb2Ygc3RhdGUsIHByb2JhYmlsaXR5IG9mIGEgaW5zdGFuY2UgZ29pbmcgZG93biBiZXR3 ZWVuIHNlbGVjdGlvbiBhbmQgZmxvdyBhcnJpdmFsIGdvZXMgdXAuIiAgVGhpcyBzZWVtcyB0byBi ZSBpbXBvcnRhbnQgYW5kIGNhbiB5b3UgZWxhYm9yYXRlPw0KDQoNClRoYW5rcw0KU3JpbmkNCg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN1bWFuZHJhIE1hamVlDQpTZW50OiBGcmlkYXks IEphbnVhcnkgMzAsIDIwMTUgMjo1MyBQTQ0KVG86IE5pY29sYXMgQk9VVEhPUlM7IENhdGh5IFpo YW5nOyAnc2ZjQGlldGYub3JnJw0KQ2M6IEplcm9tZSBUT0xMRVQNClN1YmplY3Q6IFJlOiBbc2Zj XSBDb21tZW50cyBvbiBTQ0ggRHJhZnQgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC16aGFuZy1zZmMtc2NoLTAyKQ0KDQpIZWxsbywNCg0KVGhpcyBpcyBhbiBpbnRlcmVzdGluZyBk aXNjdXNzaW9uIGFuZCBJIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCB0aGUgbW90aXZhdGlvbiBv ZiBiZXR0ZXIuIFRoZSB0cm91YmxlIHdpdGggYSBwcm90b2NvbCBkb2N1bWVudCBpcyB0aGF0IGl0 IGlzIHR5cGljYWxseSBoYXMgaW5hZGVxdWF0ZSBkZXRhaWwgYWJvdXQgdGhlIGxvZ2ljLiBTbyB0 byBjYXN0IHRoaXMgaW50byBzb21ld2hhdCBvZiBhIGNvbmNyZXRlIHRlcm1zLCBjb25zaWRlciB0 aGUgZm9sbG93aW5nLg0KDQoNCiAgICANCiAgICAgICBTRkYoeCkgIHsgU2Z4KDEpIFNmeCgyKeKA plNmeChuKSB9ICAg4oCU4oCU4oCU4oCUPiAgIFNGRih5KSB7IFNmeSgxKSBTZnkoMikNCuKApi4g U2Z5KG0pIH0gICA6OiBMb2dpY2FsIENoYWluIGluIE9ORSBkaXJlY3Rpb24gb25seS4NCiAgICAg ICANCiAgICAgICBQSFlTSUNBTCBXT1JMRDoNCiAgICAgICAgICBBKSB0aGUgU0ZGIGNvdWxkIGJl IGENCiAgICAgICAgICAgIC0gY29tcG9uZW50IG9mIFZTV0lUQ0ggKHBpY2sgeW91ciBmYXYgcHJv dG9jb2wgZm9yIGNvbmZpZ3VyaW5nIHRob3NlIGVudGl0aWVzIH0NCiAgICAgICAgICAgIC0gQSBs b2FkIGJhbGFuY2VyDQogICAgICAgICAgICAtIEEgSFcgc3dpdGNoL3JvdXRlciBzb21lIEwyL0wz IGNvbWJvDQoNCiAgICAgICAgICBCKSBTZiBpbnN0YW5jZSBjb3VsZCBiZSwNCiAgICAgICAgICAg ICAgIC0gVmlydHVhbCBtYWNoaW5lLCAjTiBvZiB0aG9zZQ0KICAgICAgICAgICAgICAgLSBwaHlz aWNhbA0KICAgICAgICAgICAgICAgLSBDb250YWluZXIgI00gd2hpY2ggaXMgb2Z0ZW4gNSBvciBt b3JlIHggI04NCiAgICAgICAgICAgICAgIC0gQ2x1c3RlciB0aGF0IHdlIGRvbuKAmXQga25vdw0K DQpJdCBpcyBwb3NzaWJsZSB0byBoYXZlIG11bHRpcGxlIHBoeXNpY2FsIFNGRih4KSBhbHNvLg0K DQpBIHNlbGVjdGlvbiBvZiBhIGdpdmVuIFNGIChzZXJ2aWNlKShpbnN0YW5jZSkgaXMgYSBjYW4g YmUgc2ltcGxlIG9yIGNvbXBsZXguIEZvciBleGFtcGxlIFNGRih4KSBtYXkgaGF2ZSB0aGUgYmVz dCBrbm93bGVkZ2UgdG8gc2VsZWN0IFNmeCgxKSBiYWVkIG9uIGEgZ2l2ZW4gY3JpdGVyaW9uICh3 aGljaCBjb3VsZCBiZSBwYXJ0IG9mIHRoZSBwb2xpY3kpLiAgVGhlbiBJIGRvbuKAmXQgc2VlIGEg cmVhc29uIHRvIGhhdmUgUlNQLg0KDQpJdCBpcyBwb3NzaWJsZSB0aGF0IGxvb2t1cCAocGF0aCkg QCBTRkYoeCkgcHJvZHVjZXMgYSBzcGVjaWZpYyBpbnN0YW5jZSBvZiBTZnkgYW5kIHllcyB0aGVu IHNvbWV0aGluZyBsaWtlIFJTUCB3b3VsZCBiZSByZXF1aXJlZC4gQnV0IEkgd291bGQgYXJndWUg dGhhdCBqb2IgU0ZGKHkpIGNhbiBhbHNvIGJlIHN1YnN1bWVkIGJ5IFNGRih4KS4NCg0KSXMgaXQg cG9zc2libGUgZm9yIGEgY2VudHJhbCBjb250cm9sbGVyIHRvIHBpY2sgZWFjaCBpbnN0YW5jZSBv ZiBzZXJ2aWNlLCBidXQgc3VjaCBhbiBpbXBsZW1lbnRhdGlvbiB0ZW5kcyB0byBzY2FsZSBwb29y bHkuIFRoZSBhbW91bnQgb2Ygc3RhdGUsIHByb2JhYmlsaXR5IG9mIGEgaW5zdGFuY2UgZ29pbmcg ZG93biBiZXR3ZWVuIHNlbGVjdGlvbiBhbmQgZmxvdyBhcnJpdmFsIGdvZXMgdXAuIA0KDQpSZWdh cmRzLg0KDQpTdW1hbmRyYQ0KDQoNCg0KT24gMS8zMC8xNSwgMzozOCBBTSwgIk5pY29sYXMgQk9V VEhPUlMiIDxOaWNvbGFzLkJPVVRIT1JTQHFvc21vcy5jb20+DQp3cm90ZToNCg0KPkhlbGxvIENh dGh5LA0KPg0KPkluZGVlZCB0aGUgbm90aW9uIG9mICJyZW5kZXJlZCBzZXJ2aWNlIHBhdGggSUQi KFJTUCBJRCkgc2VlbXMgcmVsZXZhbnQgDQo+YXMgdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBz dGlwdWxhdGVzIHRoYXQgdGhlIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCANCj4oU0ZQKSBwcm92aWRl cyBhbiBhYnN0cmFjdCBub3Rpb24gb2YgYSBzZXJ2aWNlIGNoYWluLCB3aGlsZSB0aGUgUlNQIGlz IA0KPmEgY29uc3RyYWluZWQgbGlzdCBvZiBsb2NhdGlvbnMuDQo+DQo+U0ZDIGhlYWRlciAiU2Vy dmljZSBQYXRoIElkZW50aWZpZXIiIChTUEkpICBpcyB1c2VkIGluIGJvdGggTlNIIGFuZCBTQ0gg DQo+cHJvdG9jb2wgYW5kIGluIGJvdGggY2FzZSBzZWVtIHRvIGlkZW50aWZ5IHRvIGEgcGFydGlj dWxhciBTRlAuDQo+DQo+TlNIKHY1KSBmb3IgZXhhbXBsZSBzdGF0ZXMgdGhhdA0KPiIgQXMgZGVz Y3JpYmVkIGFib3ZlLCBOU0ggY29udGFpbnMgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciAoU1BJ KSBhbmQNCj4gICBhIHNlcnZpY2UgaW5kZXggKFNJKS4gIFRoZSBTUEkgaXMsIGFzIHBlciBpdHMg bmFtZSwgYW4gaWRlbnRpZmllci4NCj4gICBUaGUgU1BJIGFsb25lIGNhbm5vdCBiZSB1c2VkIHRv IGZvcndhcmQgcGFja2V0cyBhbG9uZyBhIHNlcnZpY2UgcGF0aC4NCj4gICBSYXRoZXIgdGhlIFNQ SSBwcm92aWRlIGEgbGV2ZWwgb2YgaW5kaXJlY3Rpb24gYmV0d2VlbiB0aGUgc2VydmljZQ0KPiAg IHBhdGgvdG9wb2xvZ3kgYW5kIHRoZSB0aGUgbmV0d29yayB0cmFuc3BvcnQuICBGdXJ0aGVybW9y ZSwgdGhlcmUgaXMNCj4gICBubyByZXF1aXJlbWVudCwgb3IgZXhwZWN0YXRpb24gb2YgYW4gU1BJ IGJlaW5nIGJvdW5kIHRvIGEgcHJlLQ0KPiAgIGRldGVybWluZWQgb3Igc3RhdGljIG5ldHdvcmsg cGF0aC4iDQo+DQo+U3RpbGwgTlNIKHY1KSAgc2hvd3MgdGhhdCBTUEkgKG5vdCBhIFJTUCBJRCkg IHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBrZXkgDQo+ZWxlbWVudCBvZiBhbiBTRkYgdG8gbG9va3Vw IG9uIGZvcndhcmRpbmcgdGFibGVzLiAgQnV0IEkgY291bGQgbm90IGZpbmQgDQo+aW4gTlNIICBo b3cgdG8gdXNlIHRoZSBub3Rpb24gb2YgUmVuZGVyZWQgc2VydmljZSBwYXRoIHdoaWNoIHdhcyAN Cj5kZWZpbmVkIGluIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQuDQo+DQo+WW91IHByb3Bvc2Fs IHNlZW1zIHRvIG1lIHZlcnkgdXNlZnVsLA0KPg0KPkFuIFJTUCBJRCAoaW5kZXBlbmRlbnQgb2Yg dGhlIFNQSSBidXQgcGFydCBvZiB0aGUgc2FtZSBuYW1lIHNwYWNlKSANCj5jb3VsZCBiZSB1c2Vk IHRoZSBzYW1lIHdheSBhcyBTUEkgYnkgU0ZGIGZvciBleGFtcGxlLCBhbGxvd2luZyBhIA0KPlNl cnZpY2UgQ2xhc3NpZmllciB0byBjb250cm9sIHJlbW90ZSBsb2FkIGJhbGFuY2luZyBmb3IgZXhh bXBsZS4NCj4NCj5UaGlzIHNhaWQgdGhlIFJTUCBJRCB2YWx1ZXMgY291bGQgYmUgcmVsYXRpdmUg dG8gYSBwYXJ0aWN1bGFyIFNlcnZpY2UgDQo+UGF0aCwgd2hpY2ggd291bGQgcHJldmVudCB1c2lu ZyB0aGVtIGFzIHdlIGRvIGZvciBTUEkgaW4gU0ZGIGZvcndhcmRpbmcgDQo+dGFibGVzLg0KPg0K PldlIG1heSB3YW50IHRvIHByZWNpc2UgaWYgdGhlIFJTUCBJRCBpcyB0byBiZSByZWxhdGl2ZSBv ZiBhYnNvbHV0ZSwgYXMgDQo+aXQgc2hvdWxkIGhhdmUgYW4gaW1wYWN0IG9uIGZvcndhcmRpbmcg dGFibGUgc3RydWN0dXJlIGlmIHdlIGRlY2lkZSB0byANCj51c2UgdGhpcyBjb25jZXB0Lg0KPg0K PlBlcnNvbmFsbHkgSSBsaWtlIHRoZSBub3Rpb24gb2YgYSByZWxhdGl2ZSBSU1AgSUQsIGFzIHdl IGNvdWxkIHRoZW4gdXNlIA0KPnNvbWUgY29udmVudGlvbnMsIHN0cnVjdHVyZSBpdCwgcG9zc2li bHkgZXh0ZW5kaW5nIGl0cyB1c2UuDQo+DQo+Tmljb2xhcw0KPg0KPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+RnJvbTogQ2F0aHkgWmhhbmcgW21haWx0bzpDYXRoeS5ILlpoYW5nQGh1YXdl aS5jb21dDQo+U2VudDogamV1ZGkgMjkgamFudmllciAyMDE1IDIwOjQ0DQo+VG86IENhdGh5IFpo YW5nOyBTcmluaSBBZGRlcGFsbGk7IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgSm9lbCBNLg0K PkhhbHBlcm47ICdzZmNAaWV0Zi5vcmcnDQo+Q2M6IG5zbXVydGh5QGZyZWVzY2FsZS5jb20NCj5T dWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+KGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPg0KPkhpIGV2ZXJ5b25lLA0K Pg0KPldlIGhhdmUgdXBsb2FkZWQgYSBuZXcgU0NIIHZlcnNpb24gKDMpIHdoaWNoIGFkZHMgZGVm aW5pdGlvbiBvZiBhIG5ldyANCj5tZXRhZGF0YSB0eXBlIGZvciB0aGUgZmxvdyBJRCB0byBzdXBw b3J0IGxvYWQgYmFsYW5jaW5nIGFtb25nIFNGIA0KPmluc3RhbmNlcyBhbmQgbWl0aWdhdGUgdGhl IHBvdGVudGlhbCBpc3N1ZSBvZiAibm90IGVub3VnaCBwYXRoIElEIi4gVGhlIA0KPmZsb3cgSUQg aXMgbmFtZWQgInJlbmRlcmVkIHNlcnZpY2UgcGF0aCBJRCIgaW4gdGhlIGRyYWZ0LiBQbGVhc2Ug cmVmZXIgDQo+dG8gc2VjdGlvbiA0LjMuMiBvZiANCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC16aGFuZy1zZmMtc2NoLw0KPmZvciBkZXRhaWwgZGVzY3JpcHRpb24uDQo+ DQo+SW4gaXRzIHByZXZpb3VzIHZlcnNpb24sIFNDSCBkZWZpbmVzIGEgIkJ5cGFzcyBiaXQiIGlu IHRoZSBiYXNlIGhlYWRlci4NCj5UaGlzIGJpdCBlbmFibGVzIHRoZSBTRiB0byBwcm92aWRlIGZl ZWRiYWNrL25vdGlmaWNhdGlvbiB2aWEgdGhlIGRhdGEgDQo+cGF0aCB0byBpdHMgY29ubmVjdGlu ZyBTRkYgYWJvdXQgd2hldGhlciB0aGUgcmVtYWluaW5nIHBhY2tldHMgb2YgdGhlIA0KPlNGQyBz aG91bGQgYnlwYXNzIHRoYXQgU0YuIFRoaXMgaXMgdXNlZnVsIGluIHRoZSBjYXNlIHRoYXQgb25s eSB0aGUgDQo+Zmlyc3QgZmV3IHBhY2tldHMgb2YgYSBmbG93IG5lZWQgdG8gZ28gdG8gYSBTRiAo c3VjaCBhcyBhIERQSSBvciBGVyBvciANCj5JRFMpIGFuZCByZW1haW5pbmcgcGFja2V0cyBjYW4g YnlwYXNzIHRoYXQgU0YsIHRodXMgc2F2aW5nIHRoZSANCj5leHBlbnNpdmUgU0YgcmVzb3VyY2Ug YW5kIHJlZHVjaW5nIGRhdGEgcGF0aCBsYXRlbmN5Lg0KPg0KPkIgYml0OiBUaGUgQiAoQnlwYXNz KSBiaXQsIHdoZW4gc2V0IHRvIDEsIGl0IGlzIHVzZWQgYnkgYSBTZXJ2aWNlDQo+ICAgICAgIEZ1 bmN0aW9uIHRvIHNpZ25hbCB0byBpdHMgU2VydmljZSBGdW5jdGlvbiBGb3J3YXJkZXIgdGhhdCBu bw0KPiAgICAgICBmdXJ0aGVyIHBhY2tldHMgYXJlIHRvIGJlIHNlbnQgdG8gaXQgZm9yIHRoZSBm bG93IHNwZWNpZmllZCBpbiANCj5lbmNhcHN1bGF0ZWQgcGFja2V0Lg0KPg0KPkluIGFkZGl0aW9u LCBTQ0ggZGVmaW5lcyBhIG1ldGFkYXRhIHR5cGUgZm9yIEdlbmVyaWMgQ29udGV4dCBCbG9jaywg DQo+d2hpY2ggaXMgb3B0aW9uYWwgYW5kIGNhbiBiZSB1c2VkIGlmIG5lZWRlZCB0byBjYXJyeSBh bnkgdmVuZG9yJ3MgDQo+c3BlY2lmaWMgIkNvbnRleHQgSGVhZGVyIi4NCj4NCj5BbnkgY29tbWVu dHMgb24gdGhlc2UgbmV3IGFkZGl0aW9ucz8NCj4NCj5UaGFua3MsDQo+Q2F0aHkNCj4NCj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgQ2F0aHkgWmhhbmcNCj5TZW50OiBGcmlkYXksIERlY2VtYmVy IDA1LCAyMDE0IDExOjQ3IEFNDQo+VG86IFNyaW5pIEFkZGVwYWxsaTsgUmVpbmFsZG8gUGVubm8g KHJlcGVubm8pOyBKb2VsIE0uIEhhbHBlcm47IA0KPidzZmNAaWV0Zi5vcmcnDQo+Q2M6IG5zbXVy dGh5QGZyZWVzY2FsZS5jb20NCj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERy YWZ0DQo+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAy KQ0KPg0KPlJvbiwgTG91aXMsIE15byBhbmQgSSBoYXZlIGJlZW4gZGlzY3Vzc2luZyBvZmYgbGlu ZSBsYXN0IGZldyB3ZWVrcyANCj5hYm91dCBkZWZpbmluZyBhIG1ldGFkYXRhIHR5cGUgZm9yIGZs b3cgSUQgaW4gYWRkaXRpb24gdG8gdGhlIHBhdGggSUQgDQo+b2YgdGhlIG1haW4gaGVhZGVyIHRv IHN1cHBvcnQgbG9hZCBiYWxhbmNpbmcgYW1vbmcgU0YgaW5zdGFuY2VzLiBXZSANCj53aWxsIGRl ZmluZSBhIFRMViB0eXBlIGZvciB0aGUgZmxvdyBJRC4gVGhlIGNvbWJpbmF0aW9uIG9mICJwYXRo IElEICsgZmxvdyBJRCINCj5zcGVjaWZpZXMgYSByZWFsaXplZCBzZXJ2aWNlIGNoYWluIGluc3Rh bmNlIHBhdGguIEl0IGlzIGxlZnQgdG8gdGhlIA0KPmRlc2lnbi9pbXBsZW1lbnRhdGlvbiB3aGV0 aGVyIHRvIHVzZSBhIGNlbnRyYWxpemVkIG1ldGhvZCBvciBhIA0KPmRpc3RyaWJ1dGVkIG1ldGhv ZCB0byBiaW5kIHRoZSBmbG93IElEIHRvIGEgcmVhbGl6ZWQgc2VydmljZSBpbnN0YW5jZSANCj5w YXRoIGFsdGhvdWdoIG91ciBvcmlnaW5hbCB0aG91Z2h0IGlzIGZvciBkaXN0cmlidXRlZCBMQiB1 c2FnZS4gSSBhbSANCj5ub3Qgc3VyZSBpZiB3ZSBuZWVkIGEgYml0IGluIHRoZSBoZWFkZXIgdG8g ZGVub3RlIHdoZXRoZXIgdGhlcmUgYXJlIA0KPm1vcmUgcGF0aCBJRCBiaXRzICh3ZSBjYWxsIGl0 IGZsb3cgSUQpIGluIHRoZSBtZXRhZGF0YSBmaWVsZHMgc2luY2UgDQo+d2hlbiB5b3UgcGFyc2Ug dGhlIFRMViBtZXRhZGF0YSwgeW91IHdpbGwga25vdyB3aGV0aGVyIHRoZXJlIGFyZSBmbG93IElE IGJpdHMgb3Igbm90Lg0KPk5vdGUgdGhhdCBpZiBtdWx0aXBsZSBzZXNzaW9ucyBzaGFyZSB0aGUg c2FtZSByZWFsaXplZCBzZXJ2aWNlIGluc3RhbmNlIA0KPnBhdGgsIHRoZXkgd2lsbCBzaGFyZSB0 aGUgc2FtZSAicGF0aCBJRCsgZmxvdyBJRCIuICBXZSBjYW4gYWxzbyANCj5jb25zaWRlciBleHRl bmRpbmcgdGhlIG51bWJlciBvZiBiaXRzIHRvIDMyIGlmIHRoYXQgaXMgdGhlIGNvbnNlbnN1cy4g DQo+V2Ugd2lsbCBwb3N0IGFuIHVwZGF0ZWQgZHJhZnQgZGVzY3JpYmluZyB0aGVzZSBzb29uLg0K Pg0KPlRoYW5rcywNCj5DYXRoeQ0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJv bTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTcmluaSBB ZGRlcGFsbGkNCj5TZW50OiBGcmlkYXksIERlY2VtYmVyIDA1LCAyMDE0IDc6MTcgQU0NCj5Ubzog UmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBKb2VsIE0uIEhhbHBlcm47ICdzZmNAaWV0Zi5vcmcn DQo+Q2M6IG5zbXVydGh5QGZyZWVzY2FsZS5jb20NCj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVu dHMgb24gU0NIIERyYWZ0DQo+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFu Zy1zZmMtc2NoLTAyKQ0KPg0KPg0KPltSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5Lg0KPg0KPlNS SU5JPiBJIGFtIG5vdCBzbyBzdXJlIGFib3V0IGRhdGEgcGxhbmUgZWZmaWNpZW5jeS4gIE1vc3Qg b2YgdGhlDQo+cHJvY2Vzc29ycyB3b3JrIGdvb2QgaWYgdGhlIG51bWJlciBvZiBiaXRzIGFyZSBl aXRoZXIgMzIgb3IgNjQuICBJZiBpdCANCj5pcw0KPjI0IGJpdHMsIHRoZW4gb25lIG5lZWRzIHRv IGRvIG1hc2tpbmcgYW5kIHNoaWZ0aW5nIGJlZm9yZSB0aGUgdmFsdWUgaXMNCj51c2VkIHRvIGRv IGFueSBsb29rdXAuICAgQnV0LCB0aGlzIGRpc2N1c3Npb24gY2FuIGdvIGludG8gZGlmZmVyZW50 DQo+ZGlyZWN0aW9uIDotKSwgaXQgbWF5IG5vdCBiZSBnb29kIHRvIGdvIGluIHRoYXQgZGlyZWN0 aW9uLg0KPg0KPldoZXJlIGRvIHdlIGRyYXcgdGhlIGxpbmU/IDMyLWJpdHMsIDY0LWJpdHMsDQo+ MTI4IGJpdHM/IEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgYSBzZW5zaWJsZSB2YWx1ZSBpbiB0aGUg U2VydmljZSBQYXRoIA0KPmhlYWRlciBhbmQgaWYgeW91IG5lZWQgdG8gY29udmV5IG1vcmUgYml0 cyB5b3UgbmVlZCB0byB1c2UgdGhlIGNvbnRleHQgDQo+aGVhZGVycy4NCj4NCj5TUklOST4gVGhp cyBpcyBhIGdvb2QgcG9pbnQuICBUaGlzIHNob3VsZCB3b3JrIGZpbmUgYXMgbG9uZyBhcyB0aGVy ZSBpcw0KPndheSB0byBjb252ZXkgaW4gdGhlIG1haW4gaGVhZGVyIHRoYXQgdGhlIGV4dGVuc2lv biB0byBwYXRoIElEIGlzIA0KPmF2YWlsYWJsZSBpbiBzbyBhbmQgc28gVExWIGZpZWxkLiAgVGhh dCBzaG91bGQgd29yayB0b28uDQo+DQo+VGhhbmtzDQo+U3JpbmkNCj4NCj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+RnJvbTogUmVpbmFsZG8gUGVubm8gKHJlcGVu bm8pIDxyZXBlbm5vQGNpc2NvLmNvbT4NCj5TZW50OiBGcmlkYXksIERlY2VtYmVyIDUsIDIwMTQg NzowOCBBTQ0KPlRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47ICdz ZmNAaWV0Zi5vcmcnDQo+Q2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+U3ViamVjdDog UmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPihodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4NCj5PbiAxMi81LzE0LCA2OjU0IEFNLCAi U3JpbmkgQWRkZXBhbGxpIiA8c2FkZGVwYWxsaUBmcmVlc2NhbGUuY29tPiB3cm90ZToNCj4NCj4+ DQo+PkluIHJlYWwgZGVwbG95bWVudHMsIG51bWJlciBvZiBhY3RpdmUgcGF0aCBJRHMgYXJlIHZl cnkgbGVzc2VyIHRoYW4gDQo+PjJeNjQsIGJ1dCB0aGVyZSBpcyBhIGdvb2QgcG9zc2liaWxpdHkg b2YgdGhlIG51bWJlciBiZWluZyBtb3JlIHRoYW4gDQo+PjJeMjQgKDE2TSkuDQo+PiBJIHRoaW5r IGJpZ2dlciBwb2ludCBpcyB0aGF0IHdoeSByZXN0cmljdCB0aGlzIGluIHRoZSBzdGFuZGFyZHM/ IFdoYXQgDQo+PmFkdmFudGFnZSBkbyB3ZSBoYXZlIHJlc3RyaWN0aW5nIHRoaXMgc2l6ZSB0byAy NCBiaXRzPw0KPg0KPltSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5LiBXaGVyZSBkbyB3ZSBkcmF3 IHRoZSBsaW5lPyAzMi1iaXRzLCANCj42NC1iaXRzLA0KPjEyOCBiaXRzPyBJIHRoaW5rIHdlIHNo b3VsZCBoYXZlIGEgc2Vuc2libGUgdmFsdWUgaW4gdGhlIFNlcnZpY2UgUGF0aCANCj5oZWFkZXIg YW5kIGlmIHlvdSBuZWVkIHRvIGNvbnZleSBtb3JlIGJpdHMgeW91IG5lZWQgdG8gdXNlIHRoZSBj b250ZXh0IA0KPmhlYWRlcnMuDQo+DQo+DQo+Pg0KPj5UaGVyZSBjYW4gYmUgZGVwbG95bWVudHMs IHdoZXJlIFNGQyBjb250cm9sbGVyIChMb2dpY2FsbHkgY2VudHJhbCwgYnV0DQo+PmRpc3RyaWJ1 dGVkKSAgaXRzZWxmIGNhbiBkbyB0aGUgU0YgaW5zdGFuY2Ugc2VsZWN0aW9uIG9uIHBlcg0KPj5j b25uZWN0aW9uL3Nlc3Npb24gYmFzaXMsIHRoZXJlYnkgYXZvaWRpbmcgdGhlIExCcyBmb3Igc2Vy dmljZXMuICAgSW4gbXkNCj4+dmlldywgYXNzdW1wdGlvbiB0aGF0IHRoZXJlIHdpbGwgYmUgTEIg U0YgZm9yIGVhY2ggc2NhbGUtb3V0IHNlcnZpY2UgDQo+PmluIHRoZSBjaGFpbiBpcyBub3QgdmFs aWQgaW4gYWxsIGNhc2VzLg0KPj4NCj4+VGhhbmtzDQo+PlNyaW5pDQo+Pg0KPj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PkZyb206IFJlaW5hbGRvIFBlbm5vIChy ZXBlbm5vKSA8cmVwZW5ub0BjaXNjby5jb20+DQo+PlNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciA0 LCAyMDE0IDE6MTcgUE0NCj4+VG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IEpvZWwgTS4gSGFs cGVybjsgc2ZjQGlldGYub3JnDQo+PkNjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPj5T dWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+PihodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4+DQo+PklmIEkgdW5kZXJz dG9vZCB5b3UsIEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgcmVhbGlzdGljLiBBcmUgeW91IHNheWlu ZyANCj4+eW91IG5lZWQgNjQtYml0cyBvZiBwYXRocyBhbmQgdGhlbiB3aWxsIG1vbml0b3IgdGhl bSBhbGw/IERvIGZhdWx0IA0KPj50b2xlcmFuY2UgYW5kIE9BTSBmb3IgMl42NC1iaXRzIHdvcnRo IG9mIHBhdGhzPyBKdXN0IGZvciBjb21wYXJpc29uLCANCj4+aXTCuXMgbGlrZSBtYW5hZ2luZyBh bmQgbW9uaXRvcmluZyB0aGUgZW50aXJlIElQdjYgaG9zdCByYW5nZSwgb25lLWJ5LW9uZS4NCj4+ DQo+PkFueXdheSwgSSBkbyBub3QgZXhwZWN0IGV2ZXJ5IHNpbmdsZSBwZXJtdXRhdGlvbnMgdG8g YmUgYSBkaWZmZXJlbnQgcGF0aC4NCj4+DQo+PklmIGVhY2ggc2VydmljZSBoYXMgMjU2IGRldmlj ZXMgcHJvdmlkaW5nIHNpbWlsYXIgc2VydmljZSwgeW91IHNob3VsZCANCj4+bW9zdCBsaWtlbHkg dXNlIGxvYWQtYmFsYW5jaW5nIGFuZCB0aGVuIHlvdSB3b3VsZCBoYXZlIGEgc2luZ2xlIChvciBh DQo+PmZldykgcGF0aHMuIFRoZXJlIGlzIHNvbWUgZGlzY3Vzc2lvbiBnb2luZyBvbiBMQi4NCj4+ DQo+PkZyb20gYSBkYXRhIHBsYW5lIHBlcnNwZWN0aXZlLCB0aGUgcGF0aCBpcyB1bHRpbWF0ZWx5 IGRlZmluZWQgYnkgdGhlIA0KPj5TRkZzIHRyYXZlcnNlZCBhbmQgc2VydmljZXMgcHJvdmlkZWQs IG5vdCBieSBhIHNwZWNpZmljIElQOnBvcnQgdGhhdCANCj4+dGhlIGRldmljZSBwcm92aWRpbmcg dGhlIHNlcnZpY2Ugc2l0cyBvbi4gV2VsbCwgYXQgbGVhc3QgZnJvbSBhIA0KPj5HUEUrTlNIIHBl cnNwZWN0aXZlLg0KPj4NCj4+DQo+Pk9uIDEyLzQvMTQsIDEyOjU3IFBNLCAiU3JpbmkgQWRkZXBh bGxpIiA8c2FkZGVwYWxsaUBmcmVlc2NhbGUuY29tPiB3cm90ZToNCj4+DQo+Pj5JZiBJIHRha2Ug YSBjaGFpbiB3aXRoIDUgc2VydmljZXMgd2l0aCBlYWNoIHNlcnZpY2UgIHNheSBoYXZpbmcgMjU2 IA0KPj4+aW5zdGFuY2VzIGZvciBzY2FsZS1vdXQsIHBvc3NpYmxlIG51bWJlciBvZiBwYXRocyBh cmUNCj4+PjI1NioyNTYqMjU2KjI1NioyNTYgPSAweEZGIEZGIEZGIEZGIEZGLiBPbmUgcmVxdWly ZXMgMzMgYml0cyBpbiB0aGlzIA0KPj4+Y2FzZS4gIElmIHRoZXJlIGFyZSBtb3JlIHNlcnZpY2Vz IGluIHRoZSBjaGFpbiBvciBtb3JlIGNoYWlucyBvciBtb3JlIA0KPj4+aW5zdGFuY2VzIGZvciBz Y2FsZS1vdXQsIHRoZW4gaXQgY291bGQgZ28gdG8gYmlnIG51bWJlciB2ZXJ5IGZhc3QuDQo+Pj4N Cj4+PkFzIEkgbWVudGlvbmVkIG15IHByZWZlcmVuY2UgaXMgdG8gbWFrZSB0aGUgcGF0aCBJRCBz aXplIGZsZXhpYmxlIGZvciANCj4+PmZ1dHVyZSBncm93dGguIElmIHRoYXQgaXMgcGVyY2VpdmVk IGFzIGNvbXBsZXgsIHRoZW4gZ29pbmcgZm9yIDY0Yml0IA0KPj4+aXMgc2FmZXIgYmV0Lg0KPj4+ DQo+Pj5UaGFua3MNCj4+PlNyaW5pDQo+Pj4NCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+PkZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5j b21dDQo+Pj5TZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMDQsIDIwMTQgMTI6MDUgUE0NCj4+PlRv OiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47IHNmY0BpZXRmLm9yZw0K Pj4+Q2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+Pj5TdWJqZWN0OiBSZTogW3NmY10g Q29tbWVudHMgb24gU0NIIERyYWZ0DQo+Pj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+Pj4NCj4+PkEgY29udHJvbGxlciAob3Igb3RoZXIgZGVj aXNpb24gbG9naWMpIGNhbiBjZXJ0YWlubHkgYmUgYXdhcmUgb2Ygc3VjaCANCj4+PmNvbmNlcm5z Lg0KPj4+QnV0IHRoZSBudW1iZXIgb2Ygc2VydmljZSBmdW5jdGlvbiBwYXRocyBpcyBub3QgcmVs YXRlZCB0byB0aGUgbnVtYmVyIA0KPj4+b2YgZmxvd3Mgb3IgdGhlIG51bWJlciBvZiB0ZW5hbnRz LiAgSXQgaXMgcmVsYXRlZCB0byB0aGUgbnVtYmVyIG9mIA0KPj4+Y29tYmluYXRpb25zIG9mIHNl cnZpY2VzIGFuZCB0aGUgcG9saWNpZXMgZm9yIHNlcnZpY2UgZnVuY3Rpb24gDQo+Pj5zZWxlY3Rp b24uDQo+Pj4gV2hpbGUgdGhhdCBjYW4gYmUgYSBsYXJnZSBudW1iZXIsIEkgc3VyZSBob3BlIGl0 IGRvZXMgbm90IGNvbWUgY2xvc2UgDQo+Pj50byBzYXR1cmF0aW5nIDI0IGJpdHMuDQo+Pj4NCj4+ PkhhdmluZyBzYWlkIHRoYXQsIGlmIHdlIHRoaW5rIHRoYXQgMjQgYml0cyBpcyBvbmx5IGp1c3Qg ZW5vdWdoLCB0aGVuIA0KPj4+d2Ugb3VnaHQgdG8gdXNlIDMyLiAgRnJvbSB3aGVyZSBJIHNpdCwg SSB3b3VsZCBub3JtYWxseSBleHBlY3QgMTYgDQo+Pj5iaXRzIHRvIGJlIG1vcmUgdGhhbiBzdWZm aWNpZW50LCB3aGljaCBpcyB3aHkgSSBhbSBjb21mb3J0YWJsZSB3aXRoIDI0Lg0KPj4+SGF2aW5n IHNhaWQgdGhhdCwgdGhlIGZpZWxkIHNpemUgaXMgbm90IGEgYmlnIGRlYWwgdG8gbWUuDQo+Pj4N Cj4+PllvdXJzLA0KPj4+Sm9lbA0KPj4+DQo+Pj5PbiAxMi80LzE0LCAyOjAxIFBNLCBTcmluaSBB ZGRlcGFsbGkgd3JvdGU6DQo+Pj4+DQo+Pj4+IEkgd2FzIG5vdCBpbXBseWluZyB0aGF0IHBhdGgg SUQgc2hvdWxkIGhhdmUgaW5mb3JtYXRpb24gaW4gcmVnYXJkcyANCj4+Pj50byB0ZW5hbnQvY29u dHJvbGxlci9mbG93L3NjYWxlLW91dC4gIEJ1dCBTRkMgY29udHJvbGxlcnMgc2hvdWxkIA0KPj4+ PmtlZXAgdGhlc2UNCj4+Pj5pbiBtaW5kIHRvIGFzc2lnbiB0aGUgcGF0aCBJRC4gICAgQSBkZXBs b3ltZW50IGNhbiBoYXZlIG11bHRpcGxlDQo+Pj4+dGVuYW50cywgZWFjaCB0ZW5hbnQgY2FuIGhh dmUgbXVsdGlwbGUgbmV0d29ya3MsICB0aGVyZSBjb3VsZCBiZSANCj4+Pj5taWxsaW9ucyBvZiBm bG93cyBpbiBlYWNoIG9mIHRob3NlIG5ldHdvcmtzLiAgQW5kIGNvbnNpZGVyaW5nIGFsbCANCj4+ Pj50aGVzZSwNCj4+Pj4gMjQgYml0IHBhdGggSUQgbWF5IG5vdCBiZSBhYmxlIHRvIHJlcHJlc2Vu dCBwYXRocyBmb3IgdGhlc2UgZmxvd3MuDQo+Pj4+SGVuY2UsIEkgd2FzIHdvbmRlcmluZyB3aGV0 aGVyIHBhdGggSUQgY2FuIGJlIGV4dGVuZGVkIHRvIDY0IGJpdHMgb3IgDQo+Pj4+bWFrZSBpdCBm bGV4aWJsZS4NCj4+Pj4NCj4+Pj4gVGhhbmtzDQo+Pj4+IFNyaW5pDQo+Pj4+DQo+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gRnJvbTogSm9lbCBNLiBI YWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4+PiBTZW50OiBUaHVyc2RheSwgRGVjZW1i ZXIgNCwgMjAxNCA3OjQyIEFNDQo+Pj4+IFRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBzZmNA aWV0Zi5vcmcNCj4+Pj4gQ2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+Pj4+IFN1Ympl Y3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4+Pj4gKGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4+Pg0KPj4+PiBUaGUgSW5k ZXggaXMgbm90IGp1c3QgZm9yIGxvb3AgcHJldmVudGlvbi4gIEluIHRoZSBjYXNlIG9mICANCj4+ Pj5hbWJpZ3VpdHksIHRoZSBpbmRleCB0ZWxscyB0aGUgU0ZGIHdoZXJlIGluIHRoZSBwYXRoIHRo ZSBwYWNrZXQgDQo+Pj4+Y3VycmVudGx5IHJlc2lkZXMuDQo+Pj4+ICAgIFRoZXJlIGFyZSBtdWx0 aXBsZSB3YXlzIHN1Y2ggYW1iaWd1aXR5IGNhbiBvY2N1ci4NCj4+Pj4NCj4+Pj4gVGhlIFBhdGgg SWRlbnRpZmllciBpcyBzcGVjaWZpY2FsbHkgbm90IGV4cGVjdGVkIHRvIGluY2x1ZGUgDQo+Pj4+ IGNvbnRyb2xsZXIgSUQgb3IgVGVuYW50IElELiAgV2hpbGUgYSBkZXBsb3llciBjYW4gaGF2ZSBh IHBhdGggcGVyIA0KPj4+PiB0ZW5hbnQsIHRoZSBhcmNoaXRlY3R1cmUgc3RpbGwgZG9lcyBub3Qg dHJlYXQgdGhlIHBhdGggSUQgYXMgYSANCj4+Pj4gdGVuYW50IElELiAgVGVuYW50IElELCBjb250 cm9sbGVyIElELCBhbmQgb3RoZXIgbm9uLXBhdGgtc3BlY2lmeWluZyANCj4+Pj4gaW5mb3JtYXRp b24gaXMgdG8gYmUgY2FycmllZCBpbiBtZXRhZGF0YS4NCj4+Pj4NCj4+Pj4gWW91cnMsDQo+Pj4+ IEpvZWwNCj4+Pj4NCj4+Pj4gT24gMTIvNC8xNCwgMTA6MDIgQU0sIFNyaW5pIEFkZGVwYWxsaSB3 cm90ZToNCj4+Pj4+IFR3byBjb21tZW50cyA6DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IDEuICBTRiBJ bmRleCA6ICBTaW5jZSBpdCBpcyBtZWFudCBmb3IgbG9vcCBkZXRlY3Rpb24sICB3b3VsZG4ndCAN Cj4+Pj4+IGJldHRlciB0byByZW5hbWUgdGhpcyBhcyAiVFRMIj8NCj4+Pj4+DQo+Pj4+PiAyLiAg UGF0aCBJZGVudGlmaWVyIDogICAgMjQgYml0IHBhdGggaWRlbnRpZmllciBzZWVtcyB0byBiZSB0 b28gbGVzcy4NCj4+Pj4+IEJhc2VkIG9uIG91ciBleHBlcmllbmNlIGluIHRyYWZmaWMgc3RlZXJp bmcsICB0aGlzIHBhdGggaWRlbnRpZmllciANCj4+Pj4+bmVlZHMgdG8gZW5jb2RlIGdvb2QgYW1v dW50IG9mIGluZm9ybWF0aW9uIHRvIG1ha2UgaXQgdW5pcXVlLiAgRm9yIA0KPj4+Pj5leGFtcGxl LA0KPj4+Pj4gICAgdGhpcyBpZGVudGlmaWVyIG5lZWRzIHRvIGVuY29kZSAoaW4gb3VyIGNhc2Up IHNvbWUgaW5mb3JtYXRpb24gDQo+Pj4+PnJlcHJlc2VudGluZyB0aGUgZGlzdHJpYnV0ZWQgY29u dHJvbGxlciBJRCwgIHRlbmFudCBJRCwgIGZsb3cgSUQsDQo+Pj4+PiAgICBTZXJ2aWNlIGZ1bmN0 aW9uIGluc3RhbmNlIChpbiBjYXNlIG9mIHNjYWxlLW91dCkgYW5kIGZldyBtb3JlLi4NCj4+Pj4+ IE9uZSBzdWdnZXN0aW9uIGlzIHRvIG1ha2UgaXQgNjQgYml0cyB2YWx1ZSAgb3IgdG8gbWFrZSBp dCBldmVuIA0KPj4+Pj5leHRlbmRhYmxlLA0KPj4+Pj4gICAgaXQgaXMgZ29vZCBpZiBwYXRoIGlk ZW50aWZpZXIgaXMgYWxzbyByZXByZXNlbnRlZCBpbiBUTFYgZm9ybS4NCj4+Pj4+DQo+Pj4+Pg0K Pj4+Pj4gVGhhbmtzDQo+Pj4+Pg0KPj4+Pj4gU3JpbmkNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+ Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+Pj4NCj4+Pg0KPj4+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PnNmYyBtYWls aW5nIGxpc3QNCj4+PnNmY0BpZXRmLm9yZw0KPj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCj4+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj5zZmMgbWFpbGluZyBsaXN0DQo+c2ZjQGlldGYub3JnDQo+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBtYWlsaW5nIGxpc3QNCj5z ZmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K Pg0KPg0KPlRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzICh0aGUgIm1lc3NhZ2UiKSBh cmUgY29uZmlkZW50aWFsLCANCj5pbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWVzLiBJ ZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgDQo+cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgDQo+dGhpcyBtZXNzYWdl IGZyb20geW91ciBzeXN0ZW0uIEluIHRoaXMgY2FzZSwgeW91IGFyZSBub3QgYXV0aG9yaXplZCB0 byANCj51c2UsIGNvcHkgdGhpcyBtZXNzYWdlIGFuZC9vciBkaXNjbG9zZSB0aGUgY29udGVudCB0 byBhbnkgb3RoZXIgcGVyc29uLg0KPkUtbWFpbHMgYXJlIHN1c2NlcHRpYmxlIHRvIGFsdGVyYXRp b24uIE5laXRoZXIgUW9zbW9zIG5vciBhbnkgb2YgaXRzIA0KPnN1YnNpZGlhcmllcyBvciBhZmZp bGlhdGVzIHNoYWxsIGJlIGxpYWJsZSBmb3IgdGhlIG1lc3NhZ2UgaWYgYWx0ZXJlZCwgDQo+Y2hh bmdlZCBvciBmYWxzaWZpZWQuDQo+DQo+Q2UgbWVzc2FnZSBldCB0b3V0ZXMgc2VzIHBpw6hjZXMg am9pbnRlcyAoY2ktYXByw6hzIGxlICJtZXNzYWdlIilzb250IA0KPmNvbmZpZGVudGllbHMgZXQg w6l0YWJsaXMgw6AgbCdpbnRlbnRpb24gZXhjbHVzaXZlIGRlIHNlcyBkZXN0aW5hdGFpcmVzLiAN Cj5TaSB2b3VzIGF2ZXogcmXDp3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCBtZXJjaSBk4oCZZW4g aW5mb3JtZXIgDQo+aW1tw6lkaWF0ZW1lbnQgc29uIMOpbWV0dGV1ciBwYXIgY291cnJpZXIgw6ls ZWN0cm9uaXF1ZSBldCBk4oCZZWZmYWNlciBjZSANCj5tZXNzYWdlIGRlIHZvdHJlIHN5c3TDqG1l LiBEYW5zIGNldHRlIGh5cG90aMOoc2UsIHZvdXMgbuKAmcOqdGVzIHBhcyANCj5hdXRvcmlzw6kg w6AgdXRpbGlzZXIsIGNvcGllciBjZSBtZXNzYWdlIGV0L291IGVuIGRpdnVsZ3VlciBsZSBjb250 ZW51IMOgIA0KPnVuIHRpZXJzLiBUb3V0IG1lc3NhZ2Ugw6lsZWN0cm9uaXF1ZSBlc3Qgc3VzY2Vw dGlibGUgZCdhbHTDqXJhdGlvbi4gDQo+UW9zbW9zIGV0IHNlcyBmaWxpYWxlcyBkw6ljbGluZW50 IHRvdXRlIHJlc3BvbnNhYmlsaXTDqSBhdSB0aXRyZSBkZSBjZSANCj5tZXNzYWdlIHMnaWwgYSDD qXTDqSBhbHTDqXLDqSwgZMOpZm9ybcOpIG91IGZhbHNpZmnDqS4NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBtYWlsaW5nIGxpc3QNCj5zZmNA aWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxp bmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0K From nobody Mon Feb 2 14:42: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 F2F101A1AAC for ; Mon, 2 Feb 2015 14:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, 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 yZUtjd62j7So for ; Mon, 2 Feb 2015 14:42:10 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A89C1A1AF0 for ; Mon, 2 Feb 2015 14:42:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BSA16136; Mon, 02 Feb 2015 22:42:08 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Feb 2015 22:42:07 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.133]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0158.001; Mon, 2 Feb 2015 14:42:02 -0800 From: Cathy Zhang To: Sumandra Majee , Nicolas BOUTHORS , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZyAGG+AgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgD//7j7oIBVIj4ggALqPwCAADaLgIAEqiHQ Date: Mon, 2 Feb 2015 22:42:02 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.78] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: Jerome TOLLET Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 02 Feb 2015 22:42:14 -0000 SGkgU3VtYW5kcmEsDQoNClRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cy4gUGxlYXNlIHNlZSBp bmxpbmUuIA0KDQpDYXRoeQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3Vt YW5kcmEgTWFqZWUgW21haWx0bzpTLk1hamVlQEY1LmNvbV0gDQpTZW50OiBGcmlkYXksIEphbnVh cnkgMzAsIDIwMTUgMjo1MyBQTQ0KVG86IE5pY29sYXMgQk9VVEhPUlM7IENhdGh5IFpoYW5nOyAn c2ZjQGlldGYub3JnJw0KQ2M6IEplcm9tZSBUT0xMRVQNClN1YmplY3Q6IFJlOiBbc2ZjXSBDb21t ZW50cyBvbiBTQ0ggRHJhZnQgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFu Zy1zZmMtc2NoLTAyKQ0KDQpIZWxsbywNCg0KVGhpcyBpcyBhbiBpbnRlcmVzdGluZyBkaXNjdXNz aW9uIGFuZCBJIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCB0aGUNCm1vdGl2YXRpb24gb2YgYmV0 dGVyLiBUaGUgdHJvdWJsZSB3aXRoIGEgcHJvdG9jb2wgZG9jdW1lbnQgaXMgdGhhdCBpdCBpcw0K dHlwaWNhbGx5IGhhcyBpbmFkZXF1YXRlIGRldGFpbCBhYm91dCB0aGUgbG9naWMuIFNvIHRvIGNh c3QgdGhpcyBpbnRvDQpzb21ld2hhdCBvZiBhIGNvbmNyZXRlIHRlcm1zLCBjb25zaWRlciB0aGUg Zm9sbG93aW5nLg0KDQoNCiAgICANCiAgICAgICBTRkYoeCkgIHsgU2Z4KDEpIFNmeCgyKeKAplNm eChuKSB9ICAg4oCU4oCU4oCU4oCUPiAgIFNGRih5KSB7IFNmeSgxKSBTZnkoMikNCuKApi4gU2Z5 KG0pIH0gICA6OiBMb2dpY2FsIENoYWluIGluIE9ORSBkaXJlY3Rpb24gb25seS4NCiAgICAgICAN CiAgICAgICBQSFlTSUNBTCBXT1JMRDoNCiAgICAgICAgICBBKSB0aGUgU0ZGIGNvdWxkIGJlIGEN CiAgICAgICAgICAgIC0gY29tcG9uZW50IG9mIFZTV0lUQ0ggKHBpY2sgeW91ciBmYXYgcHJvdG9j b2wgZm9yIGNvbmZpZ3VyaW5nDQp0aG9zZSBlbnRpdGllcyB9DQogICAgICAgICAgICAtIEEgbG9h ZCBiYWxhbmNlcg0KICAgICAgICAgICAgLSBBIEhXIHN3aXRjaC9yb3V0ZXIgc29tZSBMMi9MMyBj b21ibw0KDQogICAgICAgICAgQikgU2YgaW5zdGFuY2UgY291bGQgYmUsDQogICAgICAgICAgICAg ICAtIFZpcnR1YWwgbWFjaGluZSwgI04gb2YgdGhvc2UNCiAgICAgICAgICAgICAgIC0gcGh5c2lj YWwNCiAgICAgICAgICAgICAgIC0gQ29udGFpbmVyICNNIHdoaWNoIGlzIG9mdGVuIDUgb3IgbW9y ZSB4ICNODQogICAgICAgICAgICAgICAtIENsdXN0ZXIgdGhhdCB3ZSBkb27igJl0IGtub3cNCg0K SXQgaXMgcG9zc2libGUgdG8gaGF2ZSBtdWx0aXBsZSBwaHlzaWNhbCBTRkYoeCkgYWxzby4NCg0K QSBzZWxlY3Rpb24gb2YgYSBnaXZlbiBTRiAoc2VydmljZSkoaW5zdGFuY2UpIGlzIGEgY2FuIGJl IHNpbXBsZSBvcg0KY29tcGxleC4gRm9yIGV4YW1wbGUgU0ZGKHgpIG1heSBoYXZlIHRoZSBiZXN0 IGtub3dsZWRnZSB0byBzZWxlY3QgU2Z4KDEpDQpiYWVkIG9uIGEgZ2l2ZW4gY3JpdGVyaW9uICh3 aGljaCBjb3VsZCBiZSBwYXJ0IG9mIHRoZSBwb2xpY3kpLiAgVGhlbiBJDQpkb27igJl0IHNlZSBh IHJlYXNvbiB0byBoYXZlIFJTUC4NCg0KQ2F0aHk+IFJTUCBJRCBpcyB1c2VkIGJ5IFNGRiB0byBp ZGVudGlmeSBhIHJlbmRlcmVkIHBhdGggb2Ygc2VydmljZSBpbnN0YW5jZXMuIFNvIEV2ZW4gU0ZG IGhhdmUgdGhlIGJlc3Qga25vd2xlZGdlIHRvIHNlbGVjdCB0aGUgU0Z4LCANCkNhdGh5PiBhZnRl ciB0aGUgU0ZGIHNlbGVjdHMgdGhlIFNGeCBhbmQgYmluZHMgaXQgdG8gdGhlIFJTUCBJRCwgZm9s bG93LW9uIHBhY2tldHMgY2FuIGp1c3QgYmUgZm9yd2FyZGVkIGJhc2VkIG9uIFJTUCBJRC4gDQoN Ckl0IGlzIHBvc3NpYmxlIHRoYXQgbG9va3VwIChwYXRoKSBAIFNGRih4KSBwcm9kdWNlcyBhIHNw ZWNpZmljIGluc3RhbmNlIG9mDQpTZnkgYW5kIHllcyB0aGVuIHNvbWV0aGluZyBsaWtlIFJTUCB3 b3VsZCBiZSByZXF1aXJlZC4gQnV0IEkgd291bGQgYXJndWUNCnRoYXQgam9iIFNGRih5KSBjYW4g YWxzbyBiZSBzdWJzdW1lZCBieSBTRkYoeCkuDQoNCkNhdGh5PiBJIGRvIG5vdCBnZXQgd2hhdCB5 b3UgbWVhbiBoZXJlLiBDb3VsZCB5b3UgY2xhcmlmeT8gDQoNCklzIGl0IHBvc3NpYmxlIGZvciBh IGNlbnRyYWwgY29udHJvbGxlciB0byBwaWNrIGVhY2ggaW5zdGFuY2Ugb2Ygc2VydmljZSwNCmJ1 dCBzdWNoIGFuIGltcGxlbWVudGF0aW9uIHRlbmRzIHRvIHNjYWxlIHBvb3JseS4gVGhlIGFtb3Vu dCBvZiBzdGF0ZSwNCnByb2JhYmlsaXR5IG9mIGEgaW5zdGFuY2UgZ29pbmcgZG93biBiZXR3ZWVu IHNlbGVjdGlvbiBhbmQgZmxvdyBhcnJpdmFsDQpnb2VzIHVwLiANCg0KUmVnYXJkcy4NCg0KU3Vt YW5kcmENCg0KDQoNCk9uIDEvMzAvMTUsIDM6MzggQU0sICJOaWNvbGFzIEJPVVRIT1JTIiA8Tmlj b2xhcy5CT1VUSE9SU0Bxb3Ntb3MuY29tPg0Kd3JvdGU6DQoNCj5IZWxsbyBDYXRoeSwNCj4NCj5J bmRlZWQgdGhlIG5vdGlvbiBvZiAicmVuZGVyZWQgc2VydmljZSBwYXRoIElEIihSU1AgSUQpIHNl ZW1zIHJlbGV2YW50IGFzDQo+dGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBzdGlwdWxhdGVzIHRo YXQgdGhlIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKQ0KPnByb3ZpZGVzIGFuIGFic3RyYWN0 IG5vdGlvbiBvZiBhIHNlcnZpY2UgY2hhaW4sIHdoaWxlIHRoZSBSU1AgaXMgYQ0KPmNvbnN0cmFp bmVkIGxpc3Qgb2YgbG9jYXRpb25zLg0KPg0KPlNGQyBoZWFkZXIgIlNlcnZpY2UgUGF0aCBJZGVu dGlmaWVyIiAoU1BJKSAgaXMgdXNlZCBpbiBib3RoIE5TSCBhbmQgU0NIDQo+cHJvdG9jb2wgYW5k IGluIGJvdGggY2FzZSBzZWVtIHRvIGlkZW50aWZ5IHRvIGEgcGFydGljdWxhciBTRlAuDQo+DQo+ TlNIKHY1KSBmb3IgZXhhbXBsZSBzdGF0ZXMgdGhhdA0KPiIgQXMgZGVzY3JpYmVkIGFib3ZlLCBO U0ggY29udGFpbnMgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciAoU1BJKSBhbmQNCj4gICBhIHNl cnZpY2UgaW5kZXggKFNJKS4gIFRoZSBTUEkgaXMsIGFzIHBlciBpdHMgbmFtZSwgYW4gaWRlbnRp Zmllci4NCj4gICBUaGUgU1BJIGFsb25lIGNhbm5vdCBiZSB1c2VkIHRvIGZvcndhcmQgcGFja2V0 cyBhbG9uZyBhIHNlcnZpY2UgcGF0aC4NCj4gICBSYXRoZXIgdGhlIFNQSSBwcm92aWRlIGEgbGV2 ZWwgb2YgaW5kaXJlY3Rpb24gYmV0d2VlbiB0aGUgc2VydmljZQ0KPiAgIHBhdGgvdG9wb2xvZ3kg YW5kIHRoZSB0aGUgbmV0d29yayB0cmFuc3BvcnQuICBGdXJ0aGVybW9yZSwgdGhlcmUgaXMNCj4g ICBubyByZXF1aXJlbWVudCwgb3IgZXhwZWN0YXRpb24gb2YgYW4gU1BJIGJlaW5nIGJvdW5kIHRv IGEgcHJlLQ0KPiAgIGRldGVybWluZWQgb3Igc3RhdGljIG5ldHdvcmsgcGF0aC4iDQo+DQo+U3Rp bGwgTlNIKHY1KSAgc2hvd3MgdGhhdCBTUEkgKG5vdCBhIFJTUCBJRCkgIHNob3VsZCBiZSBwYXJ0 IG9mIHRoZSBrZXkNCj5lbGVtZW50IG9mIGFuIFNGRiB0byBsb29rdXAgb24gZm9yd2FyZGluZyB0 YWJsZXMuICBCdXQgSSBjb3VsZCBub3QgZmluZA0KPmluIE5TSCAgaG93IHRvIHVzZSB0aGUgbm90 aW9uIG9mDQo+UmVuZGVyZWQgc2VydmljZSBwYXRoIHdoaWNoIHdhcyBkZWZpbmVkIGluIHRoZSBh cmNoaXRlY3R1cmUgZG9jdW1lbnQuDQo+DQo+WW91IHByb3Bvc2FsIHNlZW1zIHRvIG1lIHZlcnkg dXNlZnVsLA0KPg0KPkFuIFJTUCBJRCAoaW5kZXBlbmRlbnQgb2YgdGhlIFNQSSBidXQgcGFydCBv ZiB0aGUgc2FtZSBuYW1lIHNwYWNlKSBjb3VsZA0KPmJlIHVzZWQgdGhlIHNhbWUgd2F5IGFzIFNQ SSBieSBTRkYgZm9yIGV4YW1wbGUsIGFsbG93aW5nIGEgU2VydmljZQ0KPkNsYXNzaWZpZXIgdG8g Y29udHJvbCByZW1vdGUgbG9hZCBiYWxhbmNpbmcgZm9yIGV4YW1wbGUuDQo+DQo+VGhpcyBzYWlk IHRoZSBSU1AgSUQgdmFsdWVzIGNvdWxkIGJlIHJlbGF0aXZlIHRvIGEgcGFydGljdWxhciBTZXJ2 aWNlDQo+UGF0aCwgd2hpY2ggd291bGQgcmV2ZW50IHVzaW5nIHRoZW0gYXMgd2UgZG8gZm9yIFNQ SSBpbiBTRkYgZm9yd2FyZGluZw0KPnRhYmxlcy4NCj4NCj5XZSBtYXkgd2FudCB0byBwcmVjaXNl IGlmIHRoZSBSU1AgSUQgaXMgdG8gYmUgcmVsYXRpdmUgb2YgYWJzb2x1dGUsIGFzIGl0DQo+c2hv dWxkIGhhdmUgYW4gaW1wYWN0IG9uIGZvcndhcmRpbmcgdGFibGUgc3RydWN0dXJlIGlmIHdlIGRl Y2lkZSB0byB1c2UNCj50aGlzIGNvbmNlcHQuDQo+DQo+UGVyc29uYWxseSBJIGxpa2UgdGhlIG5v dGlvbiBvZiBhIHJlbGF0aXZlIFJTUCBJRCwgYXMgd2UgY291bGQgdGhlbiB1c2UNCj5zb21lIGNv bnZlbnRpb25zLCBzdHJ1Y3R1cmUgaXQsIHBvc3NpYmx5IGV4dGVuZGluZyBpdHMgdXNlLg0KPg0K Pk5pY29sYXMNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IENhdGh5IFpo YW5nIFttYWlsdG86Q2F0aHkuSC5aaGFuZ0BodWF3ZWkuY29tXQ0KPlNlbnQ6IGpldWRpIDI5IGph bnZpZXIgMjAxNSAyMDo0NA0KPlRvOiBDYXRoeSBaaGFuZzsgU3JpbmkgQWRkZXBhbGxpOyBSZWlu YWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4NCj5IYWxwZXJuOyAnc2ZjQGlldGYub3JnJw0K PkNjOiBuc211cnRoeUBmcmVlc2NhbGUuY29tDQo+U3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRz IG9uIFNDSCBEcmFmdA0KPihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmct c2ZjLXNjaC0wMikNCj4NCj5IaSBldmVyeW9uZSwNCj4NCj5XZSBoYXZlIHVwbG9hZGVkIGEgbmV3 IFNDSCB2ZXJzaW9uICgzKSB3aGljaCBhZGRzIGRlZmluaXRpb24gb2YgYSBuZXcNCj5tZXRhZGF0 YSB0eXBlIGZvciB0aGUgZmxvdyBJRCB0byBzdXBwb3J0IGxvYWQgYmFsYW5jaW5nIGFtb25nIFNG DQo+aW5zdGFuY2VzIGFuZCBtaXRpZ2F0ZSB0aGUgcG90ZW50aWFsIGlzc3VlIG9mICJub3QgZW5v dWdoIHBhdGggSUQiLiBUaGUNCj5mbG93IElEIGlzIG5hbWVkICJyZW5kZXJlZCBzZXJ2aWNlIHBh dGggSUQiIGluIHRoZSBkcmFmdC4gUGxlYXNlIHJlZmVyIHRvDQo+c2VjdGlvbiA0LjMuMiBvZiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16aGFuZy1zZmMtc2NoLw0KPmZv ciBkZXRhaWwgZGVzY3JpcHRpb24uDQo+DQo+SW4gaXRzIHByZXZpb3VzIHZlcnNpb24sIFNDSCBk ZWZpbmVzIGEgIkJ5cGFzcyBiaXQiIGluIHRoZSBiYXNlIGhlYWRlci4NCj5UaGlzIGJpdCBlbmFi bGVzIHRoZSBTRiB0byBwcm92aWRlIGZlZWRiYWNrL25vdGlmaWNhdGlvbiB2aWEgdGhlIGRhdGEN Cj5wYXRoIHRvIGl0cyBjb25uZWN0aW5nIFNGRiBhYm91dCB3aGV0aGVyIHRoZSByZW1haW5pbmcg cGFja2V0cyBvZiB0aGUgU0ZDDQo+c2hvdWxkIGJ5cGFzcyB0aGF0IFNGLiBUaGlzIGlzIHVzZWZ1 bCBpbiB0aGUgY2FzZSB0aGF0IG9ubHkgdGhlIGZpcnN0IGZldw0KPnBhY2tldHMgb2YgYSBmbG93 IG5lZWQgdG8gZ28gdG8gYSBTRiAoc3VjaCBhcyBhIERQSSBvciBGVyBvciBJRFMpIGFuZA0KPnJl bWFpbmluZyBwYWNrZXRzIGNhbiBieXBhc3MgdGhhdCBTRiwgdGh1cyBzYXZpbmcgdGhlIGV4cGVu c2l2ZSBTRg0KPnJlc291cmNlIGFuZCByZWR1Y2luZyBkYXRhIHBhdGggbGF0ZW5jeS4NCj4NCj5C IGJpdDogVGhlIEIgKEJ5cGFzcykgYml0LCB3aGVuIHNldCB0byAxLCBpdCBpcyB1c2VkIGJ5IGEg U2VydmljZQ0KPiAgICAgICBGdW5jdGlvbiB0byBzaWduYWwgdG8gaXRzIFNlcnZpY2UgRnVuY3Rp b24gRm9yd2FyZGVyIHRoYXQgbm8NCj4gICAgICAgZnVydGhlciBwYWNrZXRzIGFyZSB0byBiZSBz ZW50IHRvIGl0IGZvciB0aGUgZmxvdyBzcGVjaWZpZWQgaW4NCj5lbmNhcHN1bGF0ZWQgcGFja2V0 Lg0KPg0KPkluIGFkZGl0aW9uLCBTQ0ggZGVmaW5lcyBhIG1ldGFkYXRhIHR5cGUgZm9yIEdlbmVy aWMgQ29udGV4dCBCbG9jaywgd2hpY2gNCj5pcyBvcHRpb25hbCBhbmQgY2FuIGJlIHVzZWQgaWYg bmVlZGVkIHRvIGNhcnJ5IGFueSB2ZW5kb3IncyBzcGVjaWZpYw0KPiJDb250ZXh0IEhlYWRlciIu DQo+DQo+QW55IGNvbW1lbnRzIG9uIHRoZXNlIG5ldyBhZGRpdGlvbnM/DQo+DQo+VGhhbmtzLA0K PkNhdGh5DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBzZmMgW21haWx0 bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhdGh5IFpoYW5nDQo+U2VudDog RnJpZGF5LCBEZWNlbWJlciAwNSwgMjAxNCAxMTo0NyBBTQ0KPlRvOiBTcmluaSBBZGRlcGFsbGk7 IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgSm9lbCBNLiBIYWxwZXJuOw0KPidzZmNAaWV0Zi5v cmcnDQo+Q2M6IG5zbXVydGh5QGZyZWVzY2FsZS5jb20NCj5TdWJqZWN0OiBSZTogW3NmY10gQ29t bWVudHMgb24gU0NIIERyYWZ0DQo+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16 aGFuZy1zZmMtc2NoLTAyKQ0KPg0KPlJvbiwgTG91aXMsIE15byBhbmQgSSBoYXZlIGJlZW4gZGlz Y3Vzc2luZyBvZmYgbGluZSBsYXN0IGZldyB3ZWVrcyBhYm91dA0KPmRlZmluaW5nIGEgbWV0YWRh dGEgdHlwZSBmb3IgZmxvdyBJRCBpbiBhZGRpdGlvbiB0byB0aGUgcGF0aCBJRCBvZiB0aGUNCj5t YWluIGhlYWRlciB0byBzdXBwb3J0IGxvYWQgYmFsYW5jaW5nIGFtb25nIFNGIGluc3RhbmNlcy4g V2Ugd2lsbCBkZWZpbmUNCj5hIFRMViB0eXBlIGZvciB0aGUgZmxvdyBJRC4gVGhlIGNvbWJpbmF0 aW9uIG9mICJwYXRoIElEICsgZmxvdyBJRCINCj5zcGVjaWZpZXMgYSByZWFsaXplZCBzZXJ2aWNl IGNoYWluIGluc3RhbmNlIHBhdGguIEl0IGlzIGxlZnQgdG8gdGhlDQo+ZGVzaWduL2ltcGxlbWVu dGF0aW9uIHdoZXRoZXIgdG8gdXNlIGEgY2VudHJhbGl6ZWQgbWV0aG9kIG9yIGENCj5kaXN0cmli dXRlZCBtZXRob2QgdG8gYmluZCB0aGUgZmxvdyBJRCB0byBhIHJlYWxpemVkIHNlcnZpY2UgaW5z dGFuY2UNCj5wYXRoIGFsdGhvdWdoIG91ciBvcmlnaW5hbCB0aG91Z2h0IGlzIGZvciBkaXN0cmli dXRlZCBMQiB1c2FnZS4gSSBhbSBub3QNCj5zdXJlIGlmIHdlIG5lZWQgYSBiaXQgaW4gdGhlIGhl YWRlciB0byBkZW5vdGUgd2hldGhlciB0aGVyZSBhcmUgbW9yZSBwYXRoDQo+SUQgYml0cyAod2Ug Y2FsbCBpdCBmbG93IElEKSBpbiB0aGUgbWV0YWRhdGEgZmllbGRzIHNpbmNlIHdoZW4geW91IHBh cnNlDQo+dGhlIFRMViBtZXRhZGF0YSwgeW91IHdpbGwga25vdyB3aGV0aGVyIHRoZXJlIGFyZSBm bG93IElEIGJpdHMgb3Igbm90Lg0KPk5vdGUgdGhhdCBpZiBtdWx0aXBsZSBzZXNzaW9ucyBzaGFy ZSB0aGUgc2FtZSByZWFsaXplZCBzZXJ2aWNlIGluc3RhbmNlDQo+cGF0aCwgdGhleSB3aWxsIHNo YXJlIHRoZSBzYW1lICJwYXRoIElEKyBmbG93IElEIi4gIFdlIGNhbiBhbHNvIGNvbnNpZGVyDQo+ ZXh0ZW5kaW5nIHRoZSBudW1iZXIgb2YgYml0cyB0byAzMiBpZiB0aGF0IGlzIHRoZSBjb25zZW5z dXMuIFdlIHdpbGwgcG9zdA0KPmFuIHVwZGF0ZWQgZHJhZnQgZGVzY3JpYmluZyB0aGVzZSBzb29u Lg0KPg0KPlRoYW5rcywNCj5DYXRoeQ0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTcmlu aSBBZGRlcGFsbGkNCj5TZW50OiBGcmlkYXksIERlY2VtYmVyIDA1LCAyMDE0IDc6MTcgQU0NCj5U bzogUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBKb2VsIE0uIEhhbHBlcm47ICdzZmNAaWV0Zi5v cmcnDQo+Q2M6IG5zbXVydGh5QGZyZWVzY2FsZS5jb20NCj5TdWJqZWN0OiBSZTogW3NmY10gQ29t bWVudHMgb24gU0NIIERyYWZ0DQo+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16 aGFuZy1zZmMtc2NoLTAyKQ0KPg0KPg0KPltSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5Lg0KPg0K PlNSSU5JPiBJIGFtIG5vdCBzbyBzdXJlIGFib3V0IGRhdGEgcGxhbmUgZWZmaWNpZW5jeS4gIE1v c3Qgb2YgdGhlDQo+cHJvY2Vzc29ycyB3b3JrIGdvb2QgaWYgdGhlIG51bWJlciBvZiBiaXRzIGFy ZSBlaXRoZXIgMzIgb3IgNjQuICBJZiBpdCBpcw0KPjI0IGJpdHMsIHRoZW4gb25lIG5lZWRzIHRv IGRvIG1hc2tpbmcgYW5kIHNoaWZ0aW5nIGJlZm9yZSB0aGUgdmFsdWUgaXMNCj51c2VkIHRvIGRv IGFueSBsb29rdXAuICAgQnV0LCB0aGlzIGRpc2N1c3Npb24gY2FuIGdvIGludG8gZGlmZmVyZW50 DQo+ZGlyZWN0aW9uIDotKSwgaXQgbWF5IG5vdCBiZSBnb29kIHRvIGdvIGluIHRoYXQgZGlyZWN0 aW9uLg0KPg0KPldoZXJlIGRvIHdlIGRyYXcgdGhlIGxpbmU/IDMyLWJpdHMsIDY0LWJpdHMsDQo+ MTI4IGJpdHM/IEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgYSBzZW5zaWJsZSB2YWx1ZSBpbiB0aGUg U2VydmljZSBQYXRoDQo+aGVhZGVyIGFuZCBpZiB5b3UgbmVlZCB0byBjb252ZXkgbW9yZSBiaXRz IHlvdSBuZWVkIHRvIHVzZSB0aGUgY29udGV4dA0KPmhlYWRlcnMuDQo+DQo+U1JJTkk+IFRoaXMg aXMgYSBnb29kIHBvaW50LiAgVGhpcyBzaG91bGQgd29yayBmaW5lIGFzIGxvbmcgYXMgdGhlcmUg aXMNCj53YXkgdG8gY29udmV5IGluIHRoZSBtYWluIGhlYWRlciB0aGF0IHRoZSBleHRlbnNpb24g dG8gcGF0aCBJRCBpcw0KPmF2YWlsYWJsZSBpbiBzbyBhbmQgc28gVExWIGZpZWxkLiAgVGhhdCBz aG91bGQgd29yayB0b28uDQo+DQo+VGhhbmtzDQo+U3JpbmkNCj4NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+RnJvbTogUmVpbmFsZG8gUGVubm8gKHJlcGVubm8p IDxyZXBlbm5vQGNpc2NvLmNvbT4NCj5TZW50OiBGcmlkYXksIERlY2VtYmVyIDUsIDIwMTQgNzow OCBBTQ0KPlRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47ICdzZmNA aWV0Zi5vcmcnDQo+Q2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+U3ViamVjdDogUmU6 IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4NCj5PbiAxMi81LzE0LCA2OjU0IEFNLCAiU3Jp bmkgQWRkZXBhbGxpIiA8c2FkZGVwYWxsaUBmcmVlc2NhbGUuY29tPiB3cm90ZToNCj4NCj4+DQo+ PkluIHJlYWwgZGVwbG95bWVudHMsIG51bWJlciBvZiBhY3RpdmUgcGF0aCBJRHMgYXJlIHZlcnkg bGVzc2VyIHRoYW4NCj4+Ml42NCwgYnV0IHRoZXJlIGlzIGEgZ29vZCBwb3NzaWJpbGl0eSBvZiB0 aGUgbnVtYmVyIGJlaW5nIG1vcmUgdGhhbiAyXjI0DQo+PigxNk0pLg0KPj4gSSB0aGluayBiaWdn ZXIgcG9pbnQgaXMgdGhhdCB3aHkgcmVzdHJpY3QgdGhpcyBpbiB0aGUgc3RhbmRhcmRzPyBXaGF0 DQo+PmFkdmFudGFnZSBkbyB3ZSBoYXZlIHJlc3RyaWN0aW5nIHRoaXMgc2l6ZSB0byAyNCBiaXRz Pw0KPg0KPltSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5LiBXaGVyZSBkbyB3ZSBkcmF3IHRoZSBs aW5lPyAzMi1iaXRzLCA2NC1iaXRzLA0KPjEyOCBiaXRzPyBJIHRoaW5rIHdlIHNob3VsZCBoYXZl IGEgc2Vuc2libGUgdmFsdWUgaW4gdGhlIFNlcnZpY2UgUGF0aA0KPmhlYWRlciBhbmQgaWYgeW91 IG5lZWQgdG8gY29udmV5IG1vcmUgYml0cyB5b3UgbmVlZCB0byB1c2UgdGhlIGNvbnRleHQNCj5o ZWFkZXJzLg0KPg0KPg0KPj4NCj4+VGhlcmUgY2FuIGJlIGRlcGxveW1lbnRzLCB3aGVyZSBTRkMg Y29udHJvbGxlciAoTG9naWNhbGx5IGNlbnRyYWwsIGJ1dA0KPj5kaXN0cmlidXRlZCkgIGl0c2Vs ZiBjYW4gZG8gdGhlIFNGIGluc3RhbmNlIHNlbGVjdGlvbiBvbiBwZXINCj4+Y29ubmVjdGlvbi9z ZXNzaW9uIGJhc2lzLCB0aGVyZWJ5IGF2b2lkaW5nIHRoZSBMQnMgZm9yIHNlcnZpY2VzLiAgIElu IG15DQo+PnZpZXcsIGFzc3VtcHRpb24gdGhhdCB0aGVyZSB3aWxsIGJlIExCIFNGIGZvciBlYWNo IHNjYWxlLW91dCBzZXJ2aWNlIGluDQo+PnRoZSBjaGFpbiBpcyBub3QgdmFsaWQgaW4gYWxsIGNh c2VzLg0KPj4NCj4+VGhhbmtzDQo+PlNyaW5pDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PkZyb206IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKSA8cmVw ZW5ub0BjaXNjby5jb20+DQo+PlNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciA0LCAyMDE0IDE6MTcg UE0NCj4+VG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IEpvZWwgTS4gSGFscGVybjsgc2ZjQGll dGYub3JnDQo+PkNjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPj5TdWJqZWN0OiBSZTog W3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+PihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4+DQo+PklmIEkgdW5kZXJzdG9vZCB5b3UsIEkg ZG8gbm90IHRoaW5rIHRoaXMgaXMgcmVhbGlzdGljLiBBcmUgeW91IHNheWluZw0KPj55b3UgbmVl ZCA2NC1iaXRzIG9mIHBhdGhzIGFuZCB0aGVuIHdpbGwgbW9uaXRvciB0aGVtIGFsbD8gRG8gZmF1 bHQNCj4+dG9sZXJhbmNlIGFuZCBPQU0gZm9yIDJeNjQtYml0cyB3b3J0aCBvZiBwYXRocz8gSnVz dCBmb3IgY29tcGFyaXNvbiwNCj4+aXTCuXMgbGlrZSBtYW5hZ2luZyBhbmQgbW9uaXRvcmluZyB0 aGUgZW50aXJlIElQdjYgaG9zdCByYW5nZSwgb25lLWJ5LW9uZS4NCj4+DQo+PkFueXdheSwgSSBk byBub3QgZXhwZWN0IGV2ZXJ5IHNpbmdsZSBwZXJtdXRhdGlvbnMgdG8gYmUgYSBkaWZmZXJlbnQg cGF0aC4NCj4+DQo+PklmIGVhY2ggc2VydmljZSBoYXMgMjU2IGRldmljZXMgcHJvdmlkaW5nIHNp bWlsYXIgc2VydmljZSwgeW91IHNob3VsZA0KPj5tb3N0IGxpa2VseSB1c2UgbG9hZC1iYWxhbmNp bmcgYW5kIHRoZW4geW91IHdvdWxkIGhhdmUgYSBzaW5nbGUgKG9yIGENCj4+ZmV3KSBwYXRocy4g VGhlcmUgaXMgc29tZSBkaXNjdXNzaW9uIGdvaW5nIG9uIExCLg0KPj4NCj4+RnJvbSBhIGRhdGEg cGxhbmUgcGVyc3BlY3RpdmUsIHRoZSBwYXRoIGlzIHVsdGltYXRlbHkgZGVmaW5lZCBieSB0aGUN Cj4+U0ZGcyB0cmF2ZXJzZWQgYW5kIHNlcnZpY2VzIHByb3ZpZGVkLCBub3QgYnkgYSBzcGVjaWZp YyBJUDpwb3J0IHRoYXQNCj4+dGhlIGRldmljZSBwcm92aWRpbmcgdGhlIHNlcnZpY2Ugc2l0cyBv bi4gV2VsbCwgYXQgbGVhc3QgZnJvbSBhIEdQRStOU0gNCj4+cGVyc3BlY3RpdmUuDQo+Pg0KPj4N Cj4+T24gMTIvNC8xNCwgMTI6NTcgUE0sICJTcmluaSBBZGRlcGFsbGkiIDxzYWRkZXBhbGxpQGZy ZWVzY2FsZS5jb20+IHdyb3RlOg0KPj4NCj4+PklmIEkgdGFrZSBhIGNoYWluIHdpdGggNSBzZXJ2 aWNlcyB3aXRoIGVhY2ggc2VydmljZSAgc2F5IGhhdmluZyAyNTYNCj4+Pmluc3RhbmNlcyBmb3Ig c2NhbGUtb3V0LCBwb3NzaWJsZSBudW1iZXIgb2YgcGF0aHMgYXJlDQo+Pj4yNTYqMjU2KjI1Nioy NTYqMjU2ID0gMHhGRiBGRiBGRiBGRiBGRi4gT25lIHJlcXVpcmVzIDMzIGJpdHMgaW4gdGhpcw0K Pj4+Y2FzZS4gIElmIHRoZXJlIGFyZSBtb3JlIHNlcnZpY2VzIGluIHRoZSBjaGFpbiBvciBtb3Jl IGNoYWlucyBvciBtb3JlDQo+Pj5pbnN0YW5jZXMgZm9yIHNjYWxlLW91dCwgdGhlbiBpdCBjb3Vs ZCBnbyB0byBiaWcgbnVtYmVyIHZlcnkgZmFzdC4NCj4+Pg0KPj4+QXMgSSBtZW50aW9uZWQgbXkg cHJlZmVyZW5jZSBpcyB0byBtYWtlIHRoZSBwYXRoIElEIHNpemUgZmxleGlibGUgZm9yDQo+Pj5m dXR1cmUgZ3Jvd3RoLiBJZiB0aGF0IGlzIHBlcmNlaXZlZCBhcyBjb21wbGV4LCB0aGVuIGdvaW5n IGZvciA2NGJpdA0KPj4+aXMgc2FmZXIgYmV0Lg0KPj4+DQo+Pj5UaGFua3MNCj4+PlNyaW5pDQo+ Pj4NCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IEpvZWwgTS4g SGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+Pj5TZW50OiBUaHVyc2RheSwg RGVjZW1iZXIgMDQsIDIwMTQgMTI6MDUgUE0NCj4+PlRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYw OyBKb2VsIE0uIEhhbHBlcm47IHNmY0BpZXRmLm9yZw0KPj4+Q2M6IE5TIFNyaW5pdmFzYSBNdXJ0 aHktQjM3ODQwDQo+Pj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+ Pj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+ Pj4NCj4+PkEgY29udHJvbGxlciAob3Igb3RoZXIgZGVjaXNpb24gbG9naWMpIGNhbiBjZXJ0YWlu bHkgYmUgYXdhcmUgb2Ygc3VjaA0KPj4+Y29uY2VybnMuDQo+Pj5CdXQgdGhlIG51bWJlciBvZiBz ZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzIGlzIG5vdCByZWxhdGVkIHRvIHRoZSBudW1iZXINCj4+Pm9m IGZsb3dzIG9yIHRoZSBudW1iZXIgb2YgdGVuYW50cy4gIEl0IGlzIHJlbGF0ZWQgdG8gdGhlIG51 bWJlciBvZg0KPj4+Y29tYmluYXRpb25zIG9mIHNlcnZpY2VzIGFuZCB0aGUgcG9saWNpZXMgZm9y IHNlcnZpY2UgZnVuY3Rpb24NCj4+PnNlbGVjdGlvbi4NCj4+PiBXaGlsZSB0aGF0IGNhbiBiZSBh IGxhcmdlIG51bWJlciwgSSBzdXJlIGhvcGUgaXQgZG9lcyBub3QgY29tZSBjbG9zZQ0KPj4+dG8g c2F0dXJhdGluZyAyNCBiaXRzLg0KPj4+DQo+Pj5IYXZpbmcgc2FpZCB0aGF0LCBpZiB3ZSB0aGlu ayB0aGF0IDI0IGJpdHMgaXMgb25seSBqdXN0IGVub3VnaCwgdGhlbg0KPj4+d2Ugb3VnaHQgdG8g dXNlIDMyLiAgRnJvbSB3aGVyZSBJIHNpdCwgSSB3b3VsZCBub3JtYWxseSBleHBlY3QgMTYgYml0 cw0KPj4+dG8gYmUgbW9yZSB0aGFuIHN1ZmZpY2llbnQsIHdoaWNoIGlzIHdoeSBJIGFtIGNvbWZv cnRhYmxlIHdpdGggMjQuDQo+Pj5IYXZpbmcgc2FpZCB0aGF0LCB0aGUgZmllbGQgc2l6ZSBpcyBu b3QgYSBiaWcgZGVhbCB0byBtZS4NCj4+Pg0KPj4+WW91cnMsDQo+Pj5Kb2VsDQo+Pj4NCj4+Pk9u IDEyLzQvMTQsIDI6MDEgUE0sIFNyaW5pIEFkZGVwYWxsaSB3cm90ZToNCj4+Pj4NCj4+Pj4gSSB3 YXMgbm90IGltcGx5aW5nIHRoYXQgcGF0aCBJRCBzaG91bGQgaGF2ZSBpbmZvcm1hdGlvbiBpbiBy ZWdhcmRzDQo+Pj4+dG8gdGVuYW50L2NvbnRyb2xsZXIvZmxvdy9zY2FsZS1vdXQuICBCdXQgU0ZD IGNvbnRyb2xsZXJzIHNob3VsZCBrZWVwDQo+Pj4+dGhlc2UNCj4+Pj5pbiBtaW5kIHRvIGFzc2ln biB0aGUgcGF0aCBJRC4gICAgQSBkZXBsb3ltZW50IGNhbiBoYXZlIG11bHRpcGxlDQo+Pj4+dGVu YW50cywgZWFjaCB0ZW5hbnQgY2FuIGhhdmUgbXVsdGlwbGUgbmV0d29ya3MsICB0aGVyZSBjb3Vs ZCBiZQ0KPj4+Pm1pbGxpb25zIG9mIGZsb3dzIGluIGVhY2ggb2YgdGhvc2UgbmV0d29ya3MuICBB bmQgY29uc2lkZXJpbmcgYWxsDQo+Pj4+dGhlc2UsDQo+Pj4+IDI0IGJpdCBwYXRoIElEIG1heSBu b3QgYmUgYWJsZSB0byByZXByZXNlbnQgcGF0aHMgZm9yIHRoZXNlIGZsb3dzLg0KPj4+PkhlbmNl LCBJIHdhcyB3b25kZXJpbmcgd2hldGhlciBwYXRoIElEIGNhbiBiZSBleHRlbmRlZCB0byA2NCBi aXRzIG9yDQo+Pj4+bWFrZSBpdCBmbGV4aWJsZS4NCj4+Pj4NCj4+Pj4gVGhhbmtzDQo+Pj4+IFNy aW5pDQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4+PiBT ZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgNCwgMjAxNCA3OjQyIEFNDQo+Pj4+IFRvOiBBZGRlcGFs bGkgU3JpbmktQjIyMTYwOyBzZmNAaWV0Zi5vcmcNCj4+Pj4gQ2M6IE5TIFNyaW5pdmFzYSBNdXJ0 aHktQjM3ODQwDQo+Pj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQN Cj4+Pj4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAy KQ0KPj4+Pg0KPj4+PiBUaGUgSW5kZXggaXMgbm90IGp1c3QgZm9yIGxvb3AgcHJldmVudGlvbi4g IEluIHRoZSBjYXNlIG9mDQo+Pj4+IGFtYmlndWl0eSwgdGhlIGluZGV4IHRlbGxzIHRoZSBTRkYg d2hlcmUgaW4gdGhlIHBhdGggdGhlIHBhY2tldA0KPj4+PmN1cnJlbnRseSByZXNpZGVzLg0KPj4+ PiAgICBUaGVyZSBhcmUgbXVsdGlwbGUgd2F5cyBzdWNoIGFtYmlndWl0eSBjYW4gb2NjdXIuDQo+ Pj4+DQo+Pj4+IFRoZSBQYXRoIElkZW50aWZpZXIgaXMgc3BlY2lmaWNhbGx5IG5vdCBleHBlY3Rl ZCB0byBpbmNsdWRlDQo+Pj4+IGNvbnRyb2xsZXIgSUQgb3IgVGVuYW50IElELiAgV2hpbGUgYSBk ZXBsb3llciBjYW4gaGF2ZSBhIHBhdGggcGVyDQo+Pj4+IHRlbmFudCwgdGhlIGFyY2hpdGVjdHVy ZSBzdGlsbCBkb2VzIG5vdCB0cmVhdCB0aGUgcGF0aCBJRCBhcyBhDQo+Pj4+IHRlbmFudCBJRC4g IFRlbmFudCBJRCwgY29udHJvbGxlciBJRCwgYW5kIG90aGVyIG5vbi1wYXRoLXNwZWNpZnlpbmcN Cj4+Pj4gaW5mb3JtYXRpb24gaXMgdG8gYmUgY2FycmllZCBpbiBtZXRhZGF0YS4NCj4+Pj4NCj4+ Pj4gWW91cnMsDQo+Pj4+IEpvZWwNCj4+Pj4NCj4+Pj4gT24gMTIvNC8xNCwgMTA6MDIgQU0sIFNy aW5pIEFkZGVwYWxsaSB3cm90ZToNCj4+Pj4+IFR3byBjb21tZW50cyA6DQo+Pj4+Pg0KPj4+Pj4N Cj4+Pj4+IDEuICBTRiBJbmRleCA6ICBTaW5jZSBpdCBpcyBtZWFudCBmb3IgbG9vcCBkZXRlY3Rp b24sICB3b3VsZG4ndA0KPj4+Pj4gYmV0dGVyIHRvIHJlbmFtZSB0aGlzIGFzICJUVEwiPw0KPj4+ Pj4NCj4+Pj4+IDIuICBQYXRoIElkZW50aWZpZXIgOiAgICAyNCBiaXQgcGF0aCBpZGVudGlmaWVy IHNlZW1zIHRvIGJlIHRvbyBsZXNzLg0KPj4+Pj4gQmFzZWQgb24gb3VyIGV4cGVyaWVuY2UgaW4g dHJhZmZpYyBzdGVlcmluZywgIHRoaXMgcGF0aCBpZGVudGlmaWVyDQo+Pj4+Pm5lZWRzIHRvIGVu Y29kZSBnb29kIGFtb3VudCBvZiBpbmZvcm1hdGlvbiB0byBtYWtlIGl0IHVuaXF1ZS4gIEZvcg0K Pj4+Pj5leGFtcGxlLA0KPj4+Pj4gICAgdGhpcyBpZGVudGlmaWVyIG5lZWRzIHRvIGVuY29kZSAo aW4gb3VyIGNhc2UpIHNvbWUgaW5mb3JtYXRpb24NCj4+Pj4+cmVwcmVzZW50aW5nIHRoZSBkaXN0 cmlidXRlZCBjb250cm9sbGVyIElELCAgdGVuYW50IElELCAgZmxvdyBJRCwNCj4+Pj4+ICAgIFNl cnZpY2UgZnVuY3Rpb24gaW5zdGFuY2UgKGluIGNhc2Ugb2Ygc2NhbGUtb3V0KSBhbmQgZmV3IG1v cmUuLg0KPj4+Pj4gT25lIHN1Z2dlc3Rpb24gaXMgdG8gbWFrZSBpdCA2NCBiaXRzIHZhbHVlICBv ciB0byBtYWtlIGl0IGV2ZW4NCj4+Pj4+ZXh0ZW5kYWJsZSwNCj4+Pj4+ICAgIGl0IGlzIGdvb2Qg aWYgcGF0aCBpZGVudGlmaWVyIGlzIGFsc28gcmVwcmVzZW50ZWQgaW4gVExWIGZvcm0uDQo+Pj4+ Pg0KPj4+Pj4NCj4+Pj4+IFRoYW5rcw0KPj4+Pj4NCj4+Pj4+IFNyaW5pDQo+Pj4+Pg0KPj4+Pj4N Cj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0BpZXRmLm9yZw0K Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+DQo+ Pj4NCj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj5zZmMgbWFpbGluZyBsaXN0DQo+Pj5zZmNAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRm Lm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zZmMgbWFpbGlu ZyBsaXN0DQo+c2ZjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCj4NCj4NCj5UaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyAodGhlICJt ZXNzYWdlIikgYXJlIGNvbmZpZGVudGlhbCwNCj5pbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRy ZXNzZWVzLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCj5yZWNpcGllbnQsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGlzDQo+ bWVzc2FnZSBmcm9tIHlvdXIgc3lzdGVtLiBJbiB0aGlzIGNhc2UsIHlvdSBhcmUgbm90IGF1dGhv cml6ZWQgdG8gdXNlLA0KPmNvcHkgdGhpcyBtZXNzYWdlIGFuZC9vciBkaXNjbG9zZSB0aGUgY29u dGVudCB0byBhbnkgb3RoZXIgcGVyc29uLg0KPkUtbWFpbHMgYXJlIHN1c2NlcHRpYmxlIHRvIGFs dGVyYXRpb24uIE5laXRoZXIgUW9zbW9zIG5vciBhbnkgb2YgaXRzDQo+c3Vic2lkaWFyaWVzIG9y IGFmZmlsaWF0ZXMgc2hhbGwgYmUgbGlhYmxlIGZvciB0aGUgbWVzc2FnZSBpZiBhbHRlcmVkLA0K PmNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPg0KPkNlIG1lc3NhZ2UgZXQgdG91dGVzIHNlcyBwacOo Y2VzIGpvaW50ZXMgKGNpLWFwcsOocyBsZSAibWVzc2FnZSIpc29udA0KPmNvbmZpZGVudGllbHMg ZXQgw6l0YWJsaXMgw6AgbCdpbnRlbnRpb24gZXhjbHVzaXZlIGRlIHNlcyBkZXN0aW5hdGFpcmVz LiBTaQ0KPnZvdXMgYXZleiByZcOndSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIG1lcmNpIGTigJll biBpbmZvcm1lciBpbW3DqWRpYXRlbWVudA0KPnNvbiDDqW1ldHRldXIgcGFyIGNvdXJyaWVyIMOp bGVjdHJvbmlxdWUgZXQgZOKAmWVmZmFjZXIgY2UgbWVzc2FnZSBkZSB2b3RyZQ0KPnN5c3TDqG1l LiBEYW5zIGNldHRlIGh5cG90aMOoc2UsIHZvdXMgbuKAmcOqdGVzIHBhcyBhdXRvcmlzw6kgw6Ag dXRpbGlzZXIsDQo+Y29waWVyIGNlIG1lc3NhZ2UgZXQvb3UgZW4gZGl2dWxndWVyIGxlIGNvbnRl bnUgw6AgdW4gdGllcnMuIFRvdXQgbWVzc2FnZQ0KPsOpbGVjdHJvbmlxdWUgZXN0IHN1c2NlcHRp YmxlIGQnYWx0w6lyYXRpb24uIFFvc21vcyBldCBzZXMgZmlsaWFsZXMNCj5kw6ljbGluZW50IHRv dXRlIHJlc3BvbnNhYmlsaXTDqSBhdSB0aXRyZSBkZSBjZSBtZXNzYWdlIHMnaWwgYSDDqXTDqSBh bHTDqXLDqSwNCj5kw6lmb3Jtw6kgb3UgZmFsc2lmacOpLg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRm Lm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg== From nobody Mon Feb 2 15:34: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 73CAE1A1B4B for ; Mon, 2 Feb 2015 15:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.305 X-Spam-Level: X-Spam-Status: No, score=-2.305 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, TRACKER_ID=1.306, 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 eUrCtOhmqB5g for ; Mon, 2 Feb 2015 15:34:46 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87F2E1A1B3C for ; Mon, 2 Feb 2015 15:34:44 -0800 (PST) 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 BOR83674; Mon, 02 Feb 2015 23:34:42 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 2 Feb 2015 23:34:42 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.133]) by SJCEML703-CHM.china.huawei.com ([169.254.5.223]) with mapi id 14.03.0158.001; Mon, 2 Feb 2015 15:34:33 -0800 From: Henry Fourie To: Srini Addepalli , Sumandra Majee , Nicolas BOUTHORS , Cathy Zhang , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZyAGG+AgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgD//7j7oIBVIj4ggALqPwCAADaLgIADgFqAgAE9hoA= Date: Mon, 2 Feb 2015 23:34:32 +0000 Message-ID: <0F8583BBE82FA449A8B78417CC07559A09195E9F@SJCEML701-CHM.china.huawei.com> References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.69] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "nsmurthy@freescale.com" , Jerome TOLLET , Rajesh Kumar Madabushi , Bharat Mota Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 02 Feb 2015 23:34:50 -0000 U3JpbmksDQogICAgSW4geW91ciBleGFtcGxlIEkgcHJlc3VtZSB0aGF0IFNmeC0sIFNGeS0gYW5k IFNGei0gYXJlIGFsbCBpbnN0YW5jZXMgb2YgdGhlDQpzYW1lIHR5cGUgb2YgU0YsIGVnLiwgU2Z4 LSBhcmUgYWxsIGluc3RhbmNlcyBvZiBhIEZXLiBTbywgaW4gdGhlIGV4YW1wbGUsIHlvdSBoYXZl DQppbnN0YW5jZXMgb2YgYSBnaXZlbiB0eXBlLCBlZywgU0Z4LSBob21lZCBvbiB0d28gZGlmZmVy ZW50IFNGRnMuIFNGeDEgYW5kIFNGeDIgYXJlDQpob21lZCBvbiBTRkYxIGFuZCBTRngzIGlzIGhv bWVkIG9uIFNGRjIuIFRoaXMgY2FuIGJlIGRvbmUgYnV0IGFkZHMgY29tcGxleGl0eSB0bw0KYW4g aW1wbGVtZW50YXRpb24gd2hlcmUgYSBTRkYgbWF5IHdhbnQgdG8gZG8gbG9hZC1iYWxhbmNpbmcg b3ZlciBhIGdyb3VwIG9mIFNGcy4NCg0KQW4gYWx0ZXJuYXRpdmUgY29uZmlndXJhdGlvbiB3b3Vs ZCBiZSB3aGVyZSBTRnMgb2YgYSBnaXZlbiB0eXBlIGFyZSBhbGwgaG9tZWQNCm9uIHRoZSBzYW1l IFNGRiwgZWcsIFNGeDEtMyBhcmUgYWxsIGhvbWVkIG9uIFNGRjEsIGFsbG93aW5nIGl0IHRvIHBl cmZvcm0gbG9hZC1iYWxhbmNpbmcNCmFjcm9zcyB0aGlzIHNldCBvZiBTRiBpbnN0YW5jZXMuIA0K DQpTZWN0aW9uIDQuMy4yIG9mIHRoZSBTQ0ggZHJhZnQgZGVzY3JpYmVzIHRoZSB1c2Ugb2YgdGhl IFJTUCBJRCBpbiB0aGlzIGNhc2UuDQpFYWNoIFNGRiBtYXkgcGVyZm9ybSBhIGxhdGUgYmluZGlu ZyBvZiBlYWNoIFNGIGluc3RhbmNlIHRvIGEgUlNQIHRocm91Z2ggdGhlIGhvcC1ieS1ob3Agc2Vs ZWN0aW9uDQpvZiB0aGUgU0YgaW5zdGFuY2VzIGJ5IHRoZSBTRkZzIGFzIHRoZSBmaXJzdCBwYWNr ZXQgZm9yIGEgZmxvdyB0cmF2ZXJzZXMgdGhlIGNoYWluLg0KICANCiAtIExvdWlzDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIFNyaW5pIEFkZGVwYWxsaQ0KU2VudDogU3VuZGF5LCBGZWJydWFy eSAwMSwgMjAxNSAxMjoyMSBQTQ0KVG86IFN1bWFuZHJhIE1hamVlOyBOaWNvbGFzIEJPVVRIT1JT OyBDYXRoeSBaaGFuZzsgJ3NmY0BpZXRmLm9yZycNCkNjOiBuc211cnRoeUBmcmVlc2NhbGUuY29t OyBKZXJvbWUgVE9MTEVUOyBSYWplc2ggS3VtYXIgTWFkYWJ1c2hpOyBCaGFyYXQgTW90YQ0KU3Vi amVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdCAoaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQoNCkhpIFN1bWFuZHJhLA0KDQpJIGFn cmVlIHdpdGggeW91IHRoYXQgbW9yZSBpbmZvcm1hdGlvbiBjYW4gYmUgYWRkZWQgdG8gdGhlIHBy b3RvY29sIGRvY3VtZW50IG9uIHNvbWUgdXNlIGNhc2Ugc2NlbmFyaW9zIHRvIG1ha2UgaXQgY2xl YXIgb24gdGhlIHVzYWdlIG9mIFJTUC1JRCBhbmQgUGF0aC1JRC4NCg0KSnVzdCB0byBtYWtlIHRo ZSByZWFsaXN0aWMgYW5kIGNvbXBsZXggc2NlbmFyaW8NCg0KSW5ncmVzc1NGRi0tLS0tU0ZGMS0t LS0tU0ZGMi0tLS0tRWdyZXNzU0ZGDQoNCkluIHZpcnR1YWwgd29ybGQsIFNGRjEgY291bGQgYmUg ZnJvbnRlbmRpbmcgU0Z4LTEsIFNGeC0yLCBTRnktMSBhbmQgU0ZGMiBjb3VsZCBiZSBmcm9udCBl bmRpbmcgU0Z4LTMsIFNGeS0yLCBTRnotMSBGb3Igc2ltcGxpY2l0eSwgYXNzdW1lIHRoYXQgSW5n cmVzc1NGRiBpcyBhIGVkZ2Ugcm91dGVyIChlZy4gT3BlbnN0YWNrIE5ldHdvcmsgTm9kZSkgRWdy ZXNzU0ZGIGlzIGEgdmlydHVhbCBzd2l0Y2ggaG9zdGluZyBzZXQgb2YgV2ViIFNlcnZlciBWTXMu DQpTRkYxIGFuZCBTRkYyIGFyZSBhbHNvIHZpcnR1YWwgc3dpdGNoZXMgaG9zdGluZyBTRngsIFNG eSBhbmQgU0Z6IFNlcnZpY2UgVk1zLg0KDQpBc3N1bWluZyB0aGF0IGNoYWluIHJlcXVpcmVzIHBh Y2tldHMgZ28gdG8gU0Z4LCBTRnkgYW5kIFNGeiwgIEluZ3Jlc3NTRkYgKHdpdGggdGhlIGhlbHAg b2YgU0ZGIGNvbnRyb2xsZXIpIG5lZWRzIHNlbmQgdGhlIHRyYWZmaWMgdG8gb25lIG9mIFNGeC0x LCBTRngtMiBhbmQgU0Z4LTMuIEJhc2VkIG9uIFNGLXggc2VsZWN0aW9uLCBpbmdyZXNzIFNGRiBz ZW5kcyB0aGUgdHJhZmZpYyB0byBjb3JyZXNwb25kaW5nIFNGRi4gIElmIFNGeC0xIG9yIFNGeC0y IGlzIGNob3NlbiwgdGhlbiB0aGUgdHJhZmZpYyBpcyBzZW50IHRvIFNGRjEuICBJZiBTRngtMyBp cyBjaG9zZW4sIHRoZW4gdGhlIHRyYWZmaWMgaXMgc2VudCB0byB0aGUgU0ZGMi4gTmV4dCBpbiB0 aGUgY2hhaW4sIHNlbGVjdGlvbiBuZWVkcyB0byBoYXBwZW4gYmV0d2VlbiBTRnkxIGFuZCBTRnky LiAgU2ltaWxhcmx5IGZvciBuZXh0IHNlcnZpY2UgaW4gdGhlIGNoYWluLCAgIGVpdGhlciBTRkYx IG9yIFNGRjIgKHdpdGggdGhlIGhlbHAgb2YgY29udHJvbGxlcikgd2lsbCBzZW5kIHRoZSB0cmFm ZmljIHRvIFNGLXkuIEl0IGRvZXMgdGhpcyBieSBzZW5kaW5nIHRoZSB0cmFmZmljIHRvIFNGRjIg dGhhdCBpcyBob3N0aW5nIHRoZSBTRi16LiBBbmQgZmluYWxseSB0cmFmZmljIG5lZWRzIHRvIGdv IHRvIEVncmVzc1NGRiB0byBkZWxpdmVyIHRvIGRlc3RpbmF0aW9uIHdlYi1zZXJ2ZXIgVk0uDQoN CkVzc2VudGlhbGx5LCBhIGdpdmVuIFNGRiB3b3VsZCBuZWVkIHRvIGJlIHByb2dyYW1tZWQgd2l0 aCB0aGUgaW5mb3JtYXRpb24gcmVsYXRlZCB0byBuZXh0IFNGLiAgVGhhdCBpcyB3aGVyZSBwYXRo IElELCBSU1AtSUQgYW5kIE92ZXJsYXkgbmV0d29ya3Mgd291bGQgaGVscCAtIFBhdGggSUQgaW5k aWNhdGluZyB0aGUgY2hhaW4gYW5kIFJTUC1JRCBpbmRpY2F0aW5nIHRoZSBTRiBpbnN0YW5jZSBB TkQgIFZ4TEFOIGRlc3RpbmF0aW9uIElQIGluZGljYXRpbmcgdGhlIG5leHQgU0ZGLiBTRkYgQ29u dHJvbGxlciBoYXZpbmcgdGhlIG5ldHdvcmsgd2lkZSB2aXNpYmlsaXR5IHdvdWxkIHByb2dyYW0g dGhlIFNGRnMgYXBwcm9wcmlhdGVseS4gDQoNCkZvciBleGFtcGxlLCBvbiBpbmdyZXNzU0ZGLCBm bG93cyBhcmUgcHJvZ3JhbW1lZCB3aXRoIFJTUC1JRCByZWxhdGVkIHRvIFNGeCBzZXJ2aWNlIGlu c3RhbmNlcy4gIEluZ3Jlc3NTRkYsIGFzIHBhcnQgb2YgcGFja2V0IHByb2Nlc3NpbmcsIGFkZHMg dGhlIFJTUC1JRCwgUGF0aF9JRCB0byB0aGUgU0NIIGhlYWRlciBhbmQgZW5jYXBzdWxhdGVzIGlu IFZ4TEFOLiAgU0ZGMSBhbmQvb3IgU0ZGMiBhcmUgcHJvZ3JhbW1lZCB3aXRoIGZsb3dzIHRoYXQg bWF0Y2ggb24gUEFUSC1JRCBhbmQgUlNQLUlEIHRvIHNlbmQgdGhlIHRyYWZmaWMgdG8gcmlnaHQg U0Z4IGluc3RhbmNlLiBFc3NlbnRpYWxseSwgcHJldmlvdXMgU0ZGIGFkZHMgdGhlIFNDSCBoZWFk ZXIgcmVsYXRlZCB0byBuZXh0IFNGIGluc3RhbmNlcyBhbmQgaG9zdGluZyBTRkYgdXNlcyB0aGF0 IGluZm9ybWF0aW9uIHRvIHJvdXRlIHRoZSB0cmFmZmljIHRvIHJpZ2h0IFNGIGluc3RhbmNlLg0K DQpPbiB5b3VyIGNvbmNlcm4gYWJvdXQgcG9vciBzY2FsYWJpbGl0eSA6ICBTRkYgY29udHJvbGxl ciBuZWVkIG5vdCBiZSBhIHNpbmdsZSBlbnRpdHkuICBJdCBjb3VsZCBiZSBkaXN0cmlidXRlZCBh bmQgc2NhbGUtb3V0IGVudGl0eSBmb3IgcGVyZm9ybWFuY2Ugc2NhbGluZy4gICBBbHNvLCBjb250 cm9sbGVycyBuZWVkIG5vdCBiZSBpbmZvcm1lZCBvZiBldmVyeSBmaW5lIGdyYW51bGFyIGZsb3cu IEl0IGNvdWxkIGJlIGJhc2VkIG9uIDQtdHVwbGUgb3IgMy10dXBsZSBmbG93cywgdGhlcmVieSBy ZWR1Y2luZyB0aGUgbnVtYmVyIG9mIGRlY2lzaW9ucyBsb2dpY2FsIGNvbnRyb2xsZXIgbmVlZCB0 byBtYWtlLiAgDQoNCkkgZGlkIG5vdCB1bmRlcnN0YW5kICB5b3VyIGNvbmNlcm4gb24gIiBUaGUg YW1vdW50IG9mIHN0YXRlLCBwcm9iYWJpbGl0eSBvZiBhIGluc3RhbmNlIGdvaW5nIGRvd24gYmV0 d2VlbiBzZWxlY3Rpb24gYW5kIGZsb3cgYXJyaXZhbCBnb2VzIHVwLiIgIFRoaXMgc2VlbXMgdG8g YmUgaW1wb3J0YW50IGFuZCBjYW4geW91IGVsYWJvcmF0ZT8NCg0KDQpUaGFua3MNClNyaW5pDQoN Cg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdW1hbmRyYSBNYWplZQ0KU2VudDogRnJpZGF5 LCBKYW51YXJ5IDMwLCAyMDE1IDI6NTMgUE0NClRvOiBOaWNvbGFzIEJPVVRIT1JTOyBDYXRoeSBa aGFuZzsgJ3NmY0BpZXRmLm9yZycNCkNjOiBKZXJvbWUgVE9MTEVUDQpTdWJqZWN0OiBSZTogW3Nm Y10gQ29tbWVudHMgb24gU0NIIERyYWZ0IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtemhhbmctc2ZjLXNjaC0wMikNCg0KSGVsbG8sDQoNClRoaXMgaXMgYW4gaW50ZXJlc3Rpbmcg ZGlzY3Vzc2lvbiBhbmQgSSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQgdGhlIG1vdGl2YXRpb24g b2YgYmV0dGVyLiBUaGUgdHJvdWJsZSB3aXRoIGEgcHJvdG9jb2wgZG9jdW1lbnQgaXMgdGhhdCBp dCBpcyB0eXBpY2FsbHkgaGFzIGluYWRlcXVhdGUgZGV0YWlsIGFib3V0IHRoZSBsb2dpYy4gU28g dG8gY2FzdCB0aGlzIGludG8gc29tZXdoYXQgb2YgYSBjb25jcmV0ZSB0ZXJtcywgY29uc2lkZXIg dGhlIGZvbGxvd2luZy4NCg0KDQogICAgDQogICAgICAgU0ZGKHgpICB7IFNmeCgxKSBTZngoMini gKZTZngobikgfSAgIOKAlOKAlOKAlOKAlD4gICBTRkYoeSkgeyBTZnkoMSkgU2Z5KDIpDQrigKYu IFNmeShtKSB9ICAgOjogTG9naWNhbCBDaGFpbiBpbiBPTkUgZGlyZWN0aW9uIG9ubHkuDQogICAg ICAgDQogICAgICAgUEhZU0lDQUwgV09STEQ6DQogICAgICAgICAgQSkgdGhlIFNGRiBjb3VsZCBi ZSBhDQogICAgICAgICAgICAtIGNvbXBvbmVudCBvZiBWU1dJVENIIChwaWNrIHlvdXIgZmF2IHBy b3RvY29sIGZvciBjb25maWd1cmluZyB0aG9zZSBlbnRpdGllcyB9DQogICAgICAgICAgICAtIEEg bG9hZCBiYWxhbmNlcg0KICAgICAgICAgICAgLSBBIEhXIHN3aXRjaC9yb3V0ZXIgc29tZSBMMi9M MyBjb21ibw0KDQogICAgICAgICAgQikgU2YgaW5zdGFuY2UgY291bGQgYmUsDQogICAgICAgICAg ICAgICAtIFZpcnR1YWwgbWFjaGluZSwgI04gb2YgdGhvc2UNCiAgICAgICAgICAgICAgIC0gcGh5 c2ljYWwNCiAgICAgICAgICAgICAgIC0gQ29udGFpbmVyICNNIHdoaWNoIGlzIG9mdGVuIDUgb3Ig bW9yZSB4ICNODQogICAgICAgICAgICAgICAtIENsdXN0ZXIgdGhhdCB3ZSBkb27igJl0IGtub3cN Cg0KSXQgaXMgcG9zc2libGUgdG8gaGF2ZSBtdWx0aXBsZSBwaHlzaWNhbCBTRkYoeCkgYWxzby4N Cg0KQSBzZWxlY3Rpb24gb2YgYSBnaXZlbiBTRiAoc2VydmljZSkoaW5zdGFuY2UpIGlzIGEgY2Fu IGJlIHNpbXBsZSBvciBjb21wbGV4LiBGb3IgZXhhbXBsZSBTRkYoeCkgbWF5IGhhdmUgdGhlIGJl c3Qga25vd2xlZGdlIHRvIHNlbGVjdCBTZngoMSkgYmFlZCBvbiBhIGdpdmVuIGNyaXRlcmlvbiAo d2hpY2ggY291bGQgYmUgcGFydCBvZiB0aGUgcG9saWN5KS4gIFRoZW4gSSBkb27igJl0IHNlZSBh IHJlYXNvbiB0byBoYXZlIFJTUC4NCg0KSXQgaXMgcG9zc2libGUgdGhhdCBsb29rdXAgKHBhdGgp IEAgU0ZGKHgpIHByb2R1Y2VzIGEgc3BlY2lmaWMgaW5zdGFuY2Ugb2YgU2Z5IGFuZCB5ZXMgdGhl biBzb21ldGhpbmcgbGlrZSBSU1Agd291bGQgYmUgcmVxdWlyZWQuIEJ1dCBJIHdvdWxkIGFyZ3Vl IHRoYXQgam9iIFNGRih5KSBjYW4gYWxzbyBiZSBzdWJzdW1lZCBieSBTRkYoeCkuDQoNCklzIGl0 IHBvc3NpYmxlIGZvciBhIGNlbnRyYWwgY29udHJvbGxlciB0byBwaWNrIGVhY2ggaW5zdGFuY2Ug b2Ygc2VydmljZSwgYnV0IHN1Y2ggYW4gaW1wbGVtZW50YXRpb24gdGVuZHMgdG8gc2NhbGUgcG9v cmx5LiBUaGUgYW1vdW50IG9mIHN0YXRlLCBwcm9iYWJpbGl0eSBvZiBhIGluc3RhbmNlIGdvaW5n IGRvd24gYmV0d2VlbiBzZWxlY3Rpb24gYW5kIGZsb3cgYXJyaXZhbCBnb2VzIHVwLiANCg0KUmVn YXJkcy4NCg0KU3VtYW5kcmENCg0KDQoNCk9uIDEvMzAvMTUsIDM6MzggQU0sICJOaWNvbGFzIEJP VVRIT1JTIiA8Tmljb2xhcy5CT1VUSE9SU0Bxb3Ntb3MuY29tPg0Kd3JvdGU6DQoNCj5IZWxsbyBD YXRoeSwNCj4NCj5JbmRlZWQgdGhlIG5vdGlvbiBvZiAicmVuZGVyZWQgc2VydmljZSBwYXRoIElE IihSU1AgSUQpIHNlZW1zIHJlbGV2YW50IA0KPmFzIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQg c3RpcHVsYXRlcyB0aGF0IHRoZSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGgNCj4oU0ZQKSBwcm92aWRl cyBhbiBhYnN0cmFjdCBub3Rpb24gb2YgYSBzZXJ2aWNlIGNoYWluLCB3aGlsZSB0aGUgUlNQIGlz IA0KPmEgY29uc3RyYWluZWQgbGlzdCBvZiBsb2NhdGlvbnMuDQo+DQo+U0ZDIGhlYWRlciAiU2Vy dmljZSBQYXRoIElkZW50aWZpZXIiIChTUEkpICBpcyB1c2VkIGluIGJvdGggTlNIIGFuZCBTQ0gg DQo+cHJvdG9jb2wgYW5kIGluIGJvdGggY2FzZSBzZWVtIHRvIGlkZW50aWZ5IHRvIGEgcGFydGlj dWxhciBTRlAuDQo+DQo+TlNIKHY1KSBmb3IgZXhhbXBsZSBzdGF0ZXMgdGhhdA0KPiIgQXMgZGVz Y3JpYmVkIGFib3ZlLCBOU0ggY29udGFpbnMgYSBzZXJ2aWNlIHBhdGggaWRlbnRpZmllciAoU1BJ KSBhbmQNCj4gICBhIHNlcnZpY2UgaW5kZXggKFNJKS4gIFRoZSBTUEkgaXMsIGFzIHBlciBpdHMg bmFtZSwgYW4gaWRlbnRpZmllci4NCj4gICBUaGUgU1BJIGFsb25lIGNhbm5vdCBiZSB1c2VkIHRv IGZvcndhcmQgcGFja2V0cyBhbG9uZyBhIHNlcnZpY2UgcGF0aC4NCj4gICBSYXRoZXIgdGhlIFNQ SSBwcm92aWRlIGEgbGV2ZWwgb2YgaW5kaXJlY3Rpb24gYmV0d2VlbiB0aGUgc2VydmljZQ0KPiAg IHBhdGgvdG9wb2xvZ3kgYW5kIHRoZSB0aGUgbmV0d29yayB0cmFuc3BvcnQuICBGdXJ0aGVybW9y ZSwgdGhlcmUgaXMNCj4gICBubyByZXF1aXJlbWVudCwgb3IgZXhwZWN0YXRpb24gb2YgYW4gU1BJ IGJlaW5nIGJvdW5kIHRvIGEgcHJlLQ0KPiAgIGRldGVybWluZWQgb3Igc3RhdGljIG5ldHdvcmsg cGF0aC4iDQo+DQo+U3RpbGwgTlNIKHY1KSAgc2hvd3MgdGhhdCBTUEkgKG5vdCBhIFJTUCBJRCkg IHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBrZXkgDQo+ZWxlbWVudCBvZiBhbiBTRkYgdG8gbG9va3Vw IG9uIGZvcndhcmRpbmcgdGFibGVzLiAgQnV0IEkgY291bGQgbm90IGZpbmQgDQo+aW4gTlNIICBo b3cgdG8gdXNlIHRoZSBub3Rpb24gb2YgUmVuZGVyZWQgc2VydmljZSBwYXRoIHdoaWNoIHdhcyAN Cj5kZWZpbmVkIGluIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQuDQo+DQo+WW91IHByb3Bvc2Fs IHNlZW1zIHRvIG1lIHZlcnkgdXNlZnVsLA0KPg0KPkFuIFJTUCBJRCAoaW5kZXBlbmRlbnQgb2Yg dGhlIFNQSSBidXQgcGFydCBvZiB0aGUgc2FtZSBuYW1lIHNwYWNlKSANCj5jb3VsZCBiZSB1c2Vk IHRoZSBzYW1lIHdheSBhcyBTUEkgYnkgU0ZGIGZvciBleGFtcGxlLCBhbGxvd2luZyBhIA0KPlNl cnZpY2UgQ2xhc3NpZmllciB0byBjb250cm9sIHJlbW90ZSBsb2FkIGJhbGFuY2luZyBmb3IgZXhh bXBsZS4NCj4NCj5UaGlzIHNhaWQgdGhlIFJTUCBJRCB2YWx1ZXMgY291bGQgYmUgcmVsYXRpdmUg dG8gYSBwYXJ0aWN1bGFyIFNlcnZpY2UgDQo+UGF0aCwgd2hpY2ggd291bGQgcHJldmVudCB1c2lu ZyB0aGVtIGFzIHdlIGRvIGZvciBTUEkgaW4gU0ZGIGZvcndhcmRpbmcgDQo+dGFibGVzLg0KPg0K PldlIG1heSB3YW50IHRvIHByZWNpc2UgaWYgdGhlIFJTUCBJRCBpcyB0byBiZSByZWxhdGl2ZSBv ZiBhYnNvbHV0ZSwgYXMgDQo+aXQgc2hvdWxkIGhhdmUgYW4gaW1wYWN0IG9uIGZvcndhcmRpbmcg dGFibGUgc3RydWN0dXJlIGlmIHdlIGRlY2lkZSB0byANCj51c2UgdGhpcyBjb25jZXB0Lg0KPg0K PlBlcnNvbmFsbHkgSSBsaWtlIHRoZSBub3Rpb24gb2YgYSByZWxhdGl2ZSBSU1AgSUQsIGFzIHdl IGNvdWxkIHRoZW4gdXNlIA0KPnNvbWUgY29udmVudGlvbnMsIHN0cnVjdHVyZSBpdCwgcG9zc2li bHkgZXh0ZW5kaW5nIGl0cyB1c2UuDQo+DQo+Tmljb2xhcw0KPg0KPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+RnJvbTogQ2F0aHkgWmhhbmcgW21haWx0bzpDYXRoeS5ILlpoYW5nQGh1YXdl aS5jb21dDQo+U2VudDogamV1ZGkgMjkgamFudmllciAyMDE1IDIwOjQ0DQo+VG86IENhdGh5IFpo YW5nOyBTcmluaSBBZGRlcGFsbGk7IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgSm9lbCBNLg0K PkhhbHBlcm47ICdzZmNAaWV0Zi5vcmcnDQo+Q2M6IG5zbXVydGh5QGZyZWVzY2FsZS5jb20NCj5T dWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+KGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPg0KPkhpIGV2ZXJ5b25lLA0K Pg0KPldlIGhhdmUgdXBsb2FkZWQgYSBuZXcgU0NIIHZlcnNpb24gKDMpIHdoaWNoIGFkZHMgZGVm aW5pdGlvbiBvZiBhIG5ldyANCj5tZXRhZGF0YSB0eXBlIGZvciB0aGUgZmxvdyBJRCB0byBzdXBw b3J0IGxvYWQgYmFsYW5jaW5nIGFtb25nIFNGIA0KPmluc3RhbmNlcyBhbmQgbWl0aWdhdGUgdGhl IHBvdGVudGlhbCBpc3N1ZSBvZiAibm90IGVub3VnaCBwYXRoIElEIi4gVGhlIA0KPmZsb3cgSUQg aXMgbmFtZWQgInJlbmRlcmVkIHNlcnZpY2UgcGF0aCBJRCIgaW4gdGhlIGRyYWZ0LiBQbGVhc2Ug cmVmZXIgDQo+dG8gc2VjdGlvbiA0LjMuMiBvZiANCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC16aGFuZy1zZmMtc2NoLw0KPmZvciBkZXRhaWwgZGVzY3JpcHRpb24uDQo+ DQo+SW4gaXRzIHByZXZpb3VzIHZlcnNpb24sIFNDSCBkZWZpbmVzIGEgIkJ5cGFzcyBiaXQiIGlu IHRoZSBiYXNlIGhlYWRlci4NCj5UaGlzIGJpdCBlbmFibGVzIHRoZSBTRiB0byBwcm92aWRlIGZl ZWRiYWNrL25vdGlmaWNhdGlvbiB2aWEgdGhlIGRhdGEgDQo+cGF0aCB0byBpdHMgY29ubmVjdGlu ZyBTRkYgYWJvdXQgd2hldGhlciB0aGUgcmVtYWluaW5nIHBhY2tldHMgb2YgdGhlIA0KPlNGQyBz aG91bGQgYnlwYXNzIHRoYXQgU0YuIFRoaXMgaXMgdXNlZnVsIGluIHRoZSBjYXNlIHRoYXQgb25s eSB0aGUgDQo+Zmlyc3QgZmV3IHBhY2tldHMgb2YgYSBmbG93IG5lZWQgdG8gZ28gdG8gYSBTRiAo c3VjaCBhcyBhIERQSSBvciBGVyBvcg0KPklEUykgYW5kIHJlbWFpbmluZyBwYWNrZXRzIGNhbiBi eXBhc3MgdGhhdCBTRiwgdGh1cyBzYXZpbmcgdGhlIA0KPmV4cGVuc2l2ZSBTRiByZXNvdXJjZSBh bmQgcmVkdWNpbmcgZGF0YSBwYXRoIGxhdGVuY3kuDQo+DQo+QiBiaXQ6IFRoZSBCIChCeXBhc3Mp IGJpdCwgd2hlbiBzZXQgdG8gMSwgaXQgaXMgdXNlZCBieSBhIFNlcnZpY2UNCj4gICAgICAgRnVu Y3Rpb24gdG8gc2lnbmFsIHRvIGl0cyBTZXJ2aWNlIEZ1bmN0aW9uIEZvcndhcmRlciB0aGF0IG5v DQo+ICAgICAgIGZ1cnRoZXIgcGFja2V0cyBhcmUgdG8gYmUgc2VudCB0byBpdCBmb3IgdGhlIGZs b3cgc3BlY2lmaWVkIGluIA0KPmVuY2Fwc3VsYXRlZCBwYWNrZXQuDQo+DQo+SW4gYWRkaXRpb24s IFNDSCBkZWZpbmVzIGEgbWV0YWRhdGEgdHlwZSBmb3IgR2VuZXJpYyBDb250ZXh0IEJsb2NrLCAN Cj53aGljaCBpcyBvcHRpb25hbCBhbmQgY2FuIGJlIHVzZWQgaWYgbmVlZGVkIHRvIGNhcnJ5IGFu eSB2ZW5kb3IncyANCj5zcGVjaWZpYyAiQ29udGV4dCBIZWFkZXIiLg0KPg0KPkFueSBjb21tZW50 cyBvbiB0aGVzZSBuZXcgYWRkaXRpb25zPw0KPg0KPlRoYW5rcywNCj5DYXRoeQ0KPg0KPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBDYXRoeSBaaGFuZw0KPlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIg MDUsIDIwMTQgMTE6NDcgQU0NCj5UbzogU3JpbmkgQWRkZXBhbGxpOyBSZWluYWxkbyBQZW5ubyAo cmVwZW5ubyk7IEpvZWwgTS4gSGFscGVybjsgDQo+J3NmY0BpZXRmLm9yZycNCj5DYzogbnNtdXJ0 aHlAZnJlZXNjYWxlLmNvbQ0KPlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJh ZnQNCj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIp DQo+DQo+Um9uLCBMb3VpcywgTXlvIGFuZCBJIGhhdmUgYmVlbiBkaXNjdXNzaW5nIG9mZiBsaW5l IGxhc3QgZmV3IHdlZWtzIA0KPmFib3V0IGRlZmluaW5nIGEgbWV0YWRhdGEgdHlwZSBmb3IgZmxv dyBJRCBpbiBhZGRpdGlvbiB0byB0aGUgcGF0aCBJRCANCj5vZiB0aGUgbWFpbiBoZWFkZXIgdG8g c3VwcG9ydCBsb2FkIGJhbGFuY2luZyBhbW9uZyBTRiBpbnN0YW5jZXMuIFdlIA0KPndpbGwgZGVm aW5lIGEgVExWIHR5cGUgZm9yIHRoZSBmbG93IElELiBUaGUgY29tYmluYXRpb24gb2YgInBhdGgg SUQgKyBmbG93IElEIg0KPnNwZWNpZmllcyBhIHJlYWxpemVkIHNlcnZpY2UgY2hhaW4gaW5zdGFu Y2UgcGF0aC4gSXQgaXMgbGVmdCB0byB0aGUgDQo+ZGVzaWduL2ltcGxlbWVudGF0aW9uIHdoZXRo ZXIgdG8gdXNlIGEgY2VudHJhbGl6ZWQgbWV0aG9kIG9yIGEgDQo+ZGlzdHJpYnV0ZWQgbWV0aG9k IHRvIGJpbmQgdGhlIGZsb3cgSUQgdG8gYSByZWFsaXplZCBzZXJ2aWNlIGluc3RhbmNlIA0KPnBh dGggYWx0aG91Z2ggb3VyIG9yaWdpbmFsIHRob3VnaHQgaXMgZm9yIGRpc3RyaWJ1dGVkIExCIHVz YWdlLiBJIGFtIA0KPm5vdCBzdXJlIGlmIHdlIG5lZWQgYSBiaXQgaW4gdGhlIGhlYWRlciB0byBk ZW5vdGUgd2hldGhlciB0aGVyZSBhcmUgDQo+bW9yZSBwYXRoIElEIGJpdHMgKHdlIGNhbGwgaXQg ZmxvdyBJRCkgaW4gdGhlIG1ldGFkYXRhIGZpZWxkcyBzaW5jZSANCj53aGVuIHlvdSBwYXJzZSB0 aGUgVExWIG1ldGFkYXRhLCB5b3Ugd2lsbCBrbm93IHdoZXRoZXIgdGhlcmUgYXJlIGZsb3cgSUQg Yml0cyBvciBub3QuDQo+Tm90ZSB0aGF0IGlmIG11bHRpcGxlIHNlc3Npb25zIHNoYXJlIHRoZSBz YW1lIHJlYWxpemVkIHNlcnZpY2UgaW5zdGFuY2UgDQo+cGF0aCwgdGhleSB3aWxsIHNoYXJlIHRo ZSBzYW1lICJwYXRoIElEKyBmbG93IElEIi4gIFdlIGNhbiBhbHNvIA0KPmNvbnNpZGVyIGV4dGVu ZGluZyB0aGUgbnVtYmVyIG9mIGJpdHMgdG8gMzIgaWYgdGhhdCBpcyB0aGUgY29uc2Vuc3VzLg0K PldlIHdpbGwgcG9zdCBhbiB1cGRhdGVkIGRyYWZ0IGRlc2NyaWJpbmcgdGhlc2Ugc29vbi4NCj4N Cj5UaGFua3MsDQo+Q2F0aHkNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206 IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3JpbmkgQWRk ZXBhbGxpDQo+U2VudDogRnJpZGF5LCBEZWNlbWJlciAwNSwgMjAxNCA3OjE3IEFNDQo+VG86IFJl aW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgSm9lbCBNLiBIYWxwZXJuOyAnc2ZjQGlldGYub3JnJw0K PkNjOiBuc211cnRoeUBmcmVlc2NhbGUuY29tDQo+U3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRz IG9uIFNDSCBEcmFmdA0KPihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmct c2ZjLXNjaC0wMikNCj4NCj4NCj5bUlBdIERhdGEgcGxhbmUgZWZmaWNpZW5jeS4NCj4NCj5TUklO ST4gSSBhbSBub3Qgc28gc3VyZSBhYm91dCBkYXRhIHBsYW5lIGVmZmljaWVuY3kuICBNb3N0IG9m IHRoZQ0KPnByb2Nlc3NvcnMgd29yayBnb29kIGlmIHRoZSBudW1iZXIgb2YgYml0cyBhcmUgZWl0 aGVyIDMyIG9yIDY0LiAgSWYgaXQgDQo+aXMNCj4yNCBiaXRzLCB0aGVuIG9uZSBuZWVkcyB0byBk byBtYXNraW5nIGFuZCBzaGlmdGluZyBiZWZvcmUgdGhlIHZhbHVlIGlzDQo+dXNlZCB0byBkbyBh bnkgbG9va3VwLiAgIEJ1dCwgdGhpcyBkaXNjdXNzaW9uIGNhbiBnbyBpbnRvIGRpZmZlcmVudA0K PmRpcmVjdGlvbiA6LSksIGl0IG1heSBub3QgYmUgZ29vZCB0byBnbyBpbiB0aGF0IGRpcmVjdGlv bi4NCj4NCj5XaGVyZSBkbyB3ZSBkcmF3IHRoZSBsaW5lPyAzMi1iaXRzLCA2NC1iaXRzLA0KPjEy OCBiaXRzPyBJIHRoaW5rIHdlIHNob3VsZCBoYXZlIGEgc2Vuc2libGUgdmFsdWUgaW4gdGhlIFNl cnZpY2UgUGF0aCANCj5oZWFkZXIgYW5kIGlmIHlvdSBuZWVkIHRvIGNvbnZleSBtb3JlIGJpdHMg eW91IG5lZWQgdG8gdXNlIHRoZSBjb250ZXh0IA0KPmhlYWRlcnMuDQo+DQo+U1JJTkk+IFRoaXMg aXMgYSBnb29kIHBvaW50LiAgVGhpcyBzaG91bGQgd29yayBmaW5lIGFzIGxvbmcgYXMgdGhlcmUg aXMNCj53YXkgdG8gY29udmV5IGluIHRoZSBtYWluIGhlYWRlciB0aGF0IHRoZSBleHRlbnNpb24g dG8gcGF0aCBJRCBpcyANCj5hdmFpbGFibGUgaW4gc28gYW5kIHNvIFRMViBmaWVsZC4gIFRoYXQg c2hvdWxkIHdvcmsgdG9vLg0KPg0KPlRoYW5rcw0KPlNyaW5pDQo+DQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPkZyb206IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5v KSA8cmVwZW5ub0BjaXNjby5jb20+DQo+U2VudDogRnJpZGF5LCBEZWNlbWJlciA1LCAyMDE0IDc6 MDggQU0NCj5UbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2MDsgSm9lbCBNLiBIYWxwZXJuOyAnc2Zj QGlldGYub3JnJw0KPkNjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPlN1YmplY3Q6IFJl OiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+DQo+T24gMTIvNS8xNCwgNjo1NCBBTSwgIlNy aW5pIEFkZGVwYWxsaSIgPHNhZGRlcGFsbGlAZnJlZXNjYWxlLmNvbT4gd3JvdGU6DQo+DQo+Pg0K Pj5JbiByZWFsIGRlcGxveW1lbnRzLCBudW1iZXIgb2YgYWN0aXZlIHBhdGggSURzIGFyZSB2ZXJ5 IGxlc3NlciB0aGFuIA0KPj4yXjY0LCBidXQgdGhlcmUgaXMgYSBnb29kIHBvc3NpYmlsaXR5IG9m IHRoZSBudW1iZXIgYmVpbmcgbW9yZSB0aGFuDQo+PjJeMjQgKDE2TSkuDQo+PiBJIHRoaW5rIGJp Z2dlciBwb2ludCBpcyB0aGF0IHdoeSByZXN0cmljdCB0aGlzIGluIHRoZSBzdGFuZGFyZHM/IFdo YXQgDQo+PmFkdmFudGFnZSBkbyB3ZSBoYXZlIHJlc3RyaWN0aW5nIHRoaXMgc2l6ZSB0byAyNCBi aXRzPw0KPg0KPltSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5LiBXaGVyZSBkbyB3ZSBkcmF3IHRo ZSBsaW5lPyAzMi1iaXRzLCANCj42NC1iaXRzLA0KPjEyOCBiaXRzPyBJIHRoaW5rIHdlIHNob3Vs ZCBoYXZlIGEgc2Vuc2libGUgdmFsdWUgaW4gdGhlIFNlcnZpY2UgUGF0aCANCj5oZWFkZXIgYW5k IGlmIHlvdSBuZWVkIHRvIGNvbnZleSBtb3JlIGJpdHMgeW91IG5lZWQgdG8gdXNlIHRoZSBjb250 ZXh0IA0KPmhlYWRlcnMuDQo+DQo+DQo+Pg0KPj5UaGVyZSBjYW4gYmUgZGVwbG95bWVudHMsIHdo ZXJlIFNGQyBjb250cm9sbGVyIChMb2dpY2FsbHkgY2VudHJhbCwgYnV0DQo+PmRpc3RyaWJ1dGVk KSAgaXRzZWxmIGNhbiBkbyB0aGUgU0YgaW5zdGFuY2Ugc2VsZWN0aW9uIG9uIHBlcg0KPj5jb25u ZWN0aW9uL3Nlc3Npb24gYmFzaXMsIHRoZXJlYnkgYXZvaWRpbmcgdGhlIExCcyBmb3Igc2Vydmlj ZXMuICAgSW4gbXkNCj4+dmlldywgYXNzdW1wdGlvbiB0aGF0IHRoZXJlIHdpbGwgYmUgTEIgU0Yg Zm9yIGVhY2ggc2NhbGUtb3V0IHNlcnZpY2UgDQo+PmluIHRoZSBjaGFpbiBpcyBub3QgdmFsaWQg aW4gYWxsIGNhc2VzLg0KPj4NCj4+VGhhbmtzDQo+PlNyaW5pDQo+Pg0KPj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PkZyb206IFJlaW5hbGRvIFBlbm5vIChyZXBl bm5vKSA8cmVwZW5ub0BjaXNjby5jb20+DQo+PlNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciA0LCAy MDE0IDE6MTcgUE0NCj4+VG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IEpvZWwgTS4gSGFscGVy bjsgc2ZjQGlldGYub3JnDQo+PkNjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPj5TdWJq ZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+PihodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4+DQo+PklmIEkgdW5kZXJzdG9v ZCB5b3UsIEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgcmVhbGlzdGljLiBBcmUgeW91IHNheWluZyAN Cj4+eW91IG5lZWQgNjQtYml0cyBvZiBwYXRocyBhbmQgdGhlbiB3aWxsIG1vbml0b3IgdGhlbSBh bGw/IERvIGZhdWx0IA0KPj50b2xlcmFuY2UgYW5kIE9BTSBmb3IgMl42NC1iaXRzIHdvcnRoIG9m IHBhdGhzPyBKdXN0IGZvciBjb21wYXJpc29uLCANCj4+aXTCuXMgbGlrZSBtYW5hZ2luZyBhbmQg bW9uaXRvcmluZyB0aGUgZW50aXJlIElQdjYgaG9zdCByYW5nZSwgb25lLWJ5LW9uZS4NCj4+DQo+ PkFueXdheSwgSSBkbyBub3QgZXhwZWN0IGV2ZXJ5IHNpbmdsZSBwZXJtdXRhdGlvbnMgdG8gYmUg YSBkaWZmZXJlbnQgcGF0aC4NCj4+DQo+PklmIGVhY2ggc2VydmljZSBoYXMgMjU2IGRldmljZXMg cHJvdmlkaW5nIHNpbWlsYXIgc2VydmljZSwgeW91IHNob3VsZCANCj4+bW9zdCBsaWtlbHkgdXNl IGxvYWQtYmFsYW5jaW5nIGFuZCB0aGVuIHlvdSB3b3VsZCBoYXZlIGEgc2luZ2xlIChvciBhDQo+ PmZldykgcGF0aHMuIFRoZXJlIGlzIHNvbWUgZGlzY3Vzc2lvbiBnb2luZyBvbiBMQi4NCj4+DQo+ PkZyb20gYSBkYXRhIHBsYW5lIHBlcnNwZWN0aXZlLCB0aGUgcGF0aCBpcyB1bHRpbWF0ZWx5IGRl ZmluZWQgYnkgdGhlIA0KPj5TRkZzIHRyYXZlcnNlZCBhbmQgc2VydmljZXMgcHJvdmlkZWQsIG5v dCBieSBhIHNwZWNpZmljIElQOnBvcnQgdGhhdCANCj4+dGhlIGRldmljZSBwcm92aWRpbmcgdGhl IHNlcnZpY2Ugc2l0cyBvbi4gV2VsbCwgYXQgbGVhc3QgZnJvbSBhDQo+PkdQRStOU0ggcGVyc3Bl Y3RpdmUuDQo+Pg0KPj4NCj4+T24gMTIvNC8xNCwgMTI6NTcgUE0sICJTcmluaSBBZGRlcGFsbGki IDxzYWRkZXBhbGxpQGZyZWVzY2FsZS5jb20+IHdyb3RlOg0KPj4NCj4+PklmIEkgdGFrZSBhIGNo YWluIHdpdGggNSBzZXJ2aWNlcyB3aXRoIGVhY2ggc2VydmljZSAgc2F5IGhhdmluZyAyNTYgDQo+ Pj5pbnN0YW5jZXMgZm9yIHNjYWxlLW91dCwgcG9zc2libGUgbnVtYmVyIG9mIHBhdGhzIGFyZQ0K Pj4+MjU2KjI1NioyNTYqMjU2KjI1NiA9IDB4RkYgRkYgRkYgRkYgRkYuIE9uZSByZXF1aXJlcyAz MyBiaXRzIGluIHRoaXMgDQo+Pj5jYXNlLiAgSWYgdGhlcmUgYXJlIG1vcmUgc2VydmljZXMgaW4g dGhlIGNoYWluIG9yIG1vcmUgY2hhaW5zIG9yIG1vcmUgDQo+Pj5pbnN0YW5jZXMgZm9yIHNjYWxl LW91dCwgdGhlbiBpdCBjb3VsZCBnbyB0byBiaWcgbnVtYmVyIHZlcnkgZmFzdC4NCj4+Pg0KPj4+ QXMgSSBtZW50aW9uZWQgbXkgcHJlZmVyZW5jZSBpcyB0byBtYWtlIHRoZSBwYXRoIElEIHNpemUg ZmxleGlibGUgZm9yIA0KPj4+ZnV0dXJlIGdyb3d0aC4gSWYgdGhhdCBpcyBwZXJjZWl2ZWQgYXMg Y29tcGxleCwgdGhlbiBnb2luZyBmb3IgNjRiaXQgDQo+Pj5pcyBzYWZlciBiZXQuDQo+Pj4NCj4+ PlRoYW5rcw0KPj4+U3JpbmkNCj4+Pg0KPj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4+RnJvbTogSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0N Cj4+PlNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwNCwgMjAxNCAxMjowNSBQTQ0KPj4+VG86IEFk ZGVwYWxsaSBTcmluaS1CMjIxNjA7IEpvZWwgTS4gSGFscGVybjsgc2ZjQGlldGYub3JnDQo+Pj5D YzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDANCj4+PlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21t ZW50cyBvbiBTQ0ggRHJhZnQNCj4+PihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt emhhbmctc2ZjLXNjaC0wMikNCj4+Pg0KPj4+QSBjb250cm9sbGVyIChvciBvdGhlciBkZWNpc2lv biBsb2dpYykgY2FuIGNlcnRhaW5seSBiZSBhd2FyZSBvZiBzdWNoIA0KPj4+Y29uY2VybnMuDQo+ Pj5CdXQgdGhlIG51bWJlciBvZiBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzIGlzIG5vdCByZWxhdGVk IHRvIHRoZSBudW1iZXIgDQo+Pj5vZiBmbG93cyBvciB0aGUgbnVtYmVyIG9mIHRlbmFudHMuICBJ dCBpcyByZWxhdGVkIHRvIHRoZSBudW1iZXIgb2YgDQo+Pj5jb21iaW5hdGlvbnMgb2Ygc2Vydmlj ZXMgYW5kIHRoZSBwb2xpY2llcyBmb3Igc2VydmljZSBmdW5jdGlvbiANCj4+PnNlbGVjdGlvbi4N Cj4+PiBXaGlsZSB0aGF0IGNhbiBiZSBhIGxhcmdlIG51bWJlciwgSSBzdXJlIGhvcGUgaXQgZG9l cyBub3QgY29tZSBjbG9zZSANCj4+PnRvIHNhdHVyYXRpbmcgMjQgYml0cy4NCj4+Pg0KPj4+SGF2 aW5nIHNhaWQgdGhhdCwgaWYgd2UgdGhpbmsgdGhhdCAyNCBiaXRzIGlzIG9ubHkganVzdCBlbm91 Z2gsIHRoZW4gDQo+Pj53ZSBvdWdodCB0byB1c2UgMzIuICBGcm9tIHdoZXJlIEkgc2l0LCBJIHdv dWxkIG5vcm1hbGx5IGV4cGVjdCAxNiANCj4+PmJpdHMgdG8gYmUgbW9yZSB0aGFuIHN1ZmZpY2ll bnQsIHdoaWNoIGlzIHdoeSBJIGFtIGNvbWZvcnRhYmxlIHdpdGggMjQuDQo+Pj5IYXZpbmcgc2Fp ZCB0aGF0LCB0aGUgZmllbGQgc2l6ZSBpcyBub3QgYSBiaWcgZGVhbCB0byBtZS4NCj4+Pg0KPj4+ WW91cnMsDQo+Pj5Kb2VsDQo+Pj4NCj4+Pk9uIDEyLzQvMTQsIDI6MDEgUE0sIFNyaW5pIEFkZGVw YWxsaSB3cm90ZToNCj4+Pj4NCj4+Pj4gSSB3YXMgbm90IGltcGx5aW5nIHRoYXQgcGF0aCBJRCBz aG91bGQgaGF2ZSBpbmZvcm1hdGlvbiBpbiByZWdhcmRzIA0KPj4+PnRvIHRlbmFudC9jb250cm9s bGVyL2Zsb3cvc2NhbGUtb3V0LiAgQnV0IFNGQyBjb250cm9sbGVycyBzaG91bGQgDQo+Pj4+a2Vl cCB0aGVzZQ0KPj4+PmluIG1pbmQgdG8gYXNzaWduIHRoZSBwYXRoIElELiAgICBBIGRlcGxveW1l bnQgY2FuIGhhdmUgbXVsdGlwbGUNCj4+Pj50ZW5hbnRzLCBlYWNoIHRlbmFudCBjYW4gaGF2ZSBt dWx0aXBsZSBuZXR3b3JrcywgIHRoZXJlIGNvdWxkIGJlIA0KPj4+Pm1pbGxpb25zIG9mIGZsb3dz IGluIGVhY2ggb2YgdGhvc2UgbmV0d29ya3MuICBBbmQgY29uc2lkZXJpbmcgYWxsIA0KPj4+PnRo ZXNlLA0KPj4+PiAyNCBiaXQgcGF0aCBJRCBtYXkgbm90IGJlIGFibGUgdG8gcmVwcmVzZW50IHBh dGhzIGZvciB0aGVzZSBmbG93cy4NCj4+Pj5IZW5jZSwgSSB3YXMgd29uZGVyaW5nIHdoZXRoZXIg cGF0aCBJRCBjYW4gYmUgZXh0ZW5kZWQgdG8gNjQgYml0cyBvciANCj4+Pj5tYWtlIGl0IGZsZXhp YmxlLg0KPj4+Pg0KPj4+PiBUaGFua3MNCj4+Pj4gU3JpbmkNCj4+Pj4NCj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBGcm9tOiBKb2VsIE0uIEhhbHBl cm4gPGptaEBqb2VsaGFscGVybi5jb20+DQo+Pj4+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciA0 LCAyMDE0IDc6NDIgQU0NCj4+Pj4gVG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IHNmY0BpZXRm Lm9yZw0KPj4+PiBDYzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDANCj4+Pj4gU3ViamVjdDog UmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4+PiAoaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+Pj4+DQo+Pj4+IFRoZSBJbmRleCBp cyBub3QganVzdCBmb3IgbG9vcCBwcmV2ZW50aW9uLiAgSW4gdGhlIGNhc2Ugb2YgDQo+Pj4+YW1i aWd1aXR5LCB0aGUgaW5kZXggdGVsbHMgdGhlIFNGRiB3aGVyZSBpbiB0aGUgcGF0aCB0aGUgcGFj a2V0IA0KPj4+PmN1cnJlbnRseSByZXNpZGVzLg0KPj4+PiAgICBUaGVyZSBhcmUgbXVsdGlwbGUg d2F5cyBzdWNoIGFtYmlndWl0eSBjYW4gb2NjdXIuDQo+Pj4+DQo+Pj4+IFRoZSBQYXRoIElkZW50 aWZpZXIgaXMgc3BlY2lmaWNhbGx5IG5vdCBleHBlY3RlZCB0byBpbmNsdWRlIA0KPj4+PiBjb250 cm9sbGVyIElEIG9yIFRlbmFudCBJRC4gIFdoaWxlIGEgZGVwbG95ZXIgY2FuIGhhdmUgYSBwYXRo IHBlciANCj4+Pj4gdGVuYW50LCB0aGUgYXJjaGl0ZWN0dXJlIHN0aWxsIGRvZXMgbm90IHRyZWF0 IHRoZSBwYXRoIElEIGFzIGEgDQo+Pj4+IHRlbmFudCBJRC4gIFRlbmFudCBJRCwgY29udHJvbGxl ciBJRCwgYW5kIG90aGVyIG5vbi1wYXRoLXNwZWNpZnlpbmcgDQo+Pj4+IGluZm9ybWF0aW9uIGlz IHRvIGJlIGNhcnJpZWQgaW4gbWV0YWRhdGEuDQo+Pj4+DQo+Pj4+IFlvdXJzLA0KPj4+PiBKb2Vs DQo+Pj4+DQo+Pj4+IE9uIDEyLzQvMTQsIDEwOjAyIEFNLCBTcmluaSBBZGRlcGFsbGkgd3JvdGU6 DQo+Pj4+PiBUd28gY29tbWVudHMgOg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiAxLiAgU0YgSW5kZXgg OiAgU2luY2UgaXQgaXMgbWVhbnQgZm9yIGxvb3AgZGV0ZWN0aW9uLCAgd291bGRuJ3QgDQo+Pj4+ PiBiZXR0ZXIgdG8gcmVuYW1lIHRoaXMgYXMgIlRUTCI/DQo+Pj4+Pg0KPj4+Pj4gMi4gIFBhdGgg SWRlbnRpZmllciA6ICAgIDI0IGJpdCBwYXRoIGlkZW50aWZpZXIgc2VlbXMgdG8gYmUgdG9vIGxl c3MuDQo+Pj4+PiBCYXNlZCBvbiBvdXIgZXhwZXJpZW5jZSBpbiB0cmFmZmljIHN0ZWVyaW5nLCAg dGhpcyBwYXRoIGlkZW50aWZpZXIgDQo+Pj4+Pm5lZWRzIHRvIGVuY29kZSBnb29kIGFtb3VudCBv ZiBpbmZvcm1hdGlvbiB0byBtYWtlIGl0IHVuaXF1ZS4gIEZvciANCj4+Pj4+ZXhhbXBsZSwNCj4+ Pj4+ICAgIHRoaXMgaWRlbnRpZmllciBuZWVkcyB0byBlbmNvZGUgKGluIG91ciBjYXNlKSBzb21l IGluZm9ybWF0aW9uIA0KPj4+Pj5yZXByZXNlbnRpbmcgdGhlIGRpc3RyaWJ1dGVkIGNvbnRyb2xs ZXIgSUQsICB0ZW5hbnQgSUQsICBmbG93IElELA0KPj4+Pj4gICAgU2VydmljZSBmdW5jdGlvbiBp bnN0YW5jZSAoaW4gY2FzZSBvZiBzY2FsZS1vdXQpIGFuZCBmZXcgbW9yZS4uDQo+Pj4+PiBPbmUg c3VnZ2VzdGlvbiBpcyB0byBtYWtlIGl0IDY0IGJpdHMgdmFsdWUgIG9yIHRvIG1ha2UgaXQgZXZl biANCj4+Pj4+ZXh0ZW5kYWJsZSwNCj4+Pj4+ICAgIGl0IGlzIGdvb2QgaWYgcGF0aCBpZGVudGlm aWVyIGlzIGFsc28gcmVwcmVzZW50ZWQgaW4gVExWIGZvcm0uDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ IFRoYW5rcw0KPj4+Pj4NCj4+Pj4+IFNyaW5pDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0K Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+DQo+Pj4NCj4+Pl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5zZmMgbWFpbGluZyBs aXN0DQo+Pj5zZmNAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo+Pg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRmLm9yZw0KPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zZmMgbWFpbGluZyBsaXN0DQo+c2ZjQGll dGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCj4N Cj5UaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyAodGhlICJtZXNzYWdlIikgYXJlIGNv bmZpZGVudGlhbCwgDQo+aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2Vlcy4gSWYgeW91 IGFyZSBub3QgdGhlIGludGVuZGVkIA0KPnJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIA0KPnRoaXMgbWVzc2FnZSBmcm9t IHlvdXIgc3lzdGVtLiBJbiB0aGlzIGNhc2UsIHlvdSBhcmUgbm90IGF1dGhvcml6ZWQgdG8gDQo+ dXNlLCBjb3B5IHRoaXMgbWVzc2FnZSBhbmQvb3IgZGlzY2xvc2UgdGhlIGNvbnRlbnQgdG8gYW55 IG90aGVyIHBlcnNvbi4NCj5FLW1haWxzIGFyZSBzdXNjZXB0aWJsZSB0byBhbHRlcmF0aW9uLiBO ZWl0aGVyIFFvc21vcyBub3IgYW55IG9mIGl0cyANCj5zdWJzaWRpYXJpZXMgb3IgYWZmaWxpYXRl cyBzaGFsbCBiZSBsaWFibGUgZm9yIHRoZSBtZXNzYWdlIGlmIGFsdGVyZWQsIA0KPmNoYW5nZWQg b3IgZmFsc2lmaWVkLg0KPg0KPkNlIG1lc3NhZ2UgZXQgdG91dGVzIHNlcyBwacOoY2VzIGpvaW50 ZXMgKGNpLWFwcsOocyBsZSAibWVzc2FnZSIpc29udCANCj5jb25maWRlbnRpZWxzIGV0IMOpdGFi bGlzIMOgIGwnaW50ZW50aW9uIGV4Y2x1c2l2ZSBkZSBzZXMgZGVzdGluYXRhaXJlcy4NCj5TaSB2 b3VzIGF2ZXogcmXDp3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCBtZXJjaSBk4oCZZW4gaW5mb3Jt ZXIgDQo+aW1tw6lkaWF0ZW1lbnQgc29uIMOpbWV0dGV1ciBwYXIgY291cnJpZXIgw6lsZWN0cm9u aXF1ZSBldCBk4oCZZWZmYWNlciBjZSANCj5tZXNzYWdlIGRlIHZvdHJlIHN5c3TDqG1lLiBEYW5z IGNldHRlIGh5cG90aMOoc2UsIHZvdXMgbuKAmcOqdGVzIHBhcyANCj5hdXRvcmlzw6kgw6AgdXRp bGlzZXIsIGNvcGllciBjZSBtZXNzYWdlIGV0L291IGVuIGRpdnVsZ3VlciBsZSBjb250ZW51IMOg IA0KPnVuIHRpZXJzLiBUb3V0IG1lc3NhZ2Ugw6lsZWN0cm9uaXF1ZSBlc3Qgc3VzY2VwdGlibGUg ZCdhbHTDqXJhdGlvbi4NCj5Rb3Ntb3MgZXQgc2VzIGZpbGlhbGVzIGTDqWNsaW5lbnQgdG91dGUg cmVzcG9uc2FiaWxpdMOpIGF1IHRpdHJlIGRlIGNlIA0KPm1lc3NhZ2UgcydpbCBhIMOpdMOpIGFs dMOpcsOpLCBkw6lmb3Jtw6kgb3UgZmFsc2lmacOpLg0KPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0 DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1h aWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0K From nobody Mon Feb 2 18:47:16 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 61A0B1A1BD2 for ; Mon, 2 Feb 2015 18:47:15 -0800 (PST) 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 y82kOEFNWKsD for ; Mon, 2 Feb 2015 18:47:14 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF171A1DBC for ; Mon, 2 Feb 2015 18:47:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=231; q=dns/txt; s=iport; t=1422931634; x=1424141234; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vl5CPe2LP0IpQMjUZDSM6nuKsIzQCLNngHu08g3MMoU=; b=R1hzpCPyhc4N/PvcTBbjUf8FLSikbLKXDVT6kFCTDTiib6D5pOfvLTwq kKuF/ZY9p4pXig9SPiCDGKXyD7+F6b6e1X03JSv+6lZaQ1KlSe4IOHBxR ZrqrnQfsZ8zoGfD2qNtxV5qtfUE56d85Wr2YZQ54gbEXFRuOyC208tQ4I 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BJBQDHNdBU/5NdJa1agwZSWQTEfIVxAoEgQwEBAQEBfYQNAQEEVCUQAgEIDjgyJQIEAQ0FiC0N1gMBAQEBAQEBAQEBAQEBAQEBAQEBAQETBI94B4QpAQSJb4M3gWODToVXklwigjKBPG+BRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,510,1418083200"; d="scan'208";a="119867526" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP; 03 Feb 2015 02:47:13 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t132lDB4003283 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 02:47:13 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.88]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Mon, 2 Feb 2015 20:47:13 -0600 From: "Surendra Kumar (smkumar)" To: Srini Addepalli , Nicolas BOUTHORS , Sumandra Majee , Cathy Zhang , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZx/9uiAgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgCAAEtwAIBWb4+AgAEKeQCAALysgIACxPuAgABPRQCAAV38gA== Date: Tue, 3 Feb 2015 02:47:13 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> <76B41B8FACE1514795D30EC137FF391D7D2279@LILAS.jungle.qosmos.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.4.7.141117 x-originating-ip: [10.24.120.108] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <1FDF3123E6724241BF752DA63226C8AD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "nsmurthy@freescale.com" , Rajesh Kumar Madabushi , Bharat Mota Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 03 Feb 2015 02:47:15 -0000 I wouldn=B9t make a categorical statement such as this, it is just one possibility. Surendra. On 2/1/15, 1:54 PM, "Srini Addepalli" wrote: >In NFV world, SFF is a virtual switch in servers.=20 From nobody Mon Feb 2 22:33: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 463851A6F14 for ; Mon, 2 Feb 2015 22:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TRACKER_ID=1.306] 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 vsHTEdafrPBr for ; Mon, 2 Feb 2015 22:33:14 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0132.outbound.protection.outlook.com [65.55.169.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1F271A1BC9 for ; Mon, 2 Feb 2015 22:33:13 -0800 (PST) Received: from DM2PR0301MB0861.namprd03.prod.outlook.com (25.160.215.147) by DM2PR0301MB0910.namprd03.prod.outlook.com (25.160.217.140) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 3 Feb 2015 06:33:12 +0000 Received: from DM2PR0301MB0862.namprd03.prod.outlook.com (25.160.215.148) by DM2PR0301MB0861.namprd03.prod.outlook.com (25.160.215.147) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 3 Feb 2015 06:33:11 +0000 Received: from DM2PR0301MB0862.namprd03.prod.outlook.com ([25.160.215.148]) by DM2PR0301MB0862.namprd03.prod.outlook.com ([25.160.215.148]) with mapi id 15.01.0065.013; Tue, 3 Feb 2015 06:33:11 +0000 From: Srini Addepalli To: Henry Fourie , Sumandra Majee , Nicolas BOUTHORS , Cathy Zhang , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZyAGG+AgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgD//7j7oIBVIj4ggALqPwCAADaLgIADgFqAgAE9hoCAAHbz4A== Date: Tue, 3 Feb 2015 06:33:10 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> <0F8583BBE82FA449A8B78417CC07559A09195E9F@SJCEML701-CHM.china.huawei.com> In-Reply-To: <0F8583BBE82FA449A8B78417CC07559A09195E9F@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.162.248.85] authentication-results: huawei.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0861;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0861; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(164054003)(479174004)(51704005)(52314003)(13464003)(24454002)(53754006)(86362001)(74316001)(77156002)(33656002)(561944003)(62966003)(66066001)(2900100001)(102836002)(15975445007)(93886004)(122556002)(2950100001)(106116001)(76576001)(87936001)(40100003)(230783001)(54356999)(76176999)(50986999)(2656002)(19580405001)(92566002)(99286002)(54606007)(46102003)(491001)(579004)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0861; H:DM2PR0301MB0862.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2015 06:33:10.6651 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0861 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0910; X-OriginatorOrg: freescale.com Archived-At: Cc: "nsmurthy@freescale.com" , Jerome TOLLET , Rajesh Kumar Madabushi , Bharat Mota Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 03 Feb 2015 06:33:18 -0000 SGkgTG91aXMsDQoNCkluIE9wZW5zdGFjayBiYXNlZCBORlYgd29ybGQsICBOT1ZBLCBiYXNlZCBv biBpdHMgc2NoZWR1bGluZyBwb2xpY3kgYW5kIGZpbHRlcnMsIGNhbiBjcmVhdGUgdk5GIGluc3Rh bmNlcyBpbiB2YXJpb3VzIHNlcnZlcnMuICBJdCBtZWFucyB0aGF0IGluc3RhbmNlcyBvZiBvbmUg U0YgY2FuIGJlIGluIHZhcmlvdXMgc2VydmVycyBhbmQgaXQgbWVhbnMgdGhhdCBtdWx0aXBsZSBT RkZzIG1heSBiZSBmcm9udCBlbmRpbmcgb25lIHNlcnZpY2UuICBNeSBvbmx5IHBvaW50IHdhcyB0 aGF0LCB0aGlzIGlzIGEgYmlnIHBvc3NpYmlsaXR5IGFuZCB0aGF0IGlzIHdoZXJlIGNlbnRyYWxp emVkIGxvZ2ljYWwgY29udHJvbGxlciB3b3VsZCBjb21lIGluIGhhbmR5IGluIGFsbG9jYXRpbmcg UlNQIElEcyBhbmQgcHJvZ3JhbW1pbmcgdGhlbSBpbiBTRkZzIGluIHRob3NlIGNhc2VzLg0KDQpJ biBwaHlzaWNhbCBkZXBsb3ltZW50cywgb25lIGNvdWxkIGhhdmUgb25lIFNGRiBmcm9udCBlbmRp bmcgYWxsIHBoeXNpY2FsIFNGIGluc3RhbmNlcy4gIEhlcmUgbGF0ZSBiaW5kaW5nIHdvcmtzIGFz IHNhbWUgU0ZGIGlzIGdvaW5nIHRvIHNlbGVjdCB0aGUgU0YgSW5zdGFuY2UgYXMgd2VsbCB1c2Ug aXQgZm9yIGZ1cnRoZXIgcGFja2V0cy4NCg0KVGhhbmtzDQpTcmluaQ0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEhlbnJ5IEZvdXJpZQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAwMiwgMjAx NSAzOjM1IFBNDQpUbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2MDsgU3VtYW5kcmEgTWFqZWU7IE5p Y29sYXMgQk9VVEhPUlM7IENhdGh5IFpoYW5nOyAnc2ZjQGlldGYub3JnJw0KQ2M6IE5TIFNyaW5p dmFzYSBNdXJ0aHktQjM3ODQwOyBKZXJvbWUgVE9MTEVUOyBNYWRhYnVzaGkgUmFqZXNoIEt1bWFy LUIzODg3MDsgTW90YSBCaGFyYXQtQjE5NDc5DQpTdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMg b24gU0NIIERyYWZ0IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2Zj LXNjaC0wMikNCg0KU3JpbmksDQogICAgSW4geW91ciBleGFtcGxlIEkgcHJlc3VtZSB0aGF0IFNm eC0sIFNGeS0gYW5kIFNGei0gYXJlIGFsbCBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgdHlwZSBvZiBT RiwgZWcuLCBTZngtIGFyZSBhbGwgaW5zdGFuY2VzIG9mIGEgRlcuIFNvLCBpbiB0aGUgZXhhbXBs ZSwgeW91IGhhdmUgaW5zdGFuY2VzIG9mIGEgZ2l2ZW4gdHlwZSwgZWcsIFNGeC0gaG9tZWQgb24g dHdvIGRpZmZlcmVudCBTRkZzLiBTRngxIGFuZCBTRngyIGFyZSBob21lZCBvbiBTRkYxIGFuZCBT RngzIGlzIGhvbWVkIG9uIFNGRjIuIFRoaXMgY2FuIGJlIGRvbmUgYnV0IGFkZHMgY29tcGxleGl0 eSB0byBhbiBpbXBsZW1lbnRhdGlvbiB3aGVyZSBhIFNGRiBtYXkgd2FudCB0byBkbyBsb2FkLWJh bGFuY2luZyBvdmVyIGEgZ3JvdXAgb2YgU0ZzLg0KDQpBbiBhbHRlcm5hdGl2ZSBjb25maWd1cmF0 aW9uIHdvdWxkIGJlIHdoZXJlIFNGcyBvZiBhIGdpdmVuIHR5cGUgYXJlIGFsbCBob21lZCBvbiB0 aGUgc2FtZSBTRkYsIGVnLCBTRngxLTMgYXJlIGFsbCBob21lZCBvbiBTRkYxLCBhbGxvd2luZyBp dCB0byBwZXJmb3JtIGxvYWQtYmFsYW5jaW5nIGFjcm9zcyB0aGlzIHNldCBvZiBTRiBpbnN0YW5j ZXMuDQoNClNlY3Rpb24gNC4zLjIgb2YgdGhlIFNDSCBkcmFmdCBkZXNjcmliZXMgdGhlIHVzZSBv ZiB0aGUgUlNQIElEIGluIHRoaXMgY2FzZS4NCkVhY2ggU0ZGIG1heSBwZXJmb3JtIGEgbGF0ZSBi aW5kaW5nIG9mIGVhY2ggU0YgaW5zdGFuY2UgdG8gYSBSU1AgdGhyb3VnaCB0aGUgaG9wLWJ5LWhv cCBzZWxlY3Rpb24gb2YgdGhlIFNGIGluc3RhbmNlcyBieSB0aGUgU0ZGcyBhcyB0aGUgZmlyc3Qg cGFja2V0IGZvciBhIGZsb3cgdHJhdmVyc2VzIHRoZSBjaGFpbi4NCg0KIC0gTG91aXMNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgU3JpbmkgQWRkZXBhbGxpDQpTZW50OiBTdW5kYXksIEZlYnJ1 YXJ5IDAxLCAyMDE1IDEyOjIxIFBNDQpUbzogU3VtYW5kcmEgTWFqZWU7IE5pY29sYXMgQk9VVEhP UlM7IENhdGh5IFpoYW5nOyAnc2ZjQGlldGYub3JnJw0KQ2M6IG5zbXVydGh5QGZyZWVzY2FsZS5j b207IEplcm9tZSBUT0xMRVQ7IFJhamVzaCBLdW1hciBNYWRhYnVzaGk7IEJoYXJhdCBNb3RhDQpT dWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0IChodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCg0KSGkgU3VtYW5kcmEsDQoNCkkg YWdyZWUgd2l0aCB5b3UgdGhhdCBtb3JlIGluZm9ybWF0aW9uIGNhbiBiZSBhZGRlZCB0byB0aGUg cHJvdG9jb2wgZG9jdW1lbnQgb24gc29tZSB1c2UgY2FzZSBzY2VuYXJpb3MgdG8gbWFrZSBpdCBj bGVhciBvbiB0aGUgdXNhZ2Ugb2YgUlNQLUlEIGFuZCBQYXRoLUlELg0KDQpKdXN0IHRvIG1ha2Ug dGhlIHJlYWxpc3RpYyBhbmQgY29tcGxleCBzY2VuYXJpbw0KDQpJbmdyZXNzU0ZGLS0tLS1TRkYx LS0tLS1TRkYyLS0tLS1FZ3Jlc3NTRkYNCg0KSW4gdmlydHVhbCB3b3JsZCwgU0ZGMSBjb3VsZCBi ZSBmcm9udGVuZGluZyBTRngtMSwgU0Z4LTIsIFNGeS0xIGFuZCBTRkYyIGNvdWxkIGJlIGZyb250 IGVuZGluZyBTRngtMywgU0Z5LTIsIFNGei0xIEZvciBzaW1wbGljaXR5LCBhc3N1bWUgdGhhdCBJ bmdyZXNzU0ZGIGlzIGEgZWRnZSByb3V0ZXIgKGVnLiBPcGVuc3RhY2sgTmV0d29yayBOb2RlKSBF Z3Jlc3NTRkYgaXMgYSB2aXJ0dWFsIHN3aXRjaCBob3N0aW5nIHNldCBvZiBXZWIgU2VydmVyIFZN cy4NClNGRjEgYW5kIFNGRjIgYXJlIGFsc28gdmlydHVhbCBzd2l0Y2hlcyBob3N0aW5nIFNGeCwg U0Z5IGFuZCBTRnogU2VydmljZSBWTXMuDQoNCkFzc3VtaW5nIHRoYXQgY2hhaW4gcmVxdWlyZXMg cGFja2V0cyBnbyB0byBTRngsIFNGeSBhbmQgU0Z6LCAgSW5ncmVzc1NGRiAod2l0aCB0aGUgaGVs cCBvZiBTRkYgY29udHJvbGxlcikgbmVlZHMgc2VuZCB0aGUgdHJhZmZpYyB0byBvbmUgb2YgU0Z4 LTEsIFNGeC0yIGFuZCBTRngtMy4gQmFzZWQgb24gU0YteCBzZWxlY3Rpb24sIGluZ3Jlc3MgU0ZG IHNlbmRzIHRoZSB0cmFmZmljIHRvIGNvcnJlc3BvbmRpbmcgU0ZGLiAgSWYgU0Z4LTEgb3IgU0Z4 LTIgaXMgY2hvc2VuLCB0aGVuIHRoZSB0cmFmZmljIGlzIHNlbnQgdG8gU0ZGMS4gIElmIFNGeC0z IGlzIGNob3NlbiwgdGhlbiB0aGUgdHJhZmZpYyBpcyBzZW50IHRvIHRoZSBTRkYyLiBOZXh0IGlu IHRoZSBjaGFpbiwgc2VsZWN0aW9uIG5lZWRzIHRvIGhhcHBlbiBiZXR3ZWVuIFNGeTEgYW5kIFNG eTIuICBTaW1pbGFybHkgZm9yIG5leHQgc2VydmljZSBpbiB0aGUgY2hhaW4sICAgZWl0aGVyIFNG RjEgb3IgU0ZGMiAod2l0aCB0aGUgaGVscCBvZiBjb250cm9sbGVyKSB3aWxsIHNlbmQgdGhlIHRy YWZmaWMgdG8gU0YteS4gSXQgZG9lcyB0aGlzIGJ5IHNlbmRpbmcgdGhlIHRyYWZmaWMgdG8gU0ZG MiB0aGF0IGlzIGhvc3RpbmcgdGhlIFNGLXouIEFuZCBmaW5hbGx5IHRyYWZmaWMgbmVlZHMgdG8g Z28gdG8gRWdyZXNzU0ZGIHRvIGRlbGl2ZXIgdG8gZGVzdGluYXRpb24gd2ViLXNlcnZlciBWTS4N Cg0KRXNzZW50aWFsbHksIGEgZ2l2ZW4gU0ZGIHdvdWxkIG5lZWQgdG8gYmUgcHJvZ3JhbW1lZCB3 aXRoIHRoZSBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIG5leHQgU0YuICBUaGF0IGlzIHdoZXJlIHBh dGggSUQsIFJTUC1JRCBhbmQgT3ZlcmxheSBuZXR3b3JrcyB3b3VsZCBoZWxwIC0gUGF0aCBJRCBp bmRpY2F0aW5nIHRoZSBjaGFpbiBhbmQgUlNQLUlEIGluZGljYXRpbmcgdGhlIFNGIGluc3RhbmNl IEFORCAgVnhMQU4gZGVzdGluYXRpb24gSVAgaW5kaWNhdGluZyB0aGUgbmV4dCBTRkYuIFNGRiBD b250cm9sbGVyIGhhdmluZyB0aGUgbmV0d29yayB3aWRlIHZpc2liaWxpdHkgd291bGQgcHJvZ3Jh bSB0aGUgU0ZGcyBhcHByb3ByaWF0ZWx5Lg0KDQpGb3IgZXhhbXBsZSwgb24gaW5ncmVzc1NGRiwg Zmxvd3MgYXJlIHByb2dyYW1tZWQgd2l0aCBSU1AtSUQgcmVsYXRlZCB0byBTRnggc2VydmljZSBp bnN0YW5jZXMuICBJbmdyZXNzU0ZGLCBhcyBwYXJ0IG9mIHBhY2tldCBwcm9jZXNzaW5nLCBhZGRz IHRoZSBSU1AtSUQsIFBhdGhfSUQgdG8gdGhlIFNDSCBoZWFkZXIgYW5kIGVuY2Fwc3VsYXRlcyBp biBWeExBTi4gIFNGRjEgYW5kL29yIFNGRjIgYXJlIHByb2dyYW1tZWQgd2l0aCBmbG93cyB0aGF0 IG1hdGNoIG9uIFBBVEgtSUQgYW5kIFJTUC1JRCB0byBzZW5kIHRoZSB0cmFmZmljIHRvIHJpZ2h0 IFNGeCBpbnN0YW5jZS4gRXNzZW50aWFsbHksIHByZXZpb3VzIFNGRiBhZGRzIHRoZSBTQ0ggaGVh ZGVyIHJlbGF0ZWQgdG8gbmV4dCBTRiBpbnN0YW5jZXMgYW5kIGhvc3RpbmcgU0ZGIHVzZXMgdGhh dCBpbmZvcm1hdGlvbiB0byByb3V0ZSB0aGUgdHJhZmZpYyB0byByaWdodCBTRiBpbnN0YW5jZS4N Cg0KT24geW91ciBjb25jZXJuIGFib3V0IHBvb3Igc2NhbGFiaWxpdHkgOiAgU0ZGIGNvbnRyb2xs ZXIgbmVlZCBub3QgYmUgYSBzaW5nbGUgZW50aXR5LiAgSXQgY291bGQgYmUgZGlzdHJpYnV0ZWQg YW5kIHNjYWxlLW91dCBlbnRpdHkgZm9yIHBlcmZvcm1hbmNlIHNjYWxpbmcuICAgQWxzbywgY29u dHJvbGxlcnMgbmVlZCBub3QgYmUgaW5mb3JtZWQgb2YgZXZlcnkgZmluZSBncmFudWxhciBmbG93 LiBJdCBjb3VsZCBiZSBiYXNlZCBvbiA0LXR1cGxlIG9yIDMtdHVwbGUgZmxvd3MsIHRoZXJlYnkg cmVkdWNpbmcgdGhlIG51bWJlciBvZiBkZWNpc2lvbnMgbG9naWNhbCBjb250cm9sbGVyIG5lZWQg dG8gbWFrZS4NCg0KSSBkaWQgbm90IHVuZGVyc3RhbmQgIHlvdXIgY29uY2VybiBvbiAiIFRoZSBh bW91bnQgb2Ygc3RhdGUsIHByb2JhYmlsaXR5IG9mIGEgaW5zdGFuY2UgZ29pbmcgZG93biBiZXR3 ZWVuIHNlbGVjdGlvbiBhbmQgZmxvdyBhcnJpdmFsIGdvZXMgdXAuIiAgVGhpcyBzZWVtcyB0byBi ZSBpbXBvcnRhbnQgYW5kIGNhbiB5b3UgZWxhYm9yYXRlPw0KDQoNClRoYW5rcw0KU3JpbmkNCg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFN1bWFuZHJhIE1hamVlDQpTZW50OiBGcmlkYXks IEphbnVhcnkgMzAsIDIwMTUgMjo1MyBQTQ0KVG86IE5pY29sYXMgQk9VVEhPUlM7IENhdGh5IFpo YW5nOyAnc2ZjQGlldGYub3JnJw0KQ2M6IEplcm9tZSBUT0xMRVQNClN1YmplY3Q6IFJlOiBbc2Zj XSBDb21tZW50cyBvbiBTQ0ggRHJhZnQgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC16aGFuZy1zZmMtc2NoLTAyKQ0KDQpIZWxsbywNCg0KVGhpcyBpcyBhbiBpbnRlcmVzdGluZyBk aXNjdXNzaW9uIGFuZCBJIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCB0aGUgbW90aXZhdGlvbiBv ZiBiZXR0ZXIuIFRoZSB0cm91YmxlIHdpdGggYSBwcm90b2NvbCBkb2N1bWVudCBpcyB0aGF0IGl0 IGlzIHR5cGljYWxseSBoYXMgaW5hZGVxdWF0ZSBkZXRhaWwgYWJvdXQgdGhlIGxvZ2ljLiBTbyB0 byBjYXN0IHRoaXMgaW50byBzb21ld2hhdCBvZiBhIGNvbmNyZXRlIHRlcm1zLCBjb25zaWRlciB0 aGUgZm9sbG93aW5nLg0KDQoNCg0KICAgICAgIFNGRih4KSAgeyBTZngoMSkgU2Z4KDIp4oCmU2Z4 KG4pIH0gICDigJTigJTigJTigJQ+ICAgU0ZGKHkpIHsgU2Z5KDEpIFNmeSgyKQ0K4oCmLiBTZnko bSkgfSAgIDo6IExvZ2ljYWwgQ2hhaW4gaW4gT05FIGRpcmVjdGlvbiBvbmx5Lg0KDQogICAgICAg UEhZU0lDQUwgV09STEQ6DQogICAgICAgICAgQSkgdGhlIFNGRiBjb3VsZCBiZSBhDQogICAgICAg ICAgICAtIGNvbXBvbmVudCBvZiBWU1dJVENIIChwaWNrIHlvdXIgZmF2IHByb3RvY29sIGZvciBj b25maWd1cmluZyB0aG9zZSBlbnRpdGllcyB9DQogICAgICAgICAgICAtIEEgbG9hZCBiYWxhbmNl cg0KICAgICAgICAgICAgLSBBIEhXIHN3aXRjaC9yb3V0ZXIgc29tZSBMMi9MMyBjb21ibw0KDQog ICAgICAgICAgQikgU2YgaW5zdGFuY2UgY291bGQgYmUsDQogICAgICAgICAgICAgICAtIFZpcnR1 YWwgbWFjaGluZSwgI04gb2YgdGhvc2UNCiAgICAgICAgICAgICAgIC0gcGh5c2ljYWwNCiAgICAg ICAgICAgICAgIC0gQ29udGFpbmVyICNNIHdoaWNoIGlzIG9mdGVuIDUgb3IgbW9yZSB4ICNODQog ICAgICAgICAgICAgICAtIENsdXN0ZXIgdGhhdCB3ZSBkb27igJl0IGtub3cNCg0KSXQgaXMgcG9z c2libGUgdG8gaGF2ZSBtdWx0aXBsZSBwaHlzaWNhbCBTRkYoeCkgYWxzby4NCg0KQSBzZWxlY3Rp b24gb2YgYSBnaXZlbiBTRiAoc2VydmljZSkoaW5zdGFuY2UpIGlzIGEgY2FuIGJlIHNpbXBsZSBv ciBjb21wbGV4LiBGb3IgZXhhbXBsZSBTRkYoeCkgbWF5IGhhdmUgdGhlIGJlc3Qga25vd2xlZGdl IHRvIHNlbGVjdCBTZngoMSkgYmFlZCBvbiBhIGdpdmVuIGNyaXRlcmlvbiAod2hpY2ggY291bGQg YmUgcGFydCBvZiB0aGUgcG9saWN5KS4gIFRoZW4gSSBkb27igJl0IHNlZSBhIHJlYXNvbiB0byBo YXZlIFJTUC4NCg0KSXQgaXMgcG9zc2libGUgdGhhdCBsb29rdXAgKHBhdGgpIEAgU0ZGKHgpIHBy b2R1Y2VzIGEgc3BlY2lmaWMgaW5zdGFuY2Ugb2YgU2Z5IGFuZCB5ZXMgdGhlbiBzb21ldGhpbmcg bGlrZSBSU1Agd291bGQgYmUgcmVxdWlyZWQuIEJ1dCBJIHdvdWxkIGFyZ3VlIHRoYXQgam9iIFNG Rih5KSBjYW4gYWxzbyBiZSBzdWJzdW1lZCBieSBTRkYoeCkuDQoNCklzIGl0IHBvc3NpYmxlIGZv ciBhIGNlbnRyYWwgY29udHJvbGxlciB0byBwaWNrIGVhY2ggaW5zdGFuY2Ugb2Ygc2VydmljZSwg YnV0IHN1Y2ggYW4gaW1wbGVtZW50YXRpb24gdGVuZHMgdG8gc2NhbGUgcG9vcmx5LiBUaGUgYW1v dW50IG9mIHN0YXRlLCBwcm9iYWJpbGl0eSBvZiBhIGluc3RhbmNlIGdvaW5nIGRvd24gYmV0d2Vl biBzZWxlY3Rpb24gYW5kIGZsb3cgYXJyaXZhbCBnb2VzIHVwLg0KDQpSZWdhcmRzLg0KDQpTdW1h bmRyYQ0KDQoNCg0KT24gMS8zMC8xNSwgMzozOCBBTSwgIk5pY29sYXMgQk9VVEhPUlMiIDxOaWNv bGFzLkJPVVRIT1JTQHFvc21vcy5jb20+DQp3cm90ZToNCg0KPkhlbGxvIENhdGh5LA0KPg0KPklu ZGVlZCB0aGUgbm90aW9uIG9mICJyZW5kZXJlZCBzZXJ2aWNlIHBhdGggSUQiKFJTUCBJRCkgc2Vl bXMgcmVsZXZhbnQNCj5hcyB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IHN0aXB1bGF0ZXMgdGhh dCB0aGUgU2VydmljZSBGdW5jdGlvbiBQYXRoDQo+KFNGUCkgcHJvdmlkZXMgYW4gYWJzdHJhY3Qg bm90aW9uIG9mIGEgc2VydmljZSBjaGFpbiwgd2hpbGUgdGhlIFJTUCBpcw0KPmEgY29uc3RyYWlu ZWQgbGlzdCBvZiBsb2NhdGlvbnMuDQo+DQo+U0ZDIGhlYWRlciAiU2VydmljZSBQYXRoIElkZW50 aWZpZXIiIChTUEkpICBpcyB1c2VkIGluIGJvdGggTlNIIGFuZCBTQ0gNCj5wcm90b2NvbCBhbmQg aW4gYm90aCBjYXNlIHNlZW0gdG8gaWRlbnRpZnkgdG8gYSBwYXJ0aWN1bGFyIFNGUC4NCj4NCj5O U0godjUpIGZvciBleGFtcGxlIHN0YXRlcyB0aGF0DQo+IiBBcyBkZXNjcmliZWQgYWJvdmUsIE5T SCBjb250YWlucyBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIChTUEkpIGFuZA0KPiAgIGEgc2Vy dmljZSBpbmRleCAoU0kpLiAgVGhlIFNQSSBpcywgYXMgcGVyIGl0cyBuYW1lLCBhbiBpZGVudGlm aWVyLg0KPiAgIFRoZSBTUEkgYWxvbmUgY2Fubm90IGJlIHVzZWQgdG8gZm9yd2FyZCBwYWNrZXRz IGFsb25nIGEgc2VydmljZSBwYXRoLg0KPiAgIFJhdGhlciB0aGUgU1BJIHByb3ZpZGUgYSBsZXZl bCBvZiBpbmRpcmVjdGlvbiBiZXR3ZWVuIHRoZSBzZXJ2aWNlDQo+ICAgcGF0aC90b3BvbG9neSBh bmQgdGhlIHRoZSBuZXR3b3JrIHRyYW5zcG9ydC4gIEZ1cnRoZXJtb3JlLCB0aGVyZSBpcw0KPiAg IG5vIHJlcXVpcmVtZW50LCBvciBleHBlY3RhdGlvbiBvZiBhbiBTUEkgYmVpbmcgYm91bmQgdG8g YSBwcmUtDQo+ICAgZGV0ZXJtaW5lZCBvciBzdGF0aWMgbmV0d29yayBwYXRoLiINCj4NCj5TdGls bCBOU0godjUpICBzaG93cyB0aGF0IFNQSSAobm90IGEgUlNQIElEKSAgc2hvdWxkIGJlIHBhcnQg b2YgdGhlIGtleQ0KPmVsZW1lbnQgb2YgYW4gU0ZGIHRvIGxvb2t1cCBvbiBmb3J3YXJkaW5nIHRh Ymxlcy4gIEJ1dCBJIGNvdWxkIG5vdCBmaW5kDQo+aW4gTlNIICBob3cgdG8gdXNlIHRoZSBub3Rp b24gb2YgUmVuZGVyZWQgc2VydmljZSBwYXRoIHdoaWNoIHdhcw0KPmRlZmluZWQgaW4gdGhlIGFy Y2hpdGVjdHVyZSBkb2N1bWVudC4NCj4NCj5Zb3UgcHJvcG9zYWwgc2VlbXMgdG8gbWUgdmVyeSB1 c2VmdWwsDQo+DQo+QW4gUlNQIElEIChpbmRlcGVuZGVudCBvZiB0aGUgU1BJIGJ1dCBwYXJ0IG9m IHRoZSBzYW1lIG5hbWUgc3BhY2UpDQo+Y291bGQgYmUgdXNlZCB0aGUgc2FtZSB3YXkgYXMgU1BJ IGJ5IFNGRiBmb3IgZXhhbXBsZSwgYWxsb3dpbmcgYQ0KPlNlcnZpY2UgQ2xhc3NpZmllciB0byBj b250cm9sIHJlbW90ZSBsb2FkIGJhbGFuY2luZyBmb3IgZXhhbXBsZS4NCj4NCj5UaGlzIHNhaWQg dGhlIFJTUCBJRCB2YWx1ZXMgY291bGQgYmUgcmVsYXRpdmUgdG8gYSBwYXJ0aWN1bGFyIFNlcnZp Y2UNCj5QYXRoLCB3aGljaCB3b3VsZCBwcmV2ZW50IHVzaW5nIHRoZW0gYXMgd2UgZG8gZm9yIFNQ SSBpbiBTRkYgZm9yd2FyZGluZw0KPnRhYmxlcy4NCj4NCj5XZSBtYXkgd2FudCB0byBwcmVjaXNl IGlmIHRoZSBSU1AgSUQgaXMgdG8gYmUgcmVsYXRpdmUgb2YgYWJzb2x1dGUsIGFzDQo+aXQgc2hv dWxkIGhhdmUgYW4gaW1wYWN0IG9uIGZvcndhcmRpbmcgdGFibGUgc3RydWN0dXJlIGlmIHdlIGRl Y2lkZSB0bw0KPnVzZSB0aGlzIGNvbmNlcHQuDQo+DQo+UGVyc29uYWxseSBJIGxpa2UgdGhlIG5v dGlvbiBvZiBhIHJlbGF0aXZlIFJTUCBJRCwgYXMgd2UgY291bGQgdGhlbiB1c2UNCj5zb21lIGNv bnZlbnRpb25zLCBzdHJ1Y3R1cmUgaXQsIHBvc3NpYmx5IGV4dGVuZGluZyBpdHMgdXNlLg0KPg0K Pk5pY29sYXMNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IENhdGh5IFpo YW5nIFttYWlsdG86Q2F0aHkuSC5aaGFuZ0BodWF3ZWkuY29tXQ0KPlNlbnQ6IGpldWRpIDI5IGph bnZpZXIgMjAxNSAyMDo0NA0KPlRvOiBDYXRoeSBaaGFuZzsgU3JpbmkgQWRkZXBhbGxpOyBSZWlu YWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4NCj5IYWxwZXJuOyAnc2ZjQGlldGYub3JnJw0K PkNjOiBuc211cnRoeUBmcmVlc2NhbGUuY29tDQo+U3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRz IG9uIFNDSCBEcmFmdA0KPihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmct c2ZjLXNjaC0wMikNCj4NCj5IaSBldmVyeW9uZSwNCj4NCj5XZSBoYXZlIHVwbG9hZGVkIGEgbmV3 IFNDSCB2ZXJzaW9uICgzKSB3aGljaCBhZGRzIGRlZmluaXRpb24gb2YgYSBuZXcNCj5tZXRhZGF0 YSB0eXBlIGZvciB0aGUgZmxvdyBJRCB0byBzdXBwb3J0IGxvYWQgYmFsYW5jaW5nIGFtb25nIFNG DQo+aW5zdGFuY2VzIGFuZCBtaXRpZ2F0ZSB0aGUgcG90ZW50aWFsIGlzc3VlIG9mICJub3QgZW5v dWdoIHBhdGggSUQiLiBUaGUNCj5mbG93IElEIGlzIG5hbWVkICJyZW5kZXJlZCBzZXJ2aWNlIHBh dGggSUQiIGluIHRoZSBkcmFmdC4gUGxlYXNlIHJlZmVyDQo+dG8gc2VjdGlvbiA0LjMuMiBvZg0K Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLXNmYy1zY2gvDQo+ Zm9yIGRldGFpbCBkZXNjcmlwdGlvbi4NCj4NCj5JbiBpdHMgcHJldmlvdXMgdmVyc2lvbiwgU0NI IGRlZmluZXMgYSAiQnlwYXNzIGJpdCIgaW4gdGhlIGJhc2UgaGVhZGVyLg0KPlRoaXMgYml0IGVu YWJsZXMgdGhlIFNGIHRvIHByb3ZpZGUgZmVlZGJhY2svbm90aWZpY2F0aW9uIHZpYSB0aGUgZGF0 YQ0KPnBhdGggdG8gaXRzIGNvbm5lY3RpbmcgU0ZGIGFib3V0IHdoZXRoZXIgdGhlIHJlbWFpbmlu ZyBwYWNrZXRzIG9mIHRoZQ0KPlNGQyBzaG91bGQgYnlwYXNzIHRoYXQgU0YuIFRoaXMgaXMgdXNl ZnVsIGluIHRoZSBjYXNlIHRoYXQgb25seSB0aGUNCj5maXJzdCBmZXcgcGFja2V0cyBvZiBhIGZs b3cgbmVlZCB0byBnbyB0byBhIFNGIChzdWNoIGFzIGEgRFBJIG9yIEZXIG9yDQo+SURTKSBhbmQg cmVtYWluaW5nIHBhY2tldHMgY2FuIGJ5cGFzcyB0aGF0IFNGLCB0aHVzIHNhdmluZyB0aGUNCj5l eHBlbnNpdmUgU0YgcmVzb3VyY2UgYW5kIHJlZHVjaW5nIGRhdGEgcGF0aCBsYXRlbmN5Lg0KPg0K PkIgYml0OiBUaGUgQiAoQnlwYXNzKSBiaXQsIHdoZW4gc2V0IHRvIDEsIGl0IGlzIHVzZWQgYnkg YSBTZXJ2aWNlDQo+ICAgICAgIEZ1bmN0aW9uIHRvIHNpZ25hbCB0byBpdHMgU2VydmljZSBGdW5j dGlvbiBGb3J3YXJkZXIgdGhhdCBubw0KPiAgICAgICBmdXJ0aGVyIHBhY2tldHMgYXJlIHRvIGJl IHNlbnQgdG8gaXQgZm9yIHRoZSBmbG93IHNwZWNpZmllZCBpbg0KPmVuY2Fwc3VsYXRlZCBwYWNr ZXQuDQo+DQo+SW4gYWRkaXRpb24sIFNDSCBkZWZpbmVzIGEgbWV0YWRhdGEgdHlwZSBmb3IgR2Vu ZXJpYyBDb250ZXh0IEJsb2NrLA0KPndoaWNoIGlzIG9wdGlvbmFsIGFuZCBjYW4gYmUgdXNlZCBp ZiBuZWVkZWQgdG8gY2FycnkgYW55IHZlbmRvcidzDQo+c3BlY2lmaWMgIkNvbnRleHQgSGVhZGVy Ii4NCj4NCj5BbnkgY29tbWVudHMgb24gdGhlc2UgbmV3IGFkZGl0aW9ucz8NCj4NCj5UaGFua3Ms DQo+Q2F0aHkNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHNmYyBbbWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2F0aHkgWmhhbmcNCj5TZW50 OiBGcmlkYXksIERlY2VtYmVyIDA1LCAyMDE0IDExOjQ3IEFNDQo+VG86IFNyaW5pIEFkZGVwYWxs aTsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBKb2VsIE0uIEhhbHBlcm47DQo+J3NmY0BpZXRm Lm9yZycNCj5DYzogbnNtdXJ0aHlAZnJlZXNjYWxlLmNvbQ0KPlN1YmplY3Q6IFJlOiBbc2ZjXSBD b21tZW50cyBvbiBTQ0ggRHJhZnQNCj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXpoYW5nLXNmYy1zY2gtMDIpDQo+DQo+Um9uLCBMb3VpcywgTXlvIGFuZCBJIGhhdmUgYmVlbiBk aXNjdXNzaW5nIG9mZiBsaW5lIGxhc3QgZmV3IHdlZWtzDQo+YWJvdXQgZGVmaW5pbmcgYSBtZXRh ZGF0YSB0eXBlIGZvciBmbG93IElEIGluIGFkZGl0aW9uIHRvIHRoZSBwYXRoIElEDQo+b2YgdGhl IG1haW4gaGVhZGVyIHRvIHN1cHBvcnQgbG9hZCBiYWxhbmNpbmcgYW1vbmcgU0YgaW5zdGFuY2Vz LiBXZQ0KPndpbGwgZGVmaW5lIGEgVExWIHR5cGUgZm9yIHRoZSBmbG93IElELiBUaGUgY29tYmlu YXRpb24gb2YgInBhdGggSUQgKyBmbG93IElEIg0KPnNwZWNpZmllcyBhIHJlYWxpemVkIHNlcnZp Y2UgY2hhaW4gaW5zdGFuY2UgcGF0aC4gSXQgaXMgbGVmdCB0byB0aGUNCj5kZXNpZ24vaW1wbGVt ZW50YXRpb24gd2hldGhlciB0byB1c2UgYSBjZW50cmFsaXplZCBtZXRob2Qgb3IgYQ0KPmRpc3Ry aWJ1dGVkIG1ldGhvZCB0byBiaW5kIHRoZSBmbG93IElEIHRvIGEgcmVhbGl6ZWQgc2VydmljZSBp bnN0YW5jZQ0KPnBhdGggYWx0aG91Z2ggb3VyIG9yaWdpbmFsIHRob3VnaHQgaXMgZm9yIGRpc3Ry aWJ1dGVkIExCIHVzYWdlLiBJIGFtDQo+bm90IHN1cmUgaWYgd2UgbmVlZCBhIGJpdCBpbiB0aGUg aGVhZGVyIHRvIGRlbm90ZSB3aGV0aGVyIHRoZXJlIGFyZQ0KPm1vcmUgcGF0aCBJRCBiaXRzICh3 ZSBjYWxsIGl0IGZsb3cgSUQpIGluIHRoZSBtZXRhZGF0YSBmaWVsZHMgc2luY2UNCj53aGVuIHlv dSBwYXJzZSB0aGUgVExWIG1ldGFkYXRhLCB5b3Ugd2lsbCBrbm93IHdoZXRoZXIgdGhlcmUgYXJl IGZsb3cgSUQgYml0cyBvciBub3QuDQo+Tm90ZSB0aGF0IGlmIG11bHRpcGxlIHNlc3Npb25zIHNo YXJlIHRoZSBzYW1lIHJlYWxpemVkIHNlcnZpY2UgaW5zdGFuY2UNCj5wYXRoLCB0aGV5IHdpbGwg c2hhcmUgdGhlIHNhbWUgInBhdGggSUQrIGZsb3cgSUQiLiAgV2UgY2FuIGFsc28NCj5jb25zaWRl ciBleHRlbmRpbmcgdGhlIG51bWJlciBvZiBiaXRzIHRvIDMyIGlmIHRoYXQgaXMgdGhlIGNvbnNl bnN1cy4NCj5XZSB3aWxsIHBvc3QgYW4gdXBkYXRlZCBkcmFmdCBkZXNjcmliaW5nIHRoZXNlIHNv b24uDQo+DQo+VGhhbmtzLA0KPkNhdGh5DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj5Gcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNy aW5pIEFkZGVwYWxsaQ0KPlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDUsIDIwMTQgNzoxNyBBTQ0K PlRvOiBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4gSGFscGVybjsgJ3NmY0BpZXRm Lm9yZycNCj5DYzogbnNtdXJ0aHlAZnJlZXNjYWxlLmNvbQ0KPlN1YmplY3Q6IFJlOiBbc2ZjXSBD b21tZW50cyBvbiBTQ0ggRHJhZnQNCj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXpoYW5nLXNmYy1zY2gtMDIpDQo+DQo+DQo+W1JQXSBEYXRhIHBsYW5lIGVmZmljaWVuY3kuDQo+ DQo+U1JJTkk+IEkgYW0gbm90IHNvIHN1cmUgYWJvdXQgZGF0YSBwbGFuZSBlZmZpY2llbmN5LiAg TW9zdCBvZiB0aGUNCj5wcm9jZXNzb3JzIHdvcmsgZ29vZCBpZiB0aGUgbnVtYmVyIG9mIGJpdHMg YXJlIGVpdGhlciAzMiBvciA2NC4gIElmIGl0DQo+aXMNCj4yNCBiaXRzLCB0aGVuIG9uZSBuZWVk cyB0byBkbyBtYXNraW5nIGFuZCBzaGlmdGluZyBiZWZvcmUgdGhlIHZhbHVlIGlzDQo+dXNlZCB0 byBkbyBhbnkgbG9va3VwLiAgIEJ1dCwgdGhpcyBkaXNjdXNzaW9uIGNhbiBnbyBpbnRvIGRpZmZl cmVudA0KPmRpcmVjdGlvbiA6LSksIGl0IG1heSBub3QgYmUgZ29vZCB0byBnbyBpbiB0aGF0IGRp cmVjdGlvbi4NCj4NCj5XaGVyZSBkbyB3ZSBkcmF3IHRoZSBsaW5lPyAzMi1iaXRzLCA2NC1iaXRz LA0KPjEyOCBiaXRzPyBJIHRoaW5rIHdlIHNob3VsZCBoYXZlIGEgc2Vuc2libGUgdmFsdWUgaW4g dGhlIFNlcnZpY2UgUGF0aA0KPmhlYWRlciBhbmQgaWYgeW91IG5lZWQgdG8gY29udmV5IG1vcmUg Yml0cyB5b3UgbmVlZCB0byB1c2UgdGhlIGNvbnRleHQNCj5oZWFkZXJzLg0KPg0KPlNSSU5JPiBU aGlzIGlzIGEgZ29vZCBwb2ludC4gIFRoaXMgc2hvdWxkIHdvcmsgZmluZSBhcyBsb25nIGFzIHRo ZXJlIGlzDQo+d2F5IHRvIGNvbnZleSBpbiB0aGUgbWFpbiBoZWFkZXIgdGhhdCB0aGUgZXh0ZW5z aW9uIHRvIHBhdGggSUQgaXMNCj5hdmFpbGFibGUgaW4gc28gYW5kIHNvIFRMViBmaWVsZC4gIFRo YXQgc2hvdWxkIHdvcmsgdG9vLg0KPg0KPlRoYW5rcw0KPlNyaW5pDQo+DQo+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPkZyb206IFJlaW5hbGRvIFBlbm5vIChyZXBl bm5vKSA8cmVwZW5ub0BjaXNjby5jb20+DQo+U2VudDogRnJpZGF5LCBEZWNlbWJlciA1LCAyMDE0 IDc6MDggQU0NCj5UbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2MDsgSm9lbCBNLiBIYWxwZXJuOyAn c2ZjQGlldGYub3JnJw0KPkNjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPlN1YmplY3Q6 IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4oaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+DQo+T24gMTIvNS8xNCwgNjo1NCBBTSwg IlNyaW5pIEFkZGVwYWxsaSIgPHNhZGRlcGFsbGlAZnJlZXNjYWxlLmNvbT4gd3JvdGU6DQo+DQo+ Pg0KPj5JbiByZWFsIGRlcGxveW1lbnRzLCBudW1iZXIgb2YgYWN0aXZlIHBhdGggSURzIGFyZSB2 ZXJ5IGxlc3NlciB0aGFuDQo+PjJeNjQsIGJ1dCB0aGVyZSBpcyBhIGdvb2QgcG9zc2liaWxpdHkg b2YgdGhlIG51bWJlciBiZWluZyBtb3JlIHRoYW4NCj4+Ml4yNCAoMTZNKS4NCj4+IEkgdGhpbmsg YmlnZ2VyIHBvaW50IGlzIHRoYXQgd2h5IHJlc3RyaWN0IHRoaXMgaW4gdGhlIHN0YW5kYXJkcz8g V2hhdA0KPj5hZHZhbnRhZ2UgZG8gd2UgaGF2ZSByZXN0cmljdGluZyB0aGlzIHNpemUgdG8gMjQg Yml0cz8NCj4NCj5bUlBdIERhdGEgcGxhbmUgZWZmaWNpZW5jeS4gV2hlcmUgZG8gd2UgZHJhdyB0 aGUgbGluZT8gMzItYml0cywNCj42NC1iaXRzLA0KPjEyOCBiaXRzPyBJIHRoaW5rIHdlIHNob3Vs ZCBoYXZlIGEgc2Vuc2libGUgdmFsdWUgaW4gdGhlIFNlcnZpY2UgUGF0aA0KPmhlYWRlciBhbmQg aWYgeW91IG5lZWQgdG8gY29udmV5IG1vcmUgYml0cyB5b3UgbmVlZCB0byB1c2UgdGhlIGNvbnRl eHQNCj5oZWFkZXJzLg0KPg0KPg0KPj4NCj4+VGhlcmUgY2FuIGJlIGRlcGxveW1lbnRzLCB3aGVy ZSBTRkMgY29udHJvbGxlciAoTG9naWNhbGx5IGNlbnRyYWwsIGJ1dA0KPj5kaXN0cmlidXRlZCkg IGl0c2VsZiBjYW4gZG8gdGhlIFNGIGluc3RhbmNlIHNlbGVjdGlvbiBvbiBwZXINCj4+Y29ubmVj dGlvbi9zZXNzaW9uIGJhc2lzLCB0aGVyZWJ5IGF2b2lkaW5nIHRoZSBMQnMgZm9yIHNlcnZpY2Vz LiAgIEluIG15DQo+PnZpZXcsIGFzc3VtcHRpb24gdGhhdCB0aGVyZSB3aWxsIGJlIExCIFNGIGZv ciBlYWNoIHNjYWxlLW91dCBzZXJ2aWNlDQo+PmluIHRoZSBjaGFpbiBpcyBub3QgdmFsaWQgaW4g YWxsIGNhc2VzLg0KPj4NCj4+VGhhbmtzDQo+PlNyaW5pDQo+Pg0KPj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PkZyb206IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5v KSA8cmVwZW5ub0BjaXNjby5jb20+DQo+PlNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciA0LCAyMDE0 IDE6MTcgUE0NCj4+VG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IEpvZWwgTS4gSGFscGVybjsg c2ZjQGlldGYub3JnDQo+PkNjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPj5TdWJqZWN0 OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+PihodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4+DQo+PklmIEkgdW5kZXJzdG9vZCB5 b3UsIEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgcmVhbGlzdGljLiBBcmUgeW91IHNheWluZw0KPj55 b3UgbmVlZCA2NC1iaXRzIG9mIHBhdGhzIGFuZCB0aGVuIHdpbGwgbW9uaXRvciB0aGVtIGFsbD8g RG8gZmF1bHQNCj4+dG9sZXJhbmNlIGFuZCBPQU0gZm9yIDJeNjQtYml0cyB3b3J0aCBvZiBwYXRo cz8gSnVzdCBmb3IgY29tcGFyaXNvbiwNCj4+aXTCuXMgbGlrZSBtYW5hZ2luZyBhbmQgbW9uaXRv cmluZyB0aGUgZW50aXJlIElQdjYgaG9zdCByYW5nZSwgb25lLWJ5LW9uZS4NCj4+DQo+PkFueXdh eSwgSSBkbyBub3QgZXhwZWN0IGV2ZXJ5IHNpbmdsZSBwZXJtdXRhdGlvbnMgdG8gYmUgYSBkaWZm ZXJlbnQgcGF0aC4NCj4+DQo+PklmIGVhY2ggc2VydmljZSBoYXMgMjU2IGRldmljZXMgcHJvdmlk aW5nIHNpbWlsYXIgc2VydmljZSwgeW91IHNob3VsZA0KPj5tb3N0IGxpa2VseSB1c2UgbG9hZC1i YWxhbmNpbmcgYW5kIHRoZW4geW91IHdvdWxkIGhhdmUgYSBzaW5nbGUgKG9yIGENCj4+ZmV3KSBw YXRocy4gVGhlcmUgaXMgc29tZSBkaXNjdXNzaW9uIGdvaW5nIG9uIExCLg0KPj4NCj4+RnJvbSBh IGRhdGEgcGxhbmUgcGVyc3BlY3RpdmUsIHRoZSBwYXRoIGlzIHVsdGltYXRlbHkgZGVmaW5lZCBi eSB0aGUNCj4+U0ZGcyB0cmF2ZXJzZWQgYW5kIHNlcnZpY2VzIHByb3ZpZGVkLCBub3QgYnkgYSBz cGVjaWZpYyBJUDpwb3J0IHRoYXQNCj4+dGhlIGRldmljZSBwcm92aWRpbmcgdGhlIHNlcnZpY2Ug c2l0cyBvbi4gV2VsbCwgYXQgbGVhc3QgZnJvbSBhDQo+PkdQRStOU0ggcGVyc3BlY3RpdmUuDQo+ Pg0KPj4NCj4+T24gMTIvNC8xNCwgMTI6NTcgUE0sICJTcmluaSBBZGRlcGFsbGkiIDxzYWRkZXBh bGxpQGZyZWVzY2FsZS5jb20+IHdyb3RlOg0KPj4NCj4+PklmIEkgdGFrZSBhIGNoYWluIHdpdGgg NSBzZXJ2aWNlcyB3aXRoIGVhY2ggc2VydmljZSAgc2F5IGhhdmluZyAyNTYNCj4+Pmluc3RhbmNl cyBmb3Igc2NhbGUtb3V0LCBwb3NzaWJsZSBudW1iZXIgb2YgcGF0aHMgYXJlDQo+Pj4yNTYqMjU2 KjI1NioyNTYqMjU2ID0gMHhGRiBGRiBGRiBGRiBGRi4gT25lIHJlcXVpcmVzIDMzIGJpdHMgaW4g dGhpcw0KPj4+Y2FzZS4gIElmIHRoZXJlIGFyZSBtb3JlIHNlcnZpY2VzIGluIHRoZSBjaGFpbiBv ciBtb3JlIGNoYWlucyBvciBtb3JlDQo+Pj5pbnN0YW5jZXMgZm9yIHNjYWxlLW91dCwgdGhlbiBp dCBjb3VsZCBnbyB0byBiaWcgbnVtYmVyIHZlcnkgZmFzdC4NCj4+Pg0KPj4+QXMgSSBtZW50aW9u ZWQgbXkgcHJlZmVyZW5jZSBpcyB0byBtYWtlIHRoZSBwYXRoIElEIHNpemUgZmxleGlibGUgZm9y DQo+Pj5mdXR1cmUgZ3Jvd3RoLiBJZiB0aGF0IGlzIHBlcmNlaXZlZCBhcyBjb21wbGV4LCB0aGVu IGdvaW5nIGZvciA2NGJpdA0KPj4+aXMgc2FmZXIgYmV0Lg0KPj4+DQo+Pj5UaGFua3MNCj4+PlNy aW5pDQo+Pj4NCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IEpv ZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+Pj5TZW50OiBUaHVy c2RheSwgRGVjZW1iZXIgMDQsIDIwMTQgMTI6MDUgUE0NCj4+PlRvOiBBZGRlcGFsbGkgU3Jpbmkt QjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47IHNmY0BpZXRmLm9yZw0KPj4+Q2M6IE5TIFNyaW5pdmFz YSBNdXJ0aHktQjM3ODQwDQo+Pj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERy YWZ0DQo+Pj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gt MDIpDQo+Pj4NCj4+PkEgY29udHJvbGxlciAob3Igb3RoZXIgZGVjaXNpb24gbG9naWMpIGNhbiBj ZXJ0YWlubHkgYmUgYXdhcmUgb2Ygc3VjaA0KPj4+Y29uY2VybnMuDQo+Pj5CdXQgdGhlIG51bWJl ciBvZiBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzIGlzIG5vdCByZWxhdGVkIHRvIHRoZSBudW1iZXIN Cj4+Pm9mIGZsb3dzIG9yIHRoZSBudW1iZXIgb2YgdGVuYW50cy4gIEl0IGlzIHJlbGF0ZWQgdG8g dGhlIG51bWJlciBvZg0KPj4+Y29tYmluYXRpb25zIG9mIHNlcnZpY2VzIGFuZCB0aGUgcG9saWNp ZXMgZm9yIHNlcnZpY2UgZnVuY3Rpb24NCj4+PnNlbGVjdGlvbi4NCj4+PiBXaGlsZSB0aGF0IGNh biBiZSBhIGxhcmdlIG51bWJlciwgSSBzdXJlIGhvcGUgaXQgZG9lcyBub3QgY29tZSBjbG9zZQ0K Pj4+dG8gc2F0dXJhdGluZyAyNCBiaXRzLg0KPj4+DQo+Pj5IYXZpbmcgc2FpZCB0aGF0LCBpZiB3 ZSB0aGluayB0aGF0IDI0IGJpdHMgaXMgb25seSBqdXN0IGVub3VnaCwgdGhlbg0KPj4+d2Ugb3Vn aHQgdG8gdXNlIDMyLiAgRnJvbSB3aGVyZSBJIHNpdCwgSSB3b3VsZCBub3JtYWxseSBleHBlY3Qg MTYNCj4+PmJpdHMgdG8gYmUgbW9yZSB0aGFuIHN1ZmZpY2llbnQsIHdoaWNoIGlzIHdoeSBJIGFt IGNvbWZvcnRhYmxlIHdpdGggMjQuDQo+Pj5IYXZpbmcgc2FpZCB0aGF0LCB0aGUgZmllbGQgc2l6 ZSBpcyBub3QgYSBiaWcgZGVhbCB0byBtZS4NCj4+Pg0KPj4+WW91cnMsDQo+Pj5Kb2VsDQo+Pj4N Cj4+Pk9uIDEyLzQvMTQsIDI6MDEgUE0sIFNyaW5pIEFkZGVwYWxsaSB3cm90ZToNCj4+Pj4NCj4+ Pj4gSSB3YXMgbm90IGltcGx5aW5nIHRoYXQgcGF0aCBJRCBzaG91bGQgaGF2ZSBpbmZvcm1hdGlv biBpbiByZWdhcmRzDQo+Pj4+dG8gdGVuYW50L2NvbnRyb2xsZXIvZmxvdy9zY2FsZS1vdXQuICBC dXQgU0ZDIGNvbnRyb2xsZXJzIHNob3VsZA0KPj4+PmtlZXAgdGhlc2UNCj4+Pj5pbiBtaW5kIHRv IGFzc2lnbiB0aGUgcGF0aCBJRC4gICAgQSBkZXBsb3ltZW50IGNhbiBoYXZlIG11bHRpcGxlDQo+ Pj4+dGVuYW50cywgZWFjaCB0ZW5hbnQgY2FuIGhhdmUgbXVsdGlwbGUgbmV0d29ya3MsICB0aGVy ZSBjb3VsZCBiZQ0KPj4+Pm1pbGxpb25zIG9mIGZsb3dzIGluIGVhY2ggb2YgdGhvc2UgbmV0d29y a3MuICBBbmQgY29uc2lkZXJpbmcgYWxsDQo+Pj4+dGhlc2UsDQo+Pj4+IDI0IGJpdCBwYXRoIElE IG1heSBub3QgYmUgYWJsZSB0byByZXByZXNlbnQgcGF0aHMgZm9yIHRoZXNlIGZsb3dzLg0KPj4+ PkhlbmNlLCBJIHdhcyB3b25kZXJpbmcgd2hldGhlciBwYXRoIElEIGNhbiBiZSBleHRlbmRlZCB0 byA2NCBiaXRzIG9yDQo+Pj4+bWFrZSBpdCBmbGV4aWJsZS4NCj4+Pj4NCj4+Pj4gVGhhbmtzDQo+ Pj4+IFNyaW5pDQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0K Pj4+PiBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgNCwgMjAxNCA3OjQyIEFNDQo+Pj4+IFRvOiBB ZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBzZmNAaWV0Zi5vcmcNCj4+Pj4gQ2M6IE5TIFNyaW5pdmFz YSBNdXJ0aHktQjM3ODQwDQo+Pj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0gg RHJhZnQNCj4+Pj4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMt c2NoLTAyKQ0KPj4+Pg0KPj4+PiBUaGUgSW5kZXggaXMgbm90IGp1c3QgZm9yIGxvb3AgcHJldmVu dGlvbi4gIEluIHRoZSBjYXNlIG9mDQo+Pj4+YW1iaWd1aXR5LCB0aGUgaW5kZXggdGVsbHMgdGhl IFNGRiB3aGVyZSBpbiB0aGUgcGF0aCB0aGUgcGFja2V0DQo+Pj4+Y3VycmVudGx5IHJlc2lkZXMu DQo+Pj4+ICAgIFRoZXJlIGFyZSBtdWx0aXBsZSB3YXlzIHN1Y2ggYW1iaWd1aXR5IGNhbiBvY2N1 ci4NCj4+Pj4NCj4+Pj4gVGhlIFBhdGggSWRlbnRpZmllciBpcyBzcGVjaWZpY2FsbHkgbm90IGV4 cGVjdGVkIHRvIGluY2x1ZGUNCj4+Pj4gY29udHJvbGxlciBJRCBvciBUZW5hbnQgSUQuICBXaGls ZSBhIGRlcGxveWVyIGNhbiBoYXZlIGEgcGF0aCBwZXINCj4+Pj4gdGVuYW50LCB0aGUgYXJjaGl0 ZWN0dXJlIHN0aWxsIGRvZXMgbm90IHRyZWF0IHRoZSBwYXRoIElEIGFzIGENCj4+Pj4gdGVuYW50 IElELiAgVGVuYW50IElELCBjb250cm9sbGVyIElELCBhbmQgb3RoZXIgbm9uLXBhdGgtc3BlY2lm eWluZw0KPj4+PiBpbmZvcm1hdGlvbiBpcyB0byBiZSBjYXJyaWVkIGluIG1ldGFkYXRhLg0KPj4+ Pg0KPj4+PiBZb3VycywNCj4+Pj4gSm9lbA0KPj4+Pg0KPj4+PiBPbiAxMi80LzE0LCAxMDowMiBB TSwgU3JpbmkgQWRkZXBhbGxpIHdyb3RlOg0KPj4+Pj4gVHdvIGNvbW1lbnRzIDoNCj4+Pj4+DQo+ Pj4+Pg0KPj4+Pj4gMS4gIFNGIEluZGV4IDogIFNpbmNlIGl0IGlzIG1lYW50IGZvciBsb29wIGRl dGVjdGlvbiwgIHdvdWxkbid0DQo+Pj4+PiBiZXR0ZXIgdG8gcmVuYW1lIHRoaXMgYXMgIlRUTCI/ DQo+Pj4+Pg0KPj4+Pj4gMi4gIFBhdGggSWRlbnRpZmllciA6ICAgIDI0IGJpdCBwYXRoIGlkZW50 aWZpZXIgc2VlbXMgdG8gYmUgdG9vIGxlc3MuDQo+Pj4+PiBCYXNlZCBvbiBvdXIgZXhwZXJpZW5j ZSBpbiB0cmFmZmljIHN0ZWVyaW5nLCAgdGhpcyBwYXRoIGlkZW50aWZpZXINCj4+Pj4+bmVlZHMg dG8gZW5jb2RlIGdvb2QgYW1vdW50IG9mIGluZm9ybWF0aW9uIHRvIG1ha2UgaXQgdW5pcXVlLiAg Rm9yDQo+Pj4+PmV4YW1wbGUsDQo+Pj4+PiAgICB0aGlzIGlkZW50aWZpZXIgbmVlZHMgdG8gZW5j b2RlIChpbiBvdXIgY2FzZSkgc29tZSBpbmZvcm1hdGlvbg0KPj4+Pj5yZXByZXNlbnRpbmcgdGhl IGRpc3RyaWJ1dGVkIGNvbnRyb2xsZXIgSUQsICB0ZW5hbnQgSUQsICBmbG93IElELA0KPj4+Pj4g ICAgU2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZSAoaW4gY2FzZSBvZiBzY2FsZS1vdXQpIGFuZCBm ZXcgbW9yZS4uDQo+Pj4+PiBPbmUgc3VnZ2VzdGlvbiBpcyB0byBtYWtlIGl0IDY0IGJpdHMgdmFs dWUgIG9yIHRvIG1ha2UgaXQgZXZlbg0KPj4+Pj5leHRlbmRhYmxlLA0KPj4+Pj4gICAgaXQgaXMg Z29vZCBpZiBwYXRoIGlkZW50aWZpZXIgaXMgYWxzbyByZXByZXNlbnRlZCBpbiBUTFYgZm9ybS4N Cj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gVGhhbmtzDQo+Pj4+Pg0KPj4+Pj4gU3JpbmkNCj4+Pj4+DQo+ Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4gc2ZjQGlldGYu b3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+ Pj4NCj4+Pg0KPj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+PnNmYyBtYWlsaW5nIGxpc3QNCj4+PnNmY0BpZXRmLm9yZw0KPj4+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+DQo+DQo+DQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zZmMgbWFpbGluZyBsaXN0DQo+c2Zj QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4N Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBt YWlsaW5nIGxpc3QNCj5zZmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KPg0KPg0KPlRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzICh0 aGUgIm1lc3NhZ2UiKSBhcmUgY29uZmlkZW50aWFsLA0KPmludGVuZGVkIHNvbGVseSBmb3IgdGhl IGFkZHJlc3NlZXMuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0KPnJlY2lwaWVudCwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlDQo+ dGhpcyBtZXNzYWdlIGZyb20geW91ciBzeXN0ZW0uIEluIHRoaXMgY2FzZSwgeW91IGFyZSBub3Qg YXV0aG9yaXplZCB0bw0KPnVzZSwgY29weSB0aGlzIG1lc3NhZ2UgYW5kL29yIGRpc2Nsb3NlIHRo ZSBjb250ZW50IHRvIGFueSBvdGhlciBwZXJzb24uDQo+RS1tYWlscyBhcmUgc3VzY2VwdGlibGUg dG8gYWx0ZXJhdGlvbi4gTmVpdGhlciBRb3Ntb3Mgbm9yIGFueSBvZiBpdHMNCj5zdWJzaWRpYXJp ZXMgb3IgYWZmaWxpYXRlcyBzaGFsbCBiZSBsaWFibGUgZm9yIHRoZSBtZXNzYWdlIGlmIGFsdGVy ZWQsDQo+Y2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+DQo+Q2UgbWVzc2FnZSBldCB0b3V0ZXMgc2Vz IHBpw6hjZXMgam9pbnRlcyAoY2ktYXByw6hzIGxlICJtZXNzYWdlIilzb250DQo+Y29uZmlkZW50 aWVscyBldCDDqXRhYmxpcyDDoCBsJ2ludGVudGlvbiBleGNsdXNpdmUgZGUgc2VzIGRlc3RpbmF0 YWlyZXMuDQo+U2kgdm91cyBhdmV6IHJlw6d1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgbWVyY2kg ZOKAmWVuIGluZm9ybWVyDQo+aW1tw6lkaWF0ZW1lbnQgc29uIMOpbWV0dGV1ciBwYXIgY291cnJp ZXIgw6lsZWN0cm9uaXF1ZSBldCBk4oCZZWZmYWNlciBjZQ0KPm1lc3NhZ2UgZGUgdm90cmUgc3lz dMOobWUuIERhbnMgY2V0dGUgaHlwb3Row6hzZSwgdm91cyBu4oCZw6p0ZXMgcGFzDQo+YXV0b3Jp c8OpIMOgIHV0aWxpc2VyLCBjb3BpZXIgY2UgbWVzc2FnZSBldC9vdSBlbiBkaXZ1bGd1ZXIgbGUg Y29udGVudSDDoA0KPnVuIHRpZXJzLiBUb3V0IG1lc3NhZ2Ugw6lsZWN0cm9uaXF1ZSBlc3Qgc3Vz Y2VwdGlibGUgZCdhbHTDqXJhdGlvbi4NCj5Rb3Ntb3MgZXQgc2VzIGZpbGlhbGVzIGTDqWNsaW5l bnQgdG91dGUgcmVzcG9uc2FiaWxpdMOpIGF1IHRpdHJlIGRlIGNlDQo+bWVzc2FnZSBzJ2lsIGEg w6l0w6kgYWx0w6lyw6ksIGTDqWZvcm3DqSBvdSBmYWxzaWZpw6kuDQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zZmMgbWFpbGluZyBsaXN0DQo+c2Zj QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWls aW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K From nobody Mon Feb 2 22:33:28 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 D55631A6F39 for ; Mon, 2 Feb 2015 22:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8cWlTodA35cI for ; Mon, 2 Feb 2015 22:33:24 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 429AF1A6F38 for ; Mon, 2 Feb 2015 22:33:24 -0800 (PST) Received: from DM2PR0301MB1263.namprd03.prod.outlook.com (25.160.219.28) by DM2PR0301MB0622.namprd03.prod.outlook.com (25.160.95.26) with Microsoft SMTP Server (TLS) id 15.1.75.20; Tue, 3 Feb 2015 06:33:01 +0000 Received: from DM2PR0301MB0862.namprd03.prod.outlook.com (25.160.215.148) by DM2PR0301MB1263.namprd03.prod.outlook.com (25.160.219.28) with Microsoft SMTP Server (TLS) id 15.1.75.20; Tue, 3 Feb 2015 06:33:01 +0000 Received: from DM2PR0301MB0862.namprd03.prod.outlook.com ([25.160.215.148]) by DM2PR0301MB0862.namprd03.prod.outlook.com ([25.160.215.148]) with mapi id 15.01.0065.013; Tue, 3 Feb 2015 06:33:00 +0000 From: Srini Addepalli To: "Surendra Kumar (smkumar)" , Nicolas BOUTHORS , Sumandra Majee , Cathy Zhang , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZx/9uiAgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgCAAEtwAIBWb4+AgAEKeQCAALysgIACxPuAgABPRQCAAV38gIAAW73g Date: Tue, 3 Feb 2015 06:33:00 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> <76B41B8FACE1514795D30EC137FF391D7D2279@LILAS.jungle.qosmos.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.162.248.85] authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB1263;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB1263; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(479174004)(13464003)(24454002)(377454003)(46102003)(54606007)(50986999)(54356999)(76176999)(230783001)(93886004)(40100003)(76576001)(122556002)(92566002)(102836002)(86362001)(106116001)(2656002)(66066001)(33656002)(2950100001)(15975445007)(2900100001)(19580405001)(87936001)(74316001)(99286002)(77156002)(62966003)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB1263; H:DM2PR0301MB0862.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2015 06:33:00.4618 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 710a03f5-10f6-4d38-9ff4-a80b81da590d X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB1263 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0622; X-OriginatorOrg: freescale.com Archived-At: Cc: "nsmurthy@freescale.com" , Rajesh Kumar Madabushi , Bharat Mota Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 03 Feb 2015 06:33:27 -0000 Sure :-). I have heard that ToR switches are also used to switch traffic among VMs ev= en if they are on a server. In any case, my point of previous email is that multiple SFFs can be front = ending different instances of a service. Thanks Srini -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Monday, February 02, 2015 6:47 PM To: Addepalli Srini-B22160; Nicolas BOUTHORS; Sumandra Majee; Cathy Zhang; = 'sfc@ietf.org' Cc: NS Srinivasa Murthy-B37840; Madabushi Rajesh Kumar-B38870; Mota Bharat-= B19479 Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) I wouldn=B9t make a categorical statement such as this, it is just one poss= ibility. Surendra. On 2/1/15, 1:54 PM, "Srini Addepalli" wrote: >In NFV world, SFF is a virtual switch in servers. From nobody Tue Feb 3 06:19: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 B7E791A039B for ; Tue, 3 Feb 2015 06:19:37 -0800 (PST) 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 05U3bFXy0r7L for ; Tue, 3 Feb 2015 06:19:35 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936C31A0362 for ; Tue, 3 Feb 2015 06:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2584; q=dns/txt; s=iport; t=1422973175; x=1424182775; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Uk81UGSC0vMBif0jMh3POQc78oCzNLL/CADuXvkARu4=; b=Uz53nTG+NNR5ZzoxMHsbW1ZvA7aUj7YDF9xldW6i2PBNVyPBkj8otDMo rFU8wR+XKmvk1l6oKQ05tnkdis2HDHJPaKwkU3HUp3XKtFaaKxHIhbskf SHa0NIPX/zHpYB6UdOe9qNjj9nDg+LucQd32+5V1d9gIUOTQwHs0AImtK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQBP2NBU/4wNJK1QCoMGUl2CfcIGhXECHH9DAQEBAQF9hAwBAQEDASMRIBMSBQsCAQgSBgICJgICAjAVAg4CBA4FiCUIDb9lljIBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhjXspMwcEgmQugRMFjwmDToVXklwigjKBPG+BRH4BAQE X-IronPort-AV: E=Sophos;i="5.09,513,1418083200"; d="scan'208";a="120086271" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP; 03 Feb 2015 14:19:34 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t13EJYQP007230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 14:19:34 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.12]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 08:19:34 -0600 From: "Paul Quinn (paulq)" To: Nicolas BOUTHORS Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZx/9uiAgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgCAAEtwAIBWb4+AgAEKeQCABnZ2gA== Date: Tue, 3 Feb 2015 14:19:34 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <, <>> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 03 Feb 2015 14:19:38 -0000 DQo+IE9uIEphbiAzMCwgMjAxNSwgYXQgNjozOCBBTSwgTmljb2xhcyBCT1VUSE9SUyA8Tmljb2xh cy5CT1VUSE9SU0Bxb3Ntb3MuY29tPiB3cm90ZToNCj4gDQo+IEhlbGxvIENhdGh5LA0KPiANCj4g SW5kZWVkIHRoZSBub3Rpb24gb2YgInJlbmRlcmVkIHNlcnZpY2UgcGF0aCBJRCIoUlNQIElEKSBz ZWVtcyByZWxldmFudCBhcyB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IHN0aXB1bGF0ZXMgdGhh dCB0aGUgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlApIHByb3ZpZGVzIGFuIGFic3RyYWN0IG5v dGlvbiBvZiBhIHNlcnZpY2UgY2hhaW4sIHdoaWxlIHRoZSBSU1AgaXMgYSBjb25zdHJhaW5lZCBs aXN0IG9mIGxvY2F0aW9ucy4NCj4gDQo+IFNGQyBoZWFkZXIgIlNlcnZpY2UgUGF0aCBJZGVudGlm aWVyIiAoU1BJKSAgaXMgdXNlZCBpbiBib3RoIE5TSCBhbmQgU0NIIHByb3RvY29sIGFuZCBpbiBi b3RoIGNhc2Ugc2VlbSB0byBpZGVudGlmeSB0byBhIHBhcnRpY3VsYXIgU0ZQLg0KPiANCj4gTlNI KHY1KSBmb3IgZXhhbXBsZSBzdGF0ZXMgdGhhdA0KPiAiIEFzIGRlc2NyaWJlZCBhYm92ZSwgTlNI IGNvbnRhaW5zIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgKFNQSSkgYW5kDQo+ICAgYSBzZXJ2 aWNlIGluZGV4IChTSSkuICBUaGUgU1BJIGlzLCBhcyBwZXIgaXRzIG5hbWUsIGFuIGlkZW50aWZp ZXIuDQo+ICAgVGhlIFNQSSBhbG9uZSBjYW5ub3QgYmUgdXNlZCB0byBmb3J3YXJkIHBhY2tldHMg YWxvbmcgYSBzZXJ2aWNlIHBhdGguDQo+ICAgUmF0aGVyIHRoZSBTUEkgcHJvdmlkZSBhIGxldmVs IG9mIGluZGlyZWN0aW9uIGJldHdlZW4gdGhlIHNlcnZpY2UNCj4gICBwYXRoL3RvcG9sb2d5IGFu ZCB0aGUgdGhlIG5ldHdvcmsgdHJhbnNwb3J0LiAgRnVydGhlcm1vcmUsIHRoZXJlIGlzDQo+ICAg bm8gcmVxdWlyZW1lbnQsIG9yIGV4cGVjdGF0aW9uIG9mIGFuIFNQSSBiZWluZyBib3VuZCB0byBh IHByZS0NCj4gICBkZXRlcm1pbmVkIG9yIHN0YXRpYyBuZXR3b3JrIHBhdGguIg0KPiANCj4gU3Rp bGwgTlNIKHY1KSAgc2hvd3MgdGhhdCBTUEkgKG5vdCBhIFJTUCBJRCkgIHNob3VsZCBiZSBwYXJ0 IG9mIHRoZSBrZXkgIGVsZW1lbnQgb2YgYW4gU0ZGIHRvIGxvb2t1cCBvbiBmb3J3YXJkaW5nIHRh Ymxlcy4gIEJ1dCBJIGNvdWxkIG5vdCBmaW5kIGluIE5TSCAgaG93IHRvIHVzZSB0aGUgbm90aW9u IG9mDQo+IFJlbmRlcmVkIHNlcnZpY2UgcGF0aCB3aGljaCB3YXMgZGVmaW5lZCBpbiB0aGUgYXJj aGl0ZWN0dXJlIGRvY3VtZW50Lg0KPiANCg0KTmljb2xhcywgdGhhbmtzIGZvciByZWFkaW5nIE5T SC0wNSwgSSBqdXN0IHdhbnQgdG8gY2xhcmlmeSB0aGUgUlNQIC8gU1BJIGRpc2N1c3Npb24gaW4g dGhhdCBjb250ZXh0Lg0KDQpBcmNoaXRlY3R1cmFsbHksIHRoZSBkZWZpbml0aW9uIG9mIHJlbmRl cmVkIHBhdGggZG9lcyBub3QgaW1wbHkgdGhlIG5lZWQgb2YgYW4gUlNQIElELCBhbmQgdGhlIFNQ RiBJRCBjYW4gcmVwcmVzZW50IHRoZSBwYXRoIHRvIGJlIHJlbmRlcmVkIGluIHRoZSBuZXR3b3Jr LiAgV2XigJl2ZSBmb3VuZCB0aGlzIHRvIGJlIHRydWUgaW4gaW1wbGVtZW50YXRpb24uICBJZiBo b3dldmVyLCB5b3UgZmVlbCB0aGF0IGFkZGl0aW9uYWwgZ3JhbnVsYXJpdHkgaXMgcmVxdWlyZWQs IGZvciBsb2FkIGJhbGFuY2luZyBmb3IgZXhhbXBsZSwgYW4gYWRkaXRpb25hbCBJRCAoUlNQIG9y IGZsb3cgaW4gc29tZSBjYXNlcykgaXMgZWFzaWx5IGNhcnJpZWQgaW4gTlNILg0KDQpJ4oCZbSBz dXJlIHRoZSBhcmNoaXRlY3R1cmUgZHJhZnQgYXV0aG9ycyBjYW4gd2VpZ2ggaW4gYXMgbmVlZGVk IGFzIHdlbGwuDQoNCjx0cmltbWVkIGJlbG93IGZvciByZWFkYWJpbGl0eT4NCg0KVGhhbmtzLA0K UGF1bA== From nobody Tue Feb 3 07:38: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 1F5D71A0469 for ; Tue, 3 Feb 2015 07:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, 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 c586VoHuC-Xs for ; Tue, 3 Feb 2015 07:37:53 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BFAF1A036E for ; Tue, 3 Feb 2015 07:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21332; q=dns/txt; s=iport; t=1422977873; x=1424187473; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IUh2MPUTTvtN0RS/RToNmA6vwsOFQtaWKgKnTKz7Tmo=; b=MgNn3LoOU9cguiSDEkq0UHaY1Tpaelnp0QHnq+CuPa1fXeiI0dZsHy5y 6N+nTroL+jg6etRTm3n5yQBlCugreDmOCZrb3NMejqbR1EYnKnVqk9Gnv Kmo4L/zip5+ZHCuarOaiSz0atuIoP5hs80QQrkcqVSxTK3H3leElkf/fR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoIAH7q0FStJV2Q/2dsb2JhbABQCoJkIlJdgjZHv2GCGwqFcQIcgQBDAQEBAQF9hAwBAQEDAQEBAQkXESATBwsFBwQCAQYCEQEDAQEBAgIjAwICAiULFAECBggCBA4FiCUIAQyjTpxslj4BAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhjXQHMRAWBQcCAgKCYi6BEwEEjwmDTmKEdYEXgwOLBYM9IoICHBSBPG8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,513,1418083200"; d="scan'208";a="393008585" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-7.cisco.com with ESMTP; 03 Feb 2015 15:37:51 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t13FbpGd017248 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 15:37:51 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 09:37:51 -0600 From: "Carlos Pignataro (cpignata)" To: Nicolas BOUTHORS Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZyAGG+AgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgD//7j7oIBVIj4ggALIuACABoxWAA== Date: Tue, 3 Feb 2015 15:37:50 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <, <>> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.58] Content-Type: text/plain; charset="utf-8" Content-ID: <5328780F526B1045B76BBF90AF6EC7E8@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Cathy Zhang , Jerome TOLLET , "sfc@ietf.org" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 03 Feb 2015 15:37:58 -0000 SGksDQoNCltUb3AtcG9zdCByZXNwb25kaW5nLCBub3QgYWRkcmVzc2VkIHRvIGFueSBtZXNzYWdl IGluIHBhcnRpY3VsYXIgYnV0IG1ha2luZyBhIGdlbmVyaWMgY29tbWVudF0NCg0KU2luY2UgdGhl IGFyY2hpdGVjdHVyZSBkb2N1bWVudCBnb3QgY2l0ZWQgYSBjb3VwbGUgb2YgdGltZXMgaW4gdGhp cyB0aHJlYWQsIG15IHZpZXcgaXMgdGhhdCB0aGUgZmFjdCB0aGF0IHRoZSBhcmNoIGRvY3VtZW50 IGRlZmluZXMgYW4gUlNQIGRvZXMgbm90IGltcGx5IHRoYXQgdGhlcmUgb3VnaHQgdG8gYmUgYW4g UlNQIElkZW50aWZpZXIsIGxlc3Mgc28gb25lIGNhcnJpZWQgaW4gdGhlIGRhdGFwbGFuZS4NCg0K VGhlIHJlYWwgcXVlc3Rpb24gaXMgd2hhdCBjYW5ub3QgYmUgZG9uZSB3aXRoIGEgU2VydmljZSBQ YXRoIElELCBpbiB0ZXJtcyBvZiBib3RoIGZ1bmN0aW9uYWxpdHkgYW5kIHNjYWxpbmcg4oCUIHRv IG1lLCBhIGhpZXJhcmNoaWNhbCBzZXQgb2YgaWRlbnRpZmllcnMgKOKAnCBSU1AgSUQgdmFsdWVz IGNvdWxkIGJlIHJlbGF0aXZlIHRvIGEgcGFydGljdWxhciBTZXJ2aWNlIFBhdGjigJ0pIHNlZW1z IG92ZXItZW5naW5lZXJpbmcsIGFuZCBhbiBpbmRlcGVuZGVudCBhbGxvY2F0aW9uIGNhbiBjcmVh dGUgY29uZmxpY3RzLg0KDQpJbiBvdGhlciB3b3Jkcywgd2hhdCBwcm9ibGVtIGFyZSB3ZSBzb2x2 aW5nPw0KDQpUaGFua3MsDQoNCuKAlCBDYXJsb3MuDQoNCj4gT24gSmFuIDMwLCAyMDE1LCBhdCA2 OjM4IEFNLCBOaWNvbGFzIEJPVVRIT1JTIDxOaWNvbGFzLkJPVVRIT1JTQHFvc21vcy5jb20+IHdy b3RlOg0KPiANCj4gSGVsbG8gQ2F0aHksDQo+IA0KPiBJbmRlZWQgdGhlIG5vdGlvbiBvZiAicmVu ZGVyZWQgc2VydmljZSBwYXRoIElEIihSU1AgSUQpIHNlZW1zIHJlbGV2YW50IGFzIHRoZSBhcmNo aXRlY3R1cmUgZG9jdW1lbnQgc3RpcHVsYXRlcyB0aGF0IHRoZSBTZXJ2aWNlIEZ1bmN0aW9uIFBh dGggKFNGUCkgcHJvdmlkZXMgYW4gYWJzdHJhY3Qgbm90aW9uIG9mIGEgc2VydmljZSBjaGFpbiwg d2hpbGUgdGhlIFJTUCBpcyBhIGNvbnN0cmFpbmVkIGxpc3Qgb2YgbG9jYXRpb25zLg0KPiANCj4g U0ZDIGhlYWRlciAiU2VydmljZSBQYXRoIElkZW50aWZpZXIiIChTUEkpICBpcyB1c2VkIGluIGJv dGggTlNIIGFuZCBTQ0ggcHJvdG9jb2wgYW5kIGluIGJvdGggY2FzZSBzZWVtIHRvIGlkZW50aWZ5 IHRvIGEgcGFydGljdWxhciBTRlAuDQo+IA0KPiBOU0godjUpIGZvciBleGFtcGxlIHN0YXRlcyB0 aGF0DQo+ICIgQXMgZGVzY3JpYmVkIGFib3ZlLCBOU0ggY29udGFpbnMgYSBzZXJ2aWNlIHBhdGgg aWRlbnRpZmllciAoU1BJKSBhbmQNCj4gICBhIHNlcnZpY2UgaW5kZXggKFNJKS4gIFRoZSBTUEkg aXMsIGFzIHBlciBpdHMgbmFtZSwgYW4gaWRlbnRpZmllci4NCj4gICBUaGUgU1BJIGFsb25lIGNh bm5vdCBiZSB1c2VkIHRvIGZvcndhcmQgcGFja2V0cyBhbG9uZyBhIHNlcnZpY2UgcGF0aC4NCj4g ICBSYXRoZXIgdGhlIFNQSSBwcm92aWRlIGEgbGV2ZWwgb2YgaW5kaXJlY3Rpb24gYmV0d2VlbiB0 aGUgc2VydmljZQ0KPiAgIHBhdGgvdG9wb2xvZ3kgYW5kIHRoZSB0aGUgbmV0d29yayB0cmFuc3Bv cnQuICBGdXJ0aGVybW9yZSwgdGhlcmUgaXMNCj4gICBubyByZXF1aXJlbWVudCwgb3IgZXhwZWN0 YXRpb24gb2YgYW4gU1BJIGJlaW5nIGJvdW5kIHRvIGEgcHJlLQ0KPiAgIGRldGVybWluZWQgb3Ig c3RhdGljIG5ldHdvcmsgcGF0aC4iDQo+IA0KPiBTdGlsbCBOU0godjUpICBzaG93cyB0aGF0IFNQ SSAobm90IGEgUlNQIElEKSAgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGtleSAgZWxlbWVudCBvZiBh biBTRkYgdG8gbG9va3VwIG9uIGZvcndhcmRpbmcgdGFibGVzLiAgQnV0IEkgY291bGQgbm90IGZp bmQgaW4gTlNIICBob3cgdG8gdXNlIHRoZSBub3Rpb24gb2YNCj4gUmVuZGVyZWQgc2VydmljZSBw YXRoIHdoaWNoIHdhcyBkZWZpbmVkIGluIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQuDQo+IA0K PiBZb3UgcHJvcG9zYWwgc2VlbXMgdG8gbWUgdmVyeSB1c2VmdWwsDQo+IA0KPiBBbiBSU1AgSUQg KGluZGVwZW5kZW50IG9mIHRoZSBTUEkgYnV0IHBhcnQgb2YgdGhlIHNhbWUgbmFtZSBzcGFjZSkg Y291bGQgYmUgdXNlZCB0aGUgc2FtZSB3YXkgYXMgU1BJIGJ5IFNGRiBmb3IgZXhhbXBsZSwgYWxs b3dpbmcgYSBTZXJ2aWNlIENsYXNzaWZpZXIgdG8gY29udHJvbCByZW1vdGUgbG9hZCBiYWxhbmNp bmcgZm9yIGV4YW1wbGUuDQo+IA0KPiBUaGlzIHNhaWQgdGhlIFJTUCBJRCB2YWx1ZXMgY291bGQg YmUgcmVsYXRpdmUgdG8gYSBwYXJ0aWN1bGFyIFNlcnZpY2UgUGF0aCwgd2hpY2ggd291bGQgcHJl dmVudCB1c2luZyB0aGVtIGFzIHdlIGRvIGZvciBTUEkgaW4gU0ZGIGZvcndhcmRpbmcgdGFibGVz Lg0KPiANCj4gV2UgbWF5IHdhbnQgdG8gcHJlY2lzZSBpZiB0aGUgUlNQIElEIGlzIHRvIGJlIHJl bGF0aXZlIG9mIGFic29sdXRlLCBhcyBpdCBzaG91bGQgaGF2ZSBhbiBpbXBhY3Qgb24gZm9yd2Fy ZGluZyB0YWJsZSBzdHJ1Y3R1cmUgaWYgd2UgZGVjaWRlIHRvIHVzZSB0aGlzIGNvbmNlcHQuDQo+ IA0KPiBQZXJzb25hbGx5IEkgbGlrZSB0aGUgbm90aW9uIG9mIGEgcmVsYXRpdmUgUlNQIElELCBh cyB3ZSBjb3VsZCB0aGVuIHVzZSBzb21lIGNvbnZlbnRpb25zLCBzdHJ1Y3R1cmUgaXQsIHBvc3Np Ymx5IGV4dGVuZGluZyBpdHMgdXNlLg0KPiANCj4gTmljb2xhcw0KPiANCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQ2F0aHkgWmhhbmcgW21haWx0bzpDYXRoeS5ILlpoYW5n QGh1YXdlaS5jb21dDQo+IFNlbnQ6IGpldWRpIDI5IGphbnZpZXIgMjAxNSAyMDo0NA0KPiBUbzog Q2F0aHkgWmhhbmc7IFNyaW5pIEFkZGVwYWxsaTsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBK b2VsIE0uIEhhbHBlcm47ICdzZmNAaWV0Zi5vcmcnDQo+IENjOiBuc211cnRoeUBmcmVlc2NhbGUu Y29tDQo+IFN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQgKGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPiANCj4gSGkgZXZl cnlvbmUsDQo+IA0KPiBXZSBoYXZlIHVwbG9hZGVkIGEgbmV3IFNDSCB2ZXJzaW9uICgzKSB3aGlj aCBhZGRzIGRlZmluaXRpb24gb2YgYSBuZXcgbWV0YWRhdGEgdHlwZSBmb3IgdGhlIGZsb3cgSUQg dG8gc3VwcG9ydCBsb2FkIGJhbGFuY2luZyBhbW9uZyBTRiBpbnN0YW5jZXMgYW5kIG1pdGlnYXRl IHRoZSBwb3RlbnRpYWwgaXNzdWUgb2YgIm5vdCBlbm91Z2ggcGF0aCBJRCIuIFRoZSBmbG93IElE IGlzIG5hbWVkICJyZW5kZXJlZCBzZXJ2aWNlIHBhdGggSUQiIGluIHRoZSBkcmFmdC4gUGxlYXNl IHJlZmVyIHRvIHNlY3Rpb24gNC4zLjIgb2YgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtemhhbmctc2ZjLXNjaC8gZm9yIGRldGFpbCBkZXNjcmlwdGlvbi4NCj4gDQo+IElu IGl0cyBwcmV2aW91cyB2ZXJzaW9uLCBTQ0ggZGVmaW5lcyBhICJCeXBhc3MgYml0IiBpbiB0aGUg YmFzZSBoZWFkZXIuIFRoaXMgYml0IGVuYWJsZXMgdGhlIFNGIHRvIHByb3ZpZGUgZmVlZGJhY2sv bm90aWZpY2F0aW9uIHZpYSB0aGUgZGF0YSBwYXRoIHRvIGl0cyBjb25uZWN0aW5nIFNGRiBhYm91 dCB3aGV0aGVyIHRoZSByZW1haW5pbmcgcGFja2V0cyBvZiB0aGUgU0ZDIHNob3VsZCBieXBhc3Mg dGhhdCBTRi4gVGhpcyBpcyB1c2VmdWwgaW4gdGhlIGNhc2UgdGhhdCBvbmx5IHRoZSBmaXJzdCBm ZXcgcGFja2V0cyBvZiBhIGZsb3cgbmVlZCB0byBnbyB0byBhIFNGIChzdWNoIGFzIGEgRFBJIG9y IEZXIG9yIElEUykgYW5kIHJlbWFpbmluZyBwYWNrZXRzIGNhbiBieXBhc3MgdGhhdCBTRiwgdGh1 cyBzYXZpbmcgdGhlIGV4cGVuc2l2ZSBTRiByZXNvdXJjZSBhbmQgcmVkdWNpbmcgZGF0YSBwYXRo IGxhdGVuY3kuDQo+IA0KPiBCIGJpdDogVGhlIEIgKEJ5cGFzcykgYml0LCB3aGVuIHNldCB0byAx LCBpdCBpcyB1c2VkIGJ5IGEgU2VydmljZQ0KPiAgICAgICBGdW5jdGlvbiB0byBzaWduYWwgdG8g aXRzIFNlcnZpY2UgRnVuY3Rpb24gRm9yd2FyZGVyIHRoYXQgbm8NCj4gICAgICAgZnVydGhlciBw YWNrZXRzIGFyZSB0byBiZSBzZW50IHRvIGl0IGZvciB0aGUgZmxvdyBzcGVjaWZpZWQgaW4gZW5j YXBzdWxhdGVkIHBhY2tldC4NCj4gDQo+IEluIGFkZGl0aW9uLCBTQ0ggZGVmaW5lcyBhIG1ldGFk YXRhIHR5cGUgZm9yIEdlbmVyaWMgQ29udGV4dCBCbG9jaywgd2hpY2ggaXMgb3B0aW9uYWwgYW5k IGNhbiBiZSB1c2VkIGlmIG5lZWRlZCB0byBjYXJyeSBhbnkgdmVuZG9yJ3Mgc3BlY2lmaWMgIkNv bnRleHQgSGVhZGVyIi4NCj4gDQo+IEFueSBjb21tZW50cyBvbiB0aGVzZSBuZXcgYWRkaXRpb25z Pw0KPiANCj4gVGhhbmtzLA0KPiBDYXRoeQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBDYXRoeSBaaGFuZw0KPiBTZW50OiBGcmlkYXksIERlY2VtYmVyIDA1LCAyMDE0IDExOjQ3IEFN DQo+IFRvOiBTcmluaSBBZGRlcGFsbGk7IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgSm9lbCBN LiBIYWxwZXJuOyAnc2ZjQGlldGYub3JnJw0KPiBDYzogbnNtdXJ0aHlAZnJlZXNjYWxlLmNvbQ0K PiBTdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0IChodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4gDQo+IFJvbiwgTG91aXMs IE15byBhbmQgSSBoYXZlIGJlZW4gZGlzY3Vzc2luZyBvZmYgbGluZSBsYXN0IGZldyB3ZWVrcyBh Ym91dCBkZWZpbmluZyBhIG1ldGFkYXRhIHR5cGUgZm9yIGZsb3cgSUQgaW4gYWRkaXRpb24gdG8g dGhlIHBhdGggSUQgb2YgdGhlIG1haW4gaGVhZGVyIHRvIHN1cHBvcnQgbG9hZCBiYWxhbmNpbmcg YW1vbmcgU0YgaW5zdGFuY2VzLiBXZSB3aWxsIGRlZmluZSBhIFRMViB0eXBlIGZvciB0aGUgZmxv dyBJRC4gVGhlIGNvbWJpbmF0aW9uIG9mICJwYXRoIElEICsgZmxvdyBJRCIgc3BlY2lmaWVzIGEg cmVhbGl6ZWQgc2VydmljZSBjaGFpbiBpbnN0YW5jZSBwYXRoLiBJdCBpcyBsZWZ0IHRvIHRoZSBk ZXNpZ24vaW1wbGVtZW50YXRpb24gd2hldGhlciB0byB1c2UgYSBjZW50cmFsaXplZCBtZXRob2Qg b3IgYSBkaXN0cmlidXRlZCBtZXRob2QgdG8gYmluZCB0aGUgZmxvdyBJRCB0byBhIHJlYWxpemVk IHNlcnZpY2UgaW5zdGFuY2UgcGF0aCBhbHRob3VnaCBvdXIgb3JpZ2luYWwgdGhvdWdodCBpcyBm b3IgZGlzdHJpYnV0ZWQgTEIgdXNhZ2UuIEkgYW0gbm90IHN1cmUgaWYgd2UgbmVlZCBhIGJpdCBp biB0aGUgaGVhZGVyIHRvIGRlbm90ZSB3aGV0aGVyIHRoZXJlIGFyZSBtb3JlIHBhdGggSUQgYml0 cyAod2UgY2FsbCBpdCBmbG93IElEKSBpbiB0aGUgbWV0YWRhdGEgZmllbGRzIHNpbmNlIHdoZW4g eW91IHBhcnNlIHRoZSBUTFYgbWV0YWRhdGEsIHlvdSB3aWxsIGtub3cgd2hldGhlciB0aGVyZSBh cmUgZmxvdyBJRCBiaXRzIG9yIG5vdC4gTm90ZSB0aGF0IGlmIG11bHRpcGxlIHNlc3Npb25zIHNo YXJlIHRoZSBzYW1lIHJlYWxpemVkIHNlcnZpY2UgaW5zdGFuY2UgcGF0aCwgdGhleSB3aWxsIHNo YXJlIHRoZSBzYW1lICJwYXRoIElEKyBmbG93IElEIi4gIFdlIGNhbiBhbHNvIGNvbnNpZGVyIGV4 dGVuZGluZyB0aGUgbnVtYmVyIG9mIGJpdHMgdG8gMzIgaWYgdGhhdCBpcyB0aGUgY29uc2Vuc3Vz LiBXZSB3aWxsIHBvc3QgYW4gdXBkYXRlZCBkcmFmdCBkZXNjcmliaW5nIHRoZXNlIHNvb24uDQo+ IA0KPiBUaGFua3MsDQo+IENhdGh5DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNy aW5pIEFkZGVwYWxsaQ0KPiBTZW50OiBGcmlkYXksIERlY2VtYmVyIDA1LCAyMDE0IDc6MTcgQU0N Cj4gVG86IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgSm9lbCBNLiBIYWxwZXJuOyAnc2ZjQGll dGYub3JnJw0KPiBDYzogbnNtdXJ0aHlAZnJlZXNjYWxlLmNvbQ0KPiBTdWJqZWN0OiBSZTogW3Nm Y10gQ29tbWVudHMgb24gU0NIIERyYWZ0IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtemhhbmctc2ZjLXNjaC0wMikNCj4gDQo+IA0KPiBbUlBdIERhdGEgcGxhbmUgZWZmaWNpZW5j eS4NCj4gDQo+IFNSSU5JPiBJIGFtIG5vdCBzbyBzdXJlIGFib3V0IGRhdGEgcGxhbmUgZWZmaWNp ZW5jeS4gIE1vc3Qgb2YgdGhlIHByb2Nlc3NvcnMgd29yayBnb29kIGlmIHRoZSBudW1iZXIgb2Yg Yml0cyBhcmUgZWl0aGVyIDMyIG9yIDY0LiAgSWYgaXQgaXMgMjQgYml0cywgdGhlbiBvbmUgbmVl ZHMgdG8gZG8gbWFza2luZyBhbmQgc2hpZnRpbmcgYmVmb3JlIHRoZSB2YWx1ZSBpcyB1c2VkIHRv IGRvIGFueSBsb29rdXAuICAgQnV0LCB0aGlzIGRpc2N1c3Npb24gY2FuIGdvIGludG8gZGlmZmVy ZW50IGRpcmVjdGlvbiA6LSksIGl0IG1heSBub3QgYmUgZ29vZCB0byBnbyBpbiB0aGF0IGRpcmVj dGlvbi4NCj4gDQo+IFdoZXJlIGRvIHdlIGRyYXcgdGhlIGxpbmU/IDMyLWJpdHMsIDY0LWJpdHMs DQo+IDEyOCBiaXRzPyBJIHRoaW5rIHdlIHNob3VsZCBoYXZlIGEgc2Vuc2libGUgdmFsdWUgaW4g dGhlIFNlcnZpY2UgUGF0aCBoZWFkZXIgYW5kIGlmIHlvdSBuZWVkIHRvIGNvbnZleSBtb3JlIGJp dHMgeW91IG5lZWQgdG8gdXNlIHRoZSBjb250ZXh0IGhlYWRlcnMuDQo+IA0KPiBTUklOST4gVGhp cyBpcyBhIGdvb2QgcG9pbnQuICBUaGlzIHNob3VsZCB3b3JrIGZpbmUgYXMgbG9uZyBhcyB0aGVy ZSBpcyB3YXkgdG8gY29udmV5IGluIHRoZSBtYWluIGhlYWRlciB0aGF0IHRoZSBleHRlbnNpb24g dG8gcGF0aCBJRCBpcyBhdmFpbGFibGUgaW4gc28gYW5kIHNvIFRMViBmaWVsZC4gIFRoYXQgc2hv dWxkIHdvcmsgdG9vLg0KPiANCj4gVGhhbmtzDQo+IFNyaW5pDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEZyb206IFJlaW5hbGRvIFBlbm5vIChyZXBl bm5vKSA8cmVwZW5ub0BjaXNjby5jb20+DQo+IFNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgNSwgMjAx NCA3OjA4IEFNDQo+IFRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47 ICdzZmNAaWV0Zi5vcmcnDQo+IENjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPiBTdWJq ZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0IChodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4gDQo+IE9uIDEyLzUvMTQsIDY6NTQg QU0sICJTcmluaSBBZGRlcGFsbGkiIDxzYWRkZXBhbGxpQGZyZWVzY2FsZS5jb20+IHdyb3RlOg0K PiANCj4+IA0KPj4gSW4gcmVhbCBkZXBsb3ltZW50cywgbnVtYmVyIG9mIGFjdGl2ZSBwYXRoIElE cyBhcmUgdmVyeSBsZXNzZXIgdGhhbg0KPj4gMl42NCwgYnV0IHRoZXJlIGlzIGEgZ29vZCBwb3Nz aWJpbGl0eSBvZiB0aGUgbnVtYmVyIGJlaW5nIG1vcmUgdGhhbiAyXjI0ICgxNk0pLg0KPj4gSSB0 aGluayBiaWdnZXIgcG9pbnQgaXMgdGhhdCB3aHkgcmVzdHJpY3QgdGhpcyBpbiB0aGUgc3RhbmRh cmRzPyBXaGF0DQo+PiBhZHZhbnRhZ2UgZG8gd2UgaGF2ZSByZXN0cmljdGluZyB0aGlzIHNpemUg dG8gMjQgYml0cz8NCj4gDQo+IFtSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5LiBXaGVyZSBkbyB3 ZSBkcmF3IHRoZSBsaW5lPyAzMi1iaXRzLCA2NC1iaXRzLA0KPiAxMjggYml0cz8gSSB0aGluayB3 ZSBzaG91bGQgaGF2ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRoZSBTZXJ2aWNlIFBhdGggaGVhZGVy IGFuZCBpZiB5b3UgbmVlZCB0byBjb252ZXkgbW9yZSBiaXRzIHlvdSBuZWVkIHRvIHVzZSB0aGUg Y29udGV4dCBoZWFkZXJzLg0KPiANCj4gDQo+PiANCj4+IFRoZXJlIGNhbiBiZSBkZXBsb3ltZW50 cywgd2hlcmUgU0ZDIGNvbnRyb2xsZXIgKExvZ2ljYWxseSBjZW50cmFsLCBidXQNCj4+IGRpc3Ry aWJ1dGVkKSAgaXRzZWxmIGNhbiBkbyB0aGUgU0YgaW5zdGFuY2Ugc2VsZWN0aW9uIG9uIHBlcg0K Pj4gY29ubmVjdGlvbi9zZXNzaW9uIGJhc2lzLCB0aGVyZWJ5IGF2b2lkaW5nIHRoZSBMQnMgZm9y IHNlcnZpY2VzLiAgIEluIG15DQo+PiB2aWV3LCBhc3N1bXB0aW9uIHRoYXQgdGhlcmUgd2lsbCBi ZSBMQiBTRiBmb3IgZWFjaCBzY2FsZS1vdXQgc2VydmljZSBpbg0KPj4gdGhlIGNoYWluIGlzIG5v dCB2YWxpZCBpbiBhbGwgY2FzZXMuDQo+PiANCj4+IFRoYW5rcw0KPj4gU3JpbmkNCj4+IA0KPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gRnJvbTogUmVpbmFs ZG8gUGVubm8gKHJlcGVubm8pIDxyZXBlbm5vQGNpc2NvLmNvbT4NCj4+IFNlbnQ6IFRodXJzZGF5 LCBEZWNlbWJlciA0LCAyMDE0IDE6MTcgUE0NCj4+IFRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYw OyBKb2VsIE0uIEhhbHBlcm47IHNmY0BpZXRmLm9yZw0KPj4gQ2M6IE5TIFNyaW5pdmFzYSBNdXJ0 aHktQjM3ODQwDQo+PiBTdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+ PiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+ PiANCj4+IElmIEkgdW5kZXJzdG9vZCB5b3UsIEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgcmVhbGlz dGljLiBBcmUgeW91IHNheWluZw0KPj4geW91IG5lZWQgNjQtYml0cyBvZiBwYXRocyBhbmQgdGhl biB3aWxsIG1vbml0b3IgdGhlbSBhbGw/IERvIGZhdWx0DQo+PiB0b2xlcmFuY2UgYW5kIE9BTSBm b3IgMl42NC1iaXRzIHdvcnRoIG9mIHBhdGhzPyBKdXN0IGZvciBjb21wYXJpc29uLA0KPj4gaXTC uXMgbGlrZSBtYW5hZ2luZyBhbmQgbW9uaXRvcmluZyB0aGUgZW50aXJlIElQdjYgaG9zdCByYW5n ZSwgb25lLWJ5LW9uZS4NCj4+IA0KPj4gQW55d2F5LCBJIGRvIG5vdCBleHBlY3QgZXZlcnkgc2lu Z2xlIHBlcm11dGF0aW9ucyB0byBiZSBhIGRpZmZlcmVudCBwYXRoLg0KPj4gDQo+PiBJZiBlYWNo IHNlcnZpY2UgaGFzIDI1NiBkZXZpY2VzIHByb3ZpZGluZyBzaW1pbGFyIHNlcnZpY2UsIHlvdSBz aG91bGQNCj4+IG1vc3QgbGlrZWx5IHVzZSBsb2FkLWJhbGFuY2luZyBhbmQgdGhlbiB5b3Ugd291 bGQgaGF2ZSBhIHNpbmdsZSAob3IgYQ0KPj4gZmV3KSBwYXRocy4gVGhlcmUgaXMgc29tZSBkaXNj dXNzaW9uIGdvaW5nIG9uIExCLg0KPj4gDQo+PiBGcm9tIGEgZGF0YSBwbGFuZSBwZXJzcGVjdGl2 ZSwgdGhlIHBhdGggaXMgdWx0aW1hdGVseSBkZWZpbmVkIGJ5IHRoZQ0KPj4gU0ZGcyB0cmF2ZXJz ZWQgYW5kIHNlcnZpY2VzIHByb3ZpZGVkLCBub3QgYnkgYSBzcGVjaWZpYyBJUDpwb3J0IHRoYXQN Cj4+IHRoZSBkZXZpY2UgcHJvdmlkaW5nIHRoZSBzZXJ2aWNlIHNpdHMgb24uIFdlbGwsIGF0IGxl YXN0IGZyb20gYSBHUEUrTlNIIHBlcnNwZWN0aXZlLg0KPj4gDQo+PiANCj4+IE9uIDEyLzQvMTQs IDEyOjU3IFBNLCAiU3JpbmkgQWRkZXBhbGxpIiA8c2FkZGVwYWxsaUBmcmVlc2NhbGUuY29tPiB3 cm90ZToNCj4+IA0KPj4+IElmIEkgdGFrZSBhIGNoYWluIHdpdGggNSBzZXJ2aWNlcyB3aXRoIGVh Y2ggc2VydmljZSAgc2F5IGhhdmluZyAyNTYNCj4+PiBpbnN0YW5jZXMgZm9yIHNjYWxlLW91dCwg cG9zc2libGUgbnVtYmVyIG9mIHBhdGhzIGFyZQ0KPj4+IDI1NioyNTYqMjU2KjI1NioyNTYgPSAw eEZGIEZGIEZGIEZGIEZGLiBPbmUgcmVxdWlyZXMgMzMgYml0cyBpbiB0aGlzDQo+Pj4gY2FzZS4g IElmIHRoZXJlIGFyZSBtb3JlIHNlcnZpY2VzIGluIHRoZSBjaGFpbiBvciBtb3JlIGNoYWlucyBv ciBtb3JlDQo+Pj4gaW5zdGFuY2VzIGZvciBzY2FsZS1vdXQsIHRoZW4gaXQgY291bGQgZ28gdG8g YmlnIG51bWJlciB2ZXJ5IGZhc3QuDQo+Pj4gDQo+Pj4gQXMgSSBtZW50aW9uZWQgbXkgcHJlZmVy ZW5jZSBpcyB0byBtYWtlIHRoZSBwYXRoIElEIHNpemUgZmxleGlibGUgZm9yDQo+Pj4gZnV0dXJl IGdyb3d0aC4gSWYgdGhhdCBpcyBwZXJjZWl2ZWQgYXMgY29tcGxleCwgdGhlbiBnb2luZyBmb3Ig NjRiaXQNCj4+PiBpcyBzYWZlciBiZXQuDQo+Pj4gDQo+Pj4gVGhhbmtzDQo+Pj4gU3JpbmkNCj4+ PiANCj4+PiANCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IEpvZWwg TS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+Pj4gU2VudDogVGh1cnNk YXksIERlY2VtYmVyIDA0LCAyMDE0IDEyOjA1IFBNDQo+Pj4gVG86IEFkZGVwYWxsaSBTcmluaS1C MjIxNjA7IEpvZWwgTS4gSGFscGVybjsgc2ZjQGlldGYub3JnDQo+Pj4gQ2M6IE5TIFNyaW5pdmFz YSBNdXJ0aHktQjM3ODQwDQo+Pj4gU3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBE cmFmdA0KPj4+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNj aC0wMikNCj4+PiANCj4+PiBBIGNvbnRyb2xsZXIgKG9yIG90aGVyIGRlY2lzaW9uIGxvZ2ljKSBj YW4gY2VydGFpbmx5IGJlIGF3YXJlIG9mIHN1Y2gNCj4+PiBjb25jZXJucy4NCj4+PiBCdXQgdGhl IG51bWJlciBvZiBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzIGlzIG5vdCByZWxhdGVkIHRvIHRoZSBu dW1iZXINCj4+PiBvZiBmbG93cyBvciB0aGUgbnVtYmVyIG9mIHRlbmFudHMuICBJdCBpcyByZWxh dGVkIHRvIHRoZSBudW1iZXIgb2YNCj4+PiBjb21iaW5hdGlvbnMgb2Ygc2VydmljZXMgYW5kIHRo ZSBwb2xpY2llcyBmb3Igc2VydmljZSBmdW5jdGlvbiBzZWxlY3Rpb24uDQo+Pj4gV2hpbGUgdGhh dCBjYW4gYmUgYSBsYXJnZSBudW1iZXIsIEkgc3VyZSBob3BlIGl0IGRvZXMgbm90IGNvbWUgY2xv c2UNCj4+PiB0byBzYXR1cmF0aW5nIDI0IGJpdHMuDQo+Pj4gDQo+Pj4gSGF2aW5nIHNhaWQgdGhh dCwgaWYgd2UgdGhpbmsgdGhhdCAyNCBiaXRzIGlzIG9ubHkganVzdCBlbm91Z2gsIHRoZW4NCj4+ PiB3ZSBvdWdodCB0byB1c2UgMzIuICBGcm9tIHdoZXJlIEkgc2l0LCBJIHdvdWxkIG5vcm1hbGx5 IGV4cGVjdCAxNiBiaXRzDQo+Pj4gdG8gYmUgbW9yZSB0aGFuIHN1ZmZpY2llbnQsIHdoaWNoIGlz IHdoeSBJIGFtIGNvbWZvcnRhYmxlIHdpdGggMjQuDQo+Pj4gSGF2aW5nIHNhaWQgdGhhdCwgdGhl IGZpZWxkIHNpemUgaXMgbm90IGEgYmlnIGRlYWwgdG8gbWUuDQo+Pj4gDQo+Pj4gWW91cnMsDQo+ Pj4gSm9lbA0KPj4+IA0KPj4+IE9uIDEyLzQvMTQsIDI6MDEgUE0sIFNyaW5pIEFkZGVwYWxsaSB3 cm90ZToNCj4+Pj4gDQo+Pj4+IEkgd2FzIG5vdCBpbXBseWluZyB0aGF0IHBhdGggSUQgc2hvdWxk IGhhdmUgaW5mb3JtYXRpb24gaW4gcmVnYXJkcw0KPj4+PiB0byB0ZW5hbnQvY29udHJvbGxlci9m bG93L3NjYWxlLW91dC4gIEJ1dCBTRkMgY29udHJvbGxlcnMgc2hvdWxkIGtlZXAgdGhlc2UNCj4+ Pj4gaW4gbWluZCB0byBhc3NpZ24gdGhlIHBhdGggSUQuICAgIEEgZGVwbG95bWVudCBjYW4gaGF2 ZSBtdWx0aXBsZQ0KPj4+PiB0ZW5hbnRzLCBlYWNoIHRlbmFudCBjYW4gaGF2ZSBtdWx0aXBsZSBu ZXR3b3JrcywgIHRoZXJlIGNvdWxkIGJlDQo+Pj4+IG1pbGxpb25zIG9mIGZsb3dzIGluIGVhY2gg b2YgdGhvc2UgbmV0d29ya3MuICBBbmQgY29uc2lkZXJpbmcgYWxsDQo+Pj4+IHRoZXNlLA0KPj4+ PiAyNCBiaXQgcGF0aCBJRCBtYXkgbm90IGJlIGFibGUgdG8gcmVwcmVzZW50IHBhdGhzIGZvciB0 aGVzZSBmbG93cy4NCj4+Pj4gSGVuY2UsIEkgd2FzIHdvbmRlcmluZyB3aGV0aGVyIHBhdGggSUQg Y2FuIGJlIGV4dGVuZGVkIHRvIDY0IGJpdHMgb3INCj4+Pj4gbWFrZSBpdCBmbGV4aWJsZS4NCj4+ Pj4gDQo+Pj4+IFRoYW5rcw0KPj4+PiBTcmluaQ0KPj4+PiANCj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gPGpt aEBqb2VsaGFscGVybi5jb20+DQo+Pj4+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciA0LCAyMDE0 IDc6NDIgQU0NCj4+Pj4gVG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IHNmY0BpZXRmLm9yZw0K Pj4+PiBDYzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDANCj4+Pj4gU3ViamVjdDogUmU6IFtz ZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4+PiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+Pj4+IA0KPj4+PiBUaGUgSW5kZXggaXMgbm90 IGp1c3QgZm9yIGxvb3AgcHJldmVudGlvbi4gIEluIHRoZSBjYXNlIG9mDQo+Pj4+IGFtYmlndWl0 eSwgdGhlIGluZGV4IHRlbGxzIHRoZSBTRkYgd2hlcmUgaW4gdGhlIHBhdGggdGhlIHBhY2tldCBj dXJyZW50bHkgcmVzaWRlcy4NCj4+Pj4gICBUaGVyZSBhcmUgbXVsdGlwbGUgd2F5cyBzdWNoIGFt YmlndWl0eSBjYW4gb2NjdXIuDQo+Pj4+IA0KPj4+PiBUaGUgUGF0aCBJZGVudGlmaWVyIGlzIHNw ZWNpZmljYWxseSBub3QgZXhwZWN0ZWQgdG8gaW5jbHVkZQ0KPj4+PiBjb250cm9sbGVyIElEIG9y IFRlbmFudCBJRC4gIFdoaWxlIGEgZGVwbG95ZXIgY2FuIGhhdmUgYSBwYXRoIHBlcg0KPj4+PiB0 ZW5hbnQsIHRoZSBhcmNoaXRlY3R1cmUgc3RpbGwgZG9lcyBub3QgdHJlYXQgdGhlIHBhdGggSUQg YXMgYQ0KPj4+PiB0ZW5hbnQgSUQuICBUZW5hbnQgSUQsIGNvbnRyb2xsZXIgSUQsIGFuZCBvdGhl ciBub24tcGF0aC1zcGVjaWZ5aW5nDQo+Pj4+IGluZm9ybWF0aW9uIGlzIHRvIGJlIGNhcnJpZWQg aW4gbWV0YWRhdGEuDQo+Pj4+IA0KPj4+PiBZb3VycywNCj4+Pj4gSm9lbA0KPj4+PiANCj4+Pj4g T24gMTIvNC8xNCwgMTA6MDIgQU0sIFNyaW5pIEFkZGVwYWxsaSB3cm90ZToNCj4+Pj4+IFR3byBj b21tZW50cyA6DQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gMS4gIFNGIEluZGV4IDogIFNpbmNlIGl0 IGlzIG1lYW50IGZvciBsb29wIGRldGVjdGlvbiwgIHdvdWxkbid0DQo+Pj4+PiBiZXR0ZXIgdG8g cmVuYW1lIHRoaXMgYXMgIlRUTCI/DQo+Pj4+PiANCj4+Pj4+IDIuICBQYXRoIElkZW50aWZpZXIg OiAgICAyNCBiaXQgcGF0aCBpZGVudGlmaWVyIHNlZW1zIHRvIGJlIHRvbyBsZXNzLg0KPj4+Pj4g QmFzZWQgb24gb3VyIGV4cGVyaWVuY2UgaW4gdHJhZmZpYyBzdGVlcmluZywgIHRoaXMgcGF0aCBp ZGVudGlmaWVyDQo+Pj4+PiBuZWVkcyB0byBlbmNvZGUgZ29vZCBhbW91bnQgb2YgaW5mb3JtYXRp b24gdG8gbWFrZSBpdCB1bmlxdWUuICBGb3INCj4+Pj4+IGV4YW1wbGUsDQo+Pj4+PiAgIHRoaXMg aWRlbnRpZmllciBuZWVkcyB0byBlbmNvZGUgKGluIG91ciBjYXNlKSBzb21lIGluZm9ybWF0aW9u DQo+Pj4+PiByZXByZXNlbnRpbmcgdGhlIGRpc3RyaWJ1dGVkIGNvbnRyb2xsZXIgSUQsICB0ZW5h bnQgSUQsICBmbG93IElELA0KPj4+Pj4gICBTZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlIChpbiBj YXNlIG9mIHNjYWxlLW91dCkgYW5kIGZldyBtb3JlLi4NCj4+Pj4+IE9uZSBzdWdnZXN0aW9uIGlz IHRvIG1ha2UgaXQgNjQgYml0cyB2YWx1ZSAgb3IgdG8gbWFrZSBpdCBldmVuDQo+Pj4+PiBleHRl bmRhYmxlLA0KPj4+Pj4gICBpdCBpcyBnb29kIGlmIHBhdGggaWRlbnRpZmllciBpcyBhbHNvIHJl cHJlc2VudGVkIGluIFRMViBmb3JtLg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IFRoYW5rcw0KPj4+ Pj4gDQo+Pj4+PiBTcmluaQ0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gc2Zj IG1haWxpbmcgbGlzdA0KPj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+Pj4gDQo+Pj4gDQo+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBzZmMgbWFpbGluZyBsaXN0 DQo+Pj4gc2ZjQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCj4+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0 DQo+IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPiANCj4gDQo+IFRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzICh0aGUgIm1l c3NhZ2UiKSBhcmUgY29uZmlkZW50aWFsLCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNz ZWVzLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgZS1tYWlsIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGZyb20geW91ciBzeXN0ZW0uIEluIHRoaXMgY2FzZSwgeW91IGFyZSBub3QgYXV0aG9yaXplZCB0 byB1c2UsIGNvcHkgdGhpcyBtZXNzYWdlIGFuZC9vciBkaXNjbG9zZSB0aGUgY29udGVudCB0byBh bnkgb3RoZXIgcGVyc29uLiBFLW1haWxzIGFyZSBzdXNjZXB0aWJsZSB0byBhbHRlcmF0aW9uLiBO ZWl0aGVyIFFvc21vcyBub3IgYW55IG9mIGl0cyBzdWJzaWRpYXJpZXMgb3IgYWZmaWxpYXRlcyBz aGFsbCBiZSBsaWFibGUgZm9yIHRoZSBtZXNzYWdlIGlmIGFsdGVyZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLg0KPiANCj4gQ2UgbWVzc2FnZSBldCB0b3V0ZXMgc2VzIHBpw6hjZXMgam9pbnRlcyAo Y2ktYXByw6hzIGxlICJtZXNzYWdlIilzb250IGNvbmZpZGVudGllbHMgZXQgw6l0YWJsaXMgw6Ag bCdpbnRlbnRpb24gZXhjbHVzaXZlIGRlIHNlcyBkZXN0aW5hdGFpcmVzLiBTaSB2b3VzIGF2ZXog cmXDp3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCBtZXJjaSBk4oCZZW4gaW5mb3JtZXIgaW1tw6lk aWF0ZW1lbnQgc29uIMOpbWV0dGV1ciBwYXIgY291cnJpZXIgw6lsZWN0cm9uaXF1ZSBldCBk4oCZ ZWZmYWNlciBjZSBtZXNzYWdlIGRlIHZvdHJlIHN5c3TDqG1lLiBEYW5zIGNldHRlIGh5cG90aMOo c2UsIHZvdXMgbuKAmcOqdGVzIHBhcyBhdXRvcmlzw6kgw6AgdXRpbGlzZXIsIGNvcGllciBjZSBt ZXNzYWdlIGV0L291IGVuIGRpdnVsZ3VlciBsZSBjb250ZW51IMOgIHVuIHRpZXJzLiBUb3V0IG1l c3NhZ2Ugw6lsZWN0cm9uaXF1ZSBlc3Qgc3VzY2VwdGlibGUgZCdhbHTDqXJhdGlvbi4gUW9zbW9z IGV0IHNlcyBmaWxpYWxlcyBkw6ljbGluZW50IHRvdXRlIHJlc3BvbnNhYmlsaXTDqSBhdSB0aXRy ZSBkZSBjZSBtZXNzYWdlIHMnaWwgYSDDqXTDqSBhbHTDqXLDqSwgZMOpZm9ybcOpIG91IGZhbHNp ZmnDqS4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K From nobody Tue Feb 3 07:50: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 A6BC11A0A85 for ; Tue, 3 Feb 2015 07:48:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.695 X-Spam-Level: X-Spam-Status: No, score=-0.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TRACKER_ID=1.306] 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 SEzUZdMFanBS for ; Tue, 3 Feb 2015 07:48:53 -0800 (PST) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A6B1A0AF8 for ; Tue, 3 Feb 2015 07:48:53 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0174.001; Tue, 3 Feb 2015 07:48:52 -0800 From: Ron Parker To: Srini Addepalli , Henry Fourie , Sumandra Majee , Nicolas BOUTHORS , Cathy Zhang , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9kHFOTKJIie6ES015pmlGgJ3ZyAGG+AgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgD//7j7oIBXAfSAgAEKegCAALysgIAC+jmAgAHITACAAHT3AIAAE0HA Date: Tue, 3 Feb 2015 15:48:51 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> <0F8583BBE82FA449A8B78417CC07559A09195E9F@SJCEML701-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 03 Feb 2015 07:50:49 -0800 Cc: "nsmurthy@freescale.com" , Jerome TOLLET , Rajesh Kumar Madabushi , Bharat Mota Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 03 Feb 2015 15:48:57 -0000 U3JpbmksDQoNCkxhdGUgYmluZGluZyBjb3VsZCBhbHNvIGJlIHVzZWQgZm9yIHRoZSBtb3JlIGdl bmVyYWwgY2FzZSBvZiBlcXVpdmFsZW50IFNGIGluc3RhbmNlcyBob3N0ZWQgb24gbXVsdGlwbGUg U0ZGJ3MuICAgSXQgZG9lcywgaG93ZXZlciwgcmVxdWlyZSBhIG1vcmUgc29waGlzdGljYXRlZCBk ZWNpc2lvbiBtYWtpbmcgYXQgZWFjaCBwcmV2aW91cyBob3AuICBEdXJpbmcgdGhlIHRyYWlsIGJs YXppbmcgKGkuZS4sIGZpcnN0IHBhY2tldCB3aXRoIGEgcGFydGljdWxhciB7U0ZQIElELCBSU1Ag SUR9KSwgdGhlIGNsYXNzaWZpZXIgc2VsZWN0cyBvbmUgU0ZGIGFtb25nc3QgdGhvc2UgdGhhdCBo b3N0IHRoZSBmaXJzdCBTRiB0eXBlLiAgIFRoYXQgU0ZGIG11c3QgY2hvb3NlIHRoZSBTRkYgKHBl cmhhcHMgaXRzZWxmKSB0aGF0IGhvc3RzIHRoZSBzZWNvbmQgU0YgdHlwZSwgZXRjLiAgIEknbSBu b3Qgc2F5aW5nIHRoYXQgY2VudHJhbCBvcmNoZXN0cmF0aW9uIGlzIHByZWNsdWRlZCwganVzdCB0 aGF0IGxhdGUtYmluZGluZy90cmFpbC1ibGF6aW5nIGlzIHBvc3NpYmxlIGFuZCB3b3J0aCBhbGxv d2luZyBmcm9tIGFuIGFyY2hpdGVjdHVyYWwgcGVyc3BlY3RpdmUuDQoNClRoZSBwcmV2aW91cyBj b21tZW50IHJlZ2FyZGluZyB3aGV0aGVyIFNGRidzIGFyZSByZWFsaXplZCBvbiBjb21tb2RpdHkg Y2xhc3Mgc3dpdGNoZXMgaXMgcmVsZXZhbnQgaGVyZS4gICBBYnNvbHV0ZWx5IHRoYXQgaXMgb25l IGFwcHJvYWNoIGFuZCByZWFsaXRpZXMgb2YgdGhhdCBhcHByb2FjaCBwZXJoYXBzIHB1c2ggeW91 IHRvd2FyZHMgZGVzaXJpbmcgY2VudHJhbCBvcmNoZXN0cmF0aW9uLiAgIEJ1dCwgaXQgaXMgbm90 IHRoZSBvbmx5IGFwcHJvYWNoIHRoYXQgY291bGQgYmUgcmVhbGl6ZWQuICAgIFRoZXJlIGlzIHN1 Y2ggYSBicmVhZHRoIG9mIGFwcGxpY2F0aW9uIGZvciBTRkMgKGkuZS4sIGVudGVycHJpc2VzLCBj YXJyaWVycykgdGhhdCBhbGxvd2luZyBmb3IgZGlmZmVyZW50IGRlcGxveW1lbnQgc3RyYXRlZ2ll cyB3aXRoaW4gdGhlIGFyY2hpdGVjdHVyZSBpcyB2ZXJ5IHZhbHVhYmxlLg0KDQogICBSb24NCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTcmluaSBBZGRlcGFsbGkNClNlbnQ6IFR1ZXNkYXks IEZlYnJ1YXJ5IDMsIDIwMTUgMTozMyBBTQ0KVG86IEhlbnJ5IEZvdXJpZTsgU3VtYW5kcmEgTWFq ZWU7IE5pY29sYXMgQk9VVEhPUlM7IENhdGh5IFpoYW5nOyAnc2ZjQGlldGYub3JnJw0KQ2M6IG5z bXVydGh5QGZyZWVzY2FsZS5jb207IEplcm9tZSBUT0xMRVQ7IFJhamVzaCBLdW1hciBNYWRhYnVz aGk7IEJoYXJhdCBNb3RhDQpTdWJqZWN0OiBbR1JBWU1BSUxdIFJlOiBbc2ZjXSBDb21tZW50cyBv biBTQ0ggRHJhZnQgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMt c2NoLTAyKQ0KDQpIaSBMb3VpcywNCg0KSW4gT3BlbnN0YWNrIGJhc2VkIE5GViB3b3JsZCwgIE5P VkEsIGJhc2VkIG9uIGl0cyBzY2hlZHVsaW5nIHBvbGljeSBhbmQgZmlsdGVycywgY2FuIGNyZWF0 ZSB2TkYgaW5zdGFuY2VzIGluIHZhcmlvdXMgc2VydmVycy4gIEl0IG1lYW5zIHRoYXQgaW5zdGFu Y2VzIG9mIG9uZSBTRiBjYW4gYmUgaW4gdmFyaW91cyBzZXJ2ZXJzIGFuZCBpdCBtZWFucyB0aGF0 IG11bHRpcGxlIFNGRnMgbWF5IGJlIGZyb250IGVuZGluZyBvbmUgc2VydmljZS4gIE15IG9ubHkg cG9pbnQgd2FzIHRoYXQsIHRoaXMgaXMgYSBiaWcgcG9zc2liaWxpdHkgYW5kIHRoYXQgaXMgd2hl cmUgY2VudHJhbGl6ZWQgbG9naWNhbCBjb250cm9sbGVyIHdvdWxkIGNvbWUgaW4gaGFuZHkgaW4g YWxsb2NhdGluZyBSU1AgSURzIGFuZCBwcm9ncmFtbWluZyB0aGVtIGluIFNGRnMgaW4gdGhvc2Ug Y2FzZXMuDQoNCkluIHBoeXNpY2FsIGRlcGxveW1lbnRzLCBvbmUgY291bGQgaGF2ZSBvbmUgU0ZG IGZyb250IGVuZGluZyBhbGwgcGh5c2ljYWwgU0YgaW5zdGFuY2VzLiAgSGVyZSBsYXRlIGJpbmRp bmcgd29ya3MgYXMgc2FtZSBTRkYgaXMgZ29pbmcgdG8gc2VsZWN0IHRoZSBTRiBJbnN0YW5jZSBh cyB3ZWxsIHVzZSBpdCBmb3IgZnVydGhlciBwYWNrZXRzLg0KDQpUaGFua3MNClNyaW5pDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSGVucnkgRm91cmllDQpTZW50OiBNb25kYXksIEZlYnJ1 YXJ5IDAyLCAyMDE1IDM6MzUgUE0NClRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBTdW1hbmRy YSBNYWplZTsgTmljb2xhcyBCT1VUSE9SUzsgQ2F0aHkgWmhhbmc7ICdzZmNAaWV0Zi5vcmcnDQpD YzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDA7IEplcm9tZSBUT0xMRVQ7IE1hZGFidXNoaSBS YWplc2ggS3VtYXItQjM4ODcwOyBNb3RhIEJoYXJhdC1CMTk0NzkNClN1YmplY3Q6IFJlOiBbc2Zj XSBDb21tZW50cyBvbiBTQ0ggRHJhZnQgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC16aGFuZy1zZmMtc2NoLTAyKQ0KDQpTcmluaSwNCiAgICBJbiB5b3VyIGV4YW1wbGUgSSBwcmVz dW1lIHRoYXQgU2Z4LSwgU0Z5LSBhbmQgU0Z6LSBhcmUgYWxsIGluc3RhbmNlcyBvZiB0aGUgc2Ft ZSB0eXBlIG9mIFNGLCBlZy4sIFNmeC0gYXJlIGFsbCBpbnN0YW5jZXMgb2YgYSBGVy4gU28sIGlu IHRoZSBleGFtcGxlLCB5b3UgaGF2ZSBpbnN0YW5jZXMgb2YgYSBnaXZlbiB0eXBlLCBlZywgU0Z4 LSBob21lZCBvbiB0d28gZGlmZmVyZW50IFNGRnMuIFNGeDEgYW5kIFNGeDIgYXJlIGhvbWVkIG9u IFNGRjEgYW5kIFNGeDMgaXMgaG9tZWQgb24gU0ZGMi4gVGhpcyBjYW4gYmUgZG9uZSBidXQgYWRk cyBjb21wbGV4aXR5IHRvIGFuIGltcGxlbWVudGF0aW9uIHdoZXJlIGEgU0ZGIG1heSB3YW50IHRv IGRvIGxvYWQtYmFsYW5jaW5nIG92ZXIgYSBncm91cCBvZiBTRnMuDQoNCkFuIGFsdGVybmF0aXZl IGNvbmZpZ3VyYXRpb24gd291bGQgYmUgd2hlcmUgU0ZzIG9mIGEgZ2l2ZW4gdHlwZSBhcmUgYWxs IGhvbWVkIG9uIHRoZSBzYW1lIFNGRiwgZWcsIFNGeDEtMyBhcmUgYWxsIGhvbWVkIG9uIFNGRjEs IGFsbG93aW5nIGl0IHRvIHBlcmZvcm0gbG9hZC1iYWxhbmNpbmcgYWNyb3NzIHRoaXMgc2V0IG9m IFNGIGluc3RhbmNlcy4NCg0KU2VjdGlvbiA0LjMuMiBvZiB0aGUgU0NIIGRyYWZ0IGRlc2NyaWJl cyB0aGUgdXNlIG9mIHRoZSBSU1AgSUQgaW4gdGhpcyBjYXNlLg0KRWFjaCBTRkYgbWF5IHBlcmZv cm0gYSBsYXRlIGJpbmRpbmcgb2YgZWFjaCBTRiBpbnN0YW5jZSB0byBhIFJTUCB0aHJvdWdoIHRo ZSBob3AtYnktaG9wIHNlbGVjdGlvbiBvZiB0aGUgU0YgaW5zdGFuY2VzIGJ5IHRoZSBTRkZzIGFz IHRoZSBmaXJzdCBwYWNrZXQgZm9yIGEgZmxvdyB0cmF2ZXJzZXMgdGhlIGNoYWluLg0KDQogLSBM b3Vpcw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTcmluaSBBZGRlcGFsbGkNClNlbnQ6IFN1 bmRheSwgRmVicnVhcnkgMDEsIDIwMTUgMTI6MjEgUE0NClRvOiBTdW1hbmRyYSBNYWplZTsgTmlj b2xhcyBCT1VUSE9SUzsgQ2F0aHkgWmhhbmc7ICdzZmNAaWV0Zi5vcmcnDQpDYzogbnNtdXJ0aHlA ZnJlZXNjYWxlLmNvbTsgSmVyb21lIFRPTExFVDsgUmFqZXNoIEt1bWFyIE1hZGFidXNoaTsgQmhh cmF0IE1vdGENClN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQgKGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KDQpIaSBTdW1h bmRyYSwNCg0KSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IG1vcmUgaW5mb3JtYXRpb24gY2FuIGJlIGFk ZGVkIHRvIHRoZSBwcm90b2NvbCBkb2N1bWVudCBvbiBzb21lIHVzZSBjYXNlIHNjZW5hcmlvcyB0 byBtYWtlIGl0IGNsZWFyIG9uIHRoZSB1c2FnZSBvZiBSU1AtSUQgYW5kIFBhdGgtSUQuDQoNCkp1 c3QgdG8gbWFrZSB0aGUgcmVhbGlzdGljIGFuZCBjb21wbGV4IHNjZW5hcmlvDQoNCkluZ3Jlc3NT RkYtLS0tLVNGRjEtLS0tLVNGRjItLS0tLUVncmVzc1NGRg0KDQpJbiB2aXJ0dWFsIHdvcmxkLCBT RkYxIGNvdWxkIGJlIGZyb250ZW5kaW5nIFNGeC0xLCBTRngtMiwgU0Z5LTEgYW5kIFNGRjIgY291 bGQgYmUgZnJvbnQgZW5kaW5nIFNGeC0zLCBTRnktMiwgU0Z6LTEgRm9yIHNpbXBsaWNpdHksIGFz c3VtZSB0aGF0IEluZ3Jlc3NTRkYgaXMgYSBlZGdlIHJvdXRlciAoZWcuIE9wZW5zdGFjayBOZXR3 b3JrIE5vZGUpIEVncmVzc1NGRiBpcyBhIHZpcnR1YWwgc3dpdGNoIGhvc3Rpbmcgc2V0IG9mIFdl YiBTZXJ2ZXIgVk1zLg0KU0ZGMSBhbmQgU0ZGMiBhcmUgYWxzbyB2aXJ0dWFsIHN3aXRjaGVzIGhv c3RpbmcgU0Z4LCBTRnkgYW5kIFNGeiBTZXJ2aWNlIFZNcy4NCg0KQXNzdW1pbmcgdGhhdCBjaGFp biByZXF1aXJlcyBwYWNrZXRzIGdvIHRvIFNGeCwgU0Z5IGFuZCBTRnosICBJbmdyZXNzU0ZGICh3 aXRoIHRoZSBoZWxwIG9mIFNGRiBjb250cm9sbGVyKSBuZWVkcyBzZW5kIHRoZSB0cmFmZmljIHRv IG9uZSBvZiBTRngtMSwgU0Z4LTIgYW5kIFNGeC0zLiBCYXNlZCBvbiBTRi14IHNlbGVjdGlvbiwg aW5ncmVzcyBTRkYgc2VuZHMgdGhlIHRyYWZmaWMgdG8gY29ycmVzcG9uZGluZyBTRkYuICBJZiBT RngtMSBvciBTRngtMiBpcyBjaG9zZW4sIHRoZW4gdGhlIHRyYWZmaWMgaXMgc2VudCB0byBTRkYx LiAgSWYgU0Z4LTMgaXMgY2hvc2VuLCB0aGVuIHRoZSB0cmFmZmljIGlzIHNlbnQgdG8gdGhlIFNG RjIuIE5leHQgaW4gdGhlIGNoYWluLCBzZWxlY3Rpb24gbmVlZHMgdG8gaGFwcGVuIGJldHdlZW4g U0Z5MSBhbmQgU0Z5Mi4gIFNpbWlsYXJseSBmb3IgbmV4dCBzZXJ2aWNlIGluIHRoZSBjaGFpbiwg ICBlaXRoZXIgU0ZGMSBvciBTRkYyICh3aXRoIHRoZSBoZWxwIG9mIGNvbnRyb2xsZXIpIHdpbGwg c2VuZCB0aGUgdHJhZmZpYyB0byBTRi15LiBJdCBkb2VzIHRoaXMgYnkgc2VuZGluZyB0aGUgdHJh ZmZpYyB0byBTRkYyIHRoYXQgaXMgaG9zdGluZyB0aGUgU0Ytei4gQW5kIGZpbmFsbHkgdHJhZmZp YyBuZWVkcyB0byBnbyB0byBFZ3Jlc3NTRkYgdG8gZGVsaXZlciB0byBkZXN0aW5hdGlvbiB3ZWIt c2VydmVyIFZNLg0KDQpFc3NlbnRpYWxseSwgYSBnaXZlbiBTRkYgd291bGQgbmVlZCB0byBiZSBw cm9ncmFtbWVkIHdpdGggdGhlIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gbmV4dCBTRi4gIFRoYXQg aXMgd2hlcmUgcGF0aCBJRCwgUlNQLUlEIGFuZCBPdmVybGF5IG5ldHdvcmtzIHdvdWxkIGhlbHAg LSBQYXRoIElEIGluZGljYXRpbmcgdGhlIGNoYWluIGFuZCBSU1AtSUQgaW5kaWNhdGluZyB0aGUg U0YgaW5zdGFuY2UgQU5EICBWeExBTiBkZXN0aW5hdGlvbiBJUCBpbmRpY2F0aW5nIHRoZSBuZXh0 IFNGRi4gU0ZGIENvbnRyb2xsZXIgaGF2aW5nIHRoZSBuZXR3b3JrIHdpZGUgdmlzaWJpbGl0eSB3 b3VsZCBwcm9ncmFtIHRoZSBTRkZzIGFwcHJvcHJpYXRlbHkuDQoNCkZvciBleGFtcGxlLCBvbiBp bmdyZXNzU0ZGLCBmbG93cyBhcmUgcHJvZ3JhbW1lZCB3aXRoIFJTUC1JRCByZWxhdGVkIHRvIFNG eCBzZXJ2aWNlIGluc3RhbmNlcy4gIEluZ3Jlc3NTRkYsIGFzIHBhcnQgb2YgcGFja2V0IHByb2Nl c3NpbmcsIGFkZHMgdGhlIFJTUC1JRCwgUGF0aF9JRCB0byB0aGUgU0NIIGhlYWRlciBhbmQgZW5j YXBzdWxhdGVzIGluIFZ4TEFOLiAgU0ZGMSBhbmQvb3IgU0ZGMiBhcmUgcHJvZ3JhbW1lZCB3aXRo IGZsb3dzIHRoYXQgbWF0Y2ggb24gUEFUSC1JRCBhbmQgUlNQLUlEIHRvIHNlbmQgdGhlIHRyYWZm aWMgdG8gcmlnaHQgU0Z4IGluc3RhbmNlLiBFc3NlbnRpYWxseSwgcHJldmlvdXMgU0ZGIGFkZHMg dGhlIFNDSCBoZWFkZXIgcmVsYXRlZCB0byBuZXh0IFNGIGluc3RhbmNlcyBhbmQgaG9zdGluZyBT RkYgdXNlcyB0aGF0IGluZm9ybWF0aW9uIHRvIHJvdXRlIHRoZSB0cmFmZmljIHRvIHJpZ2h0IFNG IGluc3RhbmNlLg0KDQpPbiB5b3VyIGNvbmNlcm4gYWJvdXQgcG9vciBzY2FsYWJpbGl0eSA6ICBT RkYgY29udHJvbGxlciBuZWVkIG5vdCBiZSBhIHNpbmdsZSBlbnRpdHkuICBJdCBjb3VsZCBiZSBk aXN0cmlidXRlZCBhbmQgc2NhbGUtb3V0IGVudGl0eSBmb3IgcGVyZm9ybWFuY2Ugc2NhbGluZy4g ICBBbHNvLCBjb250cm9sbGVycyBuZWVkIG5vdCBiZSBpbmZvcm1lZCBvZiBldmVyeSBmaW5lIGdy YW51bGFyIGZsb3cuIEl0IGNvdWxkIGJlIGJhc2VkIG9uIDQtdHVwbGUgb3IgMy10dXBsZSBmbG93 cywgdGhlcmVieSByZWR1Y2luZyB0aGUgbnVtYmVyIG9mIGRlY2lzaW9ucyBsb2dpY2FsIGNvbnRy b2xsZXIgbmVlZCB0byBtYWtlLg0KDQpJIGRpZCBub3QgdW5kZXJzdGFuZCAgeW91ciBjb25jZXJu IG9uICIgVGhlIGFtb3VudCBvZiBzdGF0ZSwgcHJvYmFiaWxpdHkgb2YgYSBpbnN0YW5jZSBnb2lu ZyBkb3duIGJldHdlZW4gc2VsZWN0aW9uIGFuZCBmbG93IGFycml2YWwgZ29lcyB1cC4iICBUaGlz IHNlZW1zIHRvIGJlIGltcG9ydGFudCBhbmQgY2FuIHlvdSBlbGFib3JhdGU/DQoNCg0KVGhhbmtz DQpTcmluaQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNmYyBbbWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3VtYW5kcmEgTWFqZWUNClNl bnQ6IEZyaWRheSwgSmFudWFyeSAzMCwgMjAxNSAyOjUzIFBNDQpUbzogTmljb2xhcyBCT1VUSE9S UzsgQ2F0aHkgWmhhbmc7ICdzZmNAaWV0Zi5vcmcnDQpDYzogSmVyb21lIFRPTExFVA0KU3ViamVj dDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdCAoaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQoNCkhlbGxvLA0KDQpUaGlzIGlzIGFuIGlu dGVyZXN0aW5nIGRpc2N1c3Npb24gYW5kIEkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIHRoZSBt b3RpdmF0aW9uIG9mIGJldHRlci4gVGhlIHRyb3VibGUgd2l0aCBhIHByb3RvY29sIGRvY3VtZW50 IGlzIHRoYXQgaXQgaXMgdHlwaWNhbGx5IGhhcyBpbmFkZXF1YXRlIGRldGFpbCBhYm91dCB0aGUg bG9naWMuIFNvIHRvIGNhc3QgdGhpcyBpbnRvIHNvbWV3aGF0IG9mIGEgY29uY3JldGUgdGVybXMs IGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcuDQoNCg0KDQogICAgICAgU0ZGKHgpICB7IFNmeCgxKSBT ZngoMinigKZTZngobikgfSAgIOKAlOKAlOKAlOKAlD4gICBTRkYoeSkgeyBTZnkoMSkgU2Z5KDIp DQrigKYuIFNmeShtKSB9ICAgOjogTG9naWNhbCBDaGFpbiBpbiBPTkUgZGlyZWN0aW9uIG9ubHku DQoNCiAgICAgICBQSFlTSUNBTCBXT1JMRDoNCiAgICAgICAgICBBKSB0aGUgU0ZGIGNvdWxkIGJl IGENCiAgICAgICAgICAgIC0gY29tcG9uZW50IG9mIFZTV0lUQ0ggKHBpY2sgeW91ciBmYXYgcHJv dG9jb2wgZm9yIGNvbmZpZ3VyaW5nIHRob3NlIGVudGl0aWVzIH0NCiAgICAgICAgICAgIC0gQSBs b2FkIGJhbGFuY2VyDQogICAgICAgICAgICAtIEEgSFcgc3dpdGNoL3JvdXRlciBzb21lIEwyL0wz IGNvbWJvDQoNCiAgICAgICAgICBCKSBTZiBpbnN0YW5jZSBjb3VsZCBiZSwNCiAgICAgICAgICAg ICAgIC0gVmlydHVhbCBtYWNoaW5lLCAjTiBvZiB0aG9zZQ0KICAgICAgICAgICAgICAgLSBwaHlz aWNhbA0KICAgICAgICAgICAgICAgLSBDb250YWluZXIgI00gd2hpY2ggaXMgb2Z0ZW4gNSBvciBt b3JlIHggI04NCiAgICAgICAgICAgICAgIC0gQ2x1c3RlciB0aGF0IHdlIGRvbuKAmXQga25vdw0K DQpJdCBpcyBwb3NzaWJsZSB0byBoYXZlIG11bHRpcGxlIHBoeXNpY2FsIFNGRih4KSBhbHNvLg0K DQpBIHNlbGVjdGlvbiBvZiBhIGdpdmVuIFNGIChzZXJ2aWNlKShpbnN0YW5jZSkgaXMgYSBjYW4g YmUgc2ltcGxlIG9yIGNvbXBsZXguIEZvciBleGFtcGxlIFNGRih4KSBtYXkgaGF2ZSB0aGUgYmVz dCBrbm93bGVkZ2UgdG8gc2VsZWN0IFNmeCgxKSBiYWVkIG9uIGEgZ2l2ZW4gY3JpdGVyaW9uICh3 aGljaCBjb3VsZCBiZSBwYXJ0IG9mIHRoZSBwb2xpY3kpLiAgVGhlbiBJIGRvbuKAmXQgc2VlIGEg cmVhc29uIHRvIGhhdmUgUlNQLg0KDQpJdCBpcyBwb3NzaWJsZSB0aGF0IGxvb2t1cCAocGF0aCkg QCBTRkYoeCkgcHJvZHVjZXMgYSBzcGVjaWZpYyBpbnN0YW5jZSBvZiBTZnkgYW5kIHllcyB0aGVu IHNvbWV0aGluZyBsaWtlIFJTUCB3b3VsZCBiZSByZXF1aXJlZC4gQnV0IEkgd291bGQgYXJndWUg dGhhdCBqb2IgU0ZGKHkpIGNhbiBhbHNvIGJlIHN1YnN1bWVkIGJ5IFNGRih4KS4NCg0KSXMgaXQg cG9zc2libGUgZm9yIGEgY2VudHJhbCBjb250cm9sbGVyIHRvIHBpY2sgZWFjaCBpbnN0YW5jZSBv ZiBzZXJ2aWNlLCBidXQgc3VjaCBhbiBpbXBsZW1lbnRhdGlvbiB0ZW5kcyB0byBzY2FsZSBwb29y bHkuIFRoZSBhbW91bnQgb2Ygc3RhdGUsIHByb2JhYmlsaXR5IG9mIGEgaW5zdGFuY2UgZ29pbmcg ZG93biBiZXR3ZWVuIHNlbGVjdGlvbiBhbmQgZmxvdyBhcnJpdmFsIGdvZXMgdXAuDQoNClJlZ2Fy ZHMuDQoNClN1bWFuZHJhDQoNCg0KDQpPbiAxLzMwLzE1LCAzOjM4IEFNLCAiTmljb2xhcyBCT1VU SE9SUyIgPE5pY29sYXMuQk9VVEhPUlNAcW9zbW9zLmNvbT4NCndyb3RlOg0KDQo+SGVsbG8gQ2F0 aHksDQo+DQo+SW5kZWVkIHRoZSBub3Rpb24gb2YgInJlbmRlcmVkIHNlcnZpY2UgcGF0aCBJRCIo UlNQIElEKSBzZWVtcyByZWxldmFudCANCj5hcyB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IHN0 aXB1bGF0ZXMgdGhhdCB0aGUgU2VydmljZSBGdW5jdGlvbiBQYXRoDQo+KFNGUCkgcHJvdmlkZXMg YW4gYWJzdHJhY3Qgbm90aW9uIG9mIGEgc2VydmljZSBjaGFpbiwgd2hpbGUgdGhlIFJTUCBpcyAN Cj5hIGNvbnN0cmFpbmVkIGxpc3Qgb2YgbG9jYXRpb25zLg0KPg0KPlNGQyBoZWFkZXIgIlNlcnZp Y2UgUGF0aCBJZGVudGlmaWVyIiAoU1BJKSAgaXMgdXNlZCBpbiBib3RoIE5TSCBhbmQgU0NIIA0K PnByb3RvY29sIGFuZCBpbiBib3RoIGNhc2Ugc2VlbSB0byBpZGVudGlmeSB0byBhIHBhcnRpY3Vs YXIgU0ZQLg0KPg0KPk5TSCh2NSkgZm9yIGV4YW1wbGUgc3RhdGVzIHRoYXQNCj4iIEFzIGRlc2Ny aWJlZCBhYm92ZSwgTlNIIGNvbnRhaW5zIGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgKFNQSSkg YW5kDQo+ICAgYSBzZXJ2aWNlIGluZGV4IChTSSkuICBUaGUgU1BJIGlzLCBhcyBwZXIgaXRzIG5h bWUsIGFuIGlkZW50aWZpZXIuDQo+ICAgVGhlIFNQSSBhbG9uZSBjYW5ub3QgYmUgdXNlZCB0byBm b3J3YXJkIHBhY2tldHMgYWxvbmcgYSBzZXJ2aWNlIHBhdGguDQo+ICAgUmF0aGVyIHRoZSBTUEkg cHJvdmlkZSBhIGxldmVsIG9mIGluZGlyZWN0aW9uIGJldHdlZW4gdGhlIHNlcnZpY2UNCj4gICBw YXRoL3RvcG9sb2d5IGFuZCB0aGUgdGhlIG5ldHdvcmsgdHJhbnNwb3J0LiAgRnVydGhlcm1vcmUs IHRoZXJlIGlzDQo+ICAgbm8gcmVxdWlyZW1lbnQsIG9yIGV4cGVjdGF0aW9uIG9mIGFuIFNQSSBi ZWluZyBib3VuZCB0byBhIHByZS0NCj4gICBkZXRlcm1pbmVkIG9yIHN0YXRpYyBuZXR3b3JrIHBh dGguIg0KPg0KPlN0aWxsIE5TSCh2NSkgIHNob3dzIHRoYXQgU1BJIChub3QgYSBSU1AgSUQpICBz aG91bGQgYmUgcGFydCBvZiB0aGUga2V5IA0KPmVsZW1lbnQgb2YgYW4gU0ZGIHRvIGxvb2t1cCBv biBmb3J3YXJkaW5nIHRhYmxlcy4gIEJ1dCBJIGNvdWxkIG5vdCBmaW5kIA0KPmluIE5TSCAgaG93 IHRvIHVzZSB0aGUgbm90aW9uIG9mIFJlbmRlcmVkIHNlcnZpY2UgcGF0aCB3aGljaCB3YXMgDQo+ ZGVmaW5lZCBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50Lg0KPg0KPllvdSBwcm9wb3NhbCBz ZWVtcyB0byBtZSB2ZXJ5IHVzZWZ1bCwNCj4NCj5BbiBSU1AgSUQgKGluZGVwZW5kZW50IG9mIHRo ZSBTUEkgYnV0IHBhcnQgb2YgdGhlIHNhbWUgbmFtZSBzcGFjZSkgDQo+Y291bGQgYmUgdXNlZCB0 aGUgc2FtZSB3YXkgYXMgU1BJIGJ5IFNGRiBmb3IgZXhhbXBsZSwgYWxsb3dpbmcgYSANCj5TZXJ2 aWNlIENsYXNzaWZpZXIgdG8gY29udHJvbCByZW1vdGUgbG9hZCBiYWxhbmNpbmcgZm9yIGV4YW1w bGUuDQo+DQo+VGhpcyBzYWlkIHRoZSBSU1AgSUQgdmFsdWVzIGNvdWxkIGJlIHJlbGF0aXZlIHRv IGEgcGFydGljdWxhciBTZXJ2aWNlIA0KPlBhdGgsIHdoaWNoIHdvdWxkIHByZXZlbnQgdXNpbmcg dGhlbSBhcyB3ZSBkbyBmb3IgU1BJIGluIFNGRiBmb3J3YXJkaW5nIA0KPnRhYmxlcy4NCj4NCj5X ZSBtYXkgd2FudCB0byBwcmVjaXNlIGlmIHRoZSBSU1AgSUQgaXMgdG8gYmUgcmVsYXRpdmUgb2Yg YWJzb2x1dGUsIGFzIA0KPml0IHNob3VsZCBoYXZlIGFuIGltcGFjdCBvbiBmb3J3YXJkaW5nIHRh YmxlIHN0cnVjdHVyZSBpZiB3ZSBkZWNpZGUgdG8gDQo+dXNlIHRoaXMgY29uY2VwdC4NCj4NCj5Q ZXJzb25hbGx5IEkgbGlrZSB0aGUgbm90aW9uIG9mIGEgcmVsYXRpdmUgUlNQIElELCBhcyB3ZSBj b3VsZCB0aGVuIHVzZSANCj5zb21lIGNvbnZlbnRpb25zLCBzdHJ1Y3R1cmUgaXQsIHBvc3NpYmx5 IGV4dGVuZGluZyBpdHMgdXNlLg0KPg0KPk5pY29sYXMNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPkZyb206IENhdGh5IFpoYW5nIFttYWlsdG86Q2F0aHkuSC5aaGFuZ0BodWF3ZWku Y29tXQ0KPlNlbnQ6IGpldWRpIDI5IGphbnZpZXIgMjAxNSAyMDo0NA0KPlRvOiBDYXRoeSBaaGFu ZzsgU3JpbmkgQWRkZXBhbGxpOyBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4NCj5I YWxwZXJuOyAnc2ZjQGlldGYub3JnJw0KPkNjOiBuc211cnRoeUBmcmVlc2NhbGUuY29tDQo+U3Vi amVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPihodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4NCj5IaSBldmVyeW9uZSwNCj4N Cj5XZSBoYXZlIHVwbG9hZGVkIGEgbmV3IFNDSCB2ZXJzaW9uICgzKSB3aGljaCBhZGRzIGRlZmlu aXRpb24gb2YgYSBuZXcgDQo+bWV0YWRhdGEgdHlwZSBmb3IgdGhlIGZsb3cgSUQgdG8gc3VwcG9y dCBsb2FkIGJhbGFuY2luZyBhbW9uZyBTRiANCj5pbnN0YW5jZXMgYW5kIG1pdGlnYXRlIHRoZSBw b3RlbnRpYWwgaXNzdWUgb2YgIm5vdCBlbm91Z2ggcGF0aCBJRCIuIFRoZSANCj5mbG93IElEIGlz IG5hbWVkICJyZW5kZXJlZCBzZXJ2aWNlIHBhdGggSUQiIGluIHRoZSBkcmFmdC4gUGxlYXNlIHJl ZmVyIA0KPnRvIHNlY3Rpb24gNC4zLjIgb2YgDQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtemhhbmctc2ZjLXNjaC8NCj5mb3IgZGV0YWlsIGRlc2NyaXB0aW9uLg0KPg0K PkluIGl0cyBwcmV2aW91cyB2ZXJzaW9uLCBTQ0ggZGVmaW5lcyBhICJCeXBhc3MgYml0IiBpbiB0 aGUgYmFzZSBoZWFkZXIuDQo+VGhpcyBiaXQgZW5hYmxlcyB0aGUgU0YgdG8gcHJvdmlkZSBmZWVk YmFjay9ub3RpZmljYXRpb24gdmlhIHRoZSBkYXRhIA0KPnBhdGggdG8gaXRzIGNvbm5lY3Rpbmcg U0ZGIGFib3V0IHdoZXRoZXIgdGhlIHJlbWFpbmluZyBwYWNrZXRzIG9mIHRoZSANCj5TRkMgc2hv dWxkIGJ5cGFzcyB0aGF0IFNGLiBUaGlzIGlzIHVzZWZ1bCBpbiB0aGUgY2FzZSB0aGF0IG9ubHkg dGhlIA0KPmZpcnN0IGZldyBwYWNrZXRzIG9mIGEgZmxvdyBuZWVkIHRvIGdvIHRvIGEgU0YgKHN1 Y2ggYXMgYSBEUEkgb3IgRlcgb3INCj5JRFMpIGFuZCByZW1haW5pbmcgcGFja2V0cyBjYW4gYnlw YXNzIHRoYXQgU0YsIHRodXMgc2F2aW5nIHRoZSANCj5leHBlbnNpdmUgU0YgcmVzb3VyY2UgYW5k IHJlZHVjaW5nIGRhdGEgcGF0aCBsYXRlbmN5Lg0KPg0KPkIgYml0OiBUaGUgQiAoQnlwYXNzKSBi aXQsIHdoZW4gc2V0IHRvIDEsIGl0IGlzIHVzZWQgYnkgYSBTZXJ2aWNlDQo+ICAgICAgIEZ1bmN0 aW9uIHRvIHNpZ25hbCB0byBpdHMgU2VydmljZSBGdW5jdGlvbiBGb3J3YXJkZXIgdGhhdCBubw0K PiAgICAgICBmdXJ0aGVyIHBhY2tldHMgYXJlIHRvIGJlIHNlbnQgdG8gaXQgZm9yIHRoZSBmbG93 IHNwZWNpZmllZCBpbiANCj5lbmNhcHN1bGF0ZWQgcGFja2V0Lg0KPg0KPkluIGFkZGl0aW9uLCBT Q0ggZGVmaW5lcyBhIG1ldGFkYXRhIHR5cGUgZm9yIEdlbmVyaWMgQ29udGV4dCBCbG9jaywgDQo+ d2hpY2ggaXMgb3B0aW9uYWwgYW5kIGNhbiBiZSB1c2VkIGlmIG5lZWRlZCB0byBjYXJyeSBhbnkg dmVuZG9yJ3MgDQo+c3BlY2lmaWMgIkNvbnRleHQgSGVhZGVyIi4NCj4NCj5BbnkgY29tbWVudHMg b24gdGhlc2UgbmV3IGFkZGl0aW9ucz8NCj4NCj5UaGFua3MsDQo+Q2F0aHkNCj4NCj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQ2F0aHkgWmhhbmcNCj5TZW50OiBGcmlkYXksIERlY2VtYmVyIDA1 LCAyMDE0IDExOjQ3IEFNDQo+VG86IFNyaW5pIEFkZGVwYWxsaTsgUmVpbmFsZG8gUGVubm8gKHJl cGVubm8pOyBKb2VsIE0uIEhhbHBlcm47IA0KPidzZmNAaWV0Zi5vcmcnDQo+Q2M6IG5zbXVydGh5 QGZyZWVzY2FsZS5jb20NCj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0 DQo+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0K Pg0KPlJvbiwgTG91aXMsIE15byBhbmQgSSBoYXZlIGJlZW4gZGlzY3Vzc2luZyBvZmYgbGluZSBs YXN0IGZldyB3ZWVrcyANCj5hYm91dCBkZWZpbmluZyBhIG1ldGFkYXRhIHR5cGUgZm9yIGZsb3cg SUQgaW4gYWRkaXRpb24gdG8gdGhlIHBhdGggSUQgDQo+b2YgdGhlIG1haW4gaGVhZGVyIHRvIHN1 cHBvcnQgbG9hZCBiYWxhbmNpbmcgYW1vbmcgU0YgaW5zdGFuY2VzLiBXZSANCj53aWxsIGRlZmlu ZSBhIFRMViB0eXBlIGZvciB0aGUgZmxvdyBJRC4gVGhlIGNvbWJpbmF0aW9uIG9mICJwYXRoIElE ICsgZmxvdyBJRCINCj5zcGVjaWZpZXMgYSByZWFsaXplZCBzZXJ2aWNlIGNoYWluIGluc3RhbmNl IHBhdGguIEl0IGlzIGxlZnQgdG8gdGhlIA0KPmRlc2lnbi9pbXBsZW1lbnRhdGlvbiB3aGV0aGVy IHRvIHVzZSBhIGNlbnRyYWxpemVkIG1ldGhvZCBvciBhIA0KPmRpc3RyaWJ1dGVkIG1ldGhvZCB0 byBiaW5kIHRoZSBmbG93IElEIHRvIGEgcmVhbGl6ZWQgc2VydmljZSBpbnN0YW5jZSANCj5wYXRo IGFsdGhvdWdoIG91ciBvcmlnaW5hbCB0aG91Z2h0IGlzIGZvciBkaXN0cmlidXRlZCBMQiB1c2Fn ZS4gSSBhbSANCj5ub3Qgc3VyZSBpZiB3ZSBuZWVkIGEgYml0IGluIHRoZSBoZWFkZXIgdG8gZGVu b3RlIHdoZXRoZXIgdGhlcmUgYXJlIA0KPm1vcmUgcGF0aCBJRCBiaXRzICh3ZSBjYWxsIGl0IGZs b3cgSUQpIGluIHRoZSBtZXRhZGF0YSBmaWVsZHMgc2luY2UgDQo+d2hlbiB5b3UgcGFyc2UgdGhl IFRMViBtZXRhZGF0YSwgeW91IHdpbGwga25vdyB3aGV0aGVyIHRoZXJlIGFyZSBmbG93IElEIGJp dHMgb3Igbm90Lg0KPk5vdGUgdGhhdCBpZiBtdWx0aXBsZSBzZXNzaW9ucyBzaGFyZSB0aGUgc2Ft ZSByZWFsaXplZCBzZXJ2aWNlIGluc3RhbmNlIA0KPnBhdGgsIHRoZXkgd2lsbCBzaGFyZSB0aGUg c2FtZSAicGF0aCBJRCsgZmxvdyBJRCIuICBXZSBjYW4gYWxzbyANCj5jb25zaWRlciBleHRlbmRp bmcgdGhlIG51bWJlciBvZiBiaXRzIHRvIDMyIGlmIHRoYXQgaXMgdGhlIGNvbnNlbnN1cy4NCj5X ZSB3aWxsIHBvc3QgYW4gdXBkYXRlZCBkcmFmdCBkZXNjcmliaW5nIHRoZXNlIHNvb24uDQo+DQo+ VGhhbmtzLA0KPkNhdGh5DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBz ZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNyaW5pIEFkZGVw YWxsaQ0KPlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDUsIDIwMTQgNzoxNyBBTQ0KPlRvOiBSZWlu YWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4gSGFscGVybjsgJ3NmY0BpZXRmLm9yZycNCj5D YzogbnNtdXJ0aHlAZnJlZXNjYWxlLmNvbQ0KPlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBv biBTQ0ggRHJhZnQNCj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNm Yy1zY2gtMDIpDQo+DQo+DQo+W1JQXSBEYXRhIHBsYW5lIGVmZmljaWVuY3kuDQo+DQo+U1JJTkk+ IEkgYW0gbm90IHNvIHN1cmUgYWJvdXQgZGF0YSBwbGFuZSBlZmZpY2llbmN5LiAgTW9zdCBvZiB0 aGUNCj5wcm9jZXNzb3JzIHdvcmsgZ29vZCBpZiB0aGUgbnVtYmVyIG9mIGJpdHMgYXJlIGVpdGhl ciAzMiBvciA2NC4gIElmIGl0IA0KPmlzDQo+MjQgYml0cywgdGhlbiBvbmUgbmVlZHMgdG8gZG8g bWFza2luZyBhbmQgc2hpZnRpbmcgYmVmb3JlIHRoZSB2YWx1ZSBpcw0KPnVzZWQgdG8gZG8gYW55 IGxvb2t1cC4gICBCdXQsIHRoaXMgZGlzY3Vzc2lvbiBjYW4gZ28gaW50byBkaWZmZXJlbnQNCj5k aXJlY3Rpb24gOi0pLCBpdCBtYXkgbm90IGJlIGdvb2QgdG8gZ28gaW4gdGhhdCBkaXJlY3Rpb24u DQo+DQo+V2hlcmUgZG8gd2UgZHJhdyB0aGUgbGluZT8gMzItYml0cywgNjQtYml0cywNCj4xMjgg Yml0cz8gSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRoZSBTZXJ2 aWNlIFBhdGggDQo+aGVhZGVyIGFuZCBpZiB5b3UgbmVlZCB0byBjb252ZXkgbW9yZSBiaXRzIHlv dSBuZWVkIHRvIHVzZSB0aGUgY29udGV4dCANCj5oZWFkZXJzLg0KPg0KPlNSSU5JPiBUaGlzIGlz IGEgZ29vZCBwb2ludC4gIFRoaXMgc2hvdWxkIHdvcmsgZmluZSBhcyBsb25nIGFzIHRoZXJlIGlz DQo+d2F5IHRvIGNvbnZleSBpbiB0aGUgbWFpbiBoZWFkZXIgdGhhdCB0aGUgZXh0ZW5zaW9uIHRv IHBhdGggSUQgaXMgDQo+YXZhaWxhYmxlIGluIHNvIGFuZCBzbyBUTFYgZmllbGQuICBUaGF0IHNo b3VsZCB3b3JrIHRvby4NCj4NCj5UaGFua3MNCj5TcmluaQ0KPg0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5Gcm9tOiBSZWluYWxkbyBQZW5ubyAocmVwZW5ubykg PHJlcGVubm9AY2lzY28uY29tPg0KPlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgNSwgMjAxNCA3OjA4 IEFNDQo+VG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IEpvZWwgTS4gSGFscGVybjsgJ3NmY0Bp ZXRmLm9yZycNCj5DYzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDANCj5TdWJqZWN0OiBSZTog W3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPg0KPk9uIDEyLzUvMTQsIDY6NTQgQU0sICJTcmlu aSBBZGRlcGFsbGkiIDxzYWRkZXBhbGxpQGZyZWVzY2FsZS5jb20+IHdyb3RlOg0KPg0KPj4NCj4+ SW4gcmVhbCBkZXBsb3ltZW50cywgbnVtYmVyIG9mIGFjdGl2ZSBwYXRoIElEcyBhcmUgdmVyeSBs ZXNzZXIgdGhhbiANCj4+Ml42NCwgYnV0IHRoZXJlIGlzIGEgZ29vZCBwb3NzaWJpbGl0eSBvZiB0 aGUgbnVtYmVyIGJlaW5nIG1vcmUgdGhhbg0KPj4yXjI0ICgxNk0pLg0KPj4gSSB0aGluayBiaWdn ZXIgcG9pbnQgaXMgdGhhdCB3aHkgcmVzdHJpY3QgdGhpcyBpbiB0aGUgc3RhbmRhcmRzPyBXaGF0 IA0KPj5hZHZhbnRhZ2UgZG8gd2UgaGF2ZSByZXN0cmljdGluZyB0aGlzIHNpemUgdG8gMjQgYml0 cz8NCj4NCj5bUlBdIERhdGEgcGxhbmUgZWZmaWNpZW5jeS4gV2hlcmUgZG8gd2UgZHJhdyB0aGUg bGluZT8gMzItYml0cywgDQo+NjQtYml0cywNCj4xMjggYml0cz8gSSB0aGluayB3ZSBzaG91bGQg aGF2ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRoZSBTZXJ2aWNlIFBhdGggDQo+aGVhZGVyIGFuZCBp ZiB5b3UgbmVlZCB0byBjb252ZXkgbW9yZSBiaXRzIHlvdSBuZWVkIHRvIHVzZSB0aGUgY29udGV4 dCANCj5oZWFkZXJzLg0KPg0KPg0KPj4NCj4+VGhlcmUgY2FuIGJlIGRlcGxveW1lbnRzLCB3aGVy ZSBTRkMgY29udHJvbGxlciAoTG9naWNhbGx5IGNlbnRyYWwsIGJ1dA0KPj5kaXN0cmlidXRlZCkg IGl0c2VsZiBjYW4gZG8gdGhlIFNGIGluc3RhbmNlIHNlbGVjdGlvbiBvbiBwZXINCj4+Y29ubmVj dGlvbi9zZXNzaW9uIGJhc2lzLCB0aGVyZWJ5IGF2b2lkaW5nIHRoZSBMQnMgZm9yIHNlcnZpY2Vz LiAgIEluIG15DQo+PnZpZXcsIGFzc3VtcHRpb24gdGhhdCB0aGVyZSB3aWxsIGJlIExCIFNGIGZv ciBlYWNoIHNjYWxlLW91dCBzZXJ2aWNlIA0KPj5pbiB0aGUgY2hhaW4gaXMgbm90IHZhbGlkIGlu IGFsbCBjYXNlcy4NCj4+DQo+PlRoYW5rcw0KPj5TcmluaQ0KPj4NCj4+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5Gcm9tOiBSZWluYWxkbyBQZW5ubyAocmVwZW5u bykgPHJlcGVubm9AY2lzY28uY29tPg0KPj5TZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgNCwgMjAx NCAxOjE3IFBNDQo+PlRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47 IHNmY0BpZXRmLm9yZw0KPj5DYzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDANCj4+U3ViamVj dDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4oaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+Pg0KPj5JZiBJIHVuZGVyc3Rvb2Qg eW91LCBJIGRvIG5vdCB0aGluayB0aGlzIGlzIHJlYWxpc3RpYy4gQXJlIHlvdSBzYXlpbmcgDQo+ PnlvdSBuZWVkIDY0LWJpdHMgb2YgcGF0aHMgYW5kIHRoZW4gd2lsbCBtb25pdG9yIHRoZW0gYWxs PyBEbyBmYXVsdCANCj4+dG9sZXJhbmNlIGFuZCBPQU0gZm9yIDJeNjQtYml0cyB3b3J0aCBvZiBw YXRocz8gSnVzdCBmb3IgY29tcGFyaXNvbiwgDQo+Pml0wrlzIGxpa2UgbWFuYWdpbmcgYW5kIG1v bml0b3JpbmcgdGhlIGVudGlyZSBJUHY2IGhvc3QgcmFuZ2UsIG9uZS1ieS1vbmUuDQo+Pg0KPj5B bnl3YXksIEkgZG8gbm90IGV4cGVjdCBldmVyeSBzaW5nbGUgcGVybXV0YXRpb25zIHRvIGJlIGEg ZGlmZmVyZW50IHBhdGguDQo+Pg0KPj5JZiBlYWNoIHNlcnZpY2UgaGFzIDI1NiBkZXZpY2VzIHBy b3ZpZGluZyBzaW1pbGFyIHNlcnZpY2UsIHlvdSBzaG91bGQgDQo+Pm1vc3QgbGlrZWx5IHVzZSBs b2FkLWJhbGFuY2luZyBhbmQgdGhlbiB5b3Ugd291bGQgaGF2ZSBhIHNpbmdsZSAob3IgYQ0KPj5m ZXcpIHBhdGhzLiBUaGVyZSBpcyBzb21lIGRpc2N1c3Npb24gZ29pbmcgb24gTEIuDQo+Pg0KPj5G cm9tIGEgZGF0YSBwbGFuZSBwZXJzcGVjdGl2ZSwgdGhlIHBhdGggaXMgdWx0aW1hdGVseSBkZWZp bmVkIGJ5IHRoZSANCj4+U0ZGcyB0cmF2ZXJzZWQgYW5kIHNlcnZpY2VzIHByb3ZpZGVkLCBub3Qg YnkgYSBzcGVjaWZpYyBJUDpwb3J0IHRoYXQgDQo+PnRoZSBkZXZpY2UgcHJvdmlkaW5nIHRoZSBz ZXJ2aWNlIHNpdHMgb24uIFdlbGwsIGF0IGxlYXN0IGZyb20gYQ0KPj5HUEUrTlNIIHBlcnNwZWN0 aXZlLg0KPj4NCj4+DQo+Pk9uIDEyLzQvMTQsIDEyOjU3IFBNLCAiU3JpbmkgQWRkZXBhbGxpIiA8 c2FkZGVwYWxsaUBmcmVlc2NhbGUuY29tPiB3cm90ZToNCj4+DQo+Pj5JZiBJIHRha2UgYSBjaGFp biB3aXRoIDUgc2VydmljZXMgd2l0aCBlYWNoIHNlcnZpY2UgIHNheSBoYXZpbmcgMjU2IA0KPj4+ aW5zdGFuY2VzIGZvciBzY2FsZS1vdXQsIHBvc3NpYmxlIG51bWJlciBvZiBwYXRocyBhcmUNCj4+ PjI1NioyNTYqMjU2KjI1NioyNTYgPSAweEZGIEZGIEZGIEZGIEZGLiBPbmUgcmVxdWlyZXMgMzMg Yml0cyBpbiB0aGlzIA0KPj4+Y2FzZS4gIElmIHRoZXJlIGFyZSBtb3JlIHNlcnZpY2VzIGluIHRo ZSBjaGFpbiBvciBtb3JlIGNoYWlucyBvciBtb3JlIA0KPj4+aW5zdGFuY2VzIGZvciBzY2FsZS1v dXQsIHRoZW4gaXQgY291bGQgZ28gdG8gYmlnIG51bWJlciB2ZXJ5IGZhc3QuDQo+Pj4NCj4+PkFz IEkgbWVudGlvbmVkIG15IHByZWZlcmVuY2UgaXMgdG8gbWFrZSB0aGUgcGF0aCBJRCBzaXplIGZs ZXhpYmxlIGZvciANCj4+PmZ1dHVyZSBncm93dGguIElmIHRoYXQgaXMgcGVyY2VpdmVkIGFzIGNv bXBsZXgsIHRoZW4gZ29pbmcgZm9yIDY0Yml0IA0KPj4+aXMgc2FmZXIgYmV0Lg0KPj4+DQo+Pj5U aGFua3MNCj4+PlNyaW5pDQo+Pj4NCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+PkZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+ Pj5TZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMDQsIDIwMTQgMTI6MDUgUE0NCj4+PlRvOiBBZGRl cGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47IHNmY0BpZXRmLm9yZw0KPj4+Q2M6 IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+Pj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVu dHMgb24gU0NIIERyYWZ0DQo+Pj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpo YW5nLXNmYy1zY2gtMDIpDQo+Pj4NCj4+PkEgY29udHJvbGxlciAob3Igb3RoZXIgZGVjaXNpb24g bG9naWMpIGNhbiBjZXJ0YWlubHkgYmUgYXdhcmUgb2Ygc3VjaCANCj4+PmNvbmNlcm5zLg0KPj4+ QnV0IHRoZSBudW1iZXIgb2Ygc2VydmljZSBmdW5jdGlvbiBwYXRocyBpcyBub3QgcmVsYXRlZCB0 byB0aGUgbnVtYmVyIA0KPj4+b2YgZmxvd3Mgb3IgdGhlIG51bWJlciBvZiB0ZW5hbnRzLiAgSXQg aXMgcmVsYXRlZCB0byB0aGUgbnVtYmVyIG9mIA0KPj4+Y29tYmluYXRpb25zIG9mIHNlcnZpY2Vz IGFuZCB0aGUgcG9saWNpZXMgZm9yIHNlcnZpY2UgZnVuY3Rpb24gDQo+Pj5zZWxlY3Rpb24uDQo+ Pj4gV2hpbGUgdGhhdCBjYW4gYmUgYSBsYXJnZSBudW1iZXIsIEkgc3VyZSBob3BlIGl0IGRvZXMg bm90IGNvbWUgY2xvc2UgDQo+Pj50byBzYXR1cmF0aW5nIDI0IGJpdHMuDQo+Pj4NCj4+Pkhhdmlu ZyBzYWlkIHRoYXQsIGlmIHdlIHRoaW5rIHRoYXQgMjQgYml0cyBpcyBvbmx5IGp1c3QgZW5vdWdo LCB0aGVuIA0KPj4+d2Ugb3VnaHQgdG8gdXNlIDMyLiAgRnJvbSB3aGVyZSBJIHNpdCwgSSB3b3Vs ZCBub3JtYWxseSBleHBlY3QgMTYgDQo+Pj5iaXRzIHRvIGJlIG1vcmUgdGhhbiBzdWZmaWNpZW50 LCB3aGljaCBpcyB3aHkgSSBhbSBjb21mb3J0YWJsZSB3aXRoIDI0Lg0KPj4+SGF2aW5nIHNhaWQg dGhhdCwgdGhlIGZpZWxkIHNpemUgaXMgbm90IGEgYmlnIGRlYWwgdG8gbWUuDQo+Pj4NCj4+Pllv dXJzLA0KPj4+Sm9lbA0KPj4+DQo+Pj5PbiAxMi80LzE0LCAyOjAxIFBNLCBTcmluaSBBZGRlcGFs bGkgd3JvdGU6DQo+Pj4+DQo+Pj4+IEkgd2FzIG5vdCBpbXBseWluZyB0aGF0IHBhdGggSUQgc2hv dWxkIGhhdmUgaW5mb3JtYXRpb24gaW4gcmVnYXJkcyANCj4+Pj50byB0ZW5hbnQvY29udHJvbGxl ci9mbG93L3NjYWxlLW91dC4gIEJ1dCBTRkMgY29udHJvbGxlcnMgc2hvdWxkIA0KPj4+PmtlZXAg dGhlc2UNCj4+Pj5pbiBtaW5kIHRvIGFzc2lnbiB0aGUgcGF0aCBJRC4gICAgQSBkZXBsb3ltZW50 IGNhbiBoYXZlIG11bHRpcGxlDQo+Pj4+dGVuYW50cywgZWFjaCB0ZW5hbnQgY2FuIGhhdmUgbXVs dGlwbGUgbmV0d29ya3MsICB0aGVyZSBjb3VsZCBiZSANCj4+Pj5taWxsaW9ucyBvZiBmbG93cyBp biBlYWNoIG9mIHRob3NlIG5ldHdvcmtzLiAgQW5kIGNvbnNpZGVyaW5nIGFsbCANCj4+Pj50aGVz ZSwNCj4+Pj4gMjQgYml0IHBhdGggSUQgbWF5IG5vdCBiZSBhYmxlIHRvIHJlcHJlc2VudCBwYXRo cyBmb3IgdGhlc2UgZmxvd3MuDQo+Pj4+SGVuY2UsIEkgd2FzIHdvbmRlcmluZyB3aGV0aGVyIHBh dGggSUQgY2FuIGJlIGV4dGVuZGVkIHRvIDY0IGJpdHMgb3IgDQo+Pj4+bWFrZSBpdCBmbGV4aWJs ZS4NCj4+Pj4NCj4+Pj4gVGhhbmtzDQo+Pj4+IFNyaW5pDQo+Pj4+DQo+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJu IDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4+PiBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgNCwg MjAxNCA3OjQyIEFNDQo+Pj4+IFRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBzZmNAaWV0Zi5v cmcNCj4+Pj4gQ2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+Pj4+IFN1YmplY3Q6IFJl OiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4+Pj4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4+Pg0KPj4+PiBUaGUgSW5kZXggaXMg bm90IGp1c3QgZm9yIGxvb3AgcHJldmVudGlvbi4gIEluIHRoZSBjYXNlIG9mIA0KPj4+PmFtYmln dWl0eSwgdGhlIGluZGV4IHRlbGxzIHRoZSBTRkYgd2hlcmUgaW4gdGhlIHBhdGggdGhlIHBhY2tl dCANCj4+Pj5jdXJyZW50bHkgcmVzaWRlcy4NCj4+Pj4gICAgVGhlcmUgYXJlIG11bHRpcGxlIHdh eXMgc3VjaCBhbWJpZ3VpdHkgY2FuIG9jY3VyLg0KPj4+Pg0KPj4+PiBUaGUgUGF0aCBJZGVudGlm aWVyIGlzIHNwZWNpZmljYWxseSBub3QgZXhwZWN0ZWQgdG8gaW5jbHVkZSANCj4+Pj4gY29udHJv bGxlciBJRCBvciBUZW5hbnQgSUQuICBXaGlsZSBhIGRlcGxveWVyIGNhbiBoYXZlIGEgcGF0aCBw ZXIgDQo+Pj4+IHRlbmFudCwgdGhlIGFyY2hpdGVjdHVyZSBzdGlsbCBkb2VzIG5vdCB0cmVhdCB0 aGUgcGF0aCBJRCBhcyBhIA0KPj4+PiB0ZW5hbnQgSUQuICBUZW5hbnQgSUQsIGNvbnRyb2xsZXIg SUQsIGFuZCBvdGhlciBub24tcGF0aC1zcGVjaWZ5aW5nIA0KPj4+PiBpbmZvcm1hdGlvbiBpcyB0 byBiZSBjYXJyaWVkIGluIG1ldGFkYXRhLg0KPj4+Pg0KPj4+PiBZb3VycywNCj4+Pj4gSm9lbA0K Pj4+Pg0KPj4+PiBPbiAxMi80LzE0LCAxMDowMiBBTSwgU3JpbmkgQWRkZXBhbGxpIHdyb3RlOg0K Pj4+Pj4gVHdvIGNvbW1lbnRzIDoNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gMS4gIFNGIEluZGV4IDog IFNpbmNlIGl0IGlzIG1lYW50IGZvciBsb29wIGRldGVjdGlvbiwgIHdvdWxkbid0IA0KPj4+Pj4g YmV0dGVyIHRvIHJlbmFtZSB0aGlzIGFzICJUVEwiPw0KPj4+Pj4NCj4+Pj4+IDIuICBQYXRoIElk ZW50aWZpZXIgOiAgICAyNCBiaXQgcGF0aCBpZGVudGlmaWVyIHNlZW1zIHRvIGJlIHRvbyBsZXNz Lg0KPj4+Pj4gQmFzZWQgb24gb3VyIGV4cGVyaWVuY2UgaW4gdHJhZmZpYyBzdGVlcmluZywgIHRo aXMgcGF0aCBpZGVudGlmaWVyIA0KPj4+Pj5uZWVkcyB0byBlbmNvZGUgZ29vZCBhbW91bnQgb2Yg aW5mb3JtYXRpb24gdG8gbWFrZSBpdCB1bmlxdWUuICBGb3IgDQo+Pj4+PmV4YW1wbGUsDQo+Pj4+ PiAgICB0aGlzIGlkZW50aWZpZXIgbmVlZHMgdG8gZW5jb2RlIChpbiBvdXIgY2FzZSkgc29tZSBp bmZvcm1hdGlvbiANCj4+Pj4+cmVwcmVzZW50aW5nIHRoZSBkaXN0cmlidXRlZCBjb250cm9sbGVy IElELCAgdGVuYW50IElELCAgZmxvdyBJRCwNCj4+Pj4+ICAgIFNlcnZpY2UgZnVuY3Rpb24gaW5z dGFuY2UgKGluIGNhc2Ugb2Ygc2NhbGUtb3V0KSBhbmQgZmV3IG1vcmUuLg0KPj4+Pj4gT25lIHN1 Z2dlc3Rpb24gaXMgdG8gbWFrZSBpdCA2NCBiaXRzIHZhbHVlICBvciB0byBtYWtlIGl0IGV2ZW4g DQo+Pj4+PmV4dGVuZGFibGUsDQo+Pj4+PiAgICBpdCBpcyBnb29kIGlmIHBhdGggaWRlbnRpZmll ciBpcyBhbHNvIHJlcHJlc2VudGVkIGluIFRMViBmb3JtLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBU aGFua3MNCj4+Pj4+DQo+Pj4+PiBTcmluaQ0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+ PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+Pg0KPj4+DQo+Pj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+c2ZjIG1haWxpbmcgbGlz dA0KPj4+c2ZjQGlldGYub3JnDQo+Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPj4NCj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPnNmYyBtYWlsaW5nIGxpc3QNCj5zZmNAaWV0Zi5vcmcNCj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRm Lm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+DQo+ VGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgKHRoZSAibWVzc2FnZSIpIGFyZSBjb25m aWRlbnRpYWwsIA0KPmludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZXMuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCANCj5yZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSANCj50aGlzIG1lc3NhZ2UgZnJvbSB5 b3VyIHN5c3RlbS4gSW4gdGhpcyBjYXNlLCB5b3UgYXJlIG5vdCBhdXRob3JpemVkIHRvIA0KPnVz ZSwgY29weSB0aGlzIG1lc3NhZ2UgYW5kL29yIGRpc2Nsb3NlIHRoZSBjb250ZW50IHRvIGFueSBv dGhlciBwZXJzb24uDQo+RS1tYWlscyBhcmUgc3VzY2VwdGlibGUgdG8gYWx0ZXJhdGlvbi4gTmVp dGhlciBRb3Ntb3Mgbm9yIGFueSBvZiBpdHMgDQo+c3Vic2lkaWFyaWVzIG9yIGFmZmlsaWF0ZXMg c2hhbGwgYmUgbGlhYmxlIGZvciB0aGUgbWVzc2FnZSBpZiBhbHRlcmVkLCANCj5jaGFuZ2VkIG9y IGZhbHNpZmllZC4NCj4NCj5DZSBtZXNzYWdlIGV0IHRvdXRlcyBzZXMgcGnDqGNlcyBqb2ludGVz IChjaS1hcHLDqHMgbGUgIm1lc3NhZ2UiKXNvbnQgDQo+Y29uZmlkZW50aWVscyBldCDDqXRhYmxp cyDDoCBsJ2ludGVudGlvbiBleGNsdXNpdmUgZGUgc2VzIGRlc3RpbmF0YWlyZXMuDQo+U2kgdm91 cyBhdmV6IHJlw6d1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgbWVyY2kgZOKAmWVuIGluZm9ybWVy IA0KPmltbcOpZGlhdGVtZW50IHNvbiDDqW1ldHRldXIgcGFyIGNvdXJyaWVyIMOpbGVjdHJvbmlx dWUgZXQgZOKAmWVmZmFjZXIgY2UgDQo+bWVzc2FnZSBkZSB2b3RyZSBzeXN0w6htZS4gRGFucyBj ZXR0ZSBoeXBvdGjDqHNlLCB2b3VzIG7igJnDqnRlcyBwYXMgDQo+YXV0b3Jpc8OpIMOgIHV0aWxp c2VyLCBjb3BpZXIgY2UgbWVzc2FnZSBldC9vdSBlbiBkaXZ1bGd1ZXIgbGUgY29udGVudSDDoCAN Cj51biB0aWVycy4gVG91dCBtZXNzYWdlIMOpbGVjdHJvbmlxdWUgZXN0IHN1c2NlcHRpYmxlIGQn YWx0w6lyYXRpb24uDQo+UW9zbW9zIGV0IHNlcyBmaWxpYWxlcyBkw6ljbGluZW50IHRvdXRlIHJl c3BvbnNhYmlsaXTDqSBhdSB0aXRyZSBkZSBjZSANCj5tZXNzYWdlIHMnaWwgYSDDqXTDqSBhbHTD qXLDqSwgZMOpZm9ybcOpIG91IGZhbHNpZmnDqS4NCj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBtYWlsaW5nIGxpc3QNCj5zZmNAaWV0Zi5vcmcN Cj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0K c2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNmYyBtYWls aW5nIGxpc3QNCnNmY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K From nobody Tue Feb 3 08:02:25 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 602561A1AB4 for ; Tue, 3 Feb 2015 08:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, 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 Da8jJFj8oQMX for ; Tue, 3 Feb 2015 08:02:19 -0800 (PST) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA8491A19E3 for ; Tue, 3 Feb 2015 07:59:41 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0174.001; Tue, 3 Feb 2015 07:59:41 -0800 From: Ron Parker To: "Carlos Pignataro (cpignata)" , Nicolas BOUTHORS Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9kHFOTKJIie6ES015pmlGgJ3ZyAGG+AgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgD//7j7oIBXAfSAgAEKegCABoxWAP//fVtg Date: Tue, 3 Feb 2015 15:59:40 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <, <>> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Cathy Zhang , Jerome TOLLET , "sfc@ietf.org" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 03 Feb 2015 16:02:23 -0000 Q2FybG9zLA0KDQpJIGFncmVlIHRoYXQgc2luZ2xlIGxldmVsIHZzLiBkdWFsIGxldmVsIGlkZW50 aWZpZXIgaW4gdGhlIGRhdGEgcGxhbmUgaXMgYSB3b3J0aHdoaWxlIGRpc2N1c3Npb24uICAgUmVs YXRlZCB0byB0aGlzIC0tIHdpdGhpbiB0aGUgYXJjaGl0ZWN0dXJlLCB0byBteSBrbm93bGVkZ2Us IGJvdGggY2VudHJhbCBvcmNoZXN0cmF0aW9uIGFuZCBob3AtYnktaG9wIGxvYWQgYmFsYW5jaW5n L3Jlc2lsaWVuY3kgc2VsZWN0aW9uIGlzIGFsbG93ZWQuICAgDQoNCkluIGEgY2VudHJhbGx5IG9y Y2hlc3RyYXRlZCBhcHByb2FjaCwgYSBzaW5nbGUgbGV2ZWwgaWRlbnRpZmllciBhYnN0cmFjdGlu ZyB0aGUgY29uY3JldGUgc2VxdWVuY2Ugb2YgaG9wcyBpcyBzdWZmaWNpZW50LiAgIEkgd291bGQg cHJvcG9zZSB0aGF0IHRoaXMgc2luZ2xlIGxldmVsIGlkZW50aWZpZXIgd291bGQgYmUgYmV0dGVy IGNhbGxlZCB0aGUgUlNQIElEIHRoYW4gdGhlIFNGUCBJRCwgc2luY2UgU0ZQLCBieSBkZWZpbml0 aW9uIGlzIG5vdCBuZWNlc3NhcmlseSBmdWxseSBjb25jcmV0ZS9zcGVjaWZpZWQgaW4gdGVybXMg b2YgZXhhY3QgaG9wIHNlcXVlbmNlLg0KDQpJbiBhIGRpc3RyaWJ1dGVkIGhvcC1ieS1ob3AgKHRy YWlsLWJsYXplZCkgYXBwcm9hY2ggdG8gbG9hZCBiYWxhbmNpbmcgYW5kIHJlc2lsaWVuY3ksIGEg Mi1sZXZlbCBpZGVudGlmaWVyIGlzIHZlcnkgdXNlZnVsLiAgIFRoZSBTRlAgSUQgZGVzY3JpYmVz IHRoZSBzZXF1ZW5jZSBvZiBTRidzIGluIHRlcm1zIG9mIHR5cGVzLCBidXQgbm90IG5lY2Vzc2Fy aWx5IGluc3RhbmNlcy4gICBJdCBpcyBhbGxvd2VkIHRvIGNvbnZleSBwb2xpY3kgd2l0aCByZXNw ZWN0IHRvIGV4YWN0IGluc3RhbmNlcywgYW5kIHRoYXQgcG9saWN5IGNvdWxkIGJlIGZ1bGx5IGNv bmNyZXRlIG9yIGNvdWxkIGJlIG1lcmVseSBkZXNjcmliaW5nIHN1YnNldHMgKGkuZS4sIG9uZSBv ZiB0aGUgIm9yYW5nZSIgSURTL0lQUyBmb2xsb3dlZCBieSBvbmUgb2YgdGhlICJwdXJwbGUiIGZp cmV3YWxscykuICAgIEluIG9yZGVyIHRvIGFzc2lzdCB0aGUgU0ZGJ3MgdG8gbWFrZSB0aGlzIGRl Y2lzaW9uLCB0aGV5IHdvdWxkIHJlcXVpcmUgbm90IG9ubHkgdGhlIHBvbGljeSB1bmRlciB3aGlj aCB0aGV5IGFyZSB3b3JraW5nIHRvIG1ha2UgdGhpcyBkZWNpc2lvbiAoaS5lLiwgU0ZQIElEKSwg YnV0IGFsc28gYSB2YWx1ZSB0aGF0IGNvdWxkIGJlIHVzZWQgdG8gcmVwZWF0IHRoZSBhY3R1YWwg c2VsZWN0aW9ucyAoaS5lLiwgUlNQIElEKS4gICBJbiB0aGlzIGFwcHJvYWNoLCB0aGUge1NGUCBJ RCwgUlNQIElEfSB0dXBsZSBpcyBpbnRlcnByZXRlZCBhcyAiYWxsIHBhY2tldHMgd2l0aCB0aGlz IHR1cGxlIHZhbHVlIG11c3QgdHJhdmVyc2UgdGhlIGV4YWN0IHNhbWUgY29uY3JldGUgc2VxdWVu Y2UiLg0KDQpJbiBteSB2aWV3LCB0aGUgYXJjaGl0ZWN0dXJlLCBhcyBpdCBzdGFuZHMgdG9kYXks IGFsbG93cyBmb3IgYm90aCBhcHByb2FjaGVzIC0tIGNlbnRyYWxpemVkIHBhdGggbWFuYWdlbWVu dCBhbmQgZGlzdHJpYnV0ZWQgcGF0aCBtYW5hZ2VtZW50LiAgIEZ1cnRoZXJtb3JlLCBib3RoIGFy ZSB2YWxpZCBhbmQgd29ydGh3aGlsZS4NCg0KICAgUm9uDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkNClNlbnQ6IFR1ZXNkYXksIEZlYnJ1 YXJ5IDMsIDIwMTUgMTA6MzggQU0NClRvOiBOaWNvbGFzIEJPVVRIT1JTDQpDYzogQ2F0aHkgWmhh bmc7IEplcm9tZSBUT0xMRVQ7IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIENvbW1l bnRzIG9uIFNDSCBEcmFmdCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5n LXNmYy1zY2gtMDIpDQoNCkhpLA0KDQpbVG9wLXBvc3QgcmVzcG9uZGluZywgbm90IGFkZHJlc3Nl ZCB0byBhbnkgbWVzc2FnZSBpbiBwYXJ0aWN1bGFyIGJ1dCBtYWtpbmcgYSBnZW5lcmljIGNvbW1l bnRdDQoNClNpbmNlIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgZ290IGNpdGVkIGEgY291cGxl IG9mIHRpbWVzIGluIHRoaXMgdGhyZWFkLCBteSB2aWV3IGlzIHRoYXQgdGhlIGZhY3QgdGhhdCB0 aGUgYXJjaCBkb2N1bWVudCBkZWZpbmVzIGFuIFJTUCBkb2VzIG5vdCBpbXBseSB0aGF0IHRoZXJl IG91Z2h0IHRvIGJlIGFuIFJTUCBJZGVudGlmaWVyLCBsZXNzIHNvIG9uZSBjYXJyaWVkIGluIHRo ZSBkYXRhcGxhbmUuDQoNClRoZSByZWFsIHF1ZXN0aW9uIGlzIHdoYXQgY2Fubm90IGJlIGRvbmUg d2l0aCBhIFNlcnZpY2UgUGF0aCBJRCwgaW4gdGVybXMgb2YgYm90aCBmdW5jdGlvbmFsaXR5IGFu ZCBzY2FsaW5nIOKAlCB0byBtZSwgYSBoaWVyYXJjaGljYWwgc2V0IG9mIGlkZW50aWZpZXJzICji gJwgUlNQIElEIHZhbHVlcyBjb3VsZCBiZSByZWxhdGl2ZSB0byBhIHBhcnRpY3VsYXIgU2Vydmlj ZSBQYXRo4oCdKSBzZWVtcyBvdmVyLWVuZ2luZWVyaW5nLCBhbmQgYW4gaW5kZXBlbmRlbnQgYWxs b2NhdGlvbiBjYW4gY3JlYXRlIGNvbmZsaWN0cy4NCg0KSW4gb3RoZXIgd29yZHMsIHdoYXQgcHJv YmxlbSBhcmUgd2Ugc29sdmluZz8NCg0KVGhhbmtzLA0KDQrigJQgQ2FybG9zLg0KDQo+IE9uIEph biAzMCwgMjAxNSwgYXQgNjozOCBBTSwgTmljb2xhcyBCT1VUSE9SUyA8Tmljb2xhcy5CT1VUSE9S U0Bxb3Ntb3MuY29tPiB3cm90ZToNCj4gDQo+IEhlbGxvIENhdGh5LA0KPiANCj4gSW5kZWVkIHRo ZSBub3Rpb24gb2YgInJlbmRlcmVkIHNlcnZpY2UgcGF0aCBJRCIoUlNQIElEKSBzZWVtcyByZWxl dmFudCBhcyB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IHN0aXB1bGF0ZXMgdGhhdCB0aGUgU2Vy dmljZSBGdW5jdGlvbiBQYXRoIChTRlApIHByb3ZpZGVzIGFuIGFic3RyYWN0IG5vdGlvbiBvZiBh IHNlcnZpY2UgY2hhaW4sIHdoaWxlIHRoZSBSU1AgaXMgYSBjb25zdHJhaW5lZCBsaXN0IG9mIGxv Y2F0aW9ucy4NCj4gDQo+IFNGQyBoZWFkZXIgIlNlcnZpY2UgUGF0aCBJZGVudGlmaWVyIiAoU1BJ KSAgaXMgdXNlZCBpbiBib3RoIE5TSCBhbmQgU0NIIHByb3RvY29sIGFuZCBpbiBib3RoIGNhc2Ug c2VlbSB0byBpZGVudGlmeSB0byBhIHBhcnRpY3VsYXIgU0ZQLg0KPiANCj4gTlNIKHY1KSBmb3Ig ZXhhbXBsZSBzdGF0ZXMgdGhhdA0KPiAiIEFzIGRlc2NyaWJlZCBhYm92ZSwgTlNIIGNvbnRhaW5z IGEgc2VydmljZSBwYXRoIGlkZW50aWZpZXIgKFNQSSkgYW5kDQo+ICAgYSBzZXJ2aWNlIGluZGV4 IChTSSkuICBUaGUgU1BJIGlzLCBhcyBwZXIgaXRzIG5hbWUsIGFuIGlkZW50aWZpZXIuDQo+ICAg VGhlIFNQSSBhbG9uZSBjYW5ub3QgYmUgdXNlZCB0byBmb3J3YXJkIHBhY2tldHMgYWxvbmcgYSBz ZXJ2aWNlIHBhdGguDQo+ICAgUmF0aGVyIHRoZSBTUEkgcHJvdmlkZSBhIGxldmVsIG9mIGluZGly ZWN0aW9uIGJldHdlZW4gdGhlIHNlcnZpY2UNCj4gICBwYXRoL3RvcG9sb2d5IGFuZCB0aGUgdGhl IG5ldHdvcmsgdHJhbnNwb3J0LiAgRnVydGhlcm1vcmUsIHRoZXJlIGlzDQo+ICAgbm8gcmVxdWly ZW1lbnQsIG9yIGV4cGVjdGF0aW9uIG9mIGFuIFNQSSBiZWluZyBib3VuZCB0byBhIHByZS0NCj4g ICBkZXRlcm1pbmVkIG9yIHN0YXRpYyBuZXR3b3JrIHBhdGguIg0KPiANCj4gU3RpbGwgTlNIKHY1 KSAgc2hvd3MgdGhhdCBTUEkgKG5vdCBhIFJTUCBJRCkgIHNob3VsZCBiZSBwYXJ0IG9mIHRoZSAN Cj4ga2V5ICBlbGVtZW50IG9mIGFuIFNGRiB0byBsb29rdXAgb24gZm9yd2FyZGluZyB0YWJsZXMu ICBCdXQgSSBjb3VsZCBub3QgZmluZCBpbiBOU0ggIGhvdyB0byB1c2UgdGhlIG5vdGlvbiBvZiBS ZW5kZXJlZCBzZXJ2aWNlIHBhdGggd2hpY2ggd2FzIGRlZmluZWQgaW4gdGhlIGFyY2hpdGVjdHVy ZSBkb2N1bWVudC4NCj4gDQo+IFlvdSBwcm9wb3NhbCBzZWVtcyB0byBtZSB2ZXJ5IHVzZWZ1bCwN Cj4gDQo+IEFuIFJTUCBJRCAoaW5kZXBlbmRlbnQgb2YgdGhlIFNQSSBidXQgcGFydCBvZiB0aGUg c2FtZSBuYW1lIHNwYWNlKSBjb3VsZCBiZSB1c2VkIHRoZSBzYW1lIHdheSBhcyBTUEkgYnkgU0ZG IGZvciBleGFtcGxlLCBhbGxvd2luZyBhIFNlcnZpY2UgQ2xhc3NpZmllciB0byBjb250cm9sIHJl bW90ZSBsb2FkIGJhbGFuY2luZyBmb3IgZXhhbXBsZS4NCj4gDQo+IFRoaXMgc2FpZCB0aGUgUlNQ IElEIHZhbHVlcyBjb3VsZCBiZSByZWxhdGl2ZSB0byBhIHBhcnRpY3VsYXIgU2VydmljZSBQYXRo LCB3aGljaCB3b3VsZCBwcmV2ZW50IHVzaW5nIHRoZW0gYXMgd2UgZG8gZm9yIFNQSSBpbiBTRkYg Zm9yd2FyZGluZyB0YWJsZXMuDQo+IA0KPiBXZSBtYXkgd2FudCB0byBwcmVjaXNlIGlmIHRoZSBS U1AgSUQgaXMgdG8gYmUgcmVsYXRpdmUgb2YgYWJzb2x1dGUsIGFzIGl0IHNob3VsZCBoYXZlIGFu IGltcGFjdCBvbiBmb3J3YXJkaW5nIHRhYmxlIHN0cnVjdHVyZSBpZiB3ZSBkZWNpZGUgdG8gdXNl IHRoaXMgY29uY2VwdC4NCj4gDQo+IFBlcnNvbmFsbHkgSSBsaWtlIHRoZSBub3Rpb24gb2YgYSBy ZWxhdGl2ZSBSU1AgSUQsIGFzIHdlIGNvdWxkIHRoZW4gdXNlIHNvbWUgY29udmVudGlvbnMsIHN0 cnVjdHVyZSBpdCwgcG9zc2libHkgZXh0ZW5kaW5nIGl0cyB1c2UuDQo+IA0KPiBOaWNvbGFzDQo+ IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBDYXRoeSBaaGFuZyBbbWFp bHRvOkNhdGh5LkguWmhhbmdAaHVhd2VpLmNvbV0NCj4gU2VudDogamV1ZGkgMjkgamFudmllciAy MDE1IDIwOjQ0DQo+IFRvOiBDYXRoeSBaaGFuZzsgU3JpbmkgQWRkZXBhbGxpOyBSZWluYWxkbyBQ ZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4gSGFscGVybjsgJ3NmY0BpZXRmLm9yZycNCj4gQ2M6IG5z bXVydGh5QGZyZWVzY2FsZS5jb20NCj4gU3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFND SCBEcmFmdCANCj4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMt c2NoLTAyKQ0KPiANCj4gSGkgZXZlcnlvbmUsDQo+IA0KPiBXZSBoYXZlIHVwbG9hZGVkIGEgbmV3 IFNDSCB2ZXJzaW9uICgzKSB3aGljaCBhZGRzIGRlZmluaXRpb24gb2YgYSBuZXcgbWV0YWRhdGEg dHlwZSBmb3IgdGhlIGZsb3cgSUQgdG8gc3VwcG9ydCBsb2FkIGJhbGFuY2luZyBhbW9uZyBTRiBp bnN0YW5jZXMgYW5kIG1pdGlnYXRlIHRoZSBwb3RlbnRpYWwgaXNzdWUgb2YgIm5vdCBlbm91Z2gg cGF0aCBJRCIuIFRoZSBmbG93IElEIGlzIG5hbWVkICJyZW5kZXJlZCBzZXJ2aWNlIHBhdGggSUQi IGluIHRoZSBkcmFmdC4gUGxlYXNlIHJlZmVyIHRvIHNlY3Rpb24gNC4zLjIgb2YgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctc2ZjLXNjaC8gZm9yIGRldGFpbCBk ZXNjcmlwdGlvbi4NCj4gDQo+IEluIGl0cyBwcmV2aW91cyB2ZXJzaW9uLCBTQ0ggZGVmaW5lcyBh ICJCeXBhc3MgYml0IiBpbiB0aGUgYmFzZSBoZWFkZXIuIFRoaXMgYml0IGVuYWJsZXMgdGhlIFNG IHRvIHByb3ZpZGUgZmVlZGJhY2svbm90aWZpY2F0aW9uIHZpYSB0aGUgZGF0YSBwYXRoIHRvIGl0 cyBjb25uZWN0aW5nIFNGRiBhYm91dCB3aGV0aGVyIHRoZSByZW1haW5pbmcgcGFja2V0cyBvZiB0 aGUgU0ZDIHNob3VsZCBieXBhc3MgdGhhdCBTRi4gVGhpcyBpcyB1c2VmdWwgaW4gdGhlIGNhc2Ug dGhhdCBvbmx5IHRoZSBmaXJzdCBmZXcgcGFja2V0cyBvZiBhIGZsb3cgbmVlZCB0byBnbyB0byBh IFNGIChzdWNoIGFzIGEgRFBJIG9yIEZXIG9yIElEUykgYW5kIHJlbWFpbmluZyBwYWNrZXRzIGNh biBieXBhc3MgdGhhdCBTRiwgdGh1cyBzYXZpbmcgdGhlIGV4cGVuc2l2ZSBTRiByZXNvdXJjZSBh bmQgcmVkdWNpbmcgZGF0YSBwYXRoIGxhdGVuY3kuDQo+IA0KPiBCIGJpdDogVGhlIEIgKEJ5cGFz cykgYml0LCB3aGVuIHNldCB0byAxLCBpdCBpcyB1c2VkIGJ5IGEgU2VydmljZQ0KPiAgICAgICBG dW5jdGlvbiB0byBzaWduYWwgdG8gaXRzIFNlcnZpY2UgRnVuY3Rpb24gRm9yd2FyZGVyIHRoYXQg bm8NCj4gICAgICAgZnVydGhlciBwYWNrZXRzIGFyZSB0byBiZSBzZW50IHRvIGl0IGZvciB0aGUg ZmxvdyBzcGVjaWZpZWQgaW4gZW5jYXBzdWxhdGVkIHBhY2tldC4NCj4gDQo+IEluIGFkZGl0aW9u LCBTQ0ggZGVmaW5lcyBhIG1ldGFkYXRhIHR5cGUgZm9yIEdlbmVyaWMgQ29udGV4dCBCbG9jaywg d2hpY2ggaXMgb3B0aW9uYWwgYW5kIGNhbiBiZSB1c2VkIGlmIG5lZWRlZCB0byBjYXJyeSBhbnkg dmVuZG9yJ3Mgc3BlY2lmaWMgIkNvbnRleHQgSGVhZGVyIi4NCj4gDQo+IEFueSBjb21tZW50cyBv biB0aGVzZSBuZXcgYWRkaXRpb25zPw0KPiANCj4gVGhhbmtzLA0KPiBDYXRoeQ0KPiANCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDYXRoeSBaaGFuZw0KPiBTZW50OiBGcmlkYXksIERlY2Vt YmVyIDA1LCAyMDE0IDExOjQ3IEFNDQo+IFRvOiBTcmluaSBBZGRlcGFsbGk7IFJlaW5hbGRvIFBl bm5vIChyZXBlbm5vKTsgSm9lbCBNLiBIYWxwZXJuOyAnc2ZjQGlldGYub3JnJw0KPiBDYzogbnNt dXJ0aHlAZnJlZXNjYWxlLmNvbQ0KPiBTdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NI IERyYWZ0IA0KPiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1z Y2gtMDIpDQo+IA0KPiBSb24sIExvdWlzLCBNeW8gYW5kIEkgaGF2ZSBiZWVuIGRpc2N1c3Npbmcg b2ZmIGxpbmUgbGFzdCBmZXcgd2Vla3MgYWJvdXQgZGVmaW5pbmcgYSBtZXRhZGF0YSB0eXBlIGZv ciBmbG93IElEIGluIGFkZGl0aW9uIHRvIHRoZSBwYXRoIElEIG9mIHRoZSBtYWluIGhlYWRlciB0 byBzdXBwb3J0IGxvYWQgYmFsYW5jaW5nIGFtb25nIFNGIGluc3RhbmNlcy4gV2Ugd2lsbCBkZWZp bmUgYSBUTFYgdHlwZSBmb3IgdGhlIGZsb3cgSUQuIFRoZSBjb21iaW5hdGlvbiBvZiAicGF0aCBJ RCArIGZsb3cgSUQiIHNwZWNpZmllcyBhIHJlYWxpemVkIHNlcnZpY2UgY2hhaW4gaW5zdGFuY2Ug cGF0aC4gSXQgaXMgbGVmdCB0byB0aGUgZGVzaWduL2ltcGxlbWVudGF0aW9uIHdoZXRoZXIgdG8g dXNlIGEgY2VudHJhbGl6ZWQgbWV0aG9kIG9yIGEgZGlzdHJpYnV0ZWQgbWV0aG9kIHRvIGJpbmQg dGhlIGZsb3cgSUQgdG8gYSByZWFsaXplZCBzZXJ2aWNlIGluc3RhbmNlIHBhdGggYWx0aG91Z2gg b3VyIG9yaWdpbmFsIHRob3VnaHQgaXMgZm9yIGRpc3RyaWJ1dGVkIExCIHVzYWdlLiBJIGFtIG5v dCBzdXJlIGlmIHdlIG5lZWQgYSBiaXQgaW4gdGhlIGhlYWRlciB0byBkZW5vdGUgd2hldGhlciB0 aGVyZSBhcmUgbW9yZSBwYXRoIElEIGJpdHMgKHdlIGNhbGwgaXQgZmxvdyBJRCkgaW4gdGhlIG1l dGFkYXRhIGZpZWxkcyBzaW5jZSB3aGVuIHlvdSBwYXJzZSB0aGUgVExWIG1ldGFkYXRhLCB5b3Ug d2lsbCBrbm93IHdoZXRoZXIgdGhlcmUgYXJlIGZsb3cgSUQgYml0cyBvciBub3QuIE5vdGUgdGhh dCBpZiBtdWx0aXBsZSBzZXNzaW9ucyBzaGFyZSB0aGUgc2FtZSByZWFsaXplZCBzZXJ2aWNlIGlu c3RhbmNlIHBhdGgsIHRoZXkgd2lsbCBzaGFyZSB0aGUgc2FtZSAicGF0aCBJRCsgZmxvdyBJRCIu ICBXZSBjYW4gYWxzbyBjb25zaWRlciBleHRlbmRpbmcgdGhlIG51bWJlciBvZiBiaXRzIHRvIDMy IGlmIHRoYXQgaXMgdGhlIGNvbnNlbnN1cy4gV2Ugd2lsbCBwb3N0IGFuIHVwZGF0ZWQgZHJhZnQg ZGVzY3JpYmluZyB0aGVzZSBzb29uLg0KPiANCj4gVGhhbmtzLA0KPiBDYXRoeQ0KPiANCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTcmluaSBBZGRlcGFsbGkNCj4gU2VudDogRnJpZGF5LCBE ZWNlbWJlciAwNSwgMjAxNCA3OjE3IEFNDQo+IFRvOiBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7 IEpvZWwgTS4gSGFscGVybjsgJ3NmY0BpZXRmLm9yZycNCj4gQ2M6IG5zbXVydGh5QGZyZWVzY2Fs ZS5jb20NCj4gU3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdCANCj4gKGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPiANCj4g DQo+IFtSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5Lg0KPiANCj4gU1JJTkk+IEkgYW0gbm90IHNv IHN1cmUgYWJvdXQgZGF0YSBwbGFuZSBlZmZpY2llbmN5LiAgTW9zdCBvZiB0aGUgcHJvY2Vzc29y cyB3b3JrIGdvb2QgaWYgdGhlIG51bWJlciBvZiBiaXRzIGFyZSBlaXRoZXIgMzIgb3IgNjQuICBJ ZiBpdCBpcyAyNCBiaXRzLCB0aGVuIG9uZSBuZWVkcyB0byBkbyBtYXNraW5nIGFuZCBzaGlmdGlu ZyBiZWZvcmUgdGhlIHZhbHVlIGlzIHVzZWQgdG8gZG8gYW55IGxvb2t1cC4gICBCdXQsIHRoaXMg ZGlzY3Vzc2lvbiBjYW4gZ28gaW50byBkaWZmZXJlbnQgZGlyZWN0aW9uIDotKSwgaXQgbWF5IG5v dCBiZSBnb29kIHRvIGdvIGluIHRoYXQgZGlyZWN0aW9uLg0KPiANCj4gV2hlcmUgZG8gd2UgZHJh dyB0aGUgbGluZT8gMzItYml0cywgNjQtYml0cywNCj4gMTI4IGJpdHM/IEkgdGhpbmsgd2Ugc2hv dWxkIGhhdmUgYSBzZW5zaWJsZSB2YWx1ZSBpbiB0aGUgU2VydmljZSBQYXRoIGhlYWRlciBhbmQg aWYgeW91IG5lZWQgdG8gY29udmV5IG1vcmUgYml0cyB5b3UgbmVlZCB0byB1c2UgdGhlIGNvbnRl eHQgaGVhZGVycy4NCj4gDQo+IFNSSU5JPiBUaGlzIGlzIGEgZ29vZCBwb2ludC4gIFRoaXMgc2hv dWxkIHdvcmsgZmluZSBhcyBsb25nIGFzIHRoZXJlIGlzIHdheSB0byBjb252ZXkgaW4gdGhlIG1h aW4gaGVhZGVyIHRoYXQgdGhlIGV4dGVuc2lvbiB0byBwYXRoIElEIGlzIGF2YWlsYWJsZSBpbiBz byBhbmQgc28gVExWIGZpZWxkLiAgVGhhdCBzaG91bGQgd29yayB0b28uDQo+IA0KPiBUaGFua3MN Cj4gU3JpbmkNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gRnJvbTogUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pIDxyZXBlbm5vQGNpc2NvLmNvbT4NCj4g U2VudDogRnJpZGF5LCBEZWNlbWJlciA1LCAyMDE0IDc6MDggQU0NCj4gVG86IEFkZGVwYWxsaSBT cmluaS1CMjIxNjA7IEpvZWwgTS4gSGFscGVybjsgJ3NmY0BpZXRmLm9yZycNCj4gQ2M6IE5TIFNy aW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+IFN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBT Q0ggRHJhZnQgDQo+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2Zj LXNjaC0wMikNCj4gDQo+IE9uIDEyLzUvMTQsIDY6NTQgQU0sICJTcmluaSBBZGRlcGFsbGkiIDxz YWRkZXBhbGxpQGZyZWVzY2FsZS5jb20+IHdyb3RlOg0KPiANCj4+IA0KPj4gSW4gcmVhbCBkZXBs b3ltZW50cywgbnVtYmVyIG9mIGFjdGl2ZSBwYXRoIElEcyBhcmUgdmVyeSBsZXNzZXIgdGhhbiAN Cj4+IDJeNjQsIGJ1dCB0aGVyZSBpcyBhIGdvb2QgcG9zc2liaWxpdHkgb2YgdGhlIG51bWJlciBi ZWluZyBtb3JlIHRoYW4gMl4yNCAoMTZNKS4NCj4+IEkgdGhpbmsgYmlnZ2VyIHBvaW50IGlzIHRo YXQgd2h5IHJlc3RyaWN0IHRoaXMgaW4gdGhlIHN0YW5kYXJkcz8gV2hhdCANCj4+IGFkdmFudGFn ZSBkbyB3ZSBoYXZlIHJlc3RyaWN0aW5nIHRoaXMgc2l6ZSB0byAyNCBiaXRzPw0KPiANCj4gW1JQ XSBEYXRhIHBsYW5lIGVmZmljaWVuY3kuIFdoZXJlIGRvIHdlIGRyYXcgdGhlIGxpbmU/IDMyLWJp dHMsIA0KPiA2NC1iaXRzLA0KPiAxMjggYml0cz8gSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBhIHNl bnNpYmxlIHZhbHVlIGluIHRoZSBTZXJ2aWNlIFBhdGggaGVhZGVyIGFuZCBpZiB5b3UgbmVlZCB0 byBjb252ZXkgbW9yZSBiaXRzIHlvdSBuZWVkIHRvIHVzZSB0aGUgY29udGV4dCBoZWFkZXJzLg0K PiANCj4gDQo+PiANCj4+IFRoZXJlIGNhbiBiZSBkZXBsb3ltZW50cywgd2hlcmUgU0ZDIGNvbnRy b2xsZXIgKExvZ2ljYWxseSBjZW50cmFsLCANCj4+IGJ1dA0KPj4gZGlzdHJpYnV0ZWQpICBpdHNl bGYgY2FuIGRvIHRoZSBTRiBpbnN0YW5jZSBzZWxlY3Rpb24gb24gcGVyDQo+PiBjb25uZWN0aW9u L3Nlc3Npb24gYmFzaXMsIHRoZXJlYnkgYXZvaWRpbmcgdGhlIExCcyBmb3Igc2VydmljZXMuICAg SW4gbXkNCj4+IHZpZXcsIGFzc3VtcHRpb24gdGhhdCB0aGVyZSB3aWxsIGJlIExCIFNGIGZvciBl YWNoIHNjYWxlLW91dCBzZXJ2aWNlIA0KPj4gaW4gdGhlIGNoYWluIGlzIG5vdCB2YWxpZCBpbiBh bGwgY2FzZXMuDQo+PiANCj4+IFRoYW5rcw0KPj4gU3JpbmkNCj4+IA0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gRnJvbTogUmVpbmFsZG8gUGVubm8gKHJl cGVubm8pIDxyZXBlbm5vQGNpc2NvLmNvbT4NCj4+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciA0 LCAyMDE0IDE6MTcgUE0NCj4+IFRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhh bHBlcm47IHNmY0BpZXRmLm9yZw0KPj4gQ2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+ PiBTdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+PiAoaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+PiANCj4+IElmIEkg dW5kZXJzdG9vZCB5b3UsIEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgcmVhbGlzdGljLiBBcmUgeW91 IHNheWluZyANCj4+IHlvdSBuZWVkIDY0LWJpdHMgb2YgcGF0aHMgYW5kIHRoZW4gd2lsbCBtb25p dG9yIHRoZW0gYWxsPyBEbyBmYXVsdCANCj4+IHRvbGVyYW5jZSBhbmQgT0FNIGZvciAyXjY0LWJp dHMgd29ydGggb2YgcGF0aHM/IEp1c3QgZm9yIGNvbXBhcmlzb24sIA0KPj4gaXTCuXMgbGlrZSBt YW5hZ2luZyBhbmQgbW9uaXRvcmluZyB0aGUgZW50aXJlIElQdjYgaG9zdCByYW5nZSwgb25lLWJ5 LW9uZS4NCj4+IA0KPj4gQW55d2F5LCBJIGRvIG5vdCBleHBlY3QgZXZlcnkgc2luZ2xlIHBlcm11 dGF0aW9ucyB0byBiZSBhIGRpZmZlcmVudCBwYXRoLg0KPj4gDQo+PiBJZiBlYWNoIHNlcnZpY2Ug aGFzIDI1NiBkZXZpY2VzIHByb3ZpZGluZyBzaW1pbGFyIHNlcnZpY2UsIHlvdSBzaG91bGQgDQo+ PiBtb3N0IGxpa2VseSB1c2UgbG9hZC1iYWxhbmNpbmcgYW5kIHRoZW4geW91IHdvdWxkIGhhdmUg YSBzaW5nbGUgKG9yIGENCj4+IGZldykgcGF0aHMuIFRoZXJlIGlzIHNvbWUgZGlzY3Vzc2lvbiBn b2luZyBvbiBMQi4NCj4+IA0KPj4gRnJvbSBhIGRhdGEgcGxhbmUgcGVyc3BlY3RpdmUsIHRoZSBw YXRoIGlzIHVsdGltYXRlbHkgZGVmaW5lZCBieSB0aGUgDQo+PiBTRkZzIHRyYXZlcnNlZCBhbmQg c2VydmljZXMgcHJvdmlkZWQsIG5vdCBieSBhIHNwZWNpZmljIElQOnBvcnQgdGhhdCANCj4+IHRo ZSBkZXZpY2UgcHJvdmlkaW5nIHRoZSBzZXJ2aWNlIHNpdHMgb24uIFdlbGwsIGF0IGxlYXN0IGZy b20gYSBHUEUrTlNIIHBlcnNwZWN0aXZlLg0KPj4gDQo+PiANCj4+IE9uIDEyLzQvMTQsIDEyOjU3 IFBNLCAiU3JpbmkgQWRkZXBhbGxpIiA8c2FkZGVwYWxsaUBmcmVlc2NhbGUuY29tPiB3cm90ZToN Cj4+IA0KPj4+IElmIEkgdGFrZSBhIGNoYWluIHdpdGggNSBzZXJ2aWNlcyB3aXRoIGVhY2ggc2Vy dmljZSAgc2F5IGhhdmluZyAyNTYgDQo+Pj4gaW5zdGFuY2VzIGZvciBzY2FsZS1vdXQsIHBvc3Np YmxlIG51bWJlciBvZiBwYXRocyBhcmUNCj4+PiAyNTYqMjU2KjI1NioyNTYqMjU2ID0gMHhGRiBG RiBGRiBGRiBGRi4gT25lIHJlcXVpcmVzIDMzIGJpdHMgaW4gdGhpcyANCj4+PiBjYXNlLiAgSWYg dGhlcmUgYXJlIG1vcmUgc2VydmljZXMgaW4gdGhlIGNoYWluIG9yIG1vcmUgY2hhaW5zIG9yIA0K Pj4+IG1vcmUgaW5zdGFuY2VzIGZvciBzY2FsZS1vdXQsIHRoZW4gaXQgY291bGQgZ28gdG8gYmln IG51bWJlciB2ZXJ5IGZhc3QuDQo+Pj4gDQo+Pj4gQXMgSSBtZW50aW9uZWQgbXkgcHJlZmVyZW5j ZSBpcyB0byBtYWtlIHRoZSBwYXRoIElEIHNpemUgZmxleGlibGUgDQo+Pj4gZm9yIGZ1dHVyZSBn cm93dGguIElmIHRoYXQgaXMgcGVyY2VpdmVkIGFzIGNvbXBsZXgsIHRoZW4gZ29pbmcgZm9yIA0K Pj4+IDY0Yml0IGlzIHNhZmVyIGJldC4NCj4+PiANCj4+PiBUaGFua3MNCj4+PiBTcmluaQ0KPj4+ IA0KPj4+IA0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogSm9lbCBN LiBIYWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0NCj4+PiBTZW50OiBUaHVyc2Rh eSwgRGVjZW1iZXIgMDQsIDIwMTQgMTI6MDUgUE0NCj4+PiBUbzogQWRkZXBhbGxpIFNyaW5pLUIy MjE2MDsgSm9lbCBNLiBIYWxwZXJuOyBzZmNAaWV0Zi5vcmcNCj4+PiBDYzogTlMgU3Jpbml2YXNh IE11cnRoeS1CMzc4NDANCj4+PiBTdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERy YWZ0DQo+Pj4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2No LTAyKQ0KPj4+IA0KPj4+IEEgY29udHJvbGxlciAob3Igb3RoZXIgZGVjaXNpb24gbG9naWMpIGNh biBjZXJ0YWlubHkgYmUgYXdhcmUgb2YgDQo+Pj4gc3VjaCBjb25jZXJucy4NCj4+PiBCdXQgdGhl IG51bWJlciBvZiBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzIGlzIG5vdCByZWxhdGVkIHRvIHRoZSAN Cj4+PiBudW1iZXIgb2YgZmxvd3Mgb3IgdGhlIG51bWJlciBvZiB0ZW5hbnRzLiAgSXQgaXMgcmVs YXRlZCB0byB0aGUgDQo+Pj4gbnVtYmVyIG9mIGNvbWJpbmF0aW9ucyBvZiBzZXJ2aWNlcyBhbmQg dGhlIHBvbGljaWVzIGZvciBzZXJ2aWNlIGZ1bmN0aW9uIHNlbGVjdGlvbi4NCj4+PiBXaGlsZSB0 aGF0IGNhbiBiZSBhIGxhcmdlIG51bWJlciwgSSBzdXJlIGhvcGUgaXQgZG9lcyBub3QgY29tZSBj bG9zZSANCj4+PiB0byBzYXR1cmF0aW5nIDI0IGJpdHMuDQo+Pj4gDQo+Pj4gSGF2aW5nIHNhaWQg dGhhdCwgaWYgd2UgdGhpbmsgdGhhdCAyNCBiaXRzIGlzIG9ubHkganVzdCBlbm91Z2gsIHRoZW4g DQo+Pj4gd2Ugb3VnaHQgdG8gdXNlIDMyLiAgRnJvbSB3aGVyZSBJIHNpdCwgSSB3b3VsZCBub3Jt YWxseSBleHBlY3QgMTYgDQo+Pj4gYml0cyB0byBiZSBtb3JlIHRoYW4gc3VmZmljaWVudCwgd2hp Y2ggaXMgd2h5IEkgYW0gY29tZm9ydGFibGUgd2l0aCAyNC4NCj4+PiBIYXZpbmcgc2FpZCB0aGF0 LCB0aGUgZmllbGQgc2l6ZSBpcyBub3QgYSBiaWcgZGVhbCB0byBtZS4NCj4+PiANCj4+PiBZb3Vy cywNCj4+PiBKb2VsDQo+Pj4gDQo+Pj4gT24gMTIvNC8xNCwgMjowMSBQTSwgU3JpbmkgQWRkZXBh bGxpIHdyb3RlOg0KPj4+PiANCj4+Pj4gSSB3YXMgbm90IGltcGx5aW5nIHRoYXQgcGF0aCBJRCBz aG91bGQgaGF2ZSBpbmZvcm1hdGlvbiBpbiByZWdhcmRzIA0KPj4+PiB0byB0ZW5hbnQvY29udHJv bGxlci9mbG93L3NjYWxlLW91dC4gIEJ1dCBTRkMgY29udHJvbGxlcnMgc2hvdWxkIGtlZXAgdGhl c2UNCj4+Pj4gaW4gbWluZCB0byBhc3NpZ24gdGhlIHBhdGggSUQuICAgIEEgZGVwbG95bWVudCBj YW4gaGF2ZSBtdWx0aXBsZQ0KPj4+PiB0ZW5hbnRzLCBlYWNoIHRlbmFudCBjYW4gaGF2ZSBtdWx0 aXBsZSBuZXR3b3JrcywgIHRoZXJlIGNvdWxkIGJlIA0KPj4+PiBtaWxsaW9ucyBvZiBmbG93cyBp biBlYWNoIG9mIHRob3NlIG5ldHdvcmtzLiAgQW5kIGNvbnNpZGVyaW5nIGFsbCANCj4+Pj4gdGhl c2UsDQo+Pj4+IDI0IGJpdCBwYXRoIElEIG1heSBub3QgYmUgYWJsZSB0byByZXByZXNlbnQgcGF0 aHMgZm9yIHRoZXNlIGZsb3dzLg0KPj4+PiBIZW5jZSwgSSB3YXMgd29uZGVyaW5nIHdoZXRoZXIg cGF0aCBJRCBjYW4gYmUgZXh0ZW5kZWQgdG8gNjQgYml0cyANCj4+Pj4gb3IgbWFrZSBpdCBmbGV4 aWJsZS4NCj4+Pj4gDQo+Pj4+IFRoYW5rcw0KPj4+PiBTcmluaQ0KPj4+PiANCj4+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBGcm9tOiBKb2VsIE0uIEhh bHBlcm4gPGptaEBqb2VsaGFscGVybi5jb20+DQo+Pj4+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJl ciA0LCAyMDE0IDc6NDIgQU0NCj4+Pj4gVG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IHNmY0Bp ZXRmLm9yZw0KPj4+PiBDYzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDANCj4+Pj4gU3ViamVj dDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4+PiAoaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+Pj4+IA0KPj4+PiBUaGUgSW5k ZXggaXMgbm90IGp1c3QgZm9yIGxvb3AgcHJldmVudGlvbi4gIEluIHRoZSBjYXNlIG9mIA0KPj4+ PiBhbWJpZ3VpdHksIHRoZSBpbmRleCB0ZWxscyB0aGUgU0ZGIHdoZXJlIGluIHRoZSBwYXRoIHRo ZSBwYWNrZXQgY3VycmVudGx5IHJlc2lkZXMuDQo+Pj4+ICAgVGhlcmUgYXJlIG11bHRpcGxlIHdh eXMgc3VjaCBhbWJpZ3VpdHkgY2FuIG9jY3VyLg0KPj4+PiANCj4+Pj4gVGhlIFBhdGggSWRlbnRp ZmllciBpcyBzcGVjaWZpY2FsbHkgbm90IGV4cGVjdGVkIHRvIGluY2x1ZGUgDQo+Pj4+IGNvbnRy b2xsZXIgSUQgb3IgVGVuYW50IElELiAgV2hpbGUgYSBkZXBsb3llciBjYW4gaGF2ZSBhIHBhdGgg cGVyIA0KPj4+PiB0ZW5hbnQsIHRoZSBhcmNoaXRlY3R1cmUgc3RpbGwgZG9lcyBub3QgdHJlYXQg dGhlIHBhdGggSUQgYXMgYSANCj4+Pj4gdGVuYW50IElELiAgVGVuYW50IElELCBjb250cm9sbGVy IElELCBhbmQgb3RoZXIgbm9uLXBhdGgtc3BlY2lmeWluZyANCj4+Pj4gaW5mb3JtYXRpb24gaXMg dG8gYmUgY2FycmllZCBpbiBtZXRhZGF0YS4NCj4+Pj4gDQo+Pj4+IFlvdXJzLA0KPj4+PiBKb2Vs DQo+Pj4+IA0KPj4+PiBPbiAxMi80LzE0LCAxMDowMiBBTSwgU3JpbmkgQWRkZXBhbGxpIHdyb3Rl Og0KPj4+Pj4gVHdvIGNvbW1lbnRzIDoNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiAxLiAgU0YgSW5k ZXggOiAgU2luY2UgaXQgaXMgbWVhbnQgZm9yIGxvb3AgZGV0ZWN0aW9uLCAgd291bGRuJ3QgDQo+ Pj4+PiBiZXR0ZXIgdG8gcmVuYW1lIHRoaXMgYXMgIlRUTCI/DQo+Pj4+PiANCj4+Pj4+IDIuICBQ YXRoIElkZW50aWZpZXIgOiAgICAyNCBiaXQgcGF0aCBpZGVudGlmaWVyIHNlZW1zIHRvIGJlIHRv byBsZXNzLg0KPj4+Pj4gQmFzZWQgb24gb3VyIGV4cGVyaWVuY2UgaW4gdHJhZmZpYyBzdGVlcmlu ZywgIHRoaXMgcGF0aCBpZGVudGlmaWVyIA0KPj4+Pj4gbmVlZHMgdG8gZW5jb2RlIGdvb2QgYW1v dW50IG9mIGluZm9ybWF0aW9uIHRvIG1ha2UgaXQgdW5pcXVlLiAgRm9yIA0KPj4+Pj4gZXhhbXBs ZSwNCj4+Pj4+ICAgdGhpcyBpZGVudGlmaWVyIG5lZWRzIHRvIGVuY29kZSAoaW4gb3VyIGNhc2Up IHNvbWUgaW5mb3JtYXRpb24gDQo+Pj4+PiByZXByZXNlbnRpbmcgdGhlIGRpc3RyaWJ1dGVkIGNv bnRyb2xsZXIgSUQsICB0ZW5hbnQgSUQsICBmbG93IElELA0KPj4+Pj4gICBTZXJ2aWNlIGZ1bmN0 aW9uIGluc3RhbmNlIChpbiBjYXNlIG9mIHNjYWxlLW91dCkgYW5kIGZldyBtb3JlLi4NCj4+Pj4+ IE9uZSBzdWdnZXN0aW9uIGlzIHRvIG1ha2UgaXQgNjQgYml0cyB2YWx1ZSAgb3IgdG8gbWFrZSBp dCBldmVuIA0KPj4+Pj4gZXh0ZW5kYWJsZSwNCj4+Pj4+ICAgaXQgaXMgZ29vZCBpZiBwYXRoIGlk ZW50aWZpZXIgaXMgYWxzbyByZXByZXNlbnRlZCBpbiBUTFYgZm9ybS4NCj4+Pj4+IA0KPj4+Pj4g DQo+Pj4+PiBUaGFua3MNCj4+Pj4+IA0KPj4+Pj4gU3JpbmkNCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+ PiANCj4+Pj4+IA0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+IA0KPj4+ IA0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+IHNmY0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiANCj4gDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+ IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gDQo+IA0KPiBUaGlzIG1lc3NhZ2UgYW5kIGFueSBh dHRhY2htZW50cyAodGhlICJtZXNzYWdlIikgYXJlIGNvbmZpZGVudGlhbCwgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgYWRkcmVzc2Vlcy4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQg ZGVsZXRlIHRoaXMgbWVzc2FnZSBmcm9tIHlvdXIgc3lzdGVtLiBJbiB0aGlzIGNhc2UsIHlvdSBh cmUgbm90IGF1dGhvcml6ZWQgdG8gdXNlLCBjb3B5IHRoaXMgbWVzc2FnZSBhbmQvb3IgZGlzY2xv c2UgdGhlIGNvbnRlbnQgdG8gYW55IG90aGVyIHBlcnNvbi4gRS1tYWlscyBhcmUgc3VzY2VwdGli bGUgdG8gYWx0ZXJhdGlvbi4gTmVpdGhlciBRb3Ntb3Mgbm9yIGFueSBvZiBpdHMgc3Vic2lkaWFy aWVzIG9yIGFmZmlsaWF0ZXMgc2hhbGwgYmUgbGlhYmxlIGZvciB0aGUgbWVzc2FnZSBpZiBhbHRl cmVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gDQo+IENlIG1lc3NhZ2UgZXQgdG91dGVzIHNl cyBwacOoY2VzIGpvaW50ZXMgKGNpLWFwcsOocyBsZSAibWVzc2FnZSIpc29udCBjb25maWRlbnRp ZWxzIGV0IMOpdGFibGlzIMOgIGwnaW50ZW50aW9uIGV4Y2x1c2l2ZSBkZSBzZXMgZGVzdGluYXRh aXJlcy4gU2kgdm91cyBhdmV6IHJlw6d1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgbWVyY2kgZOKA mWVuIGluZm9ybWVyIGltbcOpZGlhdGVtZW50IHNvbiDDqW1ldHRldXIgcGFyIGNvdXJyaWVyIMOp bGVjdHJvbmlxdWUgZXQgZOKAmWVmZmFjZXIgY2UgbWVzc2FnZSBkZSB2b3RyZSBzeXN0w6htZS4g RGFucyBjZXR0ZSBoeXBvdGjDqHNlLCB2b3VzIG7igJnDqnRlcyBwYXMgYXV0b3Jpc8OpIMOgIHV0 aWxpc2VyLCBjb3BpZXIgY2UgbWVzc2FnZSBldC9vdSBlbiBkaXZ1bGd1ZXIgbGUgY29udGVudSDD oCB1biB0aWVycy4gVG91dCBtZXNzYWdlIMOpbGVjdHJvbmlxdWUgZXN0IHN1c2NlcHRpYmxlIGQn YWx0w6lyYXRpb24uIFFvc21vcyBldCBzZXMgZmlsaWFsZXMgZMOpY2xpbmVudCB0b3V0ZSByZXNw b25zYWJpbGl0w6kgYXUgdGl0cmUgZGUgY2UgbWVzc2FnZSBzJ2lsIGEgw6l0w6kgYWx0w6lyw6ks IGTDqWZvcm3DqSBvdSBmYWxzaWZpw6kuDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpz ZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Tue Feb 3 08:39:19 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8515D1A1A4B for ; Tue, 3 Feb 2015 08:39:18 -0800 (PST) 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 pqQwqibJsAIl for ; Tue, 3 Feb 2015 08:39:14 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 604311A1A16 for ; Tue, 3 Feb 2015 08:39:14 -0800 (PST) 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; Tue, 3 Feb 2015 11:39:12 -0500 From: Dave Dolson To: "'sfc@ietf.org'" , "walter.haeffner@vodafone.com" , "jenapper@cisco.com" , "mls.ietf@gmail.com" , "diego@tid.es" , "uttaro@att.com" Thread-Topic: Mobile use cases draft-ietf-sfc-use-case-mobility-03 Thread-Index: AdA5i9PHaEFtXImRQvatdBwSl/7IsAGQ+l7g Date: Tue, 3 Feb 2015 16:39:12 +0000 Message-ID: References: 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Mobile use cases draft-ietf-sfc-use-case-mobility-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 16:39:18 -0000 Would one of the authors (or anyone else) be able to answer my question? -Dave -----Original Message----- From: Dave Dolson=20 Sent: Monday, January 26, 2015 12:17 PM To: 'sfc@ietf.org'; 'walter.haeffner@vodafone.com'; 'jenapper@cisco.com'; '= mls.ietf@gmail.com'; 'diego@tid.es'; 'uttaro@att.com' Subject: Mobile use cases draft-ietf-sfc-use-case-mobility-03 Authors of draft-ietf-sfc-use-case-mobility, You make explicit reference (in section 2.2) to the care to be taken=20 with bidirectional flows, which I agree with. So, referring to your figure 5: +-------------------------+ | PCRF | +----+--------------+-----+ | | Gx-IF Sd-IF | | +----+-----+ +----+-----+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO [PCEF] | | O--------[SFC 1]= ---- [Appl. 1] | | | O--------[SFC 2] ---- [Appl. 2] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO P-GW O---O [TDF] O--------[SFC 3]= ---- [Appl. 3] | | | O--------[SFC 4] ---- [Appl. 4] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO | | O--------[SFC n]= ---- [Appl. n] +----------+ +----------+ * * 3GPP Bearer SGi SGi It isn't clear what device is selecting the chains for down-link traffic. Given that the TDF is making application-specific decisions, how would=20 one ensure the down-link traffic is classified to the same service=20 functions as the up-link traffic, something very critical for many of=20 the use cases? * a TDF can classify traffic using a wide variety of methods,=20 including signature-matching that uses fields only available at=20 the start of a flow, likely only appearing in one direction; (classification based solely on port number is rather weak).=20 So in the general case, decisions are made for TCP connections,=20 not for packets. I propose that the picture is more like the following, with the TDF=20 book-ending the service chains to ensure consistent classification of=20 both up-link and down-link traffic for a given transport connection. +-------------------------+ | PCRF | +----+--------------+-----+ | | Gx-IF Sd-IF | | | +----+------------------------------------+ | | [TDF] | | | +----------------------------+ | +----+-----+ | | | | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO [PCEF] | | O---[SFC 1] ---- [A= ppl. 1]---O | | | | O---[SFC 2] ---- [Appl. 2]---O |--- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO P-GW O---O O---[SFC 3] ---- [A= ppl. 3]---O | | | | O---[SFC 4] ---- [Appl. 4]---O | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO | | O---[SFC n] ---- [A= ppl. n]---O | +----------+ +-------+ +----+ * * 3GPP Bearer SGi SGi Perhaps this is what you intended. Is this what you had in mind? David Dolson Senior Software Architect, Sandvine Inc. From nobody Tue Feb 3 09:15: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 448E11A1B7A for ; Tue, 3 Feb 2015 09:15:06 -0800 (PST) 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 NaU5bW_qukl6 for ; Tue, 3 Feb 2015 09:15:02 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675B91A1A16 for ; Tue, 3 Feb 2015 09:15:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2237; q=dns/txt; s=iport; t=1422983702; x=1424193302; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=seN1Xwt+UmtUMy3VlCRzoedkDGjE3qfxo4QbC8AHUTk=; b=jaCth3ctbZDdrEK01bRLiZrHPnW96HlHkM2cL9Lzx4d/o4IR1EE8iRm4 f/zYif9C+fHdNLaii+6NAeOu9+0Nh1ftr6jXR3dW8JR1ZUOIrvYtcO/Uf V3klxshXx+PRSp5SlGwgF1QHM/ZAR20tmpal6v5eVoieze9cP2ydGpxC5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFALAB0VStJV2c/2dsb2JhbABQCoJkIlJZBMR7CoVxAoEeQwEBAQEBfYQMAQEBAwEBAQFREwcLEAIBCBIGLicLFw4CBAENBYglCAEM1n0BAQEBAQEBAQEBAQEBAQEBAQEBAQETBI8cKTMHhCkFiXGFG4NOhViSXyKCMoE8b4FEfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,513,1418083200"; d="scan'208";a="389961514" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 03 Feb 2015 17:15:01 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t13HF1L1024603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 17:15:01 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 11:15:01 -0600 From: "Ken Gray (kegray)" To: "Paul Quinn (paulq)" , Nicolas BOUTHORS Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZx/9uiAgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgCAAEtwAIBWb4+AgAEKeQCABnZ2gP//3TOA Date: Tue, 3 Feb 2015 17:15:00 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.23.212] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <650F8203CF3C5B42A3F18A66B811C703@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 03 Feb 2015 17:15:07 -0000 Not an author, but you could use the Network Shared Context for it. On 2/3/15, 9:19 AM, "Paul Quinn (paulq)" wrote: > >> On Jan 30, 2015, at 6:38 AM, Nicolas BOUTHORS >> wrote: >>=20 >> Hello Cathy, >>=20 >> Indeed the notion of "rendered service path ID"(RSP ID) seems relevant >>as the architecture document stipulates that the Service Function Path >>(SFP) provides an abstract notion of a service chain, while the RSP is a >>constrained list of locations. >>=20 >> SFC header "Service Path Identifier" (SPI) is used in both NSH and SCH >>protocol and in both case seem to identify to a particular SFP. >>=20 >> NSH(v5) for example states that >> " As described above, NSH contains a service path identifier (SPI) and >> a service index (SI). The SPI is, as per its name, an identifier. >> The SPI alone cannot be used to forward packets along a service path. >> Rather the SPI provide a level of indirection between the service >> path/topology and the the network transport. Furthermore, there is >> no requirement, or expectation of an SPI being bound to a pre- >> determined or static network path." >>=20 >> Still NSH(v5) shows that SPI (not a RSP ID) should be part of the key >> element of an SFF to lookup on forwarding tables. But I could not find >>in NSH how to use the notion of >> Rendered service path which was defined in the architecture document. >>=20 > >Nicolas, thanks for reading NSH-05, I just want to clarify the RSP / SPI >discussion in that context. > >Architecturally, the definition of rendered path does not imply the need >of an RSP ID, and the SPF ID can represent the path to be rendered in the >network. We=B9ve found this to be true in implementation. If however, yo= u >feel that additional granularity is required, for load balancing for >example, an additional ID (RSP or flow in some cases) is easily carried >in NSH. > >I=B9m sure the architecture draft authors can weigh in as needed as well. > > > >Thanks, >Paul >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Feb 3 10:08:39 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFCB1A700B for ; Tue, 3 Feb 2015 10:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, 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 hWL9fxRoKg7P for ; Tue, 3 Feb 2015 10:08:34 -0800 (PST) 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 8EE781A8760 for ; Tue, 3 Feb 2015 10:08:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17732; q=dns/txt; s=iport; t=1422986914; x=1424196514; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hUhAw4qHj0s1f9zg1rA8rljSAIcYFURsEZqGSf4HvrM=; b=OU3hgFZawjv9PsejAAtW2C3E8BRhQTNakIMo6CLlba/IanV5z6wqy65i R9gbpryPZaxMa+GY65KcdDxBr+wvS7v5rIxoQu7paZwlTSWJAh+kETMJz R+DqvdS3uH8RayOmDGVjdrE+bgbJbc2ZVTOVbdv9lYiQwGA9K5kWhRa0q 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogFABkO0VStJV2Z/2dsb2JhbABagmQiUlkEgn3BfwqFcQIcgQJDAQEBAQF9hAwBAQEEAQEBMTMHCwwEAgEIEQEDAQEBBCMFAgIlCxQDBggCBAENBRmIFAEMo1acZAaWTAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgRuIc4UHMAgQGwcCAgKCXIFHAQSPDINOhViBF4MDgkWMACKCAhwUgTxvAYFDfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,514,1418083200"; d="scan'208";a="393168403" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 03 Feb 2015 18:08:33 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t13I8X3K006118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 18:08:33 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 12:08:32 -0600 From: "Ken Gray (kegray)" To: Cathy Zhang , Srini Addepalli , "Reinaldo Penno (repenno)" , "Joel M. Halpern" , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZx/9uiAgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgCAAEtwAIBWb4+AgAdtFgA= Date: Tue, 3 Feb 2015 18:08:31 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.23.212] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "nsmurthy@freescale.com" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 03 Feb 2015 18:08:38 -0000 QXMgYSBnZW5lcmFsIGNvbW1lbnQgb24gdGhpcyBzdWJtaXNzaW9uIChhbmQgcGVyaGFwcyBsaWZl IGluIHRoZSBjdXJyZW50DQpJRVRGKS4gIEkgaGF2ZSBhIFJFQUxMWSBoYXJkIHRpbWUgZGlmZmVy ZW50aWF0aW5nIHRoaXMgZHJhZnQgZnJvbSB0aGUNCnF1aW5uIGRyYWZ0ICh3aGljaCBwcmUtZGF0 ZXMgaXQgYnkgcXVpdGUgYSBiaXQpLiAgV2h5IGFyZSB3ZSBwdXJzdWluZyBhDQpzZXBhcmF0ZSBk cmFmdCB3aGVuIHRoZSBzdWdnZXN0aW9ucywgSU1ITywgc2VlbSBpbmNyZW1lbnRhbCBhdCBiZXN0 Pw0KDQpJIGhhdmUgcmVhY2ggb3V0IHRvIHRoZSBjaGFpcnMgaGVyZSChpiB3ZSBoYXZlIGEgbG90 IHRvIHJlYWQuIEFyZW6hr3QgZHJhZnRzDQpzdXBwb3NlZCB0byBvZmZlciBzaWduaWZpY2FudGx5 IGRpZmZlcmVudCB2aWV3cyBpZiB0aGV5IGFyZSB0byBwZXJzaXN0DQood2l0aG91dCB0aGF0LCBh IKGwY2FsbCB0byBhZG9wdKGxIGJlY29tZXMgYSBiZWF1dHkgY29udGVzdCwgSU1PKT8gIE5vDQpv ZmZlbnNlIHRvIHRoZSBhdXRob3JzLCBidXQgd2Whr3JlIGluIHJldmlzaW9uIDMgYW5kIEkgZG9u oa90IHNlZSB0aGF0IGhlcmUuDQogDQoNClJlZ2FyZGluZyB0aGUgY2hhbmdlcyBpbiB0aGlzIGRv Y3VtZW50Og0KDQpJIGRvIG5vdCBmaW5kIHRoZSBmbG93IElEIGZ1bmN0aW9uYWxseSBkaWZmZXJl bnQgdGhhbiB0aGUgdXNlIGNvbnRleHQNCmhlYWRlcnMgaW4gdGhlIG5zaCBkcmFmdCwgd2hpY2gg c2VlbSB0byBiZSBhIG1vcmUgbXVsdGktcHVycG9zZSBjb25jZXB0Lg0KDQpUaGUgQiBiaXQgc3Vn Z2VzdGlvbiBjYW4gY2F1c2UgYSBjb25mbGljdCBpbiBjb250cm9sIGFuZCBjcmVhdGUgYW4gYXZl bnVlDQpmb3IgdW5kZXNpcmFibGUgYmVoYXZpb3IsIElNTy4gIEmhr3ZlIGJlZW4gd29ya2luZyBm cm9tIHRoZSBhc3N1bXB0aW9uIHRoYXQNCmEgbWluaW11bSByZXF1aXJlbWVudCBvZiBhIGZ1bmN0 aW9uIGlzIHRoYXQgaXQgYmUgbWFuYWdlYWJsZSAoaWYgZm9yIG5vDQpvdGhlciByZWFzb24gdGhh biBlZmZlY3RpdmUgZWxhc3RpY2l0eSBhbmQgY29oZXNpdmUvcHJlZGljdGFibGUgZGVsaXZlcnkN Cm9mIHNlcnZpY2UpLCBzbyBJIGhhdmUgbGl0dGxlIHN5bXBhdGh5IGZvciB0aG9zZSB0aGF0IGFy ZSBub3QgLSBiZSB0aGV5DQp2aXJ0dWFsIG9yIHBoeXNpY2FsIChldmVuIGxlc3Mgc3ltcGF0aHkg Zm9yIHZpcnR1YWwgZnVuY3Rpb25zIHRoYXQgYXJlDQp1bm1hbmFnZWFibGUsIGZyYW5rbHkpLiAg QSBzZWxmLW1hbmFnZW1lbnQgb3B0aW9uIGluIHRoZSBTRkMgc2NlbmFyaW8gaGFzDQpsb3cgdmFs dWUgYW5kIHRoZSBjb3JydXB0aW9uIG9yIG1pc3VzZSBvZiB0aGUgYml0IGNhbiBjYXVzZSBjaGFv cyAoYW4NCmV4dHJhIGxldmVsIG9mIKGwZmFpbKGxKS4NCg0KDQpUaGUgR2VuZXJpYyBDb250ZXh0 IEJsb2NrIGlzIGNvbmZ1c2luZyBpbiBsaWdodCBvZiB0aGUgYWxyZWFkeSBleHRhbnQNCm9wdGlv bmFsL3ZhcmlhYmxlIG1ldGFkYXRhIFRMVnMgKHdoeSB3b3VsZG6hr3QgeW91IGxldmVyYWdlIG9u ZSBvZiB0aGVtKT8NCg0KDQoNCk9uIDEvMjkvMTUsIDI6NDQgUE0sICJDYXRoeSBaaGFuZyIgPENh dGh5LkguWmhhbmdAaHVhd2VpLmNvbT4gd3JvdGU6DQoNCj5IaSBldmVyeW9uZSwNCj4NCj5XZSBo YXZlIHVwbG9hZGVkIGEgbmV3IFNDSCB2ZXJzaW9uICgzKSB3aGljaCBhZGRzIGRlZmluaXRpb24g b2YgYSBuZXcNCj5tZXRhZGF0YSB0eXBlIGZvciB0aGUgZmxvdyBJRCB0byBzdXBwb3J0IGxvYWQg YmFsYW5jaW5nIGFtb25nIFNGDQo+aW5zdGFuY2VzIGFuZCBtaXRpZ2F0ZSB0aGUgcG90ZW50aWFs IGlzc3VlIG9mICJub3QgZW5vdWdoIHBhdGggSUQiLiBUaGUNCj5mbG93IElEIGlzIG5hbWVkICJy ZW5kZXJlZCBzZXJ2aWNlIHBhdGggSUQiIGluIHRoZSBkcmFmdC4gUGxlYXNlIHJlZmVyIHRvDQo+ c2VjdGlvbiA0LjMuMiBvZiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC16 aGFuZy1zZmMtc2NoLw0KPmZvciBkZXRhaWwgZGVzY3JpcHRpb24uDQo+IA0KPg0KPkluIGl0cyBw cmV2aW91cyB2ZXJzaW9uLCBTQ0ggZGVmaW5lcyBhICJCeXBhc3MgYml0IiBpbiB0aGUgYmFzZSBo ZWFkZXIuDQo+VGhpcyBiaXQgZW5hYmxlcyB0aGUgU0YgdG8gcHJvdmlkZSBmZWVkYmFjay9ub3Rp ZmljYXRpb24gdmlhIHRoZSBkYXRhDQo+cGF0aCB0byBpdHMgY29ubmVjdGluZyBTRkYgYWJvdXQg d2hldGhlciB0aGUgcmVtYWluaW5nIHBhY2tldHMgb2YgdGhlIFNGQw0KPnNob3VsZCBieXBhc3Mg dGhhdCBTRi4gVGhpcyBpcyB1c2VmdWwgaW4gdGhlIGNhc2UgdGhhdCBvbmx5IHRoZSBmaXJzdCBm ZXcNCj5wYWNrZXRzIG9mIGEgZmxvdyBuZWVkIHRvIGdvIHRvIGEgU0YgKHN1Y2ggYXMgYSBEUEkg b3IgRlcgb3IgSURTKSBhbmQNCj5yZW1haW5pbmcgcGFja2V0cyBjYW4gYnlwYXNzIHRoYXQgU0Ys IHRodXMgc2F2aW5nIHRoZSBleHBlbnNpdmUgU0YNCj5yZXNvdXJjZSBhbmQgcmVkdWNpbmcgZGF0 YSBwYXRoIGxhdGVuY3kuDQo+DQo+QiBiaXQ6IFRoZSBCIChCeXBhc3MpIGJpdCwgd2hlbiBzZXQg dG8gMSwgaXQgaXMgdXNlZCBieSBhIFNlcnZpY2UNCj4gICAgICAgRnVuY3Rpb24gdG8gc2lnbmFs IHRvIGl0cyBTZXJ2aWNlIEZ1bmN0aW9uIEZvcndhcmRlciB0aGF0IG5vDQo+ICAgICAgIGZ1cnRo ZXIgcGFja2V0cyBhcmUgdG8gYmUgc2VudCB0byBpdCBmb3IgdGhlIGZsb3cgc3BlY2lmaWVkIGlu DQo+ZW5jYXBzdWxhdGVkIHBhY2tldC4NCj4NCj5JbiBhZGRpdGlvbiwgU0NIIGRlZmluZXMgYSBt ZXRhZGF0YSB0eXBlIGZvciBHZW5lcmljIENvbnRleHQgQmxvY2ssIHdoaWNoDQo+aXMgb3B0aW9u YWwgYW5kIGNhbiBiZSB1c2VkIGlmIG5lZWRlZCB0byBjYXJyeSBhbnkgdmVuZG9yJ3Mgc3BlY2lm aWMNCj4iQ29udGV4dCBIZWFkZXIiLg0KPiANCj4NCj5BbnkgY29tbWVudHMgb24gdGhlc2UgbmV3 IGFkZGl0aW9ucz8NCj4NCj5UaGFua3MsDQo+Q2F0aHkNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgQ2F0aHkgWmhhbmcNCj5TZW50OiBGcmlkYXksIERlY2VtYmVyIDA1LCAyMDE0IDExOjQ3 IEFNDQo+VG86IFNyaW5pIEFkZGVwYWxsaTsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBKb2Vs IE0uIEhhbHBlcm47DQo+J3NmY0BpZXRmLm9yZycNCj5DYzogbnNtdXJ0aHlAZnJlZXNjYWxlLmNv bQ0KPlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4oaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+DQo+Um9uLCBMb3Vp cywgTXlvIGFuZCBJIGhhdmUgYmVlbiBkaXNjdXNzaW5nIG9mZiBsaW5lIGxhc3QgZmV3IHdlZWtz IGFib3V0DQo+ZGVmaW5pbmcgYSBtZXRhZGF0YSB0eXBlIGZvciBmbG93IElEIGluIGFkZGl0aW9u IHRvIHRoZSBwYXRoIElEIG9mIHRoZQ0KPm1haW4gaGVhZGVyIHRvIHN1cHBvcnQgbG9hZCBiYWxh bmNpbmcgYW1vbmcgU0YgaW5zdGFuY2VzLiBXZSB3aWxsIGRlZmluZQ0KPmEgVExWIHR5cGUgZm9y IHRoZSBmbG93IElELiBUaGUgY29tYmluYXRpb24gb2YgInBhdGggSUQgKyBmbG93IElEIg0KPnNw ZWNpZmllcyBhIHJlYWxpemVkIHNlcnZpY2UgY2hhaW4gaW5zdGFuY2UgcGF0aC4gSXQgaXMgbGVm dCB0byB0aGUNCj5kZXNpZ24vaW1wbGVtZW50YXRpb24gd2hldGhlciB0byB1c2UgYSBjZW50cmFs aXplZCBtZXRob2Qgb3IgYQ0KPmRpc3RyaWJ1dGVkIG1ldGhvZCB0byBiaW5kIHRoZSBmbG93IElE IHRvIGEgcmVhbGl6ZWQgc2VydmljZSBpbnN0YW5jZQ0KPnBhdGggYWx0aG91Z2ggb3VyIG9yaWdp bmFsIHRob3VnaHQgaXMgZm9yIGRpc3RyaWJ1dGVkIExCIHVzYWdlLiBJIGFtIG5vdA0KPnN1cmUg aWYgd2UgbmVlZCBhIGJpdCBpbiB0aGUgaGVhZGVyIHRvIGRlbm90ZSB3aGV0aGVyIHRoZXJlIGFy ZSBtb3JlIHBhdGgNCj5JRCBiaXRzICh3ZSBjYWxsIGl0IGZsb3cgSUQpIGluIHRoZSBtZXRhZGF0 YSBmaWVsZHMgc2luY2Ugd2hlbiB5b3UgcGFyc2UNCj50aGUgVExWIG1ldGFkYXRhLCB5b3Ugd2ls bCBrbm93IHdoZXRoZXIgdGhlcmUgYXJlIGZsb3cgSUQgYml0cyBvciBub3QuDQo+Tm90ZSB0aGF0 IGlmIG11bHRpcGxlIHNlc3Npb25zIHNoYXJlIHRoZSBzYW1lIHJlYWxpemVkIHNlcnZpY2UgaW5z dGFuY2UNCj5wYXRoLCB0aGV5IHdpbGwgc2hhcmUgdGhlIHNhbWUgInBhdGggSUQrIGZsb3cgSUQi LiAgV2UgY2FuIGFsc28gY29uc2lkZXINCj5leHRlbmRpbmcgdGhlIG51bWJlciBvZiBiaXRzIHRv IDMyIGlmIHRoYXQgaXMgdGhlIGNvbnNlbnN1cy4gV2Ugd2lsbCBwb3N0DQo+YW4gdXBkYXRlZCBk cmFmdCBkZXNjcmliaW5nIHRoZXNlIHNvb24uDQo+DQo+VGhhbmtzLA0KPkNhdGh5DQo+DQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNyaW5pIEFkZGVwYWxsaQ0KPlNlbnQ6IEZyaWRheSwgRGVj ZW1iZXIgMDUsIDIwMTQgNzoxNyBBTQ0KPlRvOiBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IEpv ZWwgTS4gSGFscGVybjsgJ3NmY0BpZXRmLm9yZycNCj5DYzogbnNtdXJ0aHlAZnJlZXNjYWxlLmNv bQ0KPlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4oaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+DQo+DQo+W1JQXSBE YXRhIHBsYW5lIGVmZmljaWVuY3kuDQo+DQo+U1JJTkk+IEkgYW0gbm90IHNvIHN1cmUgYWJvdXQg ZGF0YSBwbGFuZSBlZmZpY2llbmN5LiAgTW9zdCBvZiB0aGUNCj5wcm9jZXNzb3JzIHdvcmsgZ29v ZCBpZiB0aGUgbnVtYmVyIG9mIGJpdHMgYXJlIGVpdGhlciAzMiBvciA2NC4gIElmIGl0IGlzDQo+ MjQgYml0cywgdGhlbiBvbmUgbmVlZHMgdG8gZG8gbWFza2luZyBhbmQgc2hpZnRpbmcgYmVmb3Jl IHRoZSB2YWx1ZSBpcw0KPnVzZWQgdG8gZG8gYW55IGxvb2t1cC4gICBCdXQsIHRoaXMgZGlzY3Vz c2lvbiBjYW4gZ28gaW50byBkaWZmZXJlbnQNCj5kaXJlY3Rpb24gOi0pLCBpdCBtYXkgbm90IGJl IGdvb2QgdG8gZ28gaW4gdGhhdCBkaXJlY3Rpb24uDQo+DQo+V2hlcmUgZG8gd2UgZHJhdyB0aGUg bGluZT8gMzItYml0cywgNjQtYml0cywNCj4xMjggYml0cz8gSSB0aGluayB3ZSBzaG91bGQgaGF2 ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRoZSBTZXJ2aWNlIFBhdGgNCj5oZWFkZXIgYW5kIGlmIHlv dSBuZWVkIHRvIGNvbnZleSBtb3JlIGJpdHMgeW91IG5lZWQgdG8gdXNlIHRoZSBjb250ZXh0DQo+ aGVhZGVycy4NCj4NCj5TUklOST4gVGhpcyBpcyBhIGdvb2QgcG9pbnQuICBUaGlzIHNob3VsZCB3 b3JrIGZpbmUgYXMgbG9uZyBhcyB0aGVyZSBpcw0KPndheSB0byBjb252ZXkgaW4gdGhlIG1haW4g aGVhZGVyIHRoYXQgdGhlIGV4dGVuc2lvbiB0byBwYXRoIElEIGlzDQo+YXZhaWxhYmxlIGluIHNv IGFuZCBzbyBUTFYgZmllbGQuICBUaGF0IHNob3VsZCB3b3JrIHRvby4NCj4NCj5UaGFua3MNCj5T cmluaQ0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Gcm9t OiBSZWluYWxkbyBQZW5ubyAocmVwZW5ubykgPHJlcGVubm9AY2lzY28uY29tPg0KPlNlbnQ6IEZy aWRheSwgRGVjZW1iZXIgNSwgMjAxNCA3OjA4IEFNDQo+VG86IEFkZGVwYWxsaSBTcmluaS1CMjIx NjA7IEpvZWwgTS4gSGFscGVybjsgJ3NmY0BpZXRmLm9yZycNCj5DYzogTlMgU3Jpbml2YXNhIE11 cnRoeS1CMzc4NDANCj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+ KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPg0K Pk9uIDEyLzUvMTQsIDY6NTQgQU0sICJTcmluaSBBZGRlcGFsbGkiIDxzYWRkZXBhbGxpQGZyZWVz Y2FsZS5jb20+IHdyb3RlOg0KPg0KPj4NCj4+SW4gcmVhbCBkZXBsb3ltZW50cywgbnVtYmVyIG9m IGFjdGl2ZSBwYXRoIElEcyBhcmUgdmVyeSBsZXNzZXIgdGhhbiAyXjY0LA0KPj5idXQgdGhlcmUg aXMgYSBnb29kIHBvc3NpYmlsaXR5IG9mIHRoZSBudW1iZXIgYmVpbmcgbW9yZSB0aGFuIDJeMjQg KDE2TSkuDQo+PiBJIHRoaW5rIGJpZ2dlciBwb2ludCBpcyB0aGF0IHdoeSByZXN0cmljdCB0aGlz IGluIHRoZSBzdGFuZGFyZHM/IFdoYXQNCj4+YWR2YW50YWdlIGRvIHdlIGhhdmUgcmVzdHJpY3Rp bmcgdGhpcyBzaXplIHRvIDI0IGJpdHM/DQo+DQo+W1JQXSBEYXRhIHBsYW5lIGVmZmljaWVuY3ku IFdoZXJlIGRvIHdlIGRyYXcgdGhlIGxpbmU/IDMyLWJpdHMsIDY0LWJpdHMsDQo+MTI4IGJpdHM/ IEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgYSBzZW5zaWJsZSB2YWx1ZSBpbiB0aGUgU2VydmljZSBQ YXRoDQo+aGVhZGVyIGFuZCBpZiB5b3UgbmVlZCB0byBjb252ZXkgbW9yZSBiaXRzIHlvdSBuZWVk IHRvIHVzZSB0aGUgY29udGV4dA0KPmhlYWRlcnMuDQo+DQo+DQo+Pg0KPj5UaGVyZSBjYW4gYmUg ZGVwbG95bWVudHMsIHdoZXJlIFNGQyBjb250cm9sbGVyIChMb2dpY2FsbHkgY2VudHJhbCwgYnV0 DQo+PmRpc3RyaWJ1dGVkKSAgaXRzZWxmIGNhbiBkbyB0aGUgU0YgaW5zdGFuY2Ugc2VsZWN0aW9u IG9uIHBlcg0KPj5jb25uZWN0aW9uL3Nlc3Npb24gYmFzaXMsIHRoZXJlYnkgYXZvaWRpbmcgdGhl IExCcyBmb3Igc2VydmljZXMuICAgSW4gbXkNCj4+dmlldywgYXNzdW1wdGlvbiB0aGF0IHRoZXJl IHdpbGwgYmUgTEIgU0YgZm9yIGVhY2ggc2NhbGUtb3V0IHNlcnZpY2UgaW4NCj4+dGhlIGNoYWlu IGlzIG5vdCB2YWxpZCBpbiBhbGwgY2FzZXMuDQo+Pg0KPj5UaGFua3MNCj4+U3JpbmkNCj4+DQo+ Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+RnJvbTogUmVpbmFs ZG8gUGVubm8gKHJlcGVubm8pIDxyZXBlbm5vQGNpc2NvLmNvbT4NCj4+U2VudDogVGh1cnNkYXks IERlY2VtYmVyIDQsIDIwMTQgMToxNyBQTQ0KPj5UbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2MDsg Sm9lbCBNLiBIYWxwZXJuOyBzZmNAaWV0Zi5vcmcNCj4+Q2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHkt QjM3ODQwDQo+PlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4+KGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4NCj4+ SWYgSSB1bmRlcnN0b29kIHlvdSwgSSBkbyBub3QgdGhpbmsgdGhpcyBpcyByZWFsaXN0aWMuIEFy ZSB5b3Ugc2F5aW5nIHlvdQ0KPj5uZWVkIDY0LWJpdHMgb2YgcGF0aHMgYW5kIHRoZW4gd2lsbCBt b25pdG9yIHRoZW0gYWxsPyBEbyBmYXVsdCB0b2xlcmFuY2UNCj4+YW5kIE9BTSBmb3IgMl42NC1i aXRzIHdvcnRoIG9mIHBhdGhzPyBKdXN0IGZvciBjb21wYXJpc29uLCBpdKn2cyBsaWtlDQo+Pm1h bmFnaW5nIGFuZCBtb25pdG9yaW5nIHRoZSBlbnRpcmUgSVB2NiBob3N0IHJhbmdlLCBvbmUtYnkt b25lLg0KPj4NCj4+QW55d2F5LCBJIGRvIG5vdCBleHBlY3QgZXZlcnkgc2luZ2xlIHBlcm11dGF0 aW9ucyB0byBiZSBhIGRpZmZlcmVudCBwYXRoLg0KPj4NCj4+SWYgZWFjaCBzZXJ2aWNlIGhhcyAy NTYgZGV2aWNlcyBwcm92aWRpbmcgc2ltaWxhciBzZXJ2aWNlLCB5b3Ugc2hvdWxkDQo+Pm1vc3QN Cj4+bGlrZWx5IHVzZSBsb2FkLWJhbGFuY2luZyBhbmQgdGhlbiB5b3Ugd291bGQgaGF2ZSBhIHNp bmdsZSAob3IgYSBmZXcpDQo+PnBhdGhzLiBUaGVyZSBpcyBzb21lIGRpc2N1c3Npb24gZ29pbmcg b24gTEIuDQo+Pg0KPj5Gcm9tIGEgZGF0YSBwbGFuZSBwZXJzcGVjdGl2ZSwgdGhlIHBhdGggaXMg dWx0aW1hdGVseSBkZWZpbmVkIGJ5IHRoZSBTRkZzDQo+PnRyYXZlcnNlZCBhbmQgc2VydmljZXMg cHJvdmlkZWQsIG5vdCBieSBhIHNwZWNpZmljIElQOnBvcnQgdGhhdCB0aGUNCj4+ZGV2aWNlDQo+ PnByb3ZpZGluZyB0aGUgc2VydmljZSBzaXRzIG9uLiBXZWxsLCBhdCBsZWFzdCBmcm9tIGEgR1BF K05TSCBwZXJzcGVjdGl2ZS4NCj4+DQo+Pg0KPj5PbiAxMi80LzE0LCAxMjo1NyBQTSwgIlNyaW5p IEFkZGVwYWxsaSIgPHNhZGRlcGFsbGlAZnJlZXNjYWxlLmNvbT4gd3JvdGU6DQo+Pg0KPj4+SWYg SSB0YWtlIGEgY2hhaW4gd2l0aCA1IHNlcnZpY2VzIHdpdGggZWFjaCBzZXJ2aWNlICBzYXkgaGF2 aW5nIDI1Ng0KPj4+aW5zdGFuY2VzIGZvciBzY2FsZS1vdXQsIHBvc3NpYmxlIG51bWJlciBvZiBw YXRocyBhcmUNCj4+PjI1NioyNTYqMjU2KjI1NioyNTYNCj4+Pj0gMHhGRiBGRiBGRiBGRiBGRi4g T25lIHJlcXVpcmVzIDMzIGJpdHMgaW4gdGhpcyBjYXNlLiAgSWYgdGhlcmUgYXJlDQo+Pj5tb3Jl DQo+Pj5zZXJ2aWNlcyBpbiB0aGUgY2hhaW4gb3IgbW9yZSBjaGFpbnMgb3IgbW9yZSBpbnN0YW5j ZXMgZm9yIHNjYWxlLW91dCwNCj4+PnRoZW4gaXQgY291bGQgZ28gdG8gYmlnIG51bWJlciB2ZXJ5 IGZhc3QuDQo+Pj4NCj4+PkFzIEkgbWVudGlvbmVkIG15IHByZWZlcmVuY2UgaXMgdG8gbWFrZSB0 aGUgcGF0aCBJRCBzaXplIGZsZXhpYmxlIGZvcg0KPj4+ZnV0dXJlIGdyb3d0aC4gSWYgdGhhdCBp cyBwZXJjZWl2ZWQgYXMgY29tcGxleCwgdGhlbiBnb2luZyBmb3IgNjRiaXQgaXMNCj4+PnNhZmVy IGJldC4NCj4+Pg0KPj4+VGhhbmtzDQo+Pj5TcmluaQ0KPj4+DQo+Pj4NCj4+Pi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tXQ0KPj4+U2VudDogVGh1cnNkYXksIERlY2VtYmVyIDA0LCAyMDE0IDEyOjA1 IFBNDQo+Pj5UbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2MDsgSm9lbCBNLiBIYWxwZXJuOyBzZmNA aWV0Zi5vcmcNCj4+PkNjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPj4+U3ViamVjdDog UmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4+KGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4+DQo+Pj5BIGNvbnRyb2xsZXIgKG9y IG90aGVyIGRlY2lzaW9uIGxvZ2ljKSBjYW4gY2VydGFpbmx5IGJlIGF3YXJlIG9mIHN1Y2gNCj4+ PmNvbmNlcm5zLg0KPj4+QnV0IHRoZSBudW1iZXIgb2Ygc2VydmljZSBmdW5jdGlvbiBwYXRocyBp cyBub3QgcmVsYXRlZCB0byB0aGUgbnVtYmVyIG9mDQo+Pj5mbG93cyBvciB0aGUgbnVtYmVyIG9m IHRlbmFudHMuICBJdCBpcyByZWxhdGVkIHRvIHRoZSBudW1iZXIgb2YNCj4+PmNvbWJpbmF0aW9u cyBvZiBzZXJ2aWNlcyBhbmQgdGhlIHBvbGljaWVzIGZvciBzZXJ2aWNlIGZ1bmN0aW9uDQo+Pj5z ZWxlY3Rpb24uDQo+Pj4gV2hpbGUgdGhhdCBjYW4gYmUgYSBsYXJnZSBudW1iZXIsIEkgc3VyZSBo b3BlIGl0IGRvZXMgbm90IGNvbWUgY2xvc2UgdG8NCj4+PnNhdHVyYXRpbmcgMjQgYml0cy4NCj4+ Pg0KPj4+SGF2aW5nIHNhaWQgdGhhdCwgaWYgd2UgdGhpbmsgdGhhdCAyNCBiaXRzIGlzIG9ubHkg anVzdCBlbm91Z2gsIHRoZW4gd2UNCj4+Pm91Z2h0IHRvIHVzZSAzMi4gIEZyb20gd2hlcmUgSSBz aXQsIEkgd291bGQgbm9ybWFsbHkgZXhwZWN0IDE2IGJpdHMgdG8NCj4+PmJlDQo+Pj5tb3JlIHRo YW4gc3VmZmljaWVudCwgd2hpY2ggaXMgd2h5IEkgYW0gY29tZm9ydGFibGUgd2l0aCAyNC4gIEhh dmluZw0KPj4+c2FpZA0KPj4+dGhhdCwgdGhlIGZpZWxkIHNpemUgaXMgbm90IGEgYmlnIGRlYWwg dG8gbWUuDQo+Pj4NCj4+PllvdXJzLA0KPj4+Sm9lbA0KPj4+DQo+Pj5PbiAxMi80LzE0LCAyOjAx IFBNLCBTcmluaSBBZGRlcGFsbGkgd3JvdGU6DQo+Pj4+DQo+Pj4+IEkgd2FzIG5vdCBpbXBseWlu ZyB0aGF0IHBhdGggSUQgc2hvdWxkIGhhdmUgaW5mb3JtYXRpb24gaW4gcmVnYXJkcyB0bw0KPj4+ PnRlbmFudC9jb250cm9sbGVyL2Zsb3cvc2NhbGUtb3V0LiAgQnV0IFNGQyBjb250cm9sbGVycyBz aG91bGQga2VlcA0KPj4+PnRoZXNlDQo+Pj4+aW4gbWluZCB0byBhc3NpZ24gdGhlIHBhdGggSUQu ICAgIEEgZGVwbG95bWVudCBjYW4gaGF2ZSBtdWx0aXBsZQ0KPj4+PnRlbmFudHMsIGVhY2ggdGVu YW50IGNhbiBoYXZlIG11bHRpcGxlIG5ldHdvcmtzLCAgdGhlcmUgY291bGQgYmUNCj4+Pj5taWxs aW9ucyBvZiBmbG93cyBpbiBlYWNoIG9mIHRob3NlIG5ldHdvcmtzLiAgQW5kIGNvbnNpZGVyaW5n IGFsbA0KPj4+PnRoZXNlLA0KPj4+PiAyNCBiaXQgcGF0aCBJRCBtYXkgbm90IGJlIGFibGUgdG8g cmVwcmVzZW50IHBhdGhzIGZvciB0aGVzZSBmbG93cy4NCj4+Pj5IZW5jZSwgSSB3YXMgd29uZGVy aW5nIHdoZXRoZXIgcGF0aCBJRCBjYW4gYmUgZXh0ZW5kZWQgdG8gNjQgYml0cyBvcg0KPj4+Pm1h a2UgaXQgZmxleGlibGUuDQo+Pj4+DQo+Pj4+IFRoYW5rcw0KPj4+PiBTcmluaQ0KPj4+Pg0KPj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IEZyb206IEpv ZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+Pj4gU2VudDogVGh1cnNkYXks IERlY2VtYmVyIDQsIDIwMTQgNzo0MiBBTQ0KPj4+PiBUbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2 MDsgc2ZjQGlldGYub3JnDQo+Pj4+IENjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPj4+ PiBTdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+Pj4+IChodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4+Pj4NCj4+Pj4g VGhlIEluZGV4IGlzIG5vdCBqdXN0IGZvciBsb29wIHByZXZlbnRpb24uICBJbiB0aGUgY2FzZSBv ZiBhbWJpZ3VpdHksDQo+Pj4+IHRoZSBpbmRleCB0ZWxscyB0aGUgU0ZGIHdoZXJlIGluIHRoZSBw YXRoIHRoZSBwYWNrZXQgY3VycmVudGx5DQo+Pj4+cmVzaWRlcy4NCj4+Pj4gICAgVGhlcmUgYXJl IG11bHRpcGxlIHdheXMgc3VjaCBhbWJpZ3VpdHkgY2FuIG9jY3VyLg0KPj4+Pg0KPj4+PiBUaGUg UGF0aCBJZGVudGlmaWVyIGlzIHNwZWNpZmljYWxseSBub3QgZXhwZWN0ZWQgdG8gaW5jbHVkZSBj b250cm9sbGVyDQo+Pj4+IElEIG9yIFRlbmFudCBJRC4gIFdoaWxlIGEgZGVwbG95ZXIgY2FuIGhh dmUgYSBwYXRoIHBlciB0ZW5hbnQsIHRoZQ0KPj4+PiBhcmNoaXRlY3R1cmUgc3RpbGwgZG9lcyBu b3QgdHJlYXQgdGhlIHBhdGggSUQgYXMgYSB0ZW5hbnQgSUQuICBUZW5hbnQNCj4+Pj4gSUQsIGNv bnRyb2xsZXIgSUQsIGFuZCBvdGhlciBub24tcGF0aC1zcGVjaWZ5aW5nIGluZm9ybWF0aW9uIGlz IHRvIGJlDQo+Pj4+IGNhcnJpZWQgaW4gbWV0YWRhdGEuDQo+Pj4+DQo+Pj4+IFlvdXJzLA0KPj4+ PiBKb2VsDQo+Pj4+DQo+Pj4+IE9uIDEyLzQvMTQsIDEwOjAyIEFNLCBTcmluaSBBZGRlcGFsbGkg d3JvdGU6DQo+Pj4+PiBUd28gY29tbWVudHMgOg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiAxLiAgU0Yg SW5kZXggOiAgU2luY2UgaXQgaXMgbWVhbnQgZm9yIGxvb3AgZGV0ZWN0aW9uLCAgd291bGRuJ3QN Cj4+Pj4+IGJldHRlciB0byByZW5hbWUgdGhpcyBhcyAiVFRMIj8NCj4+Pj4+DQo+Pj4+PiAyLiAg UGF0aCBJZGVudGlmaWVyIDogICAgMjQgYml0IHBhdGggaWRlbnRpZmllciBzZWVtcyB0byBiZSB0 b28gbGVzcy4NCj4+Pj4+IEJhc2VkIG9uIG91ciBleHBlcmllbmNlIGluIHRyYWZmaWMgc3RlZXJp bmcsICB0aGlzIHBhdGggaWRlbnRpZmllcg0KPj4+Pj4gbmVlZHMgdG8gZW5jb2RlIGdvb2QgYW1v dW50IG9mIGluZm9ybWF0aW9uIHRvIG1ha2UgaXQgdW5pcXVlLiAgRm9yDQo+Pj4+PmV4YW1wbGUs DQo+Pj4+PiAgICB0aGlzIGlkZW50aWZpZXIgbmVlZHMgdG8gZW5jb2RlIChpbiBvdXIgY2FzZSkg c29tZSBpbmZvcm1hdGlvbg0KPj4+Pj4gcmVwcmVzZW50aW5nIHRoZSBkaXN0cmlidXRlZCBjb250 cm9sbGVyIElELCAgdGVuYW50IElELCAgZmxvdyBJRCwNCj4+Pj4+ICAgIFNlcnZpY2UgZnVuY3Rp b24gaW5zdGFuY2UgKGluIGNhc2Ugb2Ygc2NhbGUtb3V0KSBhbmQgZmV3IG1vcmUuLg0KPj4+Pj4g T25lIHN1Z2dlc3Rpb24gaXMgdG8gbWFrZSBpdCA2NCBiaXRzIHZhbHVlICBvciB0byBtYWtlIGl0 IGV2ZW4NCj4+Pj4+ZXh0ZW5kYWJsZSwNCj4+Pj4+ICAgIGl0IGlzIGdvb2QgaWYgcGF0aCBpZGVu dGlmaWVyIGlzIGFsc28gcmVwcmVzZW50ZWQgaW4gVExWIGZvcm0uDQo+Pj4+Pg0KPj4+Pj4NCj4+ Pj4+IFRoYW5rcw0KPj4+Pj4NCj4+Pj4+IFNyaW5pDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+ Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+DQo+Pj4NCj4+Pl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5zZmMgbWFpbGlu ZyBsaXN0DQo+Pj5zZmNAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjDQo+Pg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRmLm9yZw0KPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zZmMgbWFpbGluZyBsaXN0DQo+c2Zj QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4N Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBt YWlsaW5nIGxpc3QNCj5zZmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KDQo= From nobody Tue Feb 3 11:43: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 00B621A87A9 for ; Tue, 3 Feb 2015 11:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, 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 Q6j3GHcAaD3Y for ; Tue, 3 Feb 2015 11:43:45 -0800 (PST) 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 0DEB31A8824 for ; Tue, 3 Feb 2015 11:43:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25716; q=dns/txt; s=iport; t=1422992625; x=1424202225; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QvIzv8koL+22Kp+/Qgm+FaOTbFvbFjCWoVGUB3i6yN0=; b=KvjHWoEYr8wMLrNLBNEkqX/3mCFdGlWePYt1MjdPJ+EX5vFMOdCCaR81 n0+GVXwlPgD6XxV3TBk+YAFIyqhzMkr8q+FZyzXuyggRx1kG/QuP0z/dM RVAu4vnGlDdfYROd1KL6O4g0BdFv5saLd9xviTeLUXj9dQD5yU58X8PIG A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CNCAAkJNFU/5tdJa1QCoJkIlJZBII2R79kghsKhXECHIECQwEBAQEBfYQMAQEBAwEBAQEJFxEzBwsFBwQCAQYCEQEDAQEBAgIjAwICAiULFAECBggCBA4FiCUIAQyjQ5xslkcBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhiG2FBwcxEBYFBwICAoJiLoETAQSNKYFjg05jgSuDSoEXgwOLCIM9IoICHBSBPG8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,514,1418083200"; d="scan'208";a="120153684" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 03 Feb 2015 19:43:43 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t13JhhgQ026571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 19:43:43 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 13:43:42 -0600 From: "Carlos Pignataro (cpignata)" To: Ron Parker Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZyAGG+AgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgD//7j7oIBVIj4ggALIuACABoxWAIAABhkAgAA+l4A= Date: Tue, 3 Feb 2015 19:43:41 +0000 Message-ID: <2D81DC44-1FE2-486E-B503-0F1FA26A5791@cisco.com> References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <, <>> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.215.5] Content-Type: text/plain; charset="utf-8" Content-ID: <12429960F0EC6F4AB76FDFC44A36D680@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Nicolas BOUTHORS , Cathy Zhang , Jerome TOLLET , "sfc@ietf.org" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 03 Feb 2015 19:43:49 -0000 SGksIFJvbiwNCg0KVGhhbmtzIGZvciB0aGUgZm9sbG93LXVwIOKAlCBNeSBtYWluIHBvaW50IGlz IHRoYXQgdGhlIGFyY2hpdGVjdHVyZSBkZWZpbmluZyAoeWV0IG5vdCB1c2luZykgdGhlIHRlcm0g UlNQIGRvZXMgbm90IGltcGx5IHRoZXJlIGhhcyB0byBiZSBhbiBleHBsaWNpdCBpZGVudGlmaWVy IGZvciBpdC4NCg0KV2hhdCB5b3UgZGVzY3JpYmUgYmVsb3cgc2VlbXMgdG8gYmUgdGhlIHBhc3Np bmcgb2YgZ3JhbnVsYXIgY29udGV4dCBmb3IgYSBjbGFzc2lmaWNhdGlvbiBjb2xvcmluZyBvciBm b3IgYSBwc2V1ZG8tZmxvdywgZm9yIHdoaWNoIGNvbnRleHQgaGVhZGVycyBhbmQgbWV0YWRhdGEg c2VlbSB0byBnaXZlIHRoYXQgZXh0ZW5zaWJpbGl0eS4gVG8gbWUsIHVzZSBjYXNlcyBhcmUgdXNl ZnVsIGJ1dCBub3QgbmVjZXNzYXJpbHkgdW5pdmVyc2FsbHkgYXBwbGljYWJsZSDigJQgaW4gd2hp Y2ggY2FzZSBpcyBiZXN0IHRvIGRlc2lnbiBmb3IgdGhlIGdlbmVyaWMgcGF0aCBpZCBhbmQgbm90 IG92ZXJnZW5lcmFsaXplIGZ1bmN0aW9uYWxpdHkgKHRoYXQgY2FuIGJlIHNvbHZlZCB3aXRob3V0 IGRlZmluaW5nIGEgbmV3IGlkZW50aWZpZXIpLiANCg0KVGhhbmtzIQ0KDQrigJQgQ2FybG9zLg0K DQo+IE9uIEZlYiAzLCAyMDE1LCBhdCAxMDo1OSBBTSwgUm9uIFBhcmtlciA8Um9uX1BhcmtlckBh ZmZpcm1lZG5ldHdvcmtzLmNvbT4gd3JvdGU6DQo+IA0KPiBDYXJsb3MsDQo+IA0KPiBJIGFncmVl IHRoYXQgc2luZ2xlIGxldmVsIHZzLiBkdWFsIGxldmVsIGlkZW50aWZpZXIgaW4gdGhlIGRhdGEg cGxhbmUgaXMgYSB3b3J0aHdoaWxlIGRpc2N1c3Npb24uICAgUmVsYXRlZCB0byB0aGlzIC0tIHdp dGhpbiB0aGUgYXJjaGl0ZWN0dXJlLCB0byBteSBrbm93bGVkZ2UsIGJvdGggY2VudHJhbCBvcmNo ZXN0cmF0aW9uIGFuZCBob3AtYnktaG9wIGxvYWQgYmFsYW5jaW5nL3Jlc2lsaWVuY3kgc2VsZWN0 aW9uIGlzIGFsbG93ZWQuICAgDQo+IA0KPiBJbiBhIGNlbnRyYWxseSBvcmNoZXN0cmF0ZWQgYXBw cm9hY2gsIGEgc2luZ2xlIGxldmVsIGlkZW50aWZpZXIgYWJzdHJhY3RpbmcgdGhlIGNvbmNyZXRl IHNlcXVlbmNlIG9mIGhvcHMgaXMgc3VmZmljaWVudC4gICBJIHdvdWxkIHByb3Bvc2UgdGhhdCB0 aGlzIHNpbmdsZSBsZXZlbCBpZGVudGlmaWVyIHdvdWxkIGJlIGJldHRlciBjYWxsZWQgdGhlIFJT UCBJRCB0aGFuIHRoZSBTRlAgSUQsIHNpbmNlIFNGUCwgYnkgZGVmaW5pdGlvbiBpcyBub3QgbmVj ZXNzYXJpbHkgZnVsbHkgY29uY3JldGUvc3BlY2lmaWVkIGluIHRlcm1zIG9mIGV4YWN0IGhvcCBz ZXF1ZW5jZS4NCj4gDQo+IEluIGEgZGlzdHJpYnV0ZWQgaG9wLWJ5LWhvcCAodHJhaWwtYmxhemVk KSBhcHByb2FjaCB0byBsb2FkIGJhbGFuY2luZyBhbmQgcmVzaWxpZW5jeSwgYSAyLWxldmVsIGlk ZW50aWZpZXIgaXMgdmVyeSB1c2VmdWwuICAgVGhlIFNGUCBJRCBkZXNjcmliZXMgdGhlIHNlcXVl bmNlIG9mIFNGJ3MgaW4gdGVybXMgb2YgdHlwZXMsIGJ1dCBub3QgbmVjZXNzYXJpbHkgaW5zdGFu Y2VzLiAgIEl0IGlzIGFsbG93ZWQgdG8gY29udmV5IHBvbGljeSB3aXRoIHJlc3BlY3QgdG8gZXhh Y3QgaW5zdGFuY2VzLCBhbmQgdGhhdCBwb2xpY3kgY291bGQgYmUgZnVsbHkgY29uY3JldGUgb3Ig Y291bGQgYmUgbWVyZWx5IGRlc2NyaWJpbmcgc3Vic2V0cyAoaS5lLiwgb25lIG9mIHRoZSAib3Jh bmdlIiBJRFMvSVBTIGZvbGxvd2VkIGJ5IG9uZSBvZiB0aGUgInB1cnBsZSIgZmlyZXdhbGxzKS4g ICAgSW4gb3JkZXIgdG8gYXNzaXN0IHRoZSBTRkYncyB0byBtYWtlIHRoaXMgZGVjaXNpb24sIHRo ZXkgd291bGQgcmVxdWlyZSBub3Qgb25seSB0aGUgcG9saWN5IHVuZGVyIHdoaWNoIHRoZXkgYXJl IHdvcmtpbmcgdG8gbWFrZSB0aGlzIGRlY2lzaW9uIChpLmUuLCBTRlAgSUQpLCBidXQgYWxzbyBh IHZhbHVlIHRoYXQgY291bGQgYmUgdXNlZCB0byByZXBlYXQgdGhlIGFjdHVhbCBzZWxlY3Rpb25z IChpLmUuLCBSU1AgSUQpLiAgIEluIHRoaXMgYXBwcm9hY2gsIHRoZSB7U0ZQIElELCBSU1AgSUR9 IHR1cGxlIGlzIGludGVycHJldGVkIGFzICJhbGwgcGFja2V0cyB3aXRoIHRoaXMgdHVwbGUgdmFs dWUgbXVzdCB0cmF2ZXJzZSB0aGUgZXhhY3Qgc2FtZSBjb25jcmV0ZSBzZXF1ZW5jZSIuDQo+IA0K PiBJbiBteSB2aWV3LCB0aGUgYXJjaGl0ZWN0dXJlLCBhcyBpdCBzdGFuZHMgdG9kYXksIGFsbG93 cyBmb3IgYm90aCBhcHByb2FjaGVzIC0tIGNlbnRyYWxpemVkIHBhdGggbWFuYWdlbWVudCBhbmQg ZGlzdHJpYnV0ZWQgcGF0aCBtYW5hZ2VtZW50LiAgIEZ1cnRoZXJtb3JlLCBib3RoIGFyZSB2YWxp ZCBhbmQgd29ydGh3aGlsZS4NCj4gDQo+ICAgUm9uDQo+IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpDQo+IFNlbnQ6IFR1ZXNk YXksIEZlYnJ1YXJ5IDMsIDIwMTUgMTA6MzggQU0NCj4gVG86IE5pY29sYXMgQk9VVEhPUlMNCj4g Q2M6IENhdGh5IFpoYW5nOyBKZXJvbWUgVE9MTEVUOyBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDog UmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdCAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+IA0KPiBIaSwNCj4gDQo+IFtUb3AtcG9zdCBy ZXNwb25kaW5nLCBub3QgYWRkcmVzc2VkIHRvIGFueSBtZXNzYWdlIGluIHBhcnRpY3VsYXIgYnV0 IG1ha2luZyBhIGdlbmVyaWMgY29tbWVudF0NCj4gDQo+IFNpbmNlIHRoZSBhcmNoaXRlY3R1cmUg ZG9jdW1lbnQgZ290IGNpdGVkIGEgY291cGxlIG9mIHRpbWVzIGluIHRoaXMgdGhyZWFkLCBteSB2 aWV3IGlzIHRoYXQgdGhlIGZhY3QgdGhhdCB0aGUgYXJjaCBkb2N1bWVudCBkZWZpbmVzIGFuIFJT UCBkb2VzIG5vdCBpbXBseSB0aGF0IHRoZXJlIG91Z2h0IHRvIGJlIGFuIFJTUCBJZGVudGlmaWVy LCBsZXNzIHNvIG9uZSBjYXJyaWVkIGluIHRoZSBkYXRhcGxhbmUuDQo+IA0KPiBUaGUgcmVhbCBx dWVzdGlvbiBpcyB3aGF0IGNhbm5vdCBiZSBkb25lIHdpdGggYSBTZXJ2aWNlIFBhdGggSUQsIGlu IHRlcm1zIG9mIGJvdGggZnVuY3Rpb25hbGl0eSBhbmQgc2NhbGluZyDigJQgdG8gbWUsIGEgaGll cmFyY2hpY2FsIHNldCBvZiBpZGVudGlmaWVycyAo4oCcIFJTUCBJRCB2YWx1ZXMgY291bGQgYmUg cmVsYXRpdmUgdG8gYSBwYXJ0aWN1bGFyIFNlcnZpY2UgUGF0aOKAnSkgc2VlbXMgb3Zlci1lbmdp bmVlcmluZywgYW5kIGFuIGluZGVwZW5kZW50IGFsbG9jYXRpb24gY2FuIGNyZWF0ZSBjb25mbGlj dHMuDQo+IA0KPiBJbiBvdGhlciB3b3Jkcywgd2hhdCBwcm9ibGVtIGFyZSB3ZSBzb2x2aW5nPw0K PiANCj4gVGhhbmtzLA0KPiANCj4g4oCUIENhcmxvcy4NCj4gDQo+PiBPbiBKYW4gMzAsIDIwMTUs IGF0IDY6MzggQU0sIE5pY29sYXMgQk9VVEhPUlMgPE5pY29sYXMuQk9VVEhPUlNAcW9zbW9zLmNv bT4gd3JvdGU6DQo+PiANCj4+IEhlbGxvIENhdGh5LA0KPj4gDQo+PiBJbmRlZWQgdGhlIG5vdGlv biBvZiAicmVuZGVyZWQgc2VydmljZSBwYXRoIElEIihSU1AgSUQpIHNlZW1zIHJlbGV2YW50IGFz IHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgc3RpcHVsYXRlcyB0aGF0IHRoZSBTZXJ2aWNlIEZ1 bmN0aW9uIFBhdGggKFNGUCkgcHJvdmlkZXMgYW4gYWJzdHJhY3Qgbm90aW9uIG9mIGEgc2Vydmlj ZSBjaGFpbiwgd2hpbGUgdGhlIFJTUCBpcyBhIGNvbnN0cmFpbmVkIGxpc3Qgb2YgbG9jYXRpb25z Lg0KPj4gDQo+PiBTRkMgaGVhZGVyICJTZXJ2aWNlIFBhdGggSWRlbnRpZmllciIgKFNQSSkgIGlz IHVzZWQgaW4gYm90aCBOU0ggYW5kIFNDSCBwcm90b2NvbCBhbmQgaW4gYm90aCBjYXNlIHNlZW0g dG8gaWRlbnRpZnkgdG8gYSBwYXJ0aWN1bGFyIFNGUC4NCj4+IA0KPj4gTlNIKHY1KSBmb3IgZXhh bXBsZSBzdGF0ZXMgdGhhdA0KPj4gIiBBcyBkZXNjcmliZWQgYWJvdmUsIE5TSCBjb250YWlucyBh IHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIChTUEkpIGFuZA0KPj4gIGEgc2VydmljZSBpbmRleCAo U0kpLiAgVGhlIFNQSSBpcywgYXMgcGVyIGl0cyBuYW1lLCBhbiBpZGVudGlmaWVyLg0KPj4gIFRo ZSBTUEkgYWxvbmUgY2Fubm90IGJlIHVzZWQgdG8gZm9yd2FyZCBwYWNrZXRzIGFsb25nIGEgc2Vy dmljZSBwYXRoLg0KPj4gIFJhdGhlciB0aGUgU1BJIHByb3ZpZGUgYSBsZXZlbCBvZiBpbmRpcmVj dGlvbiBiZXR3ZWVuIHRoZSBzZXJ2aWNlDQo+PiAgcGF0aC90b3BvbG9neSBhbmQgdGhlIHRoZSBu ZXR3b3JrIHRyYW5zcG9ydC4gIEZ1cnRoZXJtb3JlLCB0aGVyZSBpcw0KPj4gIG5vIHJlcXVpcmVt ZW50LCBvciBleHBlY3RhdGlvbiBvZiBhbiBTUEkgYmVpbmcgYm91bmQgdG8gYSBwcmUtDQo+PiAg ZGV0ZXJtaW5lZCBvciBzdGF0aWMgbmV0d29yayBwYXRoLiINCj4+IA0KPj4gU3RpbGwgTlNIKHY1 KSAgc2hvd3MgdGhhdCBTUEkgKG5vdCBhIFJTUCBJRCkgIHNob3VsZCBiZSBwYXJ0IG9mIHRoZSAN Cj4+IGtleSAgZWxlbWVudCBvZiBhbiBTRkYgdG8gbG9va3VwIG9uIGZvcndhcmRpbmcgdGFibGVz LiAgQnV0IEkgY291bGQgbm90IGZpbmQgaW4gTlNIICBob3cgdG8gdXNlIHRoZSBub3Rpb24gb2Yg UmVuZGVyZWQgc2VydmljZSBwYXRoIHdoaWNoIHdhcyBkZWZpbmVkIGluIHRoZSBhcmNoaXRlY3R1 cmUgZG9jdW1lbnQuDQo+PiANCj4+IFlvdSBwcm9wb3NhbCBzZWVtcyB0byBtZSB2ZXJ5IHVzZWZ1 bCwNCj4+IA0KPj4gQW4gUlNQIElEIChpbmRlcGVuZGVudCBvZiB0aGUgU1BJIGJ1dCBwYXJ0IG9m IHRoZSBzYW1lIG5hbWUgc3BhY2UpIGNvdWxkIGJlIHVzZWQgdGhlIHNhbWUgd2F5IGFzIFNQSSBi eSBTRkYgZm9yIGV4YW1wbGUsIGFsbG93aW5nIGEgU2VydmljZSBDbGFzc2lmaWVyIHRvIGNvbnRy b2wgcmVtb3RlIGxvYWQgYmFsYW5jaW5nIGZvciBleGFtcGxlLg0KPj4gDQo+PiBUaGlzIHNhaWQg dGhlIFJTUCBJRCB2YWx1ZXMgY291bGQgYmUgcmVsYXRpdmUgdG8gYSBwYXJ0aWN1bGFyIFNlcnZp Y2UgUGF0aCwgd2hpY2ggd291bGQgcHJldmVudCB1c2luZyB0aGVtIGFzIHdlIGRvIGZvciBTUEkg aW4gU0ZGIGZvcndhcmRpbmcgdGFibGVzLg0KPj4gDQo+PiBXZSBtYXkgd2FudCB0byBwcmVjaXNl IGlmIHRoZSBSU1AgSUQgaXMgdG8gYmUgcmVsYXRpdmUgb2YgYWJzb2x1dGUsIGFzIGl0IHNob3Vs ZCBoYXZlIGFuIGltcGFjdCBvbiBmb3J3YXJkaW5nIHRhYmxlIHN0cnVjdHVyZSBpZiB3ZSBkZWNp ZGUgdG8gdXNlIHRoaXMgY29uY2VwdC4NCj4+IA0KPj4gUGVyc29uYWxseSBJIGxpa2UgdGhlIG5v dGlvbiBvZiBhIHJlbGF0aXZlIFJTUCBJRCwgYXMgd2UgY291bGQgdGhlbiB1c2Ugc29tZSBjb252 ZW50aW9ucywgc3RydWN0dXJlIGl0LCBwb3NzaWJseSBleHRlbmRpbmcgaXRzIHVzZS4NCj4+IA0K Pj4gTmljb2xhcw0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTog Q2F0aHkgWmhhbmcgW21haWx0bzpDYXRoeS5ILlpoYW5nQGh1YXdlaS5jb21dDQo+PiBTZW50OiBq ZXVkaSAyOSBqYW52aWVyIDIwMTUgMjA6NDQNCj4+IFRvOiBDYXRoeSBaaGFuZzsgU3JpbmkgQWRk ZXBhbGxpOyBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4gSGFscGVybjsgJ3NmY0Bp ZXRmLm9yZycNCj4+IENjOiBuc211cnRoeUBmcmVlc2NhbGUuY29tDQo+PiBTdWJqZWN0OiBSZTog W3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0IA0KPj4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4gDQo+PiBIaSBldmVyeW9uZSwNCj4+IA0K Pj4gV2UgaGF2ZSB1cGxvYWRlZCBhIG5ldyBTQ0ggdmVyc2lvbiAoMykgd2hpY2ggYWRkcyBkZWZp bml0aW9uIG9mIGEgbmV3IG1ldGFkYXRhIHR5cGUgZm9yIHRoZSBmbG93IElEIHRvIHN1cHBvcnQg bG9hZCBiYWxhbmNpbmcgYW1vbmcgU0YgaW5zdGFuY2VzIGFuZCBtaXRpZ2F0ZSB0aGUgcG90ZW50 aWFsIGlzc3VlIG9mICJub3QgZW5vdWdoIHBhdGggSUQiLiBUaGUgZmxvdyBJRCBpcyBuYW1lZCAi cmVuZGVyZWQgc2VydmljZSBwYXRoIElEIiBpbiB0aGUgZHJhZnQuIFBsZWFzZSByZWZlciB0byBz ZWN0aW9uIDQuMy4yIG9mIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpo YW5nLXNmYy1zY2gvIGZvciBkZXRhaWwgZGVzY3JpcHRpb24uDQo+PiANCj4+IEluIGl0cyBwcmV2 aW91cyB2ZXJzaW9uLCBTQ0ggZGVmaW5lcyBhICJCeXBhc3MgYml0IiBpbiB0aGUgYmFzZSBoZWFk ZXIuIFRoaXMgYml0IGVuYWJsZXMgdGhlIFNGIHRvIHByb3ZpZGUgZmVlZGJhY2svbm90aWZpY2F0 aW9uIHZpYSB0aGUgZGF0YSBwYXRoIHRvIGl0cyBjb25uZWN0aW5nIFNGRiBhYm91dCB3aGV0aGVy IHRoZSByZW1haW5pbmcgcGFja2V0cyBvZiB0aGUgU0ZDIHNob3VsZCBieXBhc3MgdGhhdCBTRi4g VGhpcyBpcyB1c2VmdWwgaW4gdGhlIGNhc2UgdGhhdCBvbmx5IHRoZSBmaXJzdCBmZXcgcGFja2V0 cyBvZiBhIGZsb3cgbmVlZCB0byBnbyB0byBhIFNGIChzdWNoIGFzIGEgRFBJIG9yIEZXIG9yIElE UykgYW5kIHJlbWFpbmluZyBwYWNrZXRzIGNhbiBieXBhc3MgdGhhdCBTRiwgdGh1cyBzYXZpbmcg dGhlIGV4cGVuc2l2ZSBTRiByZXNvdXJjZSBhbmQgcmVkdWNpbmcgZGF0YSBwYXRoIGxhdGVuY3ku DQo+PiANCj4+IEIgYml0OiBUaGUgQiAoQnlwYXNzKSBiaXQsIHdoZW4gc2V0IHRvIDEsIGl0IGlz IHVzZWQgYnkgYSBTZXJ2aWNlDQo+PiAgICAgIEZ1bmN0aW9uIHRvIHNpZ25hbCB0byBpdHMgU2Vy dmljZSBGdW5jdGlvbiBGb3J3YXJkZXIgdGhhdCBubw0KPj4gICAgICBmdXJ0aGVyIHBhY2tldHMg YXJlIHRvIGJlIHNlbnQgdG8gaXQgZm9yIHRoZSBmbG93IHNwZWNpZmllZCBpbiBlbmNhcHN1bGF0 ZWQgcGFja2V0Lg0KPj4gDQo+PiBJbiBhZGRpdGlvbiwgU0NIIGRlZmluZXMgYSBtZXRhZGF0YSB0 eXBlIGZvciBHZW5lcmljIENvbnRleHQgQmxvY2ssIHdoaWNoIGlzIG9wdGlvbmFsIGFuZCBjYW4g YmUgdXNlZCBpZiBuZWVkZWQgdG8gY2FycnkgYW55IHZlbmRvcidzIHNwZWNpZmljICJDb250ZXh0 IEhlYWRlciIuDQo+PiANCj4+IEFueSBjb21tZW50cyBvbiB0aGVzZSBuZXcgYWRkaXRpb25zPw0K Pj4gDQo+PiBUaGFua3MsDQo+PiBDYXRoeQ0KPj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBDYXRoeSBaaGFuZw0KPj4gU2VudDogRnJpZGF5LCBEZWNlbWJlciAwNSwgMjAxNCAxMTo0 NyBBTQ0KPj4gVG86IFNyaW5pIEFkZGVwYWxsaTsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBK b2VsIE0uIEhhbHBlcm47ICdzZmNAaWV0Zi5vcmcnDQo+PiBDYzogbnNtdXJ0aHlAZnJlZXNjYWxl LmNvbQ0KPj4gU3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdCANCj4+ICho dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4+IA0K Pj4gUm9uLCBMb3VpcywgTXlvIGFuZCBJIGhhdmUgYmVlbiBkaXNjdXNzaW5nIG9mZiBsaW5lIGxh c3QgZmV3IHdlZWtzIGFib3V0IGRlZmluaW5nIGEgbWV0YWRhdGEgdHlwZSBmb3IgZmxvdyBJRCBp biBhZGRpdGlvbiB0byB0aGUgcGF0aCBJRCBvZiB0aGUgbWFpbiBoZWFkZXIgdG8gc3VwcG9ydCBs b2FkIGJhbGFuY2luZyBhbW9uZyBTRiBpbnN0YW5jZXMuIFdlIHdpbGwgZGVmaW5lIGEgVExWIHR5 cGUgZm9yIHRoZSBmbG93IElELiBUaGUgY29tYmluYXRpb24gb2YgInBhdGggSUQgKyBmbG93IElE IiBzcGVjaWZpZXMgYSByZWFsaXplZCBzZXJ2aWNlIGNoYWluIGluc3RhbmNlIHBhdGguIEl0IGlz IGxlZnQgdG8gdGhlIGRlc2lnbi9pbXBsZW1lbnRhdGlvbiB3aGV0aGVyIHRvIHVzZSBhIGNlbnRy YWxpemVkIG1ldGhvZCBvciBhIGRpc3RyaWJ1dGVkIG1ldGhvZCB0byBiaW5kIHRoZSBmbG93IElE IHRvIGEgcmVhbGl6ZWQgc2VydmljZSBpbnN0YW5jZSBwYXRoIGFsdGhvdWdoIG91ciBvcmlnaW5h bCB0aG91Z2h0IGlzIGZvciBkaXN0cmlidXRlZCBMQiB1c2FnZS4gSSBhbSBub3Qgc3VyZSBpZiB3 ZSBuZWVkIGEgYml0IGluIHRoZSBoZWFkZXIgdG8gZGVub3RlIHdoZXRoZXIgdGhlcmUgYXJlIG1v cmUgcGF0aCBJRCBiaXRzICh3ZSBjYWxsIGl0IGZsb3cgSUQpIGluIHRoZSBtZXRhZGF0YSBmaWVs ZHMgc2luY2Ugd2hlbiB5b3UgcGFyc2UgdGhlIFRMViBtZXRhZGF0YSwgeW91IHdpbGwga25vdyB3 aGV0aGVyIHRoZXJlIGFyZSBmbG93IElEIGJpdHMgb3Igbm90LiBOb3RlIHRoYXQgaWYgbXVsdGlw bGUgc2Vzc2lvbnMgc2hhcmUgdGhlIHNhbWUgcmVhbGl6ZWQgc2VydmljZSBpbnN0YW5jZSBwYXRo LCB0aGV5IHdpbGwgc2hhcmUgdGhlIHNhbWUgInBhdGggSUQrIGZsb3cgSUQiLiAgV2UgY2FuIGFs c28gY29uc2lkZXIgZXh0ZW5kaW5nIHRoZSBudW1iZXIgb2YgYml0cyB0byAzMiBpZiB0aGF0IGlz IHRoZSBjb25zZW5zdXMuIFdlIHdpbGwgcG9zdCBhbiB1cGRhdGVkIGRyYWZ0IGRlc2NyaWJpbmcg dGhlc2Ugc29vbi4NCj4+IA0KPj4gVGhhbmtzLA0KPj4gQ2F0aHkNCj4+IA0KPj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgU3JpbmkgQWRkZXBhbGxpDQo+PiBTZW50OiBGcmlkYXksIERlY2Vt YmVyIDA1LCAyMDE0IDc6MTcgQU0NCj4+IFRvOiBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IEpv ZWwgTS4gSGFscGVybjsgJ3NmY0BpZXRmLm9yZycNCj4+IENjOiBuc211cnRoeUBmcmVlc2NhbGUu Y29tDQo+PiBTdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0IA0KPj4gKGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4gDQo+ PiANCj4+IFtSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5Lg0KPj4gDQo+PiBTUklOST4gSSBhbSBu b3Qgc28gc3VyZSBhYm91dCBkYXRhIHBsYW5lIGVmZmljaWVuY3kuICBNb3N0IG9mIHRoZSBwcm9j ZXNzb3JzIHdvcmsgZ29vZCBpZiB0aGUgbnVtYmVyIG9mIGJpdHMgYXJlIGVpdGhlciAzMiBvciA2 NC4gIElmIGl0IGlzIDI0IGJpdHMsIHRoZW4gb25lIG5lZWRzIHRvIGRvIG1hc2tpbmcgYW5kIHNo aWZ0aW5nIGJlZm9yZSB0aGUgdmFsdWUgaXMgdXNlZCB0byBkbyBhbnkgbG9va3VwLiAgIEJ1dCwg dGhpcyBkaXNjdXNzaW9uIGNhbiBnbyBpbnRvIGRpZmZlcmVudCBkaXJlY3Rpb24gOi0pLCBpdCBt YXkgbm90IGJlIGdvb2QgdG8gZ28gaW4gdGhhdCBkaXJlY3Rpb24uDQo+PiANCj4+IFdoZXJlIGRv IHdlIGRyYXcgdGhlIGxpbmU/IDMyLWJpdHMsIDY0LWJpdHMsDQo+PiAxMjggYml0cz8gSSB0aGlu ayB3ZSBzaG91bGQgaGF2ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRoZSBTZXJ2aWNlIFBhdGggaGVh ZGVyIGFuZCBpZiB5b3UgbmVlZCB0byBjb252ZXkgbW9yZSBiaXRzIHlvdSBuZWVkIHRvIHVzZSB0 aGUgY29udGV4dCBoZWFkZXJzLg0KPj4gDQo+PiBTUklOST4gVGhpcyBpcyBhIGdvb2QgcG9pbnQu ICBUaGlzIHNob3VsZCB3b3JrIGZpbmUgYXMgbG9uZyBhcyB0aGVyZSBpcyB3YXkgdG8gY29udmV5 IGluIHRoZSBtYWluIGhlYWRlciB0aGF0IHRoZSBleHRlbnNpb24gdG8gcGF0aCBJRCBpcyBhdmFp bGFibGUgaW4gc28gYW5kIHNvIFRMViBmaWVsZC4gIFRoYXQgc2hvdWxkIHdvcmsgdG9vLg0KPj4g DQo+PiBUaGFua3MNCj4+IFNyaW5pDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+IEZyb206IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKSA8cmVwZW5u b0BjaXNjby5jb20+DQo+PiBTZW50OiBGcmlkYXksIERlY2VtYmVyIDUsIDIwMTQgNzowOCBBTQ0K Pj4gVG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IEpvZWwgTS4gSGFscGVybjsgJ3NmY0BpZXRm Lm9yZycNCj4+IENjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPj4gU3ViamVjdDogUmU6 IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdCANCj4+IChodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4+IA0KPj4gT24gMTIvNS8xNCwgNjo1NCBB TSwgIlNyaW5pIEFkZGVwYWxsaSIgPHNhZGRlcGFsbGlAZnJlZXNjYWxlLmNvbT4gd3JvdGU6DQo+ PiANCj4+PiANCj4+PiBJbiByZWFsIGRlcGxveW1lbnRzLCBudW1iZXIgb2YgYWN0aXZlIHBhdGgg SURzIGFyZSB2ZXJ5IGxlc3NlciB0aGFuIA0KPj4+IDJeNjQsIGJ1dCB0aGVyZSBpcyBhIGdvb2Qg cG9zc2liaWxpdHkgb2YgdGhlIG51bWJlciBiZWluZyBtb3JlIHRoYW4gMl4yNCAoMTZNKS4NCj4+ PiBJIHRoaW5rIGJpZ2dlciBwb2ludCBpcyB0aGF0IHdoeSByZXN0cmljdCB0aGlzIGluIHRoZSBz dGFuZGFyZHM/IFdoYXQgDQo+Pj4gYWR2YW50YWdlIGRvIHdlIGhhdmUgcmVzdHJpY3RpbmcgdGhp cyBzaXplIHRvIDI0IGJpdHM/DQo+PiANCj4+IFtSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5LiBX aGVyZSBkbyB3ZSBkcmF3IHRoZSBsaW5lPyAzMi1iaXRzLCANCj4+IDY0LWJpdHMsDQo+PiAxMjgg Yml0cz8gSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRoZSBTZXJ2 aWNlIFBhdGggaGVhZGVyIGFuZCBpZiB5b3UgbmVlZCB0byBjb252ZXkgbW9yZSBiaXRzIHlvdSBu ZWVkIHRvIHVzZSB0aGUgY29udGV4dCBoZWFkZXJzLg0KPj4gDQo+PiANCj4+PiANCj4+PiBUaGVy ZSBjYW4gYmUgZGVwbG95bWVudHMsIHdoZXJlIFNGQyBjb250cm9sbGVyIChMb2dpY2FsbHkgY2Vu dHJhbCwgDQo+Pj4gYnV0DQo+Pj4gZGlzdHJpYnV0ZWQpICBpdHNlbGYgY2FuIGRvIHRoZSBTRiBp bnN0YW5jZSBzZWxlY3Rpb24gb24gcGVyDQo+Pj4gY29ubmVjdGlvbi9zZXNzaW9uIGJhc2lzLCB0 aGVyZWJ5IGF2b2lkaW5nIHRoZSBMQnMgZm9yIHNlcnZpY2VzLiAgIEluIG15DQo+Pj4gdmlldywg YXNzdW1wdGlvbiB0aGF0IHRoZXJlIHdpbGwgYmUgTEIgU0YgZm9yIGVhY2ggc2NhbGUtb3V0IHNl cnZpY2UgDQo+Pj4gaW4gdGhlIGNoYWluIGlzIG5vdCB2YWxpZCBpbiBhbGwgY2FzZXMuDQo+Pj4g DQo+Pj4gVGhhbmtzDQo+Pj4gU3JpbmkNCj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4gRnJvbTogUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pIDxy ZXBlbm5vQGNpc2NvLmNvbT4NCj4+PiBTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgNCwgMjAxNCAx OjE3IFBNDQo+Pj4gVG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IEpvZWwgTS4gSGFscGVybjsg c2ZjQGlldGYub3JnDQo+Pj4gQ2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+Pj4gU3Vi amVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4+IChodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4+PiANCj4+PiBJZiBJIHVu ZGVyc3Rvb2QgeW91LCBJIGRvIG5vdCB0aGluayB0aGlzIGlzIHJlYWxpc3RpYy4gQXJlIHlvdSBz YXlpbmcgDQo+Pj4geW91IG5lZWQgNjQtYml0cyBvZiBwYXRocyBhbmQgdGhlbiB3aWxsIG1vbml0 b3IgdGhlbSBhbGw/IERvIGZhdWx0IA0KPj4+IHRvbGVyYW5jZSBhbmQgT0FNIGZvciAyXjY0LWJp dHMgd29ydGggb2YgcGF0aHM/IEp1c3QgZm9yIGNvbXBhcmlzb24sIA0KPj4+IGl0wrlzIGxpa2Ug bWFuYWdpbmcgYW5kIG1vbml0b3JpbmcgdGhlIGVudGlyZSBJUHY2IGhvc3QgcmFuZ2UsIG9uZS1i eS1vbmUuDQo+Pj4gDQo+Pj4gQW55d2F5LCBJIGRvIG5vdCBleHBlY3QgZXZlcnkgc2luZ2xlIHBl cm11dGF0aW9ucyB0byBiZSBhIGRpZmZlcmVudCBwYXRoLg0KPj4+IA0KPj4+IElmIGVhY2ggc2Vy dmljZSBoYXMgMjU2IGRldmljZXMgcHJvdmlkaW5nIHNpbWlsYXIgc2VydmljZSwgeW91IHNob3Vs ZCANCj4+PiBtb3N0IGxpa2VseSB1c2UgbG9hZC1iYWxhbmNpbmcgYW5kIHRoZW4geW91IHdvdWxk IGhhdmUgYSBzaW5nbGUgKG9yIGENCj4+PiBmZXcpIHBhdGhzLiBUaGVyZSBpcyBzb21lIGRpc2N1 c3Npb24gZ29pbmcgb24gTEIuDQo+Pj4gDQo+Pj4gRnJvbSBhIGRhdGEgcGxhbmUgcGVyc3BlY3Rp dmUsIHRoZSBwYXRoIGlzIHVsdGltYXRlbHkgZGVmaW5lZCBieSB0aGUgDQo+Pj4gU0ZGcyB0cmF2 ZXJzZWQgYW5kIHNlcnZpY2VzIHByb3ZpZGVkLCBub3QgYnkgYSBzcGVjaWZpYyBJUDpwb3J0IHRo YXQgDQo+Pj4gdGhlIGRldmljZSBwcm92aWRpbmcgdGhlIHNlcnZpY2Ugc2l0cyBvbi4gV2VsbCwg YXQgbGVhc3QgZnJvbSBhIEdQRStOU0ggcGVyc3BlY3RpdmUuDQo+Pj4gDQo+Pj4gDQo+Pj4gT24g MTIvNC8xNCwgMTI6NTcgUE0sICJTcmluaSBBZGRlcGFsbGkiIDxzYWRkZXBhbGxpQGZyZWVzY2Fs ZS5jb20+IHdyb3RlOg0KPj4+IA0KPj4+PiBJZiBJIHRha2UgYSBjaGFpbiB3aXRoIDUgc2Vydmlj ZXMgd2l0aCBlYWNoIHNlcnZpY2UgIHNheSBoYXZpbmcgMjU2IA0KPj4+PiBpbnN0YW5jZXMgZm9y IHNjYWxlLW91dCwgcG9zc2libGUgbnVtYmVyIG9mIHBhdGhzIGFyZQ0KPj4+PiAyNTYqMjU2KjI1 NioyNTYqMjU2ID0gMHhGRiBGRiBGRiBGRiBGRi4gT25lIHJlcXVpcmVzIDMzIGJpdHMgaW4gdGhp cyANCj4+Pj4gY2FzZS4gIElmIHRoZXJlIGFyZSBtb3JlIHNlcnZpY2VzIGluIHRoZSBjaGFpbiBv ciBtb3JlIGNoYWlucyBvciANCj4+Pj4gbW9yZSBpbnN0YW5jZXMgZm9yIHNjYWxlLW91dCwgdGhl biBpdCBjb3VsZCBnbyB0byBiaWcgbnVtYmVyIHZlcnkgZmFzdC4NCj4+Pj4gDQo+Pj4+IEFzIEkg bWVudGlvbmVkIG15IHByZWZlcmVuY2UgaXMgdG8gbWFrZSB0aGUgcGF0aCBJRCBzaXplIGZsZXhp YmxlIA0KPj4+PiBmb3IgZnV0dXJlIGdyb3d0aC4gSWYgdGhhdCBpcyBwZXJjZWl2ZWQgYXMgY29t cGxleCwgdGhlbiBnb2luZyBmb3IgDQo+Pj4+IDY0Yml0IGlzIHNhZmVyIGJldC4NCj4+Pj4gDQo+ Pj4+IFRoYW5rcw0KPj4+PiBTcmluaQ0KPj4+PiANCj4+Pj4gDQo+Pj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2Vs aGFscGVybi5jb21dDQo+Pj4+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwNCwgMjAxNCAxMjow NSBQTQ0KPj4+PiBUbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2MDsgSm9lbCBNLiBIYWxwZXJuOyBz ZmNAaWV0Zi5vcmcNCj4+Pj4gQ2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+Pj4+IFN1 YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4+Pj4gKGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4+PiANCj4+Pj4gQSBj b250cm9sbGVyIChvciBvdGhlciBkZWNpc2lvbiBsb2dpYykgY2FuIGNlcnRhaW5seSBiZSBhd2Fy ZSBvZiANCj4+Pj4gc3VjaCBjb25jZXJucy4NCj4+Pj4gQnV0IHRoZSBudW1iZXIgb2Ygc2Vydmlj ZSBmdW5jdGlvbiBwYXRocyBpcyBub3QgcmVsYXRlZCB0byB0aGUgDQo+Pj4+IG51bWJlciBvZiBm bG93cyBvciB0aGUgbnVtYmVyIG9mIHRlbmFudHMuICBJdCBpcyByZWxhdGVkIHRvIHRoZSANCj4+ Pj4gbnVtYmVyIG9mIGNvbWJpbmF0aW9ucyBvZiBzZXJ2aWNlcyBhbmQgdGhlIHBvbGljaWVzIGZv ciBzZXJ2aWNlIGZ1bmN0aW9uIHNlbGVjdGlvbi4NCj4+Pj4gV2hpbGUgdGhhdCBjYW4gYmUgYSBs YXJnZSBudW1iZXIsIEkgc3VyZSBob3BlIGl0IGRvZXMgbm90IGNvbWUgY2xvc2UgDQo+Pj4+IHRv IHNhdHVyYXRpbmcgMjQgYml0cy4NCj4+Pj4gDQo+Pj4+IEhhdmluZyBzYWlkIHRoYXQsIGlmIHdl IHRoaW5rIHRoYXQgMjQgYml0cyBpcyBvbmx5IGp1c3QgZW5vdWdoLCB0aGVuIA0KPj4+PiB3ZSBv dWdodCB0byB1c2UgMzIuICBGcm9tIHdoZXJlIEkgc2l0LCBJIHdvdWxkIG5vcm1hbGx5IGV4cGVj dCAxNiANCj4+Pj4gYml0cyB0byBiZSBtb3JlIHRoYW4gc3VmZmljaWVudCwgd2hpY2ggaXMgd2h5 IEkgYW0gY29tZm9ydGFibGUgd2l0aCAyNC4NCj4+Pj4gSGF2aW5nIHNhaWQgdGhhdCwgdGhlIGZp ZWxkIHNpemUgaXMgbm90IGEgYmlnIGRlYWwgdG8gbWUuDQo+Pj4+IA0KPj4+PiBZb3VycywNCj4+ Pj4gSm9lbA0KPj4+PiANCj4+Pj4gT24gMTIvNC8xNCwgMjowMSBQTSwgU3JpbmkgQWRkZXBhbGxp IHdyb3RlOg0KPj4+Pj4gDQo+Pj4+PiBJIHdhcyBub3QgaW1wbHlpbmcgdGhhdCBwYXRoIElEIHNo b3VsZCBoYXZlIGluZm9ybWF0aW9uIGluIHJlZ2FyZHMgDQo+Pj4+PiB0byB0ZW5hbnQvY29udHJv bGxlci9mbG93L3NjYWxlLW91dC4gIEJ1dCBTRkMgY29udHJvbGxlcnMgc2hvdWxkIGtlZXAgdGhl c2UNCj4+Pj4+IGluIG1pbmQgdG8gYXNzaWduIHRoZSBwYXRoIElELiAgICBBIGRlcGxveW1lbnQg Y2FuIGhhdmUgbXVsdGlwbGUNCj4+Pj4+IHRlbmFudHMsIGVhY2ggdGVuYW50IGNhbiBoYXZlIG11 bHRpcGxlIG5ldHdvcmtzLCAgdGhlcmUgY291bGQgYmUgDQo+Pj4+PiBtaWxsaW9ucyBvZiBmbG93 cyBpbiBlYWNoIG9mIHRob3NlIG5ldHdvcmtzLiAgQW5kIGNvbnNpZGVyaW5nIGFsbCANCj4+Pj4+ IHRoZXNlLA0KPj4+Pj4gMjQgYml0IHBhdGggSUQgbWF5IG5vdCBiZSBhYmxlIHRvIHJlcHJlc2Vu dCBwYXRocyBmb3IgdGhlc2UgZmxvd3MuDQo+Pj4+PiBIZW5jZSwgSSB3YXMgd29uZGVyaW5nIHdo ZXRoZXIgcGF0aCBJRCBjYW4gYmUgZXh0ZW5kZWQgdG8gNjQgYml0cyANCj4+Pj4+IG9yIG1ha2Ug aXQgZmxleGlibGUuDQo+Pj4+PiANCj4+Pj4+IFRoYW5rcw0KPj4+Pj4gU3JpbmkNCj4+Pj4+IA0K Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gRnJv bTogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4+Pj4gU2VudDogVGh1 cnNkYXksIERlY2VtYmVyIDQsIDIwMTQgNzo0MiBBTQ0KPj4+Pj4gVG86IEFkZGVwYWxsaSBTcmlu aS1CMjIxNjA7IHNmY0BpZXRmLm9yZw0KPj4+Pj4gQ2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3 ODQwDQo+Pj4+PiBTdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+Pj4+ PiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+ Pj4+PiANCj4+Pj4+IFRoZSBJbmRleCBpcyBub3QganVzdCBmb3IgbG9vcCBwcmV2ZW50aW9uLiAg SW4gdGhlIGNhc2Ugb2YgDQo+Pj4+PiBhbWJpZ3VpdHksIHRoZSBpbmRleCB0ZWxscyB0aGUgU0ZG IHdoZXJlIGluIHRoZSBwYXRoIHRoZSBwYWNrZXQgY3VycmVudGx5IHJlc2lkZXMuDQo+Pj4+PiAg VGhlcmUgYXJlIG11bHRpcGxlIHdheXMgc3VjaCBhbWJpZ3VpdHkgY2FuIG9jY3VyLg0KPj4+Pj4g DQo+Pj4+PiBUaGUgUGF0aCBJZGVudGlmaWVyIGlzIHNwZWNpZmljYWxseSBub3QgZXhwZWN0ZWQg dG8gaW5jbHVkZSANCj4+Pj4+IGNvbnRyb2xsZXIgSUQgb3IgVGVuYW50IElELiAgV2hpbGUgYSBk ZXBsb3llciBjYW4gaGF2ZSBhIHBhdGggcGVyIA0KPj4+Pj4gdGVuYW50LCB0aGUgYXJjaGl0ZWN0 dXJlIHN0aWxsIGRvZXMgbm90IHRyZWF0IHRoZSBwYXRoIElEIGFzIGEgDQo+Pj4+PiB0ZW5hbnQg SUQuICBUZW5hbnQgSUQsIGNvbnRyb2xsZXIgSUQsIGFuZCBvdGhlciBub24tcGF0aC1zcGVjaWZ5 aW5nIA0KPj4+Pj4gaW5mb3JtYXRpb24gaXMgdG8gYmUgY2FycmllZCBpbiBtZXRhZGF0YS4NCj4+ Pj4+IA0KPj4+Pj4gWW91cnMsDQo+Pj4+PiBKb2VsDQo+Pj4+PiANCj4+Pj4+IE9uIDEyLzQvMTQs IDEwOjAyIEFNLCBTcmluaSBBZGRlcGFsbGkgd3JvdGU6DQo+Pj4+Pj4gVHdvIGNvbW1lbnRzIDoN Cj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiAxLiAgU0YgSW5kZXggOiAgU2luY2UgaXQgaXMgbWVh bnQgZm9yIGxvb3AgZGV0ZWN0aW9uLCAgd291bGRuJ3QgDQo+Pj4+Pj4gYmV0dGVyIHRvIHJlbmFt ZSB0aGlzIGFzICJUVEwiPw0KPj4+Pj4+IA0KPj4+Pj4+IDIuICBQYXRoIElkZW50aWZpZXIgOiAg ICAyNCBiaXQgcGF0aCBpZGVudGlmaWVyIHNlZW1zIHRvIGJlIHRvbyBsZXNzLg0KPj4+Pj4+IEJh c2VkIG9uIG91ciBleHBlcmllbmNlIGluIHRyYWZmaWMgc3RlZXJpbmcsICB0aGlzIHBhdGggaWRl bnRpZmllciANCj4+Pj4+PiBuZWVkcyB0byBlbmNvZGUgZ29vZCBhbW91bnQgb2YgaW5mb3JtYXRp b24gdG8gbWFrZSBpdCB1bmlxdWUuICBGb3IgDQo+Pj4+Pj4gZXhhbXBsZSwNCj4+Pj4+PiAgdGhp cyBpZGVudGlmaWVyIG5lZWRzIHRvIGVuY29kZSAoaW4gb3VyIGNhc2UpIHNvbWUgaW5mb3JtYXRp b24gDQo+Pj4+Pj4gcmVwcmVzZW50aW5nIHRoZSBkaXN0cmlidXRlZCBjb250cm9sbGVyIElELCAg dGVuYW50IElELCAgZmxvdyBJRCwNCj4+Pj4+PiAgU2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZSAo aW4gY2FzZSBvZiBzY2FsZS1vdXQpIGFuZCBmZXcgbW9yZS4uDQo+Pj4+Pj4gT25lIHN1Z2dlc3Rp b24gaXMgdG8gbWFrZSBpdCA2NCBiaXRzIHZhbHVlICBvciB0byBtYWtlIGl0IGV2ZW4gDQo+Pj4+ Pj4gZXh0ZW5kYWJsZSwNCj4+Pj4+PiAgaXQgaXMgZ29vZCBpZiBwYXRoIGlkZW50aWZpZXIgaXMg YWxzbyByZXByZXNlbnRlZCBpbiBUTFYgZm9ybS4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBU aGFua3MNCj4+Pj4+PiANCj4+Pj4+PiBTcmluaQ0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IA0K Pj4+Pj4+IA0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+Pj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+Pj4gDQo+ Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+IA0KPj4gDQo+PiANCj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMgbWFp bGluZyBsaXN0DQo+PiBzZmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiBzZmNAaWV0Zi5vcmcNCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+PiANCj4+IA0KPj4g VGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0YWNobWVudHMgKHRoZSAibWVzc2FnZSIpIGFyZSBjb25m aWRlbnRpYWwsIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZXMuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgZnJvbSB5b3VyIHN5c3Rl bS4gSW4gdGhpcyBjYXNlLCB5b3UgYXJlIG5vdCBhdXRob3JpemVkIHRvIHVzZSwgY29weSB0aGlz IG1lc3NhZ2UgYW5kL29yIGRpc2Nsb3NlIHRoZSBjb250ZW50IHRvIGFueSBvdGhlciBwZXJzb24u IEUtbWFpbHMgYXJlIHN1c2NlcHRpYmxlIHRvIGFsdGVyYXRpb24uIE5laXRoZXIgUW9zbW9zIG5v ciBhbnkgb2YgaXRzIHN1YnNpZGlhcmllcyBvciBhZmZpbGlhdGVzIHNoYWxsIGJlIGxpYWJsZSBm b3IgdGhlIG1lc3NhZ2UgaWYgYWx0ZXJlZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+PiANCj4+ IENlIG1lc3NhZ2UgZXQgdG91dGVzIHNlcyBwacOoY2VzIGpvaW50ZXMgKGNpLWFwcsOocyBsZSAi bWVzc2FnZSIpc29udCBjb25maWRlbnRpZWxzIGV0IMOpdGFibGlzIMOgIGwnaW50ZW50aW9uIGV4 Y2x1c2l2ZSBkZSBzZXMgZGVzdGluYXRhaXJlcy4gU2kgdm91cyBhdmV6IHJlw6d1IGNlIG1lc3Nh Z2UgcGFyIGVycmV1ciwgbWVyY2kgZOKAmWVuIGluZm9ybWVyIGltbcOpZGlhdGVtZW50IHNvbiDD qW1ldHRldXIgcGFyIGNvdXJyaWVyIMOpbGVjdHJvbmlxdWUgZXQgZOKAmWVmZmFjZXIgY2UgbWVz c2FnZSBkZSB2b3RyZSBzeXN0w6htZS4gRGFucyBjZXR0ZSBoeXBvdGjDqHNlLCB2b3VzIG7igJnD qnRlcyBwYXMgYXV0b3Jpc8OpIMOgIHV0aWxpc2VyLCBjb3BpZXIgY2UgbWVzc2FnZSBldC9vdSBl biBkaXZ1bGd1ZXIgbGUgY29udGVudSDDoCB1biB0aWVycy4gVG91dCBtZXNzYWdlIMOpbGVjdHJv bmlxdWUgZXN0IHN1c2NlcHRpYmxlIGQnYWx0w6lyYXRpb24uIFFvc21vcyBldCBzZXMgZmlsaWFs ZXMgZMOpY2xpbmVudCB0b3V0ZSByZXNwb25zYWJpbGl0w6kgYXUgdGl0cmUgZGUgY2UgbWVzc2Fn ZSBzJ2lsIGEgw6l0w6kgYWx0w6lyw6ksIGTDqWZvcm3DqSBvdSBmYWxzaWZpw6kuDQo+PiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1haWxp bmcgbGlzdA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gc2ZjIG1haWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K From nobody Tue Feb 3 13:54:45 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FA01A036F for ; Tue, 3 Feb 2015 13:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, 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 J9EDyOegd_Sb for ; Tue, 3 Feb 2015 13:54:40 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AD131A036B for ; Tue, 3 Feb 2015 13:54:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOS91972; Tue, 03 Feb 2015 21:54:37 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 3 Feb 2015 21:54:37 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.133]) by SJCEML703-CHM.china.huawei.com ([169.254.5.223]) with mapi id 14.03.0158.001; Tue, 3 Feb 2015 13:54:27 -0800 From: Cathy Zhang To: "Ken Gray (kegray)" , Srini Addepalli , "Reinaldo Penno (repenno)" , "Joel M. Halpern" , "'sfc@ietf.org'" , Cathy Zhang Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZyAGG+AgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgD//7j7oIBVIj4ggAmgroD//7LbsA== Date: Tue, 3 Feb 2015 21:54:27 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.78] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "nsmurthy@freescale.com" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 03 Feb 2015 21:54:43 -0000 Hi Ken, Please see inline. Thanks, Cathy -----Original Message----- From: Ken Gray (kegray) [mailto:kegray@cisco.com]=20 Sent: Tuesday, February 03, 2015 10:09 AM To: Cathy Zhang; Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern= ; 'sfc@ietf.org' Cc: nsmurthy@freescale.com Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) As a general comment on this submission (and perhaps life in the current IETF). I have a REALLY hard time differentiating this draft from the quinn draft (which pre-dates it by quite a bit). Why are we pursuing a separate draft when the suggestions, IMHO, seem incremental at best? Cathy> The original motivation for drafting the SCH is to provide an altern= ative to draft-quinn-nsh to address the following perceived issues: 1. Mandatory fixed-sized metadata. We think they should not be mandatory si= nce the 4-word context fields are not needed in many scenarios=20 2. No variable length metadata. We think metadata should be optional and TL= V format should be used to define metadata=20 3. No organizationally defined metadata=20 4. No Version field. =20 When we uploaded SCH 1st version (3/24/2014), NSH version did not have the = TLV metadata and version field (they were added in its later version). I have reach out to the chairs here . we have a lot to read. Aren't drafts supposed to offer significantly different views if they are to persist (without that, a "call to adopt" becomes a beauty contest, IMO)? No offense to the authors, but we're in revision 3 and I don't see that here. =20 Regarding the changes in this document: I do not find the flow ID functionally different than the use context headers in the nsh draft, which seem to be a more multi-purpose concept. Cathy> Different people have different viewpoints. RSP ID is not defined in= NSH and from Paul (NSH author)'s reply, it seems he does not feel the need= of an RSP ID.=20 Cathy> We see the need for RSP ID and thus defined it in SCH for open discu= ssion and would like to see the community's feedback on it. =20 The B bit suggestion can cause a conflict in control and create an avenue for undesirable behavior, IMO. I've been working from the assumption that a minimum requirement of a function is that it be manageable (if for no other reason than effective elasticity and cohesive/predictable delivery of service), so I have little sympathy for those that are not - be they virtual or physical (even less sympathy for virtual functions that are unmanageable, frankly). A self-management option in the SFC scenario has low value and the corruption or misuse of the bit can cause chaos (an extra level of "fail"). Cathy> Could you clarify what you mean by "cause a conflict in control"?=20 The Generic Context Block is confusing in light of the already extant optional/variable metadata TLVs (why wouldn't you leverage one of them)? Cathy> I am not sure if I understand your point. The Generic Context Block = is one type of metadata which is in TLV format and is optional.=20 Thanks, Cathy On 1/29/15, 2:44 PM, "Cathy Zhang" wrote: >Hi everyone, > >We have uploaded a new SCH version (3) which adds definition of a new >metadata type for the flow ID to support load balancing among SF >instances and mitigate the potential issue of "not enough path ID". The >flow ID is named "rendered service path ID" in the draft. Please refer to >section 4.3.2 of https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ >for detail description. >=20 > >In its previous version, SCH defines a "Bypass bit" in the base header. >This bit enables the SF to provide feedback/notification via the data >path to its connecting SFF about whether the remaining packets of the SFC >should bypass that SF. This is useful in the case that only the first few >packets of a flow need to go to a SF (such as a DPI or FW or IDS) and >remaining packets can bypass that SF, thus saving the expensive SF >resource and reducing data path latency. > >B bit: The B (Bypass) bit, when set to 1, it is used by a Service > Function to signal to its Service Function Forwarder that no > further packets are to be sent to it for the flow specified in >encapsulated packet. > >In addition, SCH defines a metadata type for Generic Context Block, which >is optional and can be used if needed to carry any vendor's specific >"Context Header". >=20 > >Any comments on these new additions? > >Thanks, >Cathy > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Cathy Zhang >Sent: Friday, December 05, 2014 11:47 AM >To: Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; >'sfc@ietf.org' >Cc: nsmurthy@freescale.com >Subject: Re: [sfc] Comments on SCH Draft >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > >Ron, Louis, Myo and I have been discussing off line last few weeks about >defining a metadata type for flow ID in addition to the path ID of the >main header to support load balancing among SF instances. We will define >a TLV type for the flow ID. The combination of "path ID + flow ID" >specifies a realized service chain instance path. It is left to the >design/implementation whether to use a centralized method or a >distributed method to bind the flow ID to a realized service instance >path although our original thought is for distributed LB usage. I am not >sure if we need a bit in the header to denote whether there are more path >ID bits (we call it flow ID) in the metadata fields since when you parse >the TLV metadata, you will know whether there are flow ID bits or not. >Note that if multiple sessions share the same realized service instance >path, they will share the same "path ID+ flow ID". We can also consider >extending the number of bits to 32 if that is the consensus. We will post >an updated draft describing these soon. > >Thanks, >Cathy > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Srini Addepalli >Sent: Friday, December 05, 2014 7:17 AM >To: Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf.org' >Cc: nsmurthy@freescale.com >Subject: Re: [sfc] Comments on SCH Draft >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > > >[RP] Data plane efficiency. > >SRINI> I am not so sure about data plane efficiency. Most of the >processors work good if the number of bits are either 32 or 64. If it is >24 bits, then one needs to do masking and shifting before the value is >used to do any lookup. But, this discussion can go into different >direction :-), it may not be good to go in that direction. > >Where do we draw the line? 32-bits, 64-bits, >128 bits? I think we should have a sensible value in the Service Path >header and if you need to convey more bits you need to use the context >headers. > >SRINI> This is a good point. This should work fine as long as there is >way to convey in the main header that the extension to path ID is >available in so and so TLV field. That should work too. > >Thanks >Srini > >________________________________________ >From: Reinaldo Penno (repenno) >Sent: Friday, December 5, 2014 7:08 AM >To: Addepalli Srini-B22160; Joel M. Halpern; 'sfc@ietf.org' >Cc: NS Srinivasa Murthy-B37840 >Subject: Re: [sfc] Comments on SCH Draft >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > >On 12/5/14, 6:54 AM, "Srini Addepalli" wrote: > >> >>In real deployments, number of active path IDs are very lesser than 2^64, >>but there is a good possibility of the number being more than 2^24 (16M). >> I think bigger point is that why restrict this in the standards? What >>advantage do we have restricting this size to 24 bits? > >[RP] Data plane efficiency. Where do we draw the line? 32-bits, 64-bits, >128 bits? I think we should have a sensible value in the Service Path >header and if you need to convey more bits you need to use the context >headers. > > >> >>There can be deployments, where SFC controller (Logically central, but >>distributed) itself can do the SF instance selection on per >>connection/session basis, thereby avoiding the LBs for services. In my >>view, assumption that there will be LB SF for each scale-out service in >>the chain is not valid in all cases. >> >>Thanks >>Srini >> >>________________________________________ >>From: Reinaldo Penno (repenno) >>Sent: Thursday, December 4, 2014 1:17 PM >>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org >>Cc: NS Srinivasa Murthy-B37840 >>Subject: Re: [sfc] Comments on SCH Draft >>(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >> >>If I understood you, I do not think this is realistic. Are you saying you >>need 64-bits of paths and then will monitor them all? Do fault tolerance >>and OAM for 2^64-bits worth of paths? Just for comparison, it=B9s like >>managing and monitoring the entire IPv6 host range, one-by-one. >> >>Anyway, I do not expect every single permutations to be a different path. >> >>If each service has 256 devices providing similar service, you should >>most >>likely use load-balancing and then you would have a single (or a few) >>paths. There is some discussion going on LB. >> >>From a data plane perspective, the path is ultimately defined by the SFFs >>traversed and services provided, not by a specific IP:port that the >>device >>providing the service sits on. Well, at least from a GPE+NSH perspective. >> >> >>On 12/4/14, 12:57 PM, "Srini Addepalli" wrote: >> >>>If I take a chain with 5 services with each service say having 256 >>>instances for scale-out, possible number of paths are >>>256*256*256*256*256 >>>=3D 0xFF FF FF FF FF. One requires 33 bits in this case. If there are >>>more >>>services in the chain or more chains or more instances for scale-out, >>>then it could go to big number very fast. >>> >>>As I mentioned my preference is to make the path ID size flexible for >>>future growth. If that is perceived as complex, then going for 64bit is >>>safer bet. >>> >>>Thanks >>>Srini >>> >>> >>>-----Original Message----- >>>From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>Sent: Thursday, December 04, 2014 12:05 PM >>>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org >>>Cc: NS Srinivasa Murthy-B37840 >>>Subject: Re: [sfc] Comments on SCH Draft >>>(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >>> >>>A controller (or other decision logic) can certainly be aware of such >>>concerns. >>>But the number of service function paths is not related to the number of >>>flows or the number of tenants. It is related to the number of >>>combinations of services and the policies for service function >>>selection. >>> While that can be a large number, I sure hope it does not come close to >>>saturating 24 bits. >>> >>>Having said that, if we think that 24 bits is only just enough, then we >>>ought to use 32. From where I sit, I would normally expect 16 bits to >>>be >>>more than sufficient, which is why I am comfortable with 24. Having >>>said >>>that, the field size is not a big deal to me. >>> >>>Yours, >>>Joel >>> >>>On 12/4/14, 2:01 PM, Srini Addepalli wrote: >>>> >>>> I was not implying that path ID should have information in regards to >>>>tenant/controller/flow/scale-out. But SFC controllers should keep >>>>these >>>>in mind to assign the path ID. A deployment can have multiple >>>>tenants, each tenant can have multiple networks, there could be >>>>millions of flows in each of those networks. And considering all >>>>these, >>>> 24 bit path ID may not be able to represent paths for these flows. >>>>Hence, I was wondering whether path ID can be extended to 64 bits or >>>>make it flexible. >>>> >>>> Thanks >>>> Srini >>>> >>>> ________________________________________ >>>> From: Joel M. Halpern >>>> Sent: Thursday, December 4, 2014 7:42 AM >>>> To: Addepalli Srini-B22160; sfc@ietf.org >>>> Cc: NS Srinivasa Murthy-B37840 >>>> Subject: Re: [sfc] Comments on SCH Draft >>>> (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >>>> >>>> The Index is not just for loop prevention. In the case of ambiguity, >>>> the index tells the SFF where in the path the packet currently >>>>resides. >>>> There are multiple ways such ambiguity can occur. >>>> >>>> The Path Identifier is specifically not expected to include controller >>>> ID or Tenant ID. While a deployer can have a path per tenant, the >>>> architecture still does not treat the path ID as a tenant ID. Tenant >>>> ID, controller ID, and other non-path-specifying information is to be >>>> carried in metadata. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 12/4/14, 10:02 AM, Srini Addepalli wrote: >>>>> Two comments : >>>>> >>>>> >>>>> 1. SF Index : Since it is meant for loop detection, wouldn't >>>>> better to rename this as "TTL"? >>>>> >>>>> 2. Path Identifier : 24 bit path identifier seems to be too less. >>>>> Based on our experience in traffic steering, this path identifier >>>>> needs to encode good amount of information to make it unique. For >>>>>example, >>>>> this identifier needs to encode (in our case) some information >>>>> representing the distributed controller ID, tenant ID, flow ID, >>>>> Service function instance (in case of scale-out) and few more.. >>>>> One suggestion is to make it 64 bits value or to make it even >>>>>extendable, >>>>> it is good if path identifier is also represented in TLV form. >>>>> >>>>> >>>>> Thanks >>>>> >>>>> Srini >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Tue Feb 3 14:27: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 6464A1A6F14 for ; Tue, 3 Feb 2015 14:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-5, 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 JSfvqNtANOOk for ; Tue, 3 Feb 2015 14:27:19 -0800 (PST) Received: from mxe01.gs.com (mxe01.gs.com [204.4.178.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07BD01A8A77 for ; Tue, 3 Feb 2015 14:27:18 -0800 (PST) Received: from pps.filterd (gsppacdp02sd.idz.gs.com [127.0.0.1]) by gsppacdp02sd.idz.gs.com (8.14.5/8.14.5) with SMTP id t13MOp6p013624; Tue, 3 Feb 2015 17:27:07 -0500 Received: from gsppacdp06nd.inz.gs.com ([10.205.68.209]) by gsppacdp02sd.idz.gs.com with ESMTP id 1sb4nk2jav-1; Tue, 03 Feb 2015 17:27:07 -0500 Received: from pps.filterd (gsppacdp06nd.inz.gs.com [127.0.0.1]) by gsppacdp06nd.inz.gs.com (8.14.5/8.14.5) with SMTP id t13MMXOB016596; Tue, 3 Feb 2015 17:27:06 -0500 Received: from gshccdp10ex.firmwide.corp.gs.com (gshccdp10ex.firmwide.corp.gs.com [10.135.172.88]) by gsppacdp06nd.inz.gs.com with ESMTP id 1sb1skb1vb-1; Tue, 03 Feb 2015 17:27:06 -0500 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshccdp10ex.firmwide.corp.gs.com ([10.135.172.88]) with mapi; Tue, 3 Feb 2015 17:27:06 -0500 From: "Zarny, Myo" To: "'Cathy Zhang'" , "'Ken Gray (kegray)'" , "'Srini Addepalli'" , "'Reinaldo Penno (repenno)'" , "'Joel M. Halpern'" , "'sfc@ietf.org'" Date: Tue, 3 Feb 2015 17:27:05 -0500 Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZyAGG+AgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgD//7j7oIBVIj4ggAmgroD//7LbsIAADrIQ Message-ID: References: <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C230719755790GSCMAMP19EXfi_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-02-03_08:2015-02-03,2015-02-03,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-02-03_08:2015-02-03,2015-02-03,1970-01-01 signatures=0 Archived-At: Cc: "'nsmurthy@freescale.com'" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 03 Feb 2015 22:27:25 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C230719755790GSCMAMP19EXfi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ken, * IETF90 minutes explain the differences then. o Yes, the drafts are now very similar because the NSH draft has incorporated= the TLV portion. o The generic context block is to accommodate NSH's four mandatory co= ntext header fields. * The chairs are actively working on a merged document with a section for rem= aining differences. Thanks, -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Cathy Zhang Sent: 3 February 2015 4:54 PM To: Ken Gray (kegray); Srini Addepalli; Reinaldo Penno (repenno); Joel M. H= alpern; 'sfc@ietf.org'; Cathy Zhang Cc: nsmurthy@freescale.com Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) Hi Ken, Please see inline. Thanks, Cathy -----Original Message----- From: Ken Gray (kegray) [mailto:kegray@cisco.com] Sent: Tuesday, February 03, 2015 10:09 AM To: Cathy Zhang; Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern= ; 'sfc@ietf.org' Cc: nsmurthy@freescale.com Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) As a general comment on this submission (and perhaps life in the current IE= TF). I have a REALLY hard time differentiating this draft from the quinn d= raft (which pre-dates it by quite a bit). Why are we pursuing a separate d= raft when the suggestions, IMHO, seem incremental at best? Cathy> The original motivation for drafting the SCH is to provide an altern= ative to draft-quinn-nsh to address the following perceived issues: 1. Mandatory fixed-sized metadata. We think they should not be mandatory si= nce the 4-word context fields are not needed in many scenarios 2. No variab= le length metadata. We think metadata should be optional and TLV format sho= uld be used to define metadata 3. No organizationally defined metadata 4. N= o Version field. When we uploaded SCH 1st version (3/24/2014), NSH version did not have the = TLV metadata and version field (they were added in its later version). I have reach out to the chairs here . we have a lot to read. Aren't drafts = supposed to offer significantly different views if they are to persist (wit= hout that, a "call to adopt" becomes a beauty contest, IMO)? No offense to= the authors, but we're in revision 3 and I don't see that here. Regarding the changes in this document: I do not find the flow ID functionally different than the use context heade= rs in the nsh draft, which seem to be a more multi-purpose concept. Cathy> Different people have different viewpoints. RSP ID is not defined in= NSH and from Paul (NSH author)'s reply, it seems he does not feel the need= of an RSP ID. Cathy> We see the need for RSP ID and thus defined it in SCH for open discu= ssion and would like to see the community's feedback on it. The B bit suggestion can cause a conflict in control and create an avenue f= or undesirable behavior, IMO. I've been working from the assumption that a= minimum requirement of a function is that it be manageable (if for no othe= r reason than effective elasticity and cohesive/predictable delivery of ser= vice), so I have little sympathy for those that are not - be they virtual o= r physical (even less sympathy for virtual functions that are unmanageable,= frankly). A self-management option in the SFC scenario has low value and = the corruption or misuse of the bit can cause chaos (an extra level of "fai= l"). Cathy> Could you clarify what you mean by "cause a conflict in control"? The Generic Context Block is confusing in light of the already extant optio= nal/variable metadata TLVs (why wouldn't you leverage one of them)? Cathy> I am not sure if I understand your point. The Generic Context Block = is one type of metadata which is in TLV format and is optional. Thanks, Cathy On 1/29/15, 2:44 PM, "Cathy Zhang" > wrote: >Hi everyone, > >We have uploaded a new SCH version (3) which adds definition of a new >metadata type for the flow ID to support load balancing among SF >instances and mitigate the potential issue of "not enough path ID". The >flow ID is named "rendered service path ID" in the draft. Please refer >to section 4.3.2 of >https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ >for detail description. > > >In its previous version, SCH defines a "Bypass bit" in the base header. >This bit enables the SF to provide feedback/notification via the data >path to its connecting SFF about whether the remaining packets of the >SFC should bypass that SF. This is useful in the case that only the >first few packets of a flow need to go to a SF (such as a DPI or FW or >IDS) and remaining packets can bypass that SF, thus saving the >expensive SF resource and reducing data path latency. > >B bit: The B (Bypass) bit, when set to 1, it is used by a Service > Function to signal to its Service Function Forwarder that no > further packets are to be sent to it for the flow specified in >encapsulated packet. > >In addition, SCH defines a metadata type for Generic Context Block, >which is optional and can be used if needed to carry any vendor's >specific "Context Header". > > >Any comments on these new additions? > >Thanks, >Cathy > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Cathy Zhang >Sent: Friday, December 05, 2014 11:47 AM >To: Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; >'sfc@ietf.org' >Cc: nsmurthy@freescale.com >Subject: Re: [sfc] Comments on SCH Draft >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > >Ron, Louis, Myo and I have been discussing off line last few weeks >about defining a metadata type for flow ID in addition to the path ID >of the main header to support load balancing among SF instances. We >will define a TLV type for the flow ID. The combination of "path ID + flow= ID" >specifies a realized service chain instance path. It is left to the >design/implementation whether to use a centralized method or a >distributed method to bind the flow ID to a realized service instance >path although our original thought is for distributed LB usage. I am >not sure if we need a bit in the header to denote whether there are >more path ID bits (we call it flow ID) in the metadata fields since >when you parse the TLV metadata, you will know whether there are flow ID b= its or not. >Note that if multiple sessions share the same realized service instance >path, they will share the same "path ID+ flow ID". We can also >consider extending the number of bits to 32 if that is the consensus. >We will post an updated draft describing these soon. > >Thanks, >Cathy > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Srini Addepalli >Sent: Friday, December 05, 2014 7:17 AM >To: Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf.org' >Cc: nsmurthy@freescale.com >Subject: Re: [sfc] Comments on SCH Draft >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > > >[RP] Data plane efficiency. > >SRINI> I am not so sure about data plane efficiency. Most of the >processors work good if the number of bits are either 32 or 64. If it >is >24 bits, then one needs to do masking and shifting before the value is >used to do any lookup. But, this discussion can go into different >direction :-), it may not be good to go in that direction. > >Where do we draw the line? 32-bits, 64-bits, >128 bits? I think we should have a sensible value in the Service Path >header and if you need to convey more bits you need to use the context >headers. > >SRINI> This is a good point. This should work fine as long as there is >way to convey in the main header that the extension to path ID is >available in so and so TLV field. That should work too. > >Thanks >Srini > >________________________________________ >From: Reinaldo Penno (repenno) > >Sent: Friday, December 5, 2014 7:08 AM >To: Addepalli Srini-B22160; Joel M. Halpern; 'sfc@ietf.org' >Cc: NS Srinivasa Murthy-B37840 >Subject: Re: [sfc] Comments on SCH Draft >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > >On 12/5/14, 6:54 AM, "Srini Addepalli" > wrote: > >> >>In real deployments, number of active path IDs are very lesser than >>2^64, but there is a good possibility of the number being more than 2^24 = (16M). >> I think bigger point is that why restrict this in the standards? What >>advantage do we have restricting this size to 24 bits? > >[RP] Data plane efficiency. Where do we draw the line? 32-bits, >64-bits, >128 bits? I think we should have a sensible value in the Service Path >header and if you need to convey more bits you need to use the context >headers. > > >> >>There can be deployments, where SFC controller (Logically central, but >>distributed) itself can do the SF instance selection on per >>connection/session basis, thereby avoiding the LBs for services. In my >>view, assumption that there will be LB SF for each scale-out service >>in the chain is not valid in all cases. >> >>Thanks >>Srini >> >>________________________________________ >>From: Reinaldo Penno (repenno) > >>Sent: Thursday, December 4, 2014 1:17 PM >>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org >>Cc: NS Srinivasa Murthy-B37840 >>Subject: Re: [sfc] Comments on SCH Draft >>(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >> >>If I understood you, I do not think this is realistic. Are you saying >>you need 64-bits of paths and then will monitor them all? Do fault >>tolerance and OAM for 2^64-bits worth of paths? Just for comparison, >>it=B9s like managing and monitoring the entire IPv6 host range, one-by-on= e. >> >>Anyway, I do not expect every single permutations to be a different path. >> >>If each service has 256 devices providing similar service, you should >>most likely use load-balancing and then you would have a single (or a >>few) paths. There is some discussion going on LB. >> >>From a data plane perspective, the path is ultimately defined by the >>SFFs traversed and services provided, not by a specific IP:port that >>the device providing the service sits on. Well, at least from a >>GPE+NSH perspective. >> >> >>On 12/4/14, 12:57 PM, "Srini Addepalli" > wrote: >> >>>If I take a chain with 5 services with each service say having 256 >>>instances for scale-out, possible number of paths are >>>256*256*256*256*256 >>>=3D 0xFF FF FF FF FF. One requires 33 bits in this case. If there are >>>more services in the chain or more chains or more instances for >>>scale-out, then it could go to big number very fast. >>> >>>As I mentioned my preference is to make the path ID size flexible for >>>future growth. If that is perceived as complex, then going for 64bit >>>is safer bet. >>> >>>Thanks >>>Srini >>> >>> >>>-----Original Message----- >>>From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>Sent: Thursday, December 04, 2014 12:05 PM >>>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org >>>Cc: NS Srinivasa Murthy-B37840 >>>Subject: Re: [sfc] Comments on SCH Draft >>>(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >>> >>>A controller (or other decision logic) can certainly be aware of such >>>concerns. >>>But the number of service function paths is not related to the number >>>of flows or the number of tenants. It is related to the number of >>>combinations of services and the policies for service function >>>selection. >>> While that can be a large number, I sure hope it does not come close >>>to saturating 24 bits. >>> >>>Having said that, if we think that 24 bits is only just enough, then >>>we ought to use 32. From where I sit, I would normally expect 16 >>>bits to be more than sufficient, which is why I am comfortable with >>>24. Having said that, the field size is not a big deal to me. >>> >>>Yours, >>>Joel >>> >>>On 12/4/14, 2:01 PM, Srini Addepalli wrote: >>>> >>>> I was not implying that path ID should have information in regards >>>>to tenant/controller/flow/scale-out. But SFC controllers should >>>>keep these >>>>in mind to assign the path ID. A deployment can have multiple >>>>tenants, each tenant can have multiple networks, there could be >>>>millions of flows in each of those networks. And considering all >>>>these, >>>> 24 bit path ID may not be able to represent paths for these flows. >>>>Hence, I was wondering whether path ID can be extended to 64 bits or >>>>make it flexible. >>>> >>>> Thanks >>>> Srini >>>> >>>> ________________________________________ >>>> From: Joel M. Halpern = > >>>> Sent: Thursday, December 4, 2014 7:42 AM >>>> To: Addepalli Srini-B22160; sfc@ietf.org >>>> Cc: NS Srinivasa Murthy-B37840 >>>> Subject: Re: [sfc] Comments on SCH Draft >>>> (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >>>> >>>> The Index is not just for loop prevention. In the case of >>>>ambiguity, the index tells the SFF where in the path the packet >>>>currently resides. >>>> There are multiple ways such ambiguity can occur. >>>> >>>> The Path Identifier is specifically not expected to include >>>> controller ID or Tenant ID. While a deployer can have a path per >>>> tenant, the architecture still does not treat the path ID as a >>>> tenant ID. Tenant ID, controller ID, and other non-path-specifying >>>> information is to be carried in metadata. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 12/4/14, 10:02 AM, Srini Addepalli wrote: >>>>> Two comments : >>>>> >>>>> >>>>> 1. SF Index : Since it is meant for loop detection, wouldn't >>>>> better to rename this as "TTL"? >>>>> >>>>> 2. Path Identifier : 24 bit path identifier seems to be too less. >>>>> Based on our experience in traffic steering, this path identifier >>>>>needs to encode good amount of information to make it unique. For >>>>>example, >>>>> this identifier needs to encode (in our case) some information >>>>>representing the distributed controller ID, tenant ID, flow ID, >>>>> Service function instance (in case of scale-out) and few more.. >>>>> One suggestion is to make it 64 bits value or to make it even >>>>>extendable, >>>>> it is good if path identifier is also represented in TLV form. >>>>> >>>>> >>>>> Thanks >>>>> >>>>> Srini >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_A3233753A4B65F43BCA1B64DA99A9C230719755790GSCMAMP19EXfi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Ken,
  • IETF90 minutes explain = the differences then.
  • Yes, the drafts are now= very similar because the NSH draft has incorporated the TLV portion.
    • <= li style=3D"margin-top: 5pt; margin-bottom: 5pt; ">The generic context bloc= k is to accommodate NSH's four mandatory context header fields.
  • The chairs are actively= working on a merged document with a section for remaining differences.
Thanks,
 
-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.= org] On Behalf Of Cathy Zhang
Sent: 3 February 2015 4:54 PM
To: Ken Gray (kegray); Srini Addepalli; Reinaldo Penno (repenno); Joel M. H= alpern; 'sfc@ietf.org'; Cathy Zhang
Cc: nsmurthy@freescale.com
Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-s= ch-02)
 
Hi Ken,
 
Please see inline.
 
Thanks,
Cathy
 
-----Original Message-----
From: Ken Gray (kegray) [mailto:ke= gray@cisco.com]
Sent: Tuesday, February 03, 2015 10:09 AM
To: Cathy Zhang; Srini Addepalli; Reinaldo Penno (repenno); Joel M. Ha= lpern; 'sfc@ietf.org'
 
As a general comment on this submission (and perhaps life in the curre= nt IETF).  I have a REALLY hard time differentiating this draft from t= he quinn draft (which pre-dates it by quite a bit).  Why are we pursui= ng a separate draft when the suggestions, IMHO, seem incremental at best?
 
 
Cathy> The original motivation for drafting the SCH is to provide a= n alternative to draft-quinn-nsh to address the following perceived issues:=
1. Mandatory fixed-sized metadata. We think they should not be mandato= ry since the 4-word context fields are not needed in many scenarios 2. No v= ariable length metadata. We think metadata should be optional and TLV forma= t should be used to define metadata 3. No organizationally defined metadata 4. No Version field. 
When we uploaded SCH 1st version (3/24/2014), NSH version did not have= the TLV metadata and version field (they were added in its later version).=
 
 
 
I have reach out to the chairs here . we have a lot to read. Aren't dr= afts supposed to offer significantly different views if they are to persist= (without that, a "call to adopt" becomes a beauty contest, IMO)?=   No offense to the authors, but we're in revision 3 and I don't see that here.
 
 
Regarding the changes in this document:
 
I do not find the flow ID functionally different than the use context = headers in the nsh draft, which seem to be a more multi-purpose concept.
 
Cathy> Different people have different viewpoints. RSP ID is not de= fined in NSH and from Paul (NSH author)'s reply, it seems he does not feel = the need of an RSP ID.
Cathy> We see the need for RSP ID and thus defined it in SCH for op= en discussion and would like to see the community's feedback on it.  <= /div>
 
The B bit suggestion can cause a conflict in control and create an ave= nue for undesirable behavior, IMO.  I've been working from the assumpt= ion that a minimum requirement of a function is that it be manageable (if f= or no other reason than effective elasticity and cohesive/predictable delivery of service), so I have little sympathy fo= r those that are not - be they virtual or physical (even less sympathy for = virtual functions that are unmanageable, frankly).  A self-management = option in the SFC scenario has low value and the corruption or misuse of the bit can cause chaos (an extra level of = "fail").
 
Cathy> Could you clarify what you mean by "cause a conflict in= control"?
 
 
The Generic Context Block is confusing in light of the already extant = optional/variable metadata TLVs (why wouldn't you leverage one of them)?
 
Cathy> I am not sure if I understand your point. The Generic Contex= t Block is one type of metadata which is in TLV format and is optional.
 
Thanks,
Cathy
 
 
On 1/29/15, 2:44 PM, "Cathy Zhang" <Cathy.H.Zhang@huawei.com> wrote:
 
>Hi everyone,
>
>We have uploaded a new SCH version (3) which adds definition of a = new
>metadata type for the flow ID to support load balancing among SF <= /div>
>instances and mitigate the potential issue of "not enough pat= h ID". The
>flow ID is named "rendered service path ID" in the draft= . Please refer
>to section 4.3.2 of
>for detail description.
>
>
>In its previous version, SCH defines a "Bypass bit" in t= he base header.
>This bit enables the SF to provide feedback/notification via the d= ata
>path to its connecting SFF about whether the remaining packets of = the
>SFC should bypass that SF. This is useful in the case that only th= e
>first few packets of a flow need to go to a SF (such as a DPI or F= W or
>IDS) and remaining packets can bypass that SF, thus saving the
>expensive SF resource and reducing data path latency.
>
>B bit: The B (Bypass) bit, when set to 1, it is used by a Service<= /div>
>       Function to signal to its Ser= vice Function Forwarder that no
>       further packets are to be sen= t to it for the flow specified in
>encapsulated packet.
>
>In addition, SCH defines a metadata type for Generic Context Block= ,
>which is optional and can be used if needed to carry any vendor's =
>specific "Context Header".
>
>
>Any comments on these new additions?
>
>Thanks,
>Cathy
>
>-----Original Message-----
>From: sfc [mailto:sfc-boun= ces@ietf.org] On Behalf Of Cathy Zhang
>Sent: Friday, December 05, 2014 11:47 AM
>To: Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern;
>'sfc@ietf.org'
>Subject: Re: [sfc] Comments on SCH Draft
>
>Ron, Louis, Myo and I have been discussing off line last few weeks=
>about defining a metadata type for flow ID in addition to the path= ID
>of the main header to support load balancing among SF instances. W= e
>will define a TLV type for the flow ID. The combination of "p= ath ID + flow ID"
>specifies a realized service chain instance path. It is left to th= e
>design/implementation whether to use a centralized method or a
>distributed method to bind the flow ID to a realized service insta= nce
>path although our original thought is for distributed LB usage. I = am
>not sure if we need a bit in the header to denote whether there ar= e
>more path ID bits (we call it flow ID) in the metadata fields sinc= e
>when you parse the TLV metadata, you will know whether there are f= low ID bits or not.
>Note that if multiple sessions share the same realized service ins= tance
>path, they will share the same "path ID+ flow ID".&n= bsp; We can also
>consider extending the number of bits to 32 if that is the consens= us.
>We will post an updated draft describing these soon.
>
>Thanks,
>Cathy
>
>-----Original Message-----
>From: sfc [mailto:sfc-boun= ces@ietf.org] On Behalf Of Srini Addepalli
>Sent: Friday, December 05, 2014 7:17 AM
>To: Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf.org'
>Subject: Re: [sfc] Comments on SCH Draft
>
>
>[RP] Data plane efficiency.
>
>SRINI> I am not so sure about data plane efficiency.  Most= of the
>processors work good if the number of bits are either 32 or 64.&nb= sp; If it
>is
>24 bits, then one needs to do masking and shifting before the valu= e is
>used to do any lookup.   But, this discussion can go int= o different
>direction :-), it may not be good to go in that direction.
>
>Where do we draw the line? 32-bits, 64-bits,
>128 bits? I think we should have a sensible value in the Service P= ath
>header and if you need to convey more bits you need to use the con= text
>headers.
>
>SRINI> This is a good point.  This should work fine as lon= g as there is
>way to convey in the main header that the extension to path ID is =
>available in so and so TLV field.  That should work too.
>
>Thanks
>Srini
>
>________________________________________
>From: Reinaldo Penno (repenno) <repenno@cisco.com>
>Sent: Friday, December 5, 2014 7:08 AM
>To: Addepalli Srini-B22160; Joel M. Halpern; 'sfc@ietf.org'
>Cc: NS Srinivasa Murthy-B37840
>Subject: Re: [sfc] Comments on SCH Draft
>
>On 12/5/14, 6:54 AM, "Srini Addepalli" <saddepalli@freescale.com> wrote:
>
>>
>>In real deployments, number of active path IDs are very lesser= than
>>2^64, but there is a good possibility of the number being more= than 2^24 (16M).
>> I think bigger point is that why restrict this in the standar= ds? What
>>advantage do we have restricting this size to 24 bits?
>
>[RP] Data plane efficiency. Where do we draw the line? 32-bits,
>64-bits,
>128 bits? I think we should have a sensible value in the Service P= ath
>header and if you need to convey more bits you need to use the con= text
>headers.
>
>
>>
>>There can be deployments, where SFC controller (Logically cent= ral, but
>>distributed)  itself can do the SF instance selection on = per
>>connection/session basis, thereby avoiding the LBs for service= s.   In my
>>view, assumption that there will be LB SF for each scale-out s= ervice
>>in the chain is not valid in all cases.
>>
>>Thanks
>>Srini
>>
>>________________________________________
>>From: Reinaldo Penno (repenno) <repenno@cisco.com>
>>Sent: Thursday, December 4, 2014 1:17 PM
>>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org
>>Cc: NS Srinivasa Murthy-B37840
>>Subject: Re: [sfc] Comments on SCH Draft
>>
>>If I understood you, I do not think this is realistic. Are you= saying
>>you need 64-bits of paths and then will monitor them all? Do f= ault
>>tolerance and OAM for 2^64-bits worth of paths? Just for compa= rison,
>>it=B9s like managing and monitoring the entire IPv6 host range= , one-by-one.
>>
>>Anyway, I do not expect every single permutations to be a diff= erent path.
>>
>>If each service has 256 devices providing similar service, you= should
>>most likely use load-balancing and then you would have a singl= e (or a
>>few) paths. There is some discussion going on LB.
>>
>>From a data plane perspective, the path is ultimately defined = by the
>>SFFs traversed and services provided, not by a specific IP:por= t that
>>the device providing the service sits on. Well, at least from = a
>>GPE+NSH perspective.
>>
>>
>>On 12/4/14, 12:57 PM, "Srini Addepalli" <saddepalli@freescale.com> wrote= :
>>
>>>If I take a chain with 5 services with each service  = say having 256
>>>instances for scale-out, possible number of paths are
>>>256*256*256*256*256
>>>=3D 0xFF FF FF FF FF. One requires 33 bits in this case.&n= bsp; If there are
>>>more services in the chain or more chains or more instance= s for
>>>scale-out, then it could go to big number very fast.
>>>
>>>As I mentioned my preference is to make the path ID size f= lexible for
>>>future growth. If that is perceived as complex, then going= for 64bit
>>>is safer bet.
>>>
>>>Thanks
>>>Srini
>>>
>>>
>>>-----Original Message-----
>>>From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>>Sent: Thursday, December 04, 2014 12:05 PM
>>>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org
>>>Cc: NS Srinivasa Murthy-B37840
>>>Subject: Re: [sfc] Comments on SCH Draft
>>>
>>>A controller (or other decision logic) can certainly be aw= are of such
>>>concerns.
>>>But the number of service function paths is not related to= the number
>>>of flows or the number of tenants.  It is related to = the number of
>>>combinations of services and the policies for service func= tion
>>>selection.
>>> While that can be a large number, I sure hope it does not= come close
>>>to saturating 24 bits.
>>>
>>>Having said that, if we think that 24 bits is only just en= ough, then
>>>we ought to use 32.  From where I sit, I would normal= ly expect 16
>>>bits to be more than sufficient, which is why I am comfort= able with
>>>24.  Having said that, the field size is not a big de= al to me.
>>>
>>>Yours,
>>>Joel
>>>
>>>On 12/4/14, 2:01 PM, Srini Addepalli wrote:
>>>>
>>>> I was not implying that path ID should have informati= on in regards
>>>>to tenant/controller/flow/scale-out.  But SFC con= trollers should
>>>>keep these
>>>>in mind to assign the path ID.    A dep= loyment can have multiple
>>>>tenants, each tenant can have multiple networks, = there could be
>>>>millions of flows in each of those networks.  And= considering all
>>>>these,
>>>> 24 bit path ID may not be able to represent paths for= these flows.
>>>>Hence, I was wondering whether path ID can be extended= to 64 bits or
>>>>make it flexible.
>>>>
>>>> Thanks
>>>> Srini
>>>>
>>>> ________________________________________
>>>> From: Joel M. Halpern <jmh@joelhalpern.com>
>>>> Sent: Thursday, December 4, 2014 7:42 AM
>>>> To: Addepalli Srini-B22160; sfc@ietf.org
>>>> Cc: NS Srinivasa Murthy-B37840
>>>> Subject: Re: [sfc] Comments on SCH Draft
>>>>
>>>> The Index is not just for loop prevention.  In t= he case of
>>>>ambiguity,  the index tells the SFF where in the = path the packet
>>>>currently resides.
>>>>    There are multiple ways such ambigu= ity can occur.
>>>>
>>>> The Path Identifier is specifically not expected to i= nclude
>>>> controller ID or Tenant ID.  While a deployer ca= n have a path per
>>>> tenant, the architecture still does not treat the pat= h ID as a
>>>> tenant ID.  Tenant ID, controller ID, and other = non-path-specifying
>>>> information is to be carried in metadata.
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 12/4/14, 10:02 AM, Srini Addepalli wrote:
>>>>> Two comments :
>>>>>
>>>>>
>>>>> 1.  SF Index :  Since it is meant for l= oop detection,  wouldn't
>>>>> better to rename this as "TTL"?
>>>>>
>>>>> 2.  Path Identifier :    24 b= it path identifier seems to be too less.
>>>>> Based on our experience in traffic steering, = ; this path identifier 
>>>>>needs to encode good amount of information to make= it unique.  For
>>>>>example,
>>>>>    this identifier needs to encode= (in our case) some information 
>>>>>representing the distributed controller ID,  = tenant ID,  flow ID,
>>>>>    Service function instance (in c= ase of scale-out) and few more..
>>>>> One suggestion is to make it 64 bits value  = or to make it even
>>>>>extendable,
>>>>>    it is good if path identifier i= s also represented in TLV form.
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> Srini
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> sfc mailing list
>>>>> sfc@ietf.org<= /div>
>>>>>
>>>
>>>_______________________________________________
>>>sfc mailing list
>>
>
>
>_______________________________________________
>sfc mailing list
>
>_______________________________________________
>sfc mailing list
>
>_______________________________________________
>sfc mailing list
 
_______________________________________________
sfc mailing list
 
--_000_A3233753A4B65F43BCA1B64DA99A9C230719755790GSCMAMP19EXfi_-- From nobody Tue Feb 3 16:21: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 0ACCD1A1B19 for ; Tue, 3 Feb 2015 16:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 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, J_CHICKENPOX_24=0.6, 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 qQH9MU32OTK9 for ; Tue, 3 Feb 2015 16:21:00 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91CD81A1B15 for ; Tue, 3 Feb 2015 16:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58171; q=dns/txt; s=iport; t=1423009259; x=1424218859; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yhWurSFdW0r7ORXlEO7B7eHWo2qZGpMkQAAMZ6gZzLw=; b=QRunXwX5x1Tt83jN9Ew1ffHa1Spno/1OYElfJMYDJnSS3EM1TZdjpTRE 3ZwuxnZdktJqUXQLYO19oEAuMpnTHcOcUwee4RHl7C+dqML5K/KfRgpXI zJy/lHJ3QjPqLMZ1LRy515Q71e17TMFveMtA7Ir70pIZL7x5YiGd8U4n3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CMBQAOZdFU/5NdJa1agkMhIlJZBIJ9wWcZAQmFcQIcfEMBAQEBAX2EDAEBAQMBAQEBFwECEDoHCwUHBAIBCBEBAwEBASABBgUCAiULFAMGCAIEAQ0FFAWIDAgBDKMrnGQGllEBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIoOhQc4BwkXBAcCBIJcgUcFjSmBY4NOhViBF4MDgkWIQ4M9IoICHBSBPG8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,516,1418083200"; d="scan'208,217";a="120275338" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP; 04 Feb 2015 00:20:57 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t140KvWi017171 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Feb 2015 00:20:57 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 18:20:57 -0600 From: "Ken Gray (kegray)" To: "Zarny, Myo" , "'Cathy Zhang'" , "'Srini Addepalli'" , "Reinaldo Penno (repenno)" , "'Joel M. Halpern'" , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZx/9uiAgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgCAAEtwAIBWb4+AgAdtFgCAAJLygIAACR6A///L/gA= Date: Wed, 4 Feb 2015 00:20:56 +0000 Message-ID: References: <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.23.212] Content-Type: multipart/alternative; boundary="_000_D0F6CD2883CD0kegrayciscocom_" MIME-Version: 1.0 Archived-At: Cc: "'nsmurthy@freescale.com'" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 04 Feb 2015 00:21:06 -0000 --_000_D0F6CD2883CD0kegrayciscocom_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 UmVzcGVjdGZ1bGx5LCBJIGRvbqGvdCB0aGluayBUTFZzIHdlcmUgYSB1bmlxdWUgcHJvcG9zaXRp b24sIGFzIHRoZXNlIHdlcmUgZGlzY3Vzc2VkIGluZm9ybWFsbHkgaW4gbWVldGluZ3MgKHRoYXQg SSBkaWQgYXR0ZW5kKSChpiBoYXZlIHRvIHNlYXJjaCB0aGUgbGlzdCBmb3IgobBUTFahsSB1bmlx dWVuZXNzLiAgUmVnYXJkbGVzcywgd2Ugc2hvdWxkbqGvdCBoYXZlIGhhZCB0byByZWFkIHRocmVl IGl0ZXJhdGlvbnMgb2YgYW5vdGhlciBkb2N1bWVudCBqdXN0IHRvIGdldCB0aGF0IGFkZGl0aW9u Lg0KDQpSZWdhcmRpbmcgcmVtYWluaW5nIGRpZmZlcmVuY2VzIKGmIEkgZG9uoa90IHJlYWxseSBz ZWUgYW55LCB3aGljaCBtYWtlcyChsG1lcmdlobEgYSByZWFsbHkgaW5hcHByb3ByaWF0ZSB3b3Jk IGZvciB3aGF0oa9zIHJlcXVpcmVkLg0KDQpJZiChsG1lcmdlobEgbWVhbnMgobB0aW1lobEsIEkg c2VlIG5vIHJlYXNvbiB0byBkZWxheSBhIGNhbGwgZm9yIHN1cHBvcnQgb2YgdGhlIG5zaCBkcmFm dC4NCg0KT24gMi8zLzE1LCA1OjI3IFBNLCAiWmFybnksIE15byIgPE15by5aYXJueUBncy5jb208 bWFpbHRvOk15by5aYXJueUBncy5jb20+PiB3cm90ZToNCg0KSGkgS2VuLA0KDQogICogICBJRVRG OTAgbWludXRlcyBleHBsYWluIHRoZSBkaWZmZXJlbmNlcyB0aGVuLg0KDQogICogICBZZXMsIHRo ZSBkcmFmdHMgYXJlIG5vdyB2ZXJ5IHNpbWlsYXIgYmVjYXVzZSB0aGUgTlNIIGRyYWZ0IGhhcyBp bmNvcnBvcmF0ZWQgdGhlIFRMViBwb3J0aW9uLg0KICAqICAgVGhlIGdlbmVyaWMgY29udGV4dCBi bG9jayBpcyB0byBhY2NvbW1vZGF0ZSBOU0gncyBmb3VyIG1hbmRhdG9yeSBjb250ZXh0IGhlYWRl ciBmaWVsZHMuDQoNCiAgKiAgIFRoZSBjaGFpcnMgYXJlIGFjdGl2ZWx5IHdvcmtpbmcgb24gYSBt ZXJnZWQgZG9jdW1lbnQgd2l0aCBhIHNlY3Rpb24gZm9yIHJlbWFpbmluZyBkaWZmZXJlbmNlcy4N Cg0KVGhhbmtzLA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogc2ZjIFttYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDYXRoeSBaaGFuZw0KU2VudDog MyBGZWJydWFyeSAyMDE1IDQ6NTQgUE0NClRvOiBLZW4gR3JheSAoa2VncmF5KTsgU3JpbmkgQWRk ZXBhbGxpOyBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4gSGFscGVybjsgJ3NmY0Bp ZXRmLm9yZzxtYWlsdG86J3NmY0BpZXRmLm9yZz4nOyBDYXRoeSBaaGFuZw0KQ2M6IG5zbXVydGh5 QGZyZWVzY2FsZS5jb208bWFpbHRvOm5zbXVydGh5QGZyZWVzY2FsZS5jb20+DQpTdWJqZWN0OiBS ZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCg0KSGkgS2VuLA0KDQpQbGVhc2Ugc2VlIGlubGlu ZS4NCg0KVGhhbmtzLA0KQ2F0aHkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IEtlbiBHcmF5IChrZWdyYXkpIFttYWlsdG86a2VncmF5QGNpc2NvLmNvbV0NClNlbnQ6IFR1ZXNk YXksIEZlYnJ1YXJ5IDAzLCAyMDE1IDEwOjA5IEFNDQpUbzogQ2F0aHkgWmhhbmc7IFNyaW5pIEFk ZGVwYWxsaTsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBKb2VsIE0uIEhhbHBlcm47ICdzZmNA aWV0Zi5vcmc8bWFpbHRvOidzZmNAaWV0Zi5vcmc+Jw0KQ2M6IG5zbXVydGh5QGZyZWVzY2FsZS5j b208bWFpbHRvOm5zbXVydGh5QGZyZWVzY2FsZS5jb20+DQpTdWJqZWN0OiBSZTogW3NmY10gQ29t bWVudHMgb24gU0NIIERyYWZ0IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhh bmctc2ZjLXNjaC0wMikNCg0KQXMgYSBnZW5lcmFsIGNvbW1lbnQgb24gdGhpcyBzdWJtaXNzaW9u IChhbmQgcGVyaGFwcyBsaWZlIGluIHRoZSBjdXJyZW50IElFVEYpLiAgSSBoYXZlIGEgUkVBTExZ IGhhcmQgdGltZSBkaWZmZXJlbnRpYXRpbmcgdGhpcyBkcmFmdCBmcm9tIHRoZSBxdWlubiBkcmFm dCAod2hpY2ggcHJlLWRhdGVzIGl0IGJ5IHF1aXRlIGEgYml0KS4gIFdoeSBhcmUgd2UgcHVyc3Vp bmcgYSBzZXBhcmF0ZSBkcmFmdCB3aGVuIHRoZSBzdWdnZXN0aW9ucywgSU1ITywgc2VlbSBpbmNy ZW1lbnRhbCBhdCBiZXN0Pw0KDQoNCkNhdGh5PiBUaGUgb3JpZ2luYWwgbW90aXZhdGlvbiBmb3Ig ZHJhZnRpbmcgdGhlIFNDSCBpcyB0byBwcm92aWRlIGFuIGFsdGVybmF0aXZlIHRvIGRyYWZ0LXF1 aW5uLW5zaCB0byBhZGRyZXNzIHRoZSBmb2xsb3dpbmcgcGVyY2VpdmVkIGlzc3VlczoNCjEuIE1h bmRhdG9yeSBmaXhlZC1zaXplZCBtZXRhZGF0YS4gV2UgdGhpbmsgdGhleSBzaG91bGQgbm90IGJl IG1hbmRhdG9yeSBzaW5jZSB0aGUgNC13b3JkIGNvbnRleHQgZmllbGRzIGFyZSBub3QgbmVlZGVk IGluIG1hbnkgc2NlbmFyaW9zIDIuIE5vIHZhcmlhYmxlIGxlbmd0aCBtZXRhZGF0YS4gV2UgdGhp bmsgbWV0YWRhdGEgc2hvdWxkIGJlIG9wdGlvbmFsIGFuZCBUTFYgZm9ybWF0IHNob3VsZCBiZSB1 c2VkIHRvIGRlZmluZSBtZXRhZGF0YSAzLiBObyBvcmdhbml6YXRpb25hbGx5IGRlZmluZWQgbWV0 YWRhdGEgNC4gTm8gVmVyc2lvbiBmaWVsZC4NCldoZW4gd2UgdXBsb2FkZWQgU0NIIDFzdCB2ZXJz aW9uICgzLzI0LzIwMTQpLCBOU0ggdmVyc2lvbiBkaWQgbm90IGhhdmUgdGhlIFRMViBtZXRhZGF0 YSBhbmQgdmVyc2lvbiBmaWVsZCAodGhleSB3ZXJlIGFkZGVkIGluIGl0cyBsYXRlciB2ZXJzaW9u KS4NCg0KDQoNCkkgaGF2ZSByZWFjaCBvdXQgdG8gdGhlIGNoYWlycyBoZXJlIC4gd2UgaGF2ZSBh IGxvdCB0byByZWFkLiBBcmVuJ3QgZHJhZnRzIHN1cHBvc2VkIHRvIG9mZmVyIHNpZ25pZmljYW50 bHkgZGlmZmVyZW50IHZpZXdzIGlmIHRoZXkgYXJlIHRvIHBlcnNpc3QgKHdpdGhvdXQgdGhhdCwg YSAiY2FsbCB0byBhZG9wdCIgYmVjb21lcyBhIGJlYXV0eSBjb250ZXN0LCBJTU8pPyAgTm8gb2Zm ZW5zZSB0byB0aGUgYXV0aG9ycywgYnV0IHdlJ3JlIGluIHJldmlzaW9uIDMgYW5kIEkgZG9uJ3Qg c2VlIHRoYXQgaGVyZS4NCg0KDQpSZWdhcmRpbmcgdGhlIGNoYW5nZXMgaW4gdGhpcyBkb2N1bWVu dDoNCg0KSSBkbyBub3QgZmluZCB0aGUgZmxvdyBJRCBmdW5jdGlvbmFsbHkgZGlmZmVyZW50IHRo YW4gdGhlIHVzZSBjb250ZXh0IGhlYWRlcnMgaW4gdGhlIG5zaCBkcmFmdCwgd2hpY2ggc2VlbSB0 byBiZSBhIG1vcmUgbXVsdGktcHVycG9zZSBjb25jZXB0Lg0KDQpDYXRoeT4gRGlmZmVyZW50IHBl b3BsZSBoYXZlIGRpZmZlcmVudCB2aWV3cG9pbnRzLiBSU1AgSUQgaXMgbm90IGRlZmluZWQgaW4g TlNIIGFuZCBmcm9tIFBhdWwgKE5TSCBhdXRob3IpJ3MgcmVwbHksIGl0IHNlZW1zIGhlIGRvZXMg bm90IGZlZWwgdGhlIG5lZWQgb2YgYW4gUlNQIElELg0KQ2F0aHk+IFdlIHNlZSB0aGUgbmVlZCBm b3IgUlNQIElEIGFuZCB0aHVzIGRlZmluZWQgaXQgaW4gU0NIIGZvciBvcGVuIGRpc2N1c3Npb24g YW5kIHdvdWxkIGxpa2UgdG8gc2VlIHRoZSBjb21tdW5pdHkncyBmZWVkYmFjayBvbiBpdC4NCg0K VGhlIEIgYml0IHN1Z2dlc3Rpb24gY2FuIGNhdXNlIGEgY29uZmxpY3QgaW4gY29udHJvbCBhbmQg Y3JlYXRlIGFuIGF2ZW51ZSBmb3IgdW5kZXNpcmFibGUgYmVoYXZpb3IsIElNTy4gIEkndmUgYmVl biB3b3JraW5nIGZyb20gdGhlIGFzc3VtcHRpb24gdGhhdCBhIG1pbmltdW0gcmVxdWlyZW1lbnQg b2YgYSBmdW5jdGlvbiBpcyB0aGF0IGl0IGJlIG1hbmFnZWFibGUgKGlmIGZvciBubyBvdGhlciBy ZWFzb24gdGhhbiBlZmZlY3RpdmUgZWxhc3RpY2l0eSBhbmQgY29oZXNpdmUvcHJlZGljdGFibGUg ZGVsaXZlcnkgb2Ygc2VydmljZSksIHNvIEkgaGF2ZSBsaXR0bGUgc3ltcGF0aHkgZm9yIHRob3Nl IHRoYXQgYXJlIG5vdCAtIGJlIHRoZXkgdmlydHVhbCBvciBwaHlzaWNhbCAoZXZlbiBsZXNzIHN5 bXBhdGh5IGZvciB2aXJ0dWFsIGZ1bmN0aW9ucyB0aGF0IGFyZSB1bm1hbmFnZWFibGUsIGZyYW5r bHkpLiAgQSBzZWxmLW1hbmFnZW1lbnQgb3B0aW9uIGluIHRoZSBTRkMgc2NlbmFyaW8gaGFzIGxv dyB2YWx1ZSBhbmQgdGhlIGNvcnJ1cHRpb24gb3IgbWlzdXNlIG9mIHRoZSBiaXQgY2FuIGNhdXNl IGNoYW9zIChhbiBleHRyYSBsZXZlbCBvZiAiZmFpbCIpLg0KDQpDYXRoeT4gQ291bGQgeW91IGNs YXJpZnkgd2hhdCB5b3UgbWVhbiBieSAiY2F1c2UgYSBjb25mbGljdCBpbiBjb250cm9sIj8NCg0K DQpUaGUgR2VuZXJpYyBDb250ZXh0IEJsb2NrIGlzIGNvbmZ1c2luZyBpbiBsaWdodCBvZiB0aGUg YWxyZWFkeSBleHRhbnQgb3B0aW9uYWwvdmFyaWFibGUgbWV0YWRhdGEgVExWcyAod2h5IHdvdWxk bid0IHlvdSBsZXZlcmFnZSBvbmUgb2YgdGhlbSk/DQoNCkNhdGh5PiBJIGFtIG5vdCBzdXJlIGlm IEkgdW5kZXJzdGFuZCB5b3VyIHBvaW50LiBUaGUgR2VuZXJpYyBDb250ZXh0IEJsb2NrIGlzIG9u ZSB0eXBlIG9mIG1ldGFkYXRhIHdoaWNoIGlzIGluIFRMViBmb3JtYXQgYW5kIGlzIG9wdGlvbmFs Lg0KDQpUaGFua3MsDQpDYXRoeQ0KDQoNCk9uIDEvMjkvMTUsIDI6NDQgUE0sICJDYXRoeSBaaGFu ZyIgPENhdGh5LkguWmhhbmdAaHVhd2VpLmNvbTxtYWlsdG86Q2F0aHkuSC5aaGFuZ0BodWF3ZWku Y29tPj4gd3JvdGU6DQoNCj5IaSBldmVyeW9uZSwNCj4NCj5XZSBoYXZlIHVwbG9hZGVkIGEgbmV3 IFNDSCB2ZXJzaW9uICgzKSB3aGljaCBhZGRzIGRlZmluaXRpb24gb2YgYSBuZXcNCj5tZXRhZGF0 YSB0eXBlIGZvciB0aGUgZmxvdyBJRCB0byBzdXBwb3J0IGxvYWQgYmFsYW5jaW5nIGFtb25nIFNG DQo+aW5zdGFuY2VzIGFuZCBtaXRpZ2F0ZSB0aGUgcG90ZW50aWFsIGlzc3VlIG9mICJub3QgZW5v dWdoIHBhdGggSUQiLiBUaGUNCj5mbG93IElEIGlzIG5hbWVkICJyZW5kZXJlZCBzZXJ2aWNlIHBh dGggSUQiIGluIHRoZSBkcmFmdC4gUGxlYXNlIHJlZmVyDQo+dG8gc2VjdGlvbiA0LjMuMiBvZg0K Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXpoYW5nLXNmYy1zY2gvDQo+ Zm9yIGRldGFpbCBkZXNjcmlwdGlvbi4NCj4NCj4NCj5JbiBpdHMgcHJldmlvdXMgdmVyc2lvbiwg U0NIIGRlZmluZXMgYSAiQnlwYXNzIGJpdCIgaW4gdGhlIGJhc2UgaGVhZGVyLg0KPlRoaXMgYml0 IGVuYWJsZXMgdGhlIFNGIHRvIHByb3ZpZGUgZmVlZGJhY2svbm90aWZpY2F0aW9uIHZpYSB0aGUg ZGF0YQ0KPnBhdGggdG8gaXRzIGNvbm5lY3RpbmcgU0ZGIGFib3V0IHdoZXRoZXIgdGhlIHJlbWFp bmluZyBwYWNrZXRzIG9mIHRoZQ0KPlNGQyBzaG91bGQgYnlwYXNzIHRoYXQgU0YuIFRoaXMgaXMg dXNlZnVsIGluIHRoZSBjYXNlIHRoYXQgb25seSB0aGUNCj5maXJzdCBmZXcgcGFja2V0cyBvZiBh IGZsb3cgbmVlZCB0byBnbyB0byBhIFNGIChzdWNoIGFzIGEgRFBJIG9yIEZXIG9yDQo+SURTKSBh bmQgcmVtYWluaW5nIHBhY2tldHMgY2FuIGJ5cGFzcyB0aGF0IFNGLCB0aHVzIHNhdmluZyB0aGUN Cj5leHBlbnNpdmUgU0YgcmVzb3VyY2UgYW5kIHJlZHVjaW5nIGRhdGEgcGF0aCBsYXRlbmN5Lg0K Pg0KPkIgYml0OiBUaGUgQiAoQnlwYXNzKSBiaXQsIHdoZW4gc2V0IHRvIDEsIGl0IGlzIHVzZWQg YnkgYSBTZXJ2aWNlDQo+ICAgICAgIEZ1bmN0aW9uIHRvIHNpZ25hbCB0byBpdHMgU2VydmljZSBG dW5jdGlvbiBGb3J3YXJkZXIgdGhhdCBubw0KPiAgICAgICBmdXJ0aGVyIHBhY2tldHMgYXJlIHRv IGJlIHNlbnQgdG8gaXQgZm9yIHRoZSBmbG93IHNwZWNpZmllZCBpbg0KPmVuY2Fwc3VsYXRlZCBw YWNrZXQuDQo+DQo+SW4gYWRkaXRpb24sIFNDSCBkZWZpbmVzIGEgbWV0YWRhdGEgdHlwZSBmb3Ig R2VuZXJpYyBDb250ZXh0IEJsb2NrLA0KPndoaWNoIGlzIG9wdGlvbmFsIGFuZCBjYW4gYmUgdXNl ZCBpZiBuZWVkZWQgdG8gY2FycnkgYW55IHZlbmRvcidzDQo+c3BlY2lmaWMgIkNvbnRleHQgSGVh ZGVyIi4NCj4NCj4NCj5BbnkgY29tbWVudHMgb24gdGhlc2UgbmV3IGFkZGl0aW9ucz8NCj4NCj5U aGFua3MsDQo+Q2F0aHkNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHNm YyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2F0aHkgWmhhbmcN Cj5TZW50OiBGcmlkYXksIERlY2VtYmVyIDA1LCAyMDE0IDExOjQ3IEFNDQo+VG86IFNyaW5pIEFk ZGVwYWxsaTsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBKb2VsIE0uIEhhbHBlcm47DQo+J3Nm Y0BpZXRmLm9yZzxtYWlsdG86J3NmY0BpZXRmLm9yZz4nDQo+Q2M6IG5zbXVydGh5QGZyZWVzY2Fs ZS5jb208bWFpbHRvOm5zbXVydGh5QGZyZWVzY2FsZS5jb20+DQo+U3ViamVjdDogUmU6IFtzZmNd IENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtemhhbmctc2ZjLXNjaC0wMikNCj4NCj5Sb24sIExvdWlzLCBNeW8gYW5kIEkgaGF2ZSBiZWVu IGRpc2N1c3Npbmcgb2ZmIGxpbmUgbGFzdCBmZXcgd2Vla3MNCj5hYm91dCBkZWZpbmluZyBhIG1l dGFkYXRhIHR5cGUgZm9yIGZsb3cgSUQgaW4gYWRkaXRpb24gdG8gdGhlIHBhdGggSUQNCj5vZiB0 aGUgbWFpbiBoZWFkZXIgdG8gc3VwcG9ydCBsb2FkIGJhbGFuY2luZyBhbW9uZyBTRiBpbnN0YW5j ZXMuIFdlDQo+d2lsbCBkZWZpbmUgYSBUTFYgdHlwZSBmb3IgdGhlIGZsb3cgSUQuIFRoZSBjb21i aW5hdGlvbiBvZiAicGF0aCBJRCArIGZsb3cgSUQiDQo+c3BlY2lmaWVzIGEgcmVhbGl6ZWQgc2Vy dmljZSBjaGFpbiBpbnN0YW5jZSBwYXRoLiBJdCBpcyBsZWZ0IHRvIHRoZQ0KPmRlc2lnbi9pbXBs ZW1lbnRhdGlvbiB3aGV0aGVyIHRvIHVzZSBhIGNlbnRyYWxpemVkIG1ldGhvZCBvciBhDQo+ZGlz dHJpYnV0ZWQgbWV0aG9kIHRvIGJpbmQgdGhlIGZsb3cgSUQgdG8gYSByZWFsaXplZCBzZXJ2aWNl IGluc3RhbmNlDQo+cGF0aCBhbHRob3VnaCBvdXIgb3JpZ2luYWwgdGhvdWdodCBpcyBmb3IgZGlz dHJpYnV0ZWQgTEIgdXNhZ2UuIEkgYW0NCj5ub3Qgc3VyZSBpZiB3ZSBuZWVkIGEgYml0IGluIHRo ZSBoZWFkZXIgdG8gZGVub3RlIHdoZXRoZXIgdGhlcmUgYXJlDQo+bW9yZSBwYXRoIElEIGJpdHMg KHdlIGNhbGwgaXQgZmxvdyBJRCkgaW4gdGhlIG1ldGFkYXRhIGZpZWxkcyBzaW5jZQ0KPndoZW4g eW91IHBhcnNlIHRoZSBUTFYgbWV0YWRhdGEsIHlvdSB3aWxsIGtub3cgd2hldGhlciB0aGVyZSBh cmUgZmxvdyBJRCBiaXRzIG9yIG5vdC4NCj5Ob3RlIHRoYXQgaWYgbXVsdGlwbGUgc2Vzc2lvbnMg c2hhcmUgdGhlIHNhbWUgcmVhbGl6ZWQgc2VydmljZSBpbnN0YW5jZQ0KPnBhdGgsIHRoZXkgd2ls bCBzaGFyZSB0aGUgc2FtZSAicGF0aCBJRCsgZmxvdyBJRCIuICBXZSBjYW4gYWxzbw0KPmNvbnNp ZGVyIGV4dGVuZGluZyB0aGUgbnVtYmVyIG9mIGJpdHMgdG8gMzIgaWYgdGhhdCBpcyB0aGUgY29u c2Vuc3VzLg0KPldlIHdpbGwgcG9zdCBhbiB1cGRhdGVkIGRyYWZ0IGRlc2NyaWJpbmcgdGhlc2Ug c29vbi4NCj4NCj5UaGFua3MsDQo+Q2F0aHkNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg U3JpbmkgQWRkZXBhbGxpDQo+U2VudDogRnJpZGF5LCBEZWNlbWJlciAwNSwgMjAxNCA3OjE3IEFN DQo+VG86IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgSm9lbCBNLiBIYWxwZXJuOyAnc2ZjQGll dGYub3JnPG1haWx0bzonc2ZjQGlldGYub3JnPicNCj5DYzogbnNtdXJ0aHlAZnJlZXNjYWxlLmNv bTxtYWlsdG86bnNtdXJ0aHlAZnJlZXNjYWxlLmNvbT4NCj5TdWJqZWN0OiBSZTogW3NmY10gQ29t bWVudHMgb24gU0NIIERyYWZ0DQo+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16 aGFuZy1zZmMtc2NoLTAyKQ0KPg0KPg0KPltSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5Lg0KPg0K PlNSSU5JPiBJIGFtIG5vdCBzbyBzdXJlIGFib3V0IGRhdGEgcGxhbmUgZWZmaWNpZW5jeS4gIE1v c3Qgb2YgdGhlDQo+cHJvY2Vzc29ycyB3b3JrIGdvb2QgaWYgdGhlIG51bWJlciBvZiBiaXRzIGFy ZSBlaXRoZXIgMzIgb3IgNjQuICBJZiBpdA0KPmlzDQo+MjQgYml0cywgdGhlbiBvbmUgbmVlZHMg dG8gZG8gbWFza2luZyBhbmQgc2hpZnRpbmcgYmVmb3JlIHRoZSB2YWx1ZSBpcw0KPnVzZWQgdG8g ZG8gYW55IGxvb2t1cC4gICBCdXQsIHRoaXMgZGlzY3Vzc2lvbiBjYW4gZ28gaW50byBkaWZmZXJl bnQNCj5kaXJlY3Rpb24gOi0pLCBpdCBtYXkgbm90IGJlIGdvb2QgdG8gZ28gaW4gdGhhdCBkaXJl Y3Rpb24uDQo+DQo+V2hlcmUgZG8gd2UgZHJhdyB0aGUgbGluZT8gMzItYml0cywgNjQtYml0cywN Cj4xMjggYml0cz8gSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRo ZSBTZXJ2aWNlIFBhdGgNCj5oZWFkZXIgYW5kIGlmIHlvdSBuZWVkIHRvIGNvbnZleSBtb3JlIGJp dHMgeW91IG5lZWQgdG8gdXNlIHRoZSBjb250ZXh0DQo+aGVhZGVycy4NCj4NCj5TUklOST4gVGhp cyBpcyBhIGdvb2QgcG9pbnQuICBUaGlzIHNob3VsZCB3b3JrIGZpbmUgYXMgbG9uZyBhcyB0aGVy ZSBpcw0KPndheSB0byBjb252ZXkgaW4gdGhlIG1haW4gaGVhZGVyIHRoYXQgdGhlIGV4dGVuc2lv biB0byBwYXRoIElEIGlzDQo+YXZhaWxhYmxlIGluIHNvIGFuZCBzbyBUTFYgZmllbGQuICBUaGF0 IHNob3VsZCB3b3JrIHRvby4NCj4NCj5UaGFua3MNCj5TcmluaQ0KPg0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj5Gcm9tOiBSZWluYWxkbyBQZW5ubyAocmVwZW5u bykgPHJlcGVubm9AY2lzY28uY29tPG1haWx0bzpyZXBlbm5vQGNpc2NvLmNvbT4+DQo+U2VudDog RnJpZGF5LCBEZWNlbWJlciA1LCAyMDE0IDc6MDggQU0NCj5UbzogQWRkZXBhbGxpIFNyaW5pLUIy MjE2MDsgSm9lbCBNLiBIYWxwZXJuOyAnc2ZjQGlldGYub3JnPG1haWx0bzonc2ZjQGlldGYub3Jn PicNCj5DYzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDANCj5TdWJqZWN0OiBSZTogW3NmY10g Q29tbWVudHMgb24gU0NIIERyYWZ0DQo+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC16aGFuZy1zZmMtc2NoLTAyKQ0KPg0KPk9uIDEyLzUvMTQsIDY6NTQgQU0sICJTcmluaSBBZGRl cGFsbGkiIDxzYWRkZXBhbGxpQGZyZWVzY2FsZS5jb208bWFpbHRvOnNhZGRlcGFsbGlAZnJlZXNj YWxlLmNvbT4+IHdyb3RlOg0KPg0KPj4NCj4+SW4gcmVhbCBkZXBsb3ltZW50cywgbnVtYmVyIG9m IGFjdGl2ZSBwYXRoIElEcyBhcmUgdmVyeSBsZXNzZXIgdGhhbg0KPj4yXjY0LCBidXQgdGhlcmUg aXMgYSBnb29kIHBvc3NpYmlsaXR5IG9mIHRoZSBudW1iZXIgYmVpbmcgbW9yZSB0aGFuIDJeMjQg KDE2TSkuDQo+PiBJIHRoaW5rIGJpZ2dlciBwb2ludCBpcyB0aGF0IHdoeSByZXN0cmljdCB0aGlz IGluIHRoZSBzdGFuZGFyZHM/IFdoYXQNCj4+YWR2YW50YWdlIGRvIHdlIGhhdmUgcmVzdHJpY3Rp bmcgdGhpcyBzaXplIHRvIDI0IGJpdHM/DQo+DQo+W1JQXSBEYXRhIHBsYW5lIGVmZmljaWVuY3ku IFdoZXJlIGRvIHdlIGRyYXcgdGhlIGxpbmU/IDMyLWJpdHMsDQo+NjQtYml0cywNCj4xMjggYml0 cz8gSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRoZSBTZXJ2aWNl IFBhdGgNCj5oZWFkZXIgYW5kIGlmIHlvdSBuZWVkIHRvIGNvbnZleSBtb3JlIGJpdHMgeW91IG5l ZWQgdG8gdXNlIHRoZSBjb250ZXh0DQo+aGVhZGVycy4NCj4NCj4NCj4+DQo+PlRoZXJlIGNhbiBi ZSBkZXBsb3ltZW50cywgd2hlcmUgU0ZDIGNvbnRyb2xsZXIgKExvZ2ljYWxseSBjZW50cmFsLCBi dXQNCj4+ZGlzdHJpYnV0ZWQpICBpdHNlbGYgY2FuIGRvIHRoZSBTRiBpbnN0YW5jZSBzZWxlY3Rp b24gb24gcGVyDQo+PmNvbm5lY3Rpb24vc2Vzc2lvbiBiYXNpcywgdGhlcmVieSBhdm9pZGluZyB0 aGUgTEJzIGZvciBzZXJ2aWNlcy4gICBJbiBteQ0KPj52aWV3LCBhc3N1bXB0aW9uIHRoYXQgdGhl cmUgd2lsbCBiZSBMQiBTRiBmb3IgZWFjaCBzY2FsZS1vdXQgc2VydmljZQ0KPj5pbiB0aGUgY2hh aW4gaXMgbm90IHZhbGlkIGluIGFsbCBjYXNlcy4NCj4+DQo+PlRoYW5rcw0KPj5TcmluaQ0KPj4N Cj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5Gcm9tOiBSZWlu YWxkbyBQZW5ubyAocmVwZW5ubykgPHJlcGVubm9AY2lzY28uY29tPG1haWx0bzpyZXBlbm5vQGNp c2NvLmNvbT4+DQo+PlNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciA0LCAyMDE0IDE6MTcgUE0NCj4+ VG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IEpvZWwgTS4gSGFscGVybjsgc2ZjQGlldGYub3Jn PG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+PkNjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0K Pj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+PihodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4+DQo+PklmIEkgdW5k ZXJzdG9vZCB5b3UsIEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgcmVhbGlzdGljLiBBcmUgeW91IHNh eWluZw0KPj55b3UgbmVlZCA2NC1iaXRzIG9mIHBhdGhzIGFuZCB0aGVuIHdpbGwgbW9uaXRvciB0 aGVtIGFsbD8gRG8gZmF1bHQNCj4+dG9sZXJhbmNlIGFuZCBPQU0gZm9yIDJeNjQtYml0cyB3b3J0 aCBvZiBwYXRocz8gSnVzdCBmb3IgY29tcGFyaXNvbiwNCj4+aXSp9nMgbGlrZSBtYW5hZ2luZyBh bmQgbW9uaXRvcmluZyB0aGUgZW50aXJlIElQdjYgaG9zdCByYW5nZSwgb25lLWJ5LW9uZS4NCj4+ DQo+PkFueXdheSwgSSBkbyBub3QgZXhwZWN0IGV2ZXJ5IHNpbmdsZSBwZXJtdXRhdGlvbnMgdG8g YmUgYSBkaWZmZXJlbnQgcGF0aC4NCj4+DQo+PklmIGVhY2ggc2VydmljZSBoYXMgMjU2IGRldmlj ZXMgcHJvdmlkaW5nIHNpbWlsYXIgc2VydmljZSwgeW91IHNob3VsZA0KPj5tb3N0IGxpa2VseSB1 c2UgbG9hZC1iYWxhbmNpbmcgYW5kIHRoZW4geW91IHdvdWxkIGhhdmUgYSBzaW5nbGUgKG9yIGEN Cj4+ZmV3KSBwYXRocy4gVGhlcmUgaXMgc29tZSBkaXNjdXNzaW9uIGdvaW5nIG9uIExCLg0KPj4N Cj4+RnJvbSBhIGRhdGEgcGxhbmUgcGVyc3BlY3RpdmUsIHRoZSBwYXRoIGlzIHVsdGltYXRlbHkg ZGVmaW5lZCBieSB0aGUNCj4+U0ZGcyB0cmF2ZXJzZWQgYW5kIHNlcnZpY2VzIHByb3ZpZGVkLCBu b3QgYnkgYSBzcGVjaWZpYyBJUDpwb3J0IHRoYXQNCj4+dGhlIGRldmljZSBwcm92aWRpbmcgdGhl IHNlcnZpY2Ugc2l0cyBvbi4gV2VsbCwgYXQgbGVhc3QgZnJvbSBhDQo+PkdQRStOU0ggcGVyc3Bl Y3RpdmUuDQo+Pg0KPj4NCj4+T24gMTIvNC8xNCwgMTI6NTcgUE0sICJTcmluaSBBZGRlcGFsbGki IDxzYWRkZXBhbGxpQGZyZWVzY2FsZS5jb208bWFpbHRvOnNhZGRlcGFsbGlAZnJlZXNjYWxlLmNv bT4+IHdyb3RlOg0KPj4NCj4+PklmIEkgdGFrZSBhIGNoYWluIHdpdGggNSBzZXJ2aWNlcyB3aXRo IGVhY2ggc2VydmljZSAgc2F5IGhhdmluZyAyNTYNCj4+Pmluc3RhbmNlcyBmb3Igc2NhbGUtb3V0 LCBwb3NzaWJsZSBudW1iZXIgb2YgcGF0aHMgYXJlDQo+Pj4yNTYqMjU2KjI1NioyNTYqMjU2DQo+ Pj49IDB4RkYgRkYgRkYgRkYgRkYuIE9uZSByZXF1aXJlcyAzMyBiaXRzIGluIHRoaXMgY2FzZS4g IElmIHRoZXJlIGFyZQ0KPj4+bW9yZSBzZXJ2aWNlcyBpbiB0aGUgY2hhaW4gb3IgbW9yZSBjaGFp bnMgb3IgbW9yZSBpbnN0YW5jZXMgZm9yDQo+Pj5zY2FsZS1vdXQsIHRoZW4gaXQgY291bGQgZ28g dG8gYmlnIG51bWJlciB2ZXJ5IGZhc3QuDQo+Pj4NCj4+PkFzIEkgbWVudGlvbmVkIG15IHByZWZl cmVuY2UgaXMgdG8gbWFrZSB0aGUgcGF0aCBJRCBzaXplIGZsZXhpYmxlIGZvcg0KPj4+ZnV0dXJl IGdyb3d0aC4gSWYgdGhhdCBpcyBwZXJjZWl2ZWQgYXMgY29tcGxleCwgdGhlbiBnb2luZyBmb3Ig NjRiaXQNCj4+PmlzIHNhZmVyIGJldC4NCj4+Pg0KPj4+VGhhbmtzDQo+Pj5TcmluaQ0KPj4+DQo+ Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBKb2VsIE0uIEhhbHBl cm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPj4+U2VudDogVGh1cnNkYXksIERlY2Vt YmVyIDA0LCAyMDE0IDEyOjA1IFBNDQo+Pj5UbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2MDsgSm9l bCBNLiBIYWxwZXJuOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+PkNjOiBO UyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPj4+U3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRz IG9uIFNDSCBEcmFmdA0KPj4+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFu Zy1zZmMtc2NoLTAyKQ0KPj4+DQo+Pj5BIGNvbnRyb2xsZXIgKG9yIG90aGVyIGRlY2lzaW9uIGxv Z2ljKSBjYW4gY2VydGFpbmx5IGJlIGF3YXJlIG9mIHN1Y2gNCj4+PmNvbmNlcm5zLg0KPj4+QnV0 IHRoZSBudW1iZXIgb2Ygc2VydmljZSBmdW5jdGlvbiBwYXRocyBpcyBub3QgcmVsYXRlZCB0byB0 aGUgbnVtYmVyDQo+Pj5vZiBmbG93cyBvciB0aGUgbnVtYmVyIG9mIHRlbmFudHMuICBJdCBpcyBy ZWxhdGVkIHRvIHRoZSBudW1iZXIgb2YNCj4+PmNvbWJpbmF0aW9ucyBvZiBzZXJ2aWNlcyBhbmQg dGhlIHBvbGljaWVzIGZvciBzZXJ2aWNlIGZ1bmN0aW9uDQo+Pj5zZWxlY3Rpb24uDQo+Pj4gV2hp bGUgdGhhdCBjYW4gYmUgYSBsYXJnZSBudW1iZXIsIEkgc3VyZSBob3BlIGl0IGRvZXMgbm90IGNv bWUgY2xvc2UNCj4+PnRvIHNhdHVyYXRpbmcgMjQgYml0cy4NCj4+Pg0KPj4+SGF2aW5nIHNhaWQg dGhhdCwgaWYgd2UgdGhpbmsgdGhhdCAyNCBiaXRzIGlzIG9ubHkganVzdCBlbm91Z2gsIHRoZW4N Cj4+PndlIG91Z2h0IHRvIHVzZSAzMi4gIEZyb20gd2hlcmUgSSBzaXQsIEkgd291bGQgbm9ybWFs bHkgZXhwZWN0IDE2DQo+Pj5iaXRzIHRvIGJlIG1vcmUgdGhhbiBzdWZmaWNpZW50LCB3aGljaCBp cyB3aHkgSSBhbSBjb21mb3J0YWJsZSB3aXRoDQo+Pj4yNC4gIEhhdmluZyBzYWlkIHRoYXQsIHRo ZSBmaWVsZCBzaXplIGlzIG5vdCBhIGJpZyBkZWFsIHRvIG1lLg0KPj4+DQo+Pj5Zb3VycywNCj4+ PkpvZWwNCj4+Pg0KPj4+T24gMTIvNC8xNCwgMjowMSBQTSwgU3JpbmkgQWRkZXBhbGxpIHdyb3Rl Og0KPj4+Pg0KPj4+PiBJIHdhcyBub3QgaW1wbHlpbmcgdGhhdCBwYXRoIElEIHNob3VsZCBoYXZl IGluZm9ybWF0aW9uIGluIHJlZ2FyZHMNCj4+Pj50byB0ZW5hbnQvY29udHJvbGxlci9mbG93L3Nj YWxlLW91dC4gIEJ1dCBTRkMgY29udHJvbGxlcnMgc2hvdWxkDQo+Pj4+a2VlcCB0aGVzZQ0KPj4+ PmluIG1pbmQgdG8gYXNzaWduIHRoZSBwYXRoIElELiAgICBBIGRlcGxveW1lbnQgY2FuIGhhdmUg bXVsdGlwbGUNCj4+Pj50ZW5hbnRzLCBlYWNoIHRlbmFudCBjYW4gaGF2ZSBtdWx0aXBsZSBuZXR3 b3JrcywgIHRoZXJlIGNvdWxkIGJlDQo+Pj4+bWlsbGlvbnMgb2YgZmxvd3MgaW4gZWFjaCBvZiB0 aG9zZSBuZXR3b3Jrcy4gIEFuZCBjb25zaWRlcmluZyBhbGwNCj4+Pj50aGVzZSwNCj4+Pj4gMjQg Yml0IHBhdGggSUQgbWF5IG5vdCBiZSBhYmxlIHRvIHJlcHJlc2VudCBwYXRocyBmb3IgdGhlc2Ug Zmxvd3MuDQo+Pj4+SGVuY2UsIEkgd2FzIHdvbmRlcmluZyB3aGV0aGVyIHBhdGggSUQgY2FuIGJl IGV4dGVuZGVkIHRvIDY0IGJpdHMgb3INCj4+Pj5tYWtlIGl0IGZsZXhpYmxlLg0KPj4+Pg0KPj4+ PiBUaGFua3MNCj4+Pj4gU3JpbmkNCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+PiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gPGptaEBqb2VsaGFs cGVybi5jb208bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+Pg0KPj4+PiBTZW50OiBUaHVyc2Rh eSwgRGVjZW1iZXIgNCwgMjAxNCA3OjQyIEFNDQo+Pj4+IFRvOiBBZGRlcGFsbGkgU3JpbmktQjIy MTYwOyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+Pj4gQ2M6IE5TIFNyaW5p dmFzYSBNdXJ0aHktQjM3ODQwDQo+Pj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBT Q0ggRHJhZnQNCj4+Pj4gKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1z ZmMtc2NoLTAyKQ0KPj4+Pg0KPj4+PiBUaGUgSW5kZXggaXMgbm90IGp1c3QgZm9yIGxvb3AgcHJl dmVudGlvbi4gIEluIHRoZSBjYXNlIG9mDQo+Pj4+YW1iaWd1aXR5LCAgdGhlIGluZGV4IHRlbGxz IHRoZSBTRkYgd2hlcmUgaW4gdGhlIHBhdGggdGhlIHBhY2tldA0KPj4+PmN1cnJlbnRseSByZXNp ZGVzLg0KPj4+PiAgICBUaGVyZSBhcmUgbXVsdGlwbGUgd2F5cyBzdWNoIGFtYmlndWl0eSBjYW4g b2NjdXIuDQo+Pj4+DQo+Pj4+IFRoZSBQYXRoIElkZW50aWZpZXIgaXMgc3BlY2lmaWNhbGx5IG5v dCBleHBlY3RlZCB0byBpbmNsdWRlDQo+Pj4+IGNvbnRyb2xsZXIgSUQgb3IgVGVuYW50IElELiAg V2hpbGUgYSBkZXBsb3llciBjYW4gaGF2ZSBhIHBhdGggcGVyDQo+Pj4+IHRlbmFudCwgdGhlIGFy Y2hpdGVjdHVyZSBzdGlsbCBkb2VzIG5vdCB0cmVhdCB0aGUgcGF0aCBJRCBhcyBhDQo+Pj4+IHRl bmFudCBJRC4gIFRlbmFudCBJRCwgY29udHJvbGxlciBJRCwgYW5kIG90aGVyIG5vbi1wYXRoLXNw ZWNpZnlpbmcNCj4+Pj4gaW5mb3JtYXRpb24gaXMgdG8gYmUgY2FycmllZCBpbiBtZXRhZGF0YS4N Cj4+Pj4NCj4+Pj4gWW91cnMsDQo+Pj4+IEpvZWwNCj4+Pj4NCj4+Pj4gT24gMTIvNC8xNCwgMTA6 MDIgQU0sIFNyaW5pIEFkZGVwYWxsaSB3cm90ZToNCj4+Pj4+IFR3byBjb21tZW50cyA6DQo+Pj4+ Pg0KPj4+Pj4NCj4+Pj4+IDEuICBTRiBJbmRleCA6ICBTaW5jZSBpdCBpcyBtZWFudCBmb3IgbG9v cCBkZXRlY3Rpb24sICB3b3VsZG4ndA0KPj4+Pj4gYmV0dGVyIHRvIHJlbmFtZSB0aGlzIGFzICJU VEwiPw0KPj4+Pj4NCj4+Pj4+IDIuICBQYXRoIElkZW50aWZpZXIgOiAgICAyNCBiaXQgcGF0aCBp ZGVudGlmaWVyIHNlZW1zIHRvIGJlIHRvbyBsZXNzLg0KPj4+Pj4gQmFzZWQgb24gb3VyIGV4cGVy aWVuY2UgaW4gdHJhZmZpYyBzdGVlcmluZywgIHRoaXMgcGF0aCBpZGVudGlmaWVyDQo+Pj4+Pm5l ZWRzIHRvIGVuY29kZSBnb29kIGFtb3VudCBvZiBpbmZvcm1hdGlvbiB0byBtYWtlIGl0IHVuaXF1 ZS4gIEZvcg0KPj4+Pj5leGFtcGxlLA0KPj4+Pj4gICAgdGhpcyBpZGVudGlmaWVyIG5lZWRzIHRv IGVuY29kZSAoaW4gb3VyIGNhc2UpIHNvbWUgaW5mb3JtYXRpb24NCj4+Pj4+cmVwcmVzZW50aW5n IHRoZSBkaXN0cmlidXRlZCBjb250cm9sbGVyIElELCAgdGVuYW50IElELCAgZmxvdyBJRCwNCj4+ Pj4+ICAgIFNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2UgKGluIGNhc2Ugb2Ygc2NhbGUtb3V0KSBh bmQgZmV3IG1vcmUuLg0KPj4+Pj4gT25lIHN1Z2dlc3Rpb24gaXMgdG8gbWFrZSBpdCA2NCBiaXRz IHZhbHVlICBvciB0byBtYWtlIGl0IGV2ZW4NCj4+Pj4+ZXh0ZW5kYWJsZSwNCj4+Pj4+ICAgIGl0 IGlzIGdvb2QgaWYgcGF0aCBpZGVudGlmaWVyIGlzIGFsc28gcmVwcmVzZW50ZWQgaW4gVExWIGZv cm0uDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IFRoYW5rcw0KPj4+Pj4NCj4+Pj4+IFNyaW5pDQo+Pj4+ Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0Bp ZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+DQo+Pj4NCj4+Pl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5zZmMgbWFpbGluZyBsaXN0DQo+Pj5zZmNA aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+Pg0KPg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRmLm9yZzxt YWlsdG86c2ZjQGlldGYub3JnPg0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj5zZmMgbWFpbGluZyBsaXN0DQo+c2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+ DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBtYWlsaW5nIGxp c3QNCj5zZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnPG1haWx0 bzpzZmNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KDQo= --_000_D0F6CD2883CD0kegrayciscocom_ Content-Type: text/html; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxkaXY+UmVzcGVjdGZ1 bGx5LCBJIGRvbqGvdCB0aGluayBUTFZzIHdlcmUgYSB1bmlxdWUgcHJvcG9zaXRpb24sIGFzIHRo ZXNlIHdlcmUgZGlzY3Vzc2VkIGluZm9ybWFsbHkgaW4gbWVldGluZ3MgKHRoYXQgSSBkaWQgYXR0 ZW5kKSChpiBoYXZlIHRvIHNlYXJjaCB0aGUgbGlzdCBmb3IgobBUTFahsSB1bmlxdWVuZXNzLiAm bmJzcDtSZWdhcmRsZXNzLCB3ZSBzaG91bGRuoa90IGhhdmUgaGFkIHRvIHJlYWQgdGhyZWUgaXRl cmF0aW9ucyBvZiBhbm90aGVyIGRvY3VtZW50DQoganVzdCB0byBnZXQgdGhhdCBhZGRpdGlvbi4g Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5SZWdhcmRpbmcgcmVtYWluaW5n IGRpZmZlcmVuY2VzIKGmIEkgZG9uoa90IHJlYWxseSBzZWUgYW55LCB3aGljaCBtYWtlcyChsG1l cmdlobEgYSByZWFsbHkgaW5hcHByb3ByaWF0ZSB3b3JkIGZvciB3aGF0oa9zIHJlcXVpcmVkLjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SWYgobBtZXJnZaGxIG1lYW5zIKGwdGltZaGx LCBJIHNlZSBubyByZWFzb24gdG8gZGVsYXkgYSBjYWxsIGZvciBzdXBwb3J0IG9mIHRoZSBuc2gg ZHJhZnQuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9T RUNUSU9OIj4NCjxkaXY+DQo8ZGl2Pk9uIDIvMy8xNSwgNToyNyBQTSwgJnF1b3Q7WmFybnksIE15 byZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk15by5aYXJueUBncy5jb20iPk15by5aYXJueUBn cy5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBFeGNoYW5nZSBT ZXJ2ZXIiPg0KPCEtLSBjb252ZXJ0ZWQgZnJvbSBydGYgLS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVv dGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxlZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4 MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmks c2Fucy1zZXJpZiIgc2l6ZT0iMiI+DQo8ZGl2PkhpIEtlbiw8L2Rpdj4NCjx1bCBzdHlsZT0ibWFy Z2luLXRvcDogMHB0OyBtYXJnaW4tYm90dG9tOiAwcHQ7IG1hcmdpbi1sZWZ0OiA1NHB0OyAiPg0K PGxpIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsgIj5JRVRGOTAg bWludXRlcyBleHBsYWluIHRoZSBkaWZmZXJlbmNlcyB0aGVuLg0KPC9saT48L3VsPg0KPHVsIHN0 eWxlPSJtYXJnaW4tdG9wOiAwcHQ7IG1hcmdpbi1ib3R0b206IDBwdDsgbWFyZ2luLWxlZnQ6IDkw cHQ7ICI+DQo8bGkgc3R5bGU9Im1hcmdpbi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAi PlllcywgdGhlIGRyYWZ0cyBhcmUgbm93IHZlcnkgc2ltaWxhciBiZWNhdXNlIHRoZSBOU0ggZHJh ZnQgaGFzIGluY29ycG9yYXRlZCB0aGUgVExWIHBvcnRpb24uPC9saT48bGkgc3R5bGU9Im1hcmdp bi10b3A6IDVwdDsgbWFyZ2luLWJvdHRvbTogNXB0OyAiPlRoZSBnZW5lcmljIGNvbnRleHQgYmxv Y2sgaXMgdG8gYWNjb21tb2RhdGUgTlNIJ3MgZm91ciBtYW5kYXRvcnkgY29udGV4dCBoZWFkZXIg ZmllbGRzLjwvbGk+PC91bD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDogMHB0OyBtYXJnaW4tYm90 dG9tOiAwcHQ7IG1hcmdpbi1sZWZ0OiA1NHB0OyAiPg0KPGxpIHN0eWxlPSJtYXJnaW4tdG9wOiA1 cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsgIj5UaGUgY2hhaXJzIGFyZSBhY3RpdmVseSB3b3JraW5n IG9uIGEgbWVyZ2VkIGRvY3VtZW50IHdpdGggYSBzZWN0aW9uIGZvciByZW1haW5pbmcgZGlmZmVy ZW5jZXMuPC9saT48L3VsPg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0K PGRpdj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IHNmYyBbPGEgaHJlZj0i bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+XSBPbiBCZWhhbGYgT2YgQ2F0aHkgWmhhbmc8YnI+DQpTZW50OiAzIEZlYnJ1YXJ5IDIwMTUg NDo1NCBQTTxicj4NClRvOiBLZW4gR3JheSAoa2VncmF5KTsgU3JpbmkgQWRkZXBhbGxpOyBSZWlu YWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4gSGFscGVybjsNCjxhIGhyZWY9Im1haWx0bzon c2ZjQGlldGYub3JnIj4nc2ZjQGlldGYub3JnPC9hPic7IENhdGh5IFpoYW5nPGJyPg0KQ2M6IDxh IGhyZWY9Im1haWx0bzpuc211cnRoeUBmcmVlc2NhbGUuY29tIj5uc211cnRoeUBmcmVlc2NhbGUu Y29tPC9hPjxicj4NClN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQgKDxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAy Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMjwvYT4p PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5IaSBLZW4sPC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj5QbGVhc2Ugc2VlIGlubGluZS48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+Q2F0aHk8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8ZGl2Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9kaXY+DQo8ZGl2PkZyb206IEtlbiBH cmF5IChrZWdyYXkpIFs8YSBocmVmPSJtYWlsdG86a2VncmF5QGNpc2NvLmNvbSI+bWFpbHRvOmtl Z3JheUBjaXNjby5jb208L2E+XTwvZGl2Pg0KPGRpdj5TZW50OiBUdWVzZGF5LCBGZWJydWFyeSAw MywgMjAxNSAxMDowOSBBTTwvZGl2Pg0KPGRpdj5UbzogQ2F0aHkgWmhhbmc7IFNyaW5pIEFkZGVw YWxsaTsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBKb2VsIE0uIEhhbHBlcm47DQo8YSBocmVm PSJtYWlsdG86J3NmY0BpZXRmLm9yZyI+J3NmY0BpZXRmLm9yZzwvYT4nPC9kaXY+DQo8ZGl2PkNj OiA8YSBocmVmPSJtYWlsdG86bnNtdXJ0aHlAZnJlZXNjYWxlLmNvbSI+bnNtdXJ0aHlAZnJlZXNj YWxlLmNvbTwvYT48L2Rpdj4NCjxkaXY+U3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFND SCBEcmFmdCAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5n LXNmYy1zY2gtMDIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMt c2NoLTAyPC9hPik8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkFzIGEgZ2VuZXJhbCBj b21tZW50IG9uIHRoaXMgc3VibWlzc2lvbiAoYW5kIHBlcmhhcHMgbGlmZSBpbiB0aGUgY3VycmVu dCBJRVRGKS4mbmJzcDsgSSBoYXZlIGEgUkVBTExZIGhhcmQgdGltZSBkaWZmZXJlbnRpYXRpbmcg dGhpcyBkcmFmdCBmcm9tIHRoZSBxdWlubiBkcmFmdCAod2hpY2ggcHJlLWRhdGVzIGl0IGJ5IHF1 aXRlIGEgYml0KS4mbmJzcDsgV2h5IGFyZSB3ZSBwdXJzdWluZyBhIHNlcGFyYXRlIGRyYWZ0IHdo ZW4gdGhlIHN1Z2dlc3Rpb25zLA0KIElNSE8sIHNlZW0gaW5jcmVtZW50YWwgYXQgYmVzdD88L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5DYXRoeSZndDsg VGhlIG9yaWdpbmFsIG1vdGl2YXRpb24gZm9yIGRyYWZ0aW5nIHRoZSBTQ0ggaXMgdG8gcHJvdmlk ZSBhbiBhbHRlcm5hdGl2ZSB0byBkcmFmdC1xdWlubi1uc2ggdG8gYWRkcmVzcyB0aGUgZm9sbG93 aW5nIHBlcmNlaXZlZCBpc3N1ZXM6PC9kaXY+DQo8ZGl2PjEuIE1hbmRhdG9yeSBmaXhlZC1zaXpl ZCBtZXRhZGF0YS4gV2UgdGhpbmsgdGhleSBzaG91bGQgbm90IGJlIG1hbmRhdG9yeSBzaW5jZSB0 aGUgNC13b3JkIGNvbnRleHQgZmllbGRzIGFyZSBub3QgbmVlZGVkIGluIG1hbnkgc2NlbmFyaW9z IDIuIE5vIHZhcmlhYmxlIGxlbmd0aCBtZXRhZGF0YS4gV2UgdGhpbmsgbWV0YWRhdGEgc2hvdWxk IGJlIG9wdGlvbmFsIGFuZCBUTFYgZm9ybWF0IHNob3VsZCBiZSB1c2VkIHRvIGRlZmluZSBtZXRh ZGF0YQ0KIDMuIE5vIG9yZ2FuaXphdGlvbmFsbHkgZGVmaW5lZCBtZXRhZGF0YSA0LiBObyBWZXJz aW9uIGZpZWxkLiZuYnNwOyA8L2Rpdj4NCjxkaXY+V2hlbiB3ZSB1cGxvYWRlZCBTQ0ggMXN0IHZl cnNpb24gKDMvMjQvMjAxNCksIE5TSCB2ZXJzaW9uIGRpZCBub3QgaGF2ZSB0aGUgVExWIG1ldGFk YXRhIGFuZCB2ZXJzaW9uIGZpZWxkICh0aGV5IHdlcmUgYWRkZWQgaW4gaXRzIGxhdGVyIHZlcnNp b24pLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KPGRpdj5JIGhhdmUgcmVhY2ggb3V0IHRvIHRoZSBjaGFpcnMgaGVyZSAuIHdl IGhhdmUgYSBsb3QgdG8gcmVhZC4gQXJlbid0IGRyYWZ0cyBzdXBwb3NlZCB0byBvZmZlciBzaWdu aWZpY2FudGx5IGRpZmZlcmVudCB2aWV3cyBpZiB0aGV5IGFyZSB0byBwZXJzaXN0ICh3aXRob3V0 IHRoYXQsIGEgJnF1b3Q7Y2FsbCB0byBhZG9wdCZxdW90OyBiZWNvbWVzIGEgYmVhdXR5IGNvbnRl c3QsIElNTyk/Jm5ic3A7IE5vIG9mZmVuc2UgdG8gdGhlIGF1dGhvcnMsIGJ1dCB3ZSdyZSBpbg0K IHJldmlzaW9uIDMgYW5kIEkgZG9uJ3Qgc2VlIHRoYXQgaGVyZS48L2Rpdj4NCjxkaXY+Jm5ic3A7 PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5SZWdhcmRpbmcgdGhlIGNoYW5nZXMgaW4g dGhpcyBkb2N1bWVudDo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkkgZG8gbm90IGZp bmQgdGhlIGZsb3cgSUQgZnVuY3Rpb25hbGx5IGRpZmZlcmVudCB0aGFuIHRoZSB1c2UgY29udGV4 dCBoZWFkZXJzIGluIHRoZSBuc2ggZHJhZnQsIHdoaWNoIHNlZW0gdG8gYmUgYSBtb3JlIG11bHRp LXB1cnBvc2UgY29uY2VwdC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkNhdGh5Jmd0 OyBEaWZmZXJlbnQgcGVvcGxlIGhhdmUgZGlmZmVyZW50IHZpZXdwb2ludHMuIFJTUCBJRCBpcyBu b3QgZGVmaW5lZCBpbiBOU0ggYW5kIGZyb20gUGF1bCAoTlNIIGF1dGhvcikncyByZXBseSwgaXQg c2VlbXMgaGUgZG9lcyBub3QgZmVlbCB0aGUgbmVlZCBvZiBhbiBSU1AgSUQuDQo8L2Rpdj4NCjxk aXY+Q2F0aHkmZ3Q7IFdlIHNlZSB0aGUgbmVlZCBmb3IgUlNQIElEIGFuZCB0aHVzIGRlZmluZWQg aXQgaW4gU0NIIGZvciBvcGVuIGRpc2N1c3Npb24gYW5kIHdvdWxkIGxpa2UgdG8gc2VlIHRoZSBj b21tdW5pdHkncyBmZWVkYmFjayBvbiBpdC4mbmJzcDsNCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+VGhlIEIgYml0IHN1Z2dlc3Rpb24gY2FuIGNhdXNlIGEgY29uZmxpY3QgaW4gY29u dHJvbCBhbmQgY3JlYXRlIGFuIGF2ZW51ZSBmb3IgdW5kZXNpcmFibGUgYmVoYXZpb3IsIElNTy4m bmJzcDsgSSd2ZSBiZWVuIHdvcmtpbmcgZnJvbSB0aGUgYXNzdW1wdGlvbiB0aGF0IGEgbWluaW11 bSByZXF1aXJlbWVudCBvZiBhIGZ1bmN0aW9uIGlzIHRoYXQgaXQgYmUgbWFuYWdlYWJsZSAoaWYg Zm9yIG5vIG90aGVyIHJlYXNvbiB0aGFuIGVmZmVjdGl2ZSBlbGFzdGljaXR5DQogYW5kIGNvaGVz aXZlL3ByZWRpY3RhYmxlIGRlbGl2ZXJ5IG9mIHNlcnZpY2UpLCBzbyBJIGhhdmUgbGl0dGxlIHN5 bXBhdGh5IGZvciB0aG9zZSB0aGF0IGFyZSBub3QgLSBiZSB0aGV5IHZpcnR1YWwgb3IgcGh5c2lj YWwgKGV2ZW4gbGVzcyBzeW1wYXRoeSBmb3IgdmlydHVhbCBmdW5jdGlvbnMgdGhhdCBhcmUgdW5t YW5hZ2VhYmxlLCBmcmFua2x5KS4mbmJzcDsgQSBzZWxmLW1hbmFnZW1lbnQgb3B0aW9uIGluIHRo ZSBTRkMgc2NlbmFyaW8gaGFzIGxvdyB2YWx1ZQ0KIGFuZCB0aGUgY29ycnVwdGlvbiBvciBtaXN1 c2Ugb2YgdGhlIGJpdCBjYW4gY2F1c2UgY2hhb3MgKGFuIGV4dHJhIGxldmVsIG9mICZxdW90O2Zh aWwmcXVvdDspLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Q2F0aHkmZ3Q7IENvdWxk IHlvdSBjbGFyaWZ5IHdoYXQgeW91IG1lYW4gYnkgJnF1b3Q7Y2F1c2UgYSBjb25mbGljdCBpbiBj b250cm9sJnF1b3Q7PyA8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj5UaGUgR2VuZXJpYyBDb250ZXh0IEJsb2NrIGlzIGNvbmZ1c2luZyBpbiBsaWdodCBv ZiB0aGUgYWxyZWFkeSBleHRhbnQgb3B0aW9uYWwvdmFyaWFibGUgbWV0YWRhdGEgVExWcyAod2h5 IHdvdWxkbid0IHlvdSBsZXZlcmFnZSBvbmUgb2YgdGhlbSk/PC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj5DYXRoeSZndDsgSSBhbSBub3Qgc3VyZSBpZiBJIHVuZGVyc3RhbmQgeW91ciBw b2ludC4gVGhlIEdlbmVyaWMgQ29udGV4dCBCbG9jayBpcyBvbmUgdHlwZSBvZiBtZXRhZGF0YSB3 aGljaCBpcyBpbiBUTFYgZm9ybWF0IGFuZCBpcyBvcHRpb25hbC4NCjwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5DYXRoeTwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk9uIDEvMjkvMTUsIDI6NDQgUE0sICZx dW90O0NhdGh5IFpoYW5nJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Q2F0aHkuSC5aaGFuZ0Bo dWF3ZWkuY29tIj5DYXRoeS5ILlpoYW5nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PiZndDtIaSBldmVyeW9uZSw8L2Rpdj4NCjxkaXY+Jmd0 OzwvZGl2Pg0KPGRpdj4mZ3Q7V2UgaGF2ZSB1cGxvYWRlZCBhIG5ldyBTQ0ggdmVyc2lvbiAoMykg d2hpY2ggYWRkcyBkZWZpbml0aW9uIG9mIGEgbmV3IDwvZGl2Pg0KPGRpdj4mZ3Q7bWV0YWRhdGEg dHlwZSBmb3IgdGhlIGZsb3cgSUQgdG8gc3VwcG9ydCBsb2FkIGJhbGFuY2luZyBhbW9uZyBTRiA8 L2Rpdj4NCjxkaXY+Jmd0O2luc3RhbmNlcyBhbmQgbWl0aWdhdGUgdGhlIHBvdGVudGlhbCBpc3N1 ZSBvZiAmcXVvdDtub3QgZW5vdWdoIHBhdGggSUQmcXVvdDsuIFRoZSA8L2Rpdj4NCjxkaXY+Jmd0 O2Zsb3cgSUQgaXMgbmFtZWQgJnF1b3Q7cmVuZGVyZWQgc2VydmljZSBwYXRoIElEJnF1b3Q7IGlu IHRoZSBkcmFmdC4gUGxlYXNlIHJlZmVyIDwvZGl2Pg0KPGRpdj4mZ3Q7dG8gc2VjdGlvbiA0LjMu MiBvZiA8L2Rpdj4NCjxkaXY+Jmd0OzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXpoYW5nLXNmYy1zY2gvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC16aGFuZy1zZmMtc2NoLzwvYT48L2Rpdj4NCjxkaXY+Jmd0O2ZvciBkZXRhaWwg ZGVzY3JpcHRpb24uPC9kaXY+DQo8ZGl2PiZndDsgPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxk aXY+Jmd0O0luIGl0cyBwcmV2aW91cyB2ZXJzaW9uLCBTQ0ggZGVmaW5lcyBhICZxdW90O0J5cGFz cyBiaXQmcXVvdDsgaW4gdGhlIGJhc2UgaGVhZGVyLjwvZGl2Pg0KPGRpdj4mZ3Q7VGhpcyBiaXQg ZW5hYmxlcyB0aGUgU0YgdG8gcHJvdmlkZSBmZWVkYmFjay9ub3RpZmljYXRpb24gdmlhIHRoZSBk YXRhIDwvZGl2Pg0KPGRpdj4mZ3Q7cGF0aCB0byBpdHMgY29ubmVjdGluZyBTRkYgYWJvdXQgd2hl dGhlciB0aGUgcmVtYWluaW5nIHBhY2tldHMgb2YgdGhlIDwvZGl2Pg0KPGRpdj4mZ3Q7U0ZDIHNo b3VsZCBieXBhc3MgdGhhdCBTRi4gVGhpcyBpcyB1c2VmdWwgaW4gdGhlIGNhc2UgdGhhdCBvbmx5 IHRoZSA8L2Rpdj4NCjxkaXY+Jmd0O2ZpcnN0IGZldyBwYWNrZXRzIG9mIGEgZmxvdyBuZWVkIHRv IGdvIHRvIGEgU0YgKHN1Y2ggYXMgYSBEUEkgb3IgRlcgb3IgPC9kaXY+DQo8ZGl2PiZndDtJRFMp IGFuZCByZW1haW5pbmcgcGFja2V0cyBjYW4gYnlwYXNzIHRoYXQgU0YsIHRodXMgc2F2aW5nIHRo ZSA8L2Rpdj4NCjxkaXY+Jmd0O2V4cGVuc2l2ZSBTRiByZXNvdXJjZSBhbmQgcmVkdWNpbmcgZGF0 YSBwYXRoIGxhdGVuY3kuPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0O0IgYml0OiBU aGUgQiAoQnlwYXNzKSBiaXQsIHdoZW4gc2V0IHRvIDEsIGl0IGlzIHVzZWQgYnkgYSBTZXJ2aWNl PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRnVu Y3Rpb24gdG8gc2lnbmFsIHRvIGl0cyBTZXJ2aWNlIEZ1bmN0aW9uIEZvcndhcmRlciB0aGF0IG5v PC9kaXY+DQo8ZGl2PiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZnVy dGhlciBwYWNrZXRzIGFyZSB0byBiZSBzZW50IHRvIGl0IGZvciB0aGUgZmxvdyBzcGVjaWZpZWQg aW4gPC9kaXY+DQo8ZGl2PiZndDtlbmNhcHN1bGF0ZWQgcGFja2V0LjwvZGl2Pg0KPGRpdj4mZ3Q7 PC9kaXY+DQo8ZGl2PiZndDtJbiBhZGRpdGlvbiwgU0NIIGRlZmluZXMgYSBtZXRhZGF0YSB0eXBl IGZvciBHZW5lcmljIENvbnRleHQgQmxvY2ssIDwvZGl2Pg0KPGRpdj4mZ3Q7d2hpY2ggaXMgb3B0 aW9uYWwgYW5kIGNhbiBiZSB1c2VkIGlmIG5lZWRlZCB0byBjYXJyeSBhbnkgdmVuZG9yJ3MgPC9k aXY+DQo8ZGl2PiZndDtzcGVjaWZpYyAmcXVvdDtDb250ZXh0IEhlYWRlciZxdW90Oy48L2Rpdj4N CjxkaXY+Jmd0OyA8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7QW55IGNvbW1lbnRz IG9uIHRoZXNlIG5ldyBhZGRpdGlvbnM/PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0 O1RoYW5rcyw8L2Rpdj4NCjxkaXY+Jmd0O0NhdGh5PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxk aXY+Jmd0Oy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9kaXY+DQo8ZGl2PiZndDtGcm9tOiBz ZmMgWzxhIGhyZWY9Im1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNmYy1ib3Vu Y2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIENhdGh5IFpoYW5nPC9kaXY+DQo8ZGl2PiZn dDtTZW50OiBGcmlkYXksIERlY2VtYmVyIDA1LCAyMDE0IDExOjQ3IEFNPC9kaXY+DQo8ZGl2PiZn dDtUbzogU3JpbmkgQWRkZXBhbGxpOyBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4g SGFscGVybjsgPC9kaXY+DQo8ZGl2PiZndDs8YSBocmVmPSJtYWlsdG86J3NmY0BpZXRmLm9yZyI+ J3NmY0BpZXRmLm9yZzwvYT4nPC9kaXY+DQo8ZGl2PiZndDtDYzogPGEgaHJlZj0ibWFpbHRvOm5z bXVydGh5QGZyZWVzY2FsZS5jb20iPm5zbXVydGh5QGZyZWVzY2FsZS5jb208L2E+PC9kaXY+DQo8 ZGl2PiZndDtTdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0PC9kaXY+DQo8 ZGl2PiZndDsoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5n LXNmYy1zY2gtMDIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMt c2NoLTAyPC9hPik8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Um9uLCBMb3Vpcywg TXlvIGFuZCBJIGhhdmUgYmVlbiBkaXNjdXNzaW5nIG9mZiBsaW5lIGxhc3QgZmV3IHdlZWtzIDwv ZGl2Pg0KPGRpdj4mZ3Q7YWJvdXQgZGVmaW5pbmcgYSBtZXRhZGF0YSB0eXBlIGZvciBmbG93IElE IGluIGFkZGl0aW9uIHRvIHRoZSBwYXRoIElEIDwvZGl2Pg0KPGRpdj4mZ3Q7b2YgdGhlIG1haW4g aGVhZGVyIHRvIHN1cHBvcnQgbG9hZCBiYWxhbmNpbmcgYW1vbmcgU0YgaW5zdGFuY2VzLiBXZSA8 L2Rpdj4NCjxkaXY+Jmd0O3dpbGwgZGVmaW5lIGEgVExWIHR5cGUgZm9yIHRoZSBmbG93IElELiBU aGUgY29tYmluYXRpb24gb2YgJnF1b3Q7cGF0aCBJRCAmIzQzOyBmbG93IElEJnF1b3Q7PC9kaXY+ DQo8ZGl2PiZndDtzcGVjaWZpZXMgYSByZWFsaXplZCBzZXJ2aWNlIGNoYWluIGluc3RhbmNlIHBh dGguIEl0IGlzIGxlZnQgdG8gdGhlIDwvZGl2Pg0KPGRpdj4mZ3Q7ZGVzaWduL2ltcGxlbWVudGF0 aW9uIHdoZXRoZXIgdG8gdXNlIGEgY2VudHJhbGl6ZWQgbWV0aG9kIG9yIGEgPC9kaXY+DQo8ZGl2 PiZndDtkaXN0cmlidXRlZCBtZXRob2QgdG8gYmluZCB0aGUgZmxvdyBJRCB0byBhIHJlYWxpemVk IHNlcnZpY2UgaW5zdGFuY2UgPC9kaXY+DQo8ZGl2PiZndDtwYXRoIGFsdGhvdWdoIG91ciBvcmln aW5hbCB0aG91Z2h0IGlzIGZvciBkaXN0cmlidXRlZCBMQiB1c2FnZS4gSSBhbSA8L2Rpdj4NCjxk aXY+Jmd0O25vdCBzdXJlIGlmIHdlIG5lZWQgYSBiaXQgaW4gdGhlIGhlYWRlciB0byBkZW5vdGUg d2hldGhlciB0aGVyZSBhcmUgPC9kaXY+DQo8ZGl2PiZndDttb3JlIHBhdGggSUQgYml0cyAod2Ug Y2FsbCBpdCBmbG93IElEKSBpbiB0aGUgbWV0YWRhdGEgZmllbGRzIHNpbmNlIDwvZGl2Pg0KPGRp dj4mZ3Q7d2hlbiB5b3UgcGFyc2UgdGhlIFRMViBtZXRhZGF0YSwgeW91IHdpbGwga25vdyB3aGV0 aGVyIHRoZXJlIGFyZSBmbG93IElEIGJpdHMgb3Igbm90LjwvZGl2Pg0KPGRpdj4mZ3Q7Tm90ZSB0 aGF0IGlmIG11bHRpcGxlIHNlc3Npb25zIHNoYXJlIHRoZSBzYW1lIHJlYWxpemVkIHNlcnZpY2Ug aW5zdGFuY2UgPC9kaXY+DQo8ZGl2PiZndDtwYXRoLCB0aGV5IHdpbGwgc2hhcmUgdGhlIHNhbWUg JnF1b3Q7cGF0aCBJRCYjNDM7IGZsb3cgSUQmcXVvdDsuJm5ic3A7IFdlIGNhbiBhbHNvIDwvZGl2 Pg0KPGRpdj4mZ3Q7Y29uc2lkZXIgZXh0ZW5kaW5nIHRoZSBudW1iZXIgb2YgYml0cyB0byAzMiBp ZiB0aGF0IGlzIHRoZSBjb25zZW5zdXMuIDwvZGl2Pg0KPGRpdj4mZ3Q7V2Ugd2lsbCBwb3N0IGFu IHVwZGF0ZWQgZHJhZnQgZGVzY3JpYmluZyB0aGVzZSBzb29uLjwvZGl2Pg0KPGRpdj4mZ3Q7PC9k aXY+DQo8ZGl2PiZndDtUaGFua3MsPC9kaXY+DQo8ZGl2PiZndDtDYXRoeTwvZGl2Pg0KPGRpdj4m Z3Q7PC9kaXY+DQo8ZGl2PiZndDstLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwvZGl2Pg0KPGRp dj4mZ3Q7RnJvbTogc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBTcmluaSBBZGRlcGFs bGk8L2Rpdj4NCjxkaXY+Jmd0O1NlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDUsIDIwMTQgNzoxNyBB TTwvZGl2Pg0KPGRpdj4mZ3Q7VG86IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgSm9lbCBNLiBI YWxwZXJuOyA8YSBocmVmPSJtYWlsdG86J3NmY0BpZXRmLm9yZyI+DQonc2ZjQGlldGYub3JnPC9h Pic8L2Rpdj4NCjxkaXY+Jmd0O0NjOiA8YSBocmVmPSJtYWlsdG86bnNtdXJ0aHlAZnJlZXNjYWxl LmNvbSI+bnNtdXJ0aHlAZnJlZXNjYWxlLmNvbTwvYT48L2Rpdj4NCjxkaXY+Jmd0O1N1YmplY3Q6 IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQ8L2Rpdj4NCjxkaXY+Jmd0Oyg8YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMiI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDI8L2E+KTwvZGl2 Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0O1tSUF0gRGF0YSBw bGFuZSBlZmZpY2llbmN5LjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDtTUklOSSZn dDsgSSBhbSBub3Qgc28gc3VyZSBhYm91dCBkYXRhIHBsYW5lIGVmZmljaWVuY3kuJm5ic3A7IE1v c3Qgb2YgdGhlPC9kaXY+DQo8ZGl2PiZndDtwcm9jZXNzb3JzIHdvcmsgZ29vZCBpZiB0aGUgbnVt YmVyIG9mIGJpdHMgYXJlIGVpdGhlciAzMiBvciA2NC4mbmJzcDsgSWYgaXQgPC9kaXY+DQo8ZGl2 PiZndDtpczwvZGl2Pg0KPGRpdj4mZ3Q7MjQgYml0cywgdGhlbiBvbmUgbmVlZHMgdG8gZG8gbWFz a2luZyBhbmQgc2hpZnRpbmcgYmVmb3JlIHRoZSB2YWx1ZSBpczwvZGl2Pg0KPGRpdj4mZ3Q7dXNl ZCB0byBkbyBhbnkgbG9va3VwLiZuYnNwOyZuYnNwOyBCdXQsIHRoaXMgZGlzY3Vzc2lvbiBjYW4g Z28gaW50byBkaWZmZXJlbnQ8L2Rpdj4NCjxkaXY+Jmd0O2RpcmVjdGlvbiA6LSksIGl0IG1heSBu b3QgYmUgZ29vZCB0byBnbyBpbiB0aGF0IGRpcmVjdGlvbi48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2 Pg0KPGRpdj4mZ3Q7V2hlcmUgZG8gd2UgZHJhdyB0aGUgbGluZT8gMzItYml0cywgNjQtYml0cyw8 L2Rpdj4NCjxkaXY+Jmd0OzEyOCBiaXRzPyBJIHRoaW5rIHdlIHNob3VsZCBoYXZlIGEgc2Vuc2li bGUgdmFsdWUgaW4gdGhlIFNlcnZpY2UgUGF0aCA8L2Rpdj4NCjxkaXY+Jmd0O2hlYWRlciBhbmQg aWYgeW91IG5lZWQgdG8gY29udmV5IG1vcmUgYml0cyB5b3UgbmVlZCB0byB1c2UgdGhlIGNvbnRl eHQgPC9kaXY+DQo8ZGl2PiZndDtoZWFkZXJzLjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2 PiZndDtTUklOSSZndDsgVGhpcyBpcyBhIGdvb2QgcG9pbnQuJm5ic3A7IFRoaXMgc2hvdWxkIHdv cmsgZmluZSBhcyBsb25nIGFzIHRoZXJlIGlzPC9kaXY+DQo8ZGl2PiZndDt3YXkgdG8gY29udmV5 IGluIHRoZSBtYWluIGhlYWRlciB0aGF0IHRoZSBleHRlbnNpb24gdG8gcGF0aCBJRCBpcyA8L2Rp dj4NCjxkaXY+Jmd0O2F2YWlsYWJsZSBpbiBzbyBhbmQgc28gVExWIGZpZWxkLiZuYnNwOyBUaGF0 IHNob3VsZCB3b3JrIHRvby48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7VGhhbmtz PC9kaXY+DQo8ZGl2PiZndDtTcmluaTwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDtf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9kaXY+DQo8ZGl2PiZndDtG cm9tOiBSZWluYWxkbyBQZW5ubyAocmVwZW5ubykgJmx0OzxhIGhyZWY9Im1haWx0bzpyZXBlbm5v QGNpc2NvLmNvbSI+cmVwZW5ub0BjaXNjby5jb208L2E+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7U2Vu dDogRnJpZGF5LCBEZWNlbWJlciA1LCAyMDE0IDc6MDggQU08L2Rpdj4NCjxkaXY+Jmd0O1RvOiBB ZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47IDxhIGhyZWY9Im1haWx0bzon c2ZjQGlldGYub3JnIj4NCidzZmNAaWV0Zi5vcmc8L2E+JzwvZGl2Pg0KPGRpdj4mZ3Q7Q2M6IE5T IFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwPC9kaXY+DQo8ZGl2PiZndDtTdWJqZWN0OiBSZTogW3Nm Y10gQ29tbWVudHMgb24gU0NIIERyYWZ0PC9kaXY+DQo8ZGl2PiZndDsoPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIiPmh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyPC9hPik8L2Rpdj4NCjxkaXY+ Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7T24gMTIvNS8xNCwgNjo1NCBBTSwgJnF1b3Q7U3JpbmkgQWRk ZXBhbGxpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2FkZGVwYWxsaUBmcmVlc2NhbGUuY29t Ij5zYWRkZXBhbGxpQGZyZWVzY2FsZS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxkaXY+Jmd0 OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O0luIHJlYWwgZGVwbG95 bWVudHMsIG51bWJlciBvZiBhY3RpdmUgcGF0aCBJRHMgYXJlIHZlcnkgbGVzc2VyIHRoYW4gPC9k aXY+DQo8ZGl2PiZndDsmZ3Q7Ml42NCwgYnV0IHRoZXJlIGlzIGEgZ29vZCBwb3NzaWJpbGl0eSBv ZiB0aGUgbnVtYmVyIGJlaW5nIG1vcmUgdGhhbiAyXjI0ICgxNk0pLjwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyBJIHRoaW5rIGJpZ2dlciBwb2ludCBpcyB0aGF0IHdoeSByZXN0cmljdCB0aGlzIGluIHRo ZSBzdGFuZGFyZHM/IFdoYXQgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7YWR2YW50YWdlIGRvIHdlIGhh dmUgcmVzdHJpY3RpbmcgdGhpcyBzaXplIHRvIDI0IGJpdHM/PC9kaXY+DQo8ZGl2PiZndDs8L2Rp dj4NCjxkaXY+Jmd0O1tSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5LiBXaGVyZSBkbyB3ZSBkcmF3 IHRoZSBsaW5lPyAzMi1iaXRzLCA8L2Rpdj4NCjxkaXY+Jmd0OzY0LWJpdHMsPC9kaXY+DQo8ZGl2 PiZndDsxMjggYml0cz8gSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBhIHNlbnNpYmxlIHZhbHVlIGlu IHRoZSBTZXJ2aWNlIFBhdGggPC9kaXY+DQo8ZGl2PiZndDtoZWFkZXIgYW5kIGlmIHlvdSBuZWVk IHRvIGNvbnZleSBtb3JlIGJpdHMgeW91IG5lZWQgdG8gdXNlIHRoZSBjb250ZXh0IDwvZGl2Pg0K PGRpdj4mZ3Q7aGVhZGVycy48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7VGhlcmUgY2FuIGJlIGRlcGxveW1l bnRzLCB3aGVyZSBTRkMgY29udHJvbGxlciAoTG9naWNhbGx5IGNlbnRyYWwsIGJ1dDwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0O2Rpc3RyaWJ1dGVkKSZuYnNwOyBpdHNlbGYgY2FuIGRvIHRoZSBTRiBpbnN0 YW5jZSBzZWxlY3Rpb24gb24gcGVyPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Y29ubmVjdGlvbi9zZXNz aW9uIGJhc2lzLCB0aGVyZWJ5IGF2b2lkaW5nIHRoZSBMQnMgZm9yIHNlcnZpY2VzLiZuYnNwOyZu YnNwOyBJbiBteTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O3ZpZXcsIGFzc3VtcHRpb24gdGhhdCB0aGVy ZSB3aWxsIGJlIExCIFNGIGZvciBlYWNoIHNjYWxlLW91dCBzZXJ2aWNlIDwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0O2luIHRoZSBjaGFpbiBpcyBub3QgdmFsaWQgaW4gYWxsIGNhc2VzLjwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O1RoYW5rczwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 O1NyaW5pPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O0Zyb206 IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJlcGVubm9AY2lz Y28uY29tIj5yZXBlbm5vQGNpc2NvLmNvbTwvYT4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7U2Vu dDogVGh1cnNkYXksIERlY2VtYmVyIDQsIDIwMTQgMToxNyBQTTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 O1RvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47IDxhIGhyZWY9Im1h aWx0bzpzZmNAaWV0Zi5vcmciPg0Kc2ZjQGlldGYub3JnPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 O0NjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O1N1Ympl Y3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQ8L2Rpdj4NCjxkaXY+Jmd0OyZndDso PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gt MDIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyPC9h Pik8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDtJZiBJIHVuZGVyc3Rv b2QgeW91LCBJIGRvIG5vdCB0aGluayB0aGlzIGlzIHJlYWxpc3RpYy4gQXJlIHlvdSBzYXlpbmcg PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7eW91IG5lZWQgNjQtYml0cyBvZiBwYXRocyBhbmQgdGhlbiB3 aWxsIG1vbml0b3IgdGhlbSBhbGw/IERvIGZhdWx0IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O3RvbGVy YW5jZSBhbmQgT0FNIGZvciAyXjY0LWJpdHMgd29ydGggb2YgcGF0aHM/IEp1c3QgZm9yIGNvbXBh cmlzb24sIDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O2l0qfZzIGxpa2UgbWFuYWdpbmcgYW5kIG1vbml0 b3JpbmcgdGhlIGVudGlyZSBJUHY2IGhvc3QgcmFuZ2UsIG9uZS1ieS1vbmUuPC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7QW55d2F5LCBJIGRvIG5vdCBleHBlY3QgZXZl cnkgc2luZ2xlIHBlcm11dGF0aW9ucyB0byBiZSBhIGRpZmZlcmVudCBwYXRoLjwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O0lmIGVhY2ggc2VydmljZSBoYXMgMjU2IGRl dmljZXMgcHJvdmlkaW5nIHNpbWlsYXIgc2VydmljZSwgeW91IHNob3VsZCA8L2Rpdj4NCjxkaXY+ Jmd0OyZndDttb3N0IGxpa2VseSB1c2UgbG9hZC1iYWxhbmNpbmcgYW5kIHRoZW4geW91IHdvdWxk IGhhdmUgYSBzaW5nbGUgKG9yIGEgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7ZmV3KSBwYXRocy4gVGhl cmUgaXMgc29tZSBkaXNjdXNzaW9uIGdvaW5nIG9uIExCLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0Ozwv ZGl2Pg0KPGRpdj4mZ3Q7Jmd0O0Zyb20gYSBkYXRhIHBsYW5lIHBlcnNwZWN0aXZlLCB0aGUgcGF0 aCBpcyB1bHRpbWF0ZWx5IGRlZmluZWQgYnkgdGhlIDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O1NGRnMg dHJhdmVyc2VkIGFuZCBzZXJ2aWNlcyBwcm92aWRlZCwgbm90IGJ5IGEgc3BlY2lmaWMgSVA6cG9y dCB0aGF0IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0O3RoZSBkZXZpY2UgcHJvdmlkaW5nIHRoZSBzZXJ2 aWNlIHNpdHMgb24uIFdlbGwsIGF0IGxlYXN0IGZyb20gYSA8L2Rpdj4NCjxkaXY+Jmd0OyZndDtH UEUmIzQzO05TSCBwZXJzcGVjdGl2ZS48L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+ Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDtPbiAxMi80LzE0LCAxMjo1NyBQTSwgJnF1b3Q7 U3JpbmkgQWRkZXBhbGxpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c2FkZGVwYWxsaUBmcmVl c2NhbGUuY29tIj5zYWRkZXBhbGxpQGZyZWVzY2FsZS5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4N CjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7SWYgSSB0YWtlIGEgY2hhaW4g d2l0aCA1IHNlcnZpY2VzIHdpdGggZWFjaCBzZXJ2aWNlJm5ic3A7IHNheSBoYXZpbmcgMjU2IDwv ZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDtpbnN0YW5jZXMgZm9yIHNjYWxlLW91dCwgcG9zc2libGUg bnVtYmVyIG9mIHBhdGhzIGFyZTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsyNTYqMjU2KjI1Nioy NTYqMjU2PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0Oz0gMHhGRiBGRiBGRiBGRiBGRi4gT25lIHJl cXVpcmVzIDMzIGJpdHMgaW4gdGhpcyBjYXNlLiZuYnNwOyBJZiB0aGVyZSBhcmUgPC9kaXY+DQo8 ZGl2PiZndDsmZ3Q7Jmd0O21vcmUgc2VydmljZXMgaW4gdGhlIGNoYWluIG9yIG1vcmUgY2hhaW5z IG9yIG1vcmUgaW5zdGFuY2VzIGZvciA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7c2NhbGUtb3V0 LCB0aGVuIGl0IGNvdWxkIGdvIHRvIGJpZyBudW1iZXIgdmVyeSBmYXN0LjwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7QXMgSSBtZW50aW9uZWQgbXkgcHJl ZmVyZW5jZSBpcyB0byBtYWtlIHRoZSBwYXRoIElEIHNpemUgZmxleGlibGUgZm9yIDwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OyZndDtmdXR1cmUgZ3Jvd3RoLiBJZiB0aGF0IGlzIHBlcmNlaXZlZCBhcyBj b21wbGV4LCB0aGVuIGdvaW5nIGZvciA2NGJpdCA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7aXMg c2FmZXIgYmV0LjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsm Z3Q7VGhhbmtzPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0O1NyaW5pPC9kaXY+DQo8ZGl2PiZndDsm Z3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7RnJvbTog Sm9lbCBNLiBIYWxwZXJuIFs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+bWFp bHRvOmptaEBqb2VsaGFscGVybi5jb208L2E+XTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDtTZW50 OiBUaHVyc2RheSwgRGVjZW1iZXIgMDQsIDIwMTQgMTI6MDUgUE08L2Rpdj4NCjxkaXY+Jmd0OyZn dDsmZ3Q7VG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IEpvZWwgTS4gSGFscGVybjsgPGEgaHJl Zj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+DQpzZmNAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7Jmd0O0NjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MDwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyZndDtTdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0PC9kaXY+DQo8 ZGl2PiZndDsmZ3Q7Jmd0Oyg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtemhhbmctc2ZjLXNjaC0wMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpo YW5nLXNmYy1zY2gtMDI8L2E+KTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDs8L2Rpdj4NCjxkaXY+ Jmd0OyZndDsmZ3Q7QSBjb250cm9sbGVyIChvciBvdGhlciBkZWNpc2lvbiBsb2dpYykgY2FuIGNl cnRhaW5seSBiZSBhd2FyZSBvZiBzdWNoIDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDtjb25jZXJu cy48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7QnV0IHRoZSBudW1iZXIgb2Ygc2VydmljZSBmdW5j dGlvbiBwYXRocyBpcyBub3QgcmVsYXRlZCB0byB0aGUgbnVtYmVyIDwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyZndDtvZiBmbG93cyBvciB0aGUgbnVtYmVyIG9mIHRlbmFudHMuJm5ic3A7IEl0IGlzIHJl bGF0ZWQgdG8gdGhlIG51bWJlciBvZiA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Y29tYmluYXRp b25zIG9mIHNlcnZpY2VzIGFuZCB0aGUgcG9saWNpZXMgZm9yIHNlcnZpY2UgZnVuY3Rpb24gPC9k aXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0O3NlbGVjdGlvbi48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7 IFdoaWxlIHRoYXQgY2FuIGJlIGEgbGFyZ2UgbnVtYmVyLCBJIHN1cmUgaG9wZSBpdCBkb2VzIG5v dCBjb21lIGNsb3NlIDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDt0byBzYXR1cmF0aW5nIDI0IGJp dHMuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDtIYXZp bmcgc2FpZCB0aGF0LCBpZiB3ZSB0aGluayB0aGF0IDI0IGJpdHMgaXMgb25seSBqdXN0IGVub3Vn aCwgdGhlbiA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7d2Ugb3VnaHQgdG8gdXNlIDMyLiZuYnNw OyBGcm9tIHdoZXJlIEkgc2l0LCBJIHdvdWxkIG5vcm1hbGx5IGV4cGVjdCAxNiA8L2Rpdj4NCjxk aXY+Jmd0OyZndDsmZ3Q7Yml0cyB0byBiZSBtb3JlIHRoYW4gc3VmZmljaWVudCwgd2hpY2ggaXMg d2h5IEkgYW0gY29tZm9ydGFibGUgd2l0aCA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7MjQuJm5i c3A7IEhhdmluZyBzYWlkIHRoYXQsIHRoZSBmaWVsZCBzaXplIGlzIG5vdCBhIGJpZyBkZWFsIHRv IG1lLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7WW91 cnMsPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0O0pvZWw8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7 PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0O09uIDEyLzQvMTQsIDI6MDEgUE0sIFNyaW5pIEFkZGVw YWxsaSB3cm90ZTo8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyZndDsmZ3Q7IEkgd2FzIG5vdCBpbXBseWluZyB0aGF0IHBhdGggSUQgc2hvdWxkIGhhdmUg aW5mb3JtYXRpb24gaW4gcmVnYXJkcyA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0O3RvIHRl bmFudC9jb250cm9sbGVyL2Zsb3cvc2NhbGUtb3V0LiZuYnNwOyBCdXQgU0ZDIGNvbnRyb2xsZXJz IHNob3VsZCA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0O2tlZXAgdGhlc2U8L2Rpdj4NCjxk aXY+Jmd0OyZndDsmZ3Q7Jmd0O2luIG1pbmQgdG8gYXNzaWduIHRoZSBwYXRoIElELiZuYnNwOyZu YnNwOyZuYnNwOyBBIGRlcGxveW1lbnQgY2FuIGhhdmUgbXVsdGlwbGU8L2Rpdj4NCjxkaXY+Jmd0 OyZndDsmZ3Q7Jmd0O3RlbmFudHMsIGVhY2ggdGVuYW50IGNhbiBoYXZlIG11bHRpcGxlIG5ldHdv cmtzLCZuYnNwOyB0aGVyZSBjb3VsZCBiZSA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0O21p bGxpb25zIG9mIGZsb3dzIGluIGVhY2ggb2YgdGhvc2UgbmV0d29ya3MuJm5ic3A7IEFuZCBjb25z aWRlcmluZyBhbGwgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDt0aGVzZSw8L2Rpdj4NCjxk aXY+Jmd0OyZndDsmZ3Q7Jmd0OyAyNCBiaXQgcGF0aCBJRCBtYXkgbm90IGJlIGFibGUgdG8gcmVw cmVzZW50IHBhdGhzIGZvciB0aGVzZSBmbG93cy48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0 O0hlbmNlLCBJIHdhcyB3b25kZXJpbmcgd2hldGhlciBwYXRoIElEIGNhbiBiZSBleHRlbmRlZCB0 byA2NCBiaXRzIG9yIDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7bWFrZSBpdCBmbGV4aWJs ZS48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsm Z3Q7IFRoYW5rczwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7IFNyaW5pPC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZn dDsgRnJvbTogSm9lbCBNLiBIYWxwZXJuICZsdDs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxw ZXJuLmNvbSI+am1oQGpvZWxoYWxwZXJuLmNvbTwvYT4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDQsIDIwMTQgNzo0MiBBTTwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyA8YSBocmVm PSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PiZndDsm Z3Q7Jmd0OyZndDsgQ2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwPC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdDwv ZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7ICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDI8L2E+KTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsm Z3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsgVGhlIEluZGV4IGlzIG5vdCBqdXN0IGZv ciBsb29wIHByZXZlbnRpb24uJm5ic3A7IEluIHRoZSBjYXNlIG9mIDwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyZndDsmZ3Q7YW1iaWd1aXR5LCZuYnNwOyB0aGUgaW5kZXggdGVsbHMgdGhlIFNGRiB3aGVy ZSBpbiB0aGUgcGF0aCB0aGUgcGFja2V0IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Y3Vy cmVudGx5IHJlc2lkZXMuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsm bmJzcDsgVGhlcmUgYXJlIG11bHRpcGxlIHdheXMgc3VjaCBhbWJpZ3VpdHkgY2FuIG9jY3VyLjwv ZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsg VGhlIFBhdGggSWRlbnRpZmllciBpcyBzcGVjaWZpY2FsbHkgbm90IGV4cGVjdGVkIHRvIGluY2x1 ZGUgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsgY29udHJvbGxlciBJRCBvciBUZW5hbnQg SUQuJm5ic3A7IFdoaWxlIGEgZGVwbG95ZXIgY2FuIGhhdmUgYSBwYXRoIHBlciA8L2Rpdj4NCjxk aXY+Jmd0OyZndDsmZ3Q7Jmd0OyB0ZW5hbnQsIHRoZSBhcmNoaXRlY3R1cmUgc3RpbGwgZG9lcyBu b3QgdHJlYXQgdGhlIHBhdGggSUQgYXMgYSA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyB0 ZW5hbnQgSUQuJm5ic3A7IFRlbmFudCBJRCwgY29udHJvbGxlciBJRCwgYW5kIG90aGVyIG5vbi1w YXRoLXNwZWNpZnlpbmcgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsgaW5mb3JtYXRpb24g aXMgdG8gYmUgY2FycmllZCBpbiBtZXRhZGF0YS48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0 OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7IFlvdXJzLDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 OyZndDsmZ3Q7IEpvZWw8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OyZndDsmZ3Q7IE9uIDEyLzQvMTQsIDEwOjAyIEFNLCBTcmluaSBBZGRlcGFsbGkgd3Jv dGU6PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFR3byBjb21tZW50cyA6PC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDEuJm5ic3A7IFNGIEluZGV4IDom bmJzcDsgU2luY2UgaXQgaXMgbWVhbnQgZm9yIGxvb3AgZGV0ZWN0aW9uLCZuYnNwOyB3b3VsZG4n dCA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmV0dGVyIHRvIHJlbmFtZSB0aGlz IGFzICZxdW90O1RUTCZxdW90Oz88L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8L2Rp dj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMi4mbmJzcDsgUGF0aCBJZGVudGlmaWVyIDom bmJzcDsmbmJzcDsmbmJzcDsgMjQgYml0IHBhdGggaWRlbnRpZmllciBzZWVtcyB0byBiZSB0b28g bGVzcy48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQmFzZWQgb24gb3VyIGV4cGVy aWVuY2UgaW4gdHJhZmZpYyBzdGVlcmluZywmbmJzcDsgdGhpcyBwYXRoIGlkZW50aWZpZXImbmJz cDsgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7bmVlZHMgdG8gZW5jb2RlIGdvb2Qg YW1vdW50IG9mIGluZm9ybWF0aW9uIHRvIG1ha2UgaXQgdW5pcXVlLiZuYnNwOyBGb3IgPC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ZXhhbXBsZSw8L2Rpdj4NCjxkaXY+Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhpcyBpZGVudGlmaWVyIG5lZWRzIHRvIGVu Y29kZSAoaW4gb3VyIGNhc2UpIHNvbWUgaW5mb3JtYXRpb24mbmJzcDsgPC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7cmVwcmVzZW50aW5nIHRoZSBkaXN0cmlidXRlZCBjb250cm9sbGVy IElELCZuYnNwOyB0ZW5hbnQgSUQsJm5ic3A7IGZsb3cgSUQsPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2Ug KGluIGNhc2Ugb2Ygc2NhbGUtb3V0KSBhbmQgZmV3IG1vcmUuLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBPbmUgc3VnZ2VzdGlvbiBpcyB0byBtYWtlIGl0IDY0IGJpdHMgdmFsdWUm bmJzcDsgb3IgdG8gbWFrZSBpdCBldmVuIDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 O2V4dGVuZGFibGUsPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGl0IGlzIGdvb2QgaWYgcGF0aCBpZGVudGlmaWVyIGlzIGFsc28gcmVwcmVzZW50ZWQg aW4gVExWIGZvcm0uPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRo YW5rczwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBTcmluaTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZmMgbWFpbGluZyBsaXN0PC9k aXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5v cmciPnNmY0BpZXRmLm9yZzwvYT48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZn dDsmZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2Rp dj4NCjxkaXY+Jmd0OyZndDsmZ3Q7c2ZjIG1haWxpbmcgbGlzdDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 OyZndDs8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7Jmd0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwv YT48L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7 PC9kaXY+DQo8ZGl2PiZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzwvZGl2Pg0KPGRpdj4mZ3Q7c2ZjIG1haWxpbmcgbGlzdDwvZGl2Pg0KPGRpdj4mZ3Q7 PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjwvZGl2Pg0KPGRp dj4mZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjwvZGl2Pg0KPGRp dj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzwvZGl2Pg0KPGRpdj4mZ3Q7c2ZjIG1haWxpbmcgbGlzdDwvZGl2Pg0KPGRp dj4mZ3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjwvZGl2 Pg0KPGRpdj4mZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjwvZGl2 Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzwvZGl2Pg0KPGRpdj4mZ3Q7c2ZjIG1haWxpbmcgbGlzdDwvZGl2 Pg0KPGRpdj4mZ3Q7PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9h PjwvZGl2Pg0KPGRpdj4mZ3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9h PjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188L2Rpdj4NCjxkaXY+c2ZjIG1haWxpbmcgbGlzdDwvZGl2 Pg0KPGRpdj48YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PC9k aXY+DQo8ZGl2PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48L2Rpdj4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_D0F6CD2883CD0kegrayciscocom_-- From nobody Tue Feb 3 16:29:04 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 301121A1B47 for ; Tue, 3 Feb 2015 16:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.497 X-Spam-Level: * X-Spam-Status: No, score=1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, MIME_QP_LONG_LINE=0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-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 qHLuR87RBqPw for ; Tue, 3 Feb 2015 16:28:57 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7461A1B3D for ; Tue, 3 Feb 2015 16:28:56 -0800 (PST) Received: from [192.168.0.183] (WPIS-64-140-207-26.worldpath.net [64.140.207.26]) by lucidvision.com (Postfix) with ESMTP id 262182DBAB93; Tue, 3 Feb 2015 19:28:55 -0500 (EST) Content-Type: multipart/alternative; boundary=Apple-Mail-8537282D-FB07-4B98-96D1-A0D4999E2174 Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Tue, 3 Feb 2015 19:28:53 -0500 Content-Transfer-Encoding: 7bit Message-Id: <7AE1FFB3-9A5F-41BC-B5F8-70DD6CBFB4AD@lucidvision.com> References: <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> To: "Ken Gray (kegray)" Archived-At: Cc: "sfc@ietf.org" , Cathy Zhang , "Zarny, Myo" , "nsmurthy@freescale.com" , Srini Addepalli , "Joel M. Halpern" , "Reinaldo Penno \(repenno\)" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 04 Feb 2015 00:29:02 -0000 --Apple-Mail-8537282D-FB07-4B98-96D1-A0D4999E2174 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I very much agree with ken's comments below. There is no reason to merge the= drafts other than waste everyone's time. If you have something substantive t= o contribute, go head and specify that very specific change. However, coming= up with a draft that is what appears to be %95 the same as the other one do= es not seem like a good reason to merge drafts. You typically only do this w= hen there are two very different approaches that the WG wants combined. This= does not seem like that to me. Tom=20 > On Feb 3, 2015, at 7:20 PM, Ken Gray (kegray) wrote: >=20 > Respectfully, I don=E2=80=99t think TLVs were a unique proposition, as the= se were discussed informally in meetings (that I did attend) =E2=80=A6 have t= o search the list for =E2=80=9CTLV=E2=80=9D uniqueness. Regardless, we shou= ldn=E2=80=99t have had to read three iterations of another document just to g= et that addition. =20 >=20 > Regarding remaining differences =E2=80=A6 I don=E2=80=99t really see any, w= hich makes =E2=80=9Cmerge=E2=80=9D a really inappropriate word for what=E2=80= =99s required. >=20 > If =E2=80=9Cmerge=E2=80=9D means =E2=80=9Ctime=E2=80=9D, I see no reason t= o delay a call for support of the nsh draft. >=20 > On 2/3/15, 5:27 PM, "Zarny, Myo" wrote: >=20 > Hi Ken, > IETF90 minutes explain the differences then. > Yes, the drafts are now very similar because the NSH draft has incorporate= d the TLV portion. > The generic context block is to accommodate NSH's four mandatory context h= eader fields. > The chairs are actively working on a merged document with a section for re= maining differences. > Thanks, > =20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Cathy Zhang > Sent: 3 February 2015 4:54 PM > To: Ken Gray (kegray); Srini Addepalli; Reinaldo Penno (repenno); Joel M. H= alpern; 'sfc@ietf.org'; Cathy Zhang > Cc: nsmurthy@freescale.com > Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draf= t-zhang-sfc-sch-02) > =20 > Hi Ken, > =20 > Please see inline. > =20 > Thanks, > Cathy > =20 > -----Original Message----- > From: Ken Gray (kegray) [mailto:kegray@cisco.com] > Sent: Tuesday, February 03, 2015 10:09 AM > To: Cathy Zhang; Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halper= n; 'sfc@ietf.org' > Cc: nsmurthy@freescale.com > Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draf= t-zhang-sfc-sch-02) > =20 > As a general comment on this submission (and perhaps life in the current I= ETF). I have a REALLY hard time differentiating this draft from the quinn d= raft (which pre-dates it by quite a bit). Why are we pursuing a separate dr= aft when the suggestions, IMHO, seem incremental at best? > =20 > =20 > Cathy> The original motivation for drafting the SCH is to provide an alter= native to draft-quinn-nsh to address the following perceived issues: > 1. Mandatory fixed-sized metadata. We think they should not be mandatory s= ince the 4-word context fields are not needed in many scenarios 2. No variab= le length metadata. We think metadata should be optional and TLV format shou= ld be used to define metadata 3. No organizationally defined metadata 4. No V= ersion field.=20 > When we uploaded SCH 1st version (3/24/2014), NSH version did not have the= TLV metadata and version field (they were added in its later version). > =20 > =20 > =20 > I have reach out to the chairs here . we have a lot to read. Aren't drafts= supposed to offer significantly different views if they are to persist (wit= hout that, a "call to adopt" becomes a beauty contest, IMO)? No offense to t= he authors, but we're in revision 3 and I don't see that here. > =20 > =20 > Regarding the changes in this document: > =20 > I do not find the flow ID functionally different than the use context head= ers in the nsh draft, which seem to be a more multi-purpose concept. > =20 > Cathy> Different people have different viewpoints. RSP ID is not defined i= n NSH and from Paul (NSH author)'s reply, it seems he does not feel the need= of an RSP ID. > Cathy> We see the need for RSP ID and thus defined it in SCH for open disc= ussion and would like to see the community's feedback on it.=20 > =20 > The B bit suggestion can cause a conflict in control and create an avenue f= or undesirable behavior, IMO. I've been working from the assumption that a m= inimum requirement of a function is that it be manageable (if for no other r= eason than effective elasticity and cohesive/predictable delivery of service= ), so I have little sympathy for those that are not - be they virtual or phy= sical (even less sympathy for virtual functions that are unmanageable, frank= ly). A self-management option in the SFC scenario has low value and the cor= ruption or misuse of the bit can cause chaos (an extra level of "fail"). > =20 > Cathy> Could you clarify what you mean by "cause a conflict in control"? > =20 > =20 > The Generic Context Block is confusing in light of the already extant opti= onal/variable metadata TLVs (why wouldn't you leverage one of them)? > =20 > Cathy> I am not sure if I understand your point. The Generic Context Block= is one type of metadata which is in TLV format and is optional. > =20 > Thanks, > Cathy > =20 > =20 > On 1/29/15, 2:44 PM, "Cathy Zhang" wrote: > =20 > >Hi everyone, > > > >We have uploaded a new SCH version (3) which adds definition of a new > >metadata type for the flow ID to support load balancing among SF > >instances and mitigate the potential issue of "not enough path ID". The > >flow ID is named "rendered service path ID" in the draft. Please refer > >to section 4.3.2 of > >https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ > >for detail description. > > > > > >In its previous version, SCH defines a "Bypass bit" in the base header. > >This bit enables the SF to provide feedback/notification via the data > >path to its connecting SFF about whether the remaining packets of the > >SFC should bypass that SF. This is useful in the case that only the > >first few packets of a flow need to go to a SF (such as a DPI or FW or > >IDS) and remaining packets can bypass that SF, thus saving the > >expensive SF resource and reducing data path latency. > > > >B bit: The B (Bypass) bit, when set to 1, it is used by a Service > > Function to signal to its Service Function Forwarder that no > > further packets are to be sent to it for the flow specified in > >encapsulated packet. > > > >In addition, SCH defines a metadata type for Generic Context Block, > >which is optional and can be used if needed to carry any vendor's > >specific "Context Header". > > > > > >Any comments on these new additions? > > > >Thanks, > >Cathy > > > >-----Original Message----- > >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Cathy Zhang > >Sent: Friday, December 05, 2014 11:47 AM > >To: Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; > >'sfc@ietf.org' > >Cc: nsmurthy@freescale.com > >Subject: Re: [sfc] Comments on SCH Draft > >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > > > >Ron, Louis, Myo and I have been discussing off line last few weeks > >about defining a metadata type for flow ID in addition to the path ID > >of the main header to support load balancing among SF instances. We > >will define a TLV type for the flow ID. The combination of "path ID + flo= w ID" > >specifies a realized service chain instance path. It is left to the > >design/implementation whether to use a centralized method or a > >distributed method to bind the flow ID to a realized service instance > >path although our original thought is for distributed LB usage. I am > >not sure if we need a bit in the header to denote whether there are > >more path ID bits (we call it flow ID) in the metadata fields since > >when you parse the TLV metadata, you will know whether there are flow ID b= its or not. > >Note that if multiple sessions share the same realized service instance > >path, they will share the same "path ID+ flow ID". We can also > >consider extending the number of bits to 32 if that is the consensus. > >We will post an updated draft describing these soon. > > > >Thanks, > >Cathy > > > >-----Original Message----- > >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Srini Addepalli > >Sent: Friday, December 05, 2014 7:17 AM > >To: Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf.org' > >Cc: nsmurthy@freescale.com > >Subject: Re: [sfc] Comments on SCH Draft > >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > > > > > >[RP] Data plane efficiency. > > > >SRINI> I am not so sure about data plane efficiency. Most of the > >processors work good if the number of bits are either 32 or 64. If it > >is > >24 bits, then one needs to do masking and shifting before the value is > >used to do any lookup. But, this discussion can go into different > >direction :-), it may not be good to go in that direction. > > > >Where do we draw the line? 32-bits, 64-bits, > >128 bits? I think we should have a sensible value in the Service Path > >header and if you need to convey more bits you need to use the context > >headers. > > > >SRINI> This is a good point. This should work fine as long as there is > >way to convey in the main header that the extension to path ID is > >available in so and so TLV field. That should work too. > > > >Thanks > >Srini > > > >________________________________________ > >From: Reinaldo Penno (repenno) > >Sent: Friday, December 5, 2014 7:08 AM > >To: Addepalli Srini-B22160; Joel M. Halpern; 'sfc@ietf.org' > >Cc: NS Srinivasa Murthy-B37840 > >Subject: Re: [sfc] Comments on SCH Draft > >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > > > >On 12/5/14, 6:54 AM, "Srini Addepalli" wrote: > > > >> > >>In real deployments, number of active path IDs are very lesser than > >>2^64, but there is a good possibility of the number being more than 2^24= (16M). > >> I think bigger point is that why restrict this in the standards? What > >>advantage do we have restricting this size to 24 bits? > > > >[RP] Data plane efficiency. Where do we draw the line? 32-bits, > >64-bits, > >128 bits? I think we should have a sensible value in the Service Path > >header and if you need to convey more bits you need to use the context > >headers. > > > > > >> > >>There can be deployments, where SFC controller (Logically central, but > >>distributed) itself can do the SF instance selection on per > >>connection/session basis, thereby avoiding the LBs for services. In my= > >>view, assumption that there will be LB SF for each scale-out service > >>in the chain is not valid in all cases. > >> > >>Thanks > >>Srini > >> > >>________________________________________ > >>From: Reinaldo Penno (repenno) > >>Sent: Thursday, December 4, 2014 1:17 PM > >>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org > >>Cc: NS Srinivasa Murthy-B37840 > >>Subject: Re: [sfc] Comments on SCH Draft > >>(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > >> > >>If I understood you, I do not think this is realistic. Are you saying > >>you need 64-bits of paths and then will monitor them all? Do fault > >>tolerance and OAM for 2^64-bits worth of paths? Just for comparison, > >>it=C2=B9s like managing and monitoring the entire IPv6 host range, one-b= y-one. > >> > >>Anyway, I do not expect every single permutations to be a different path= . > >> > >>If each service has 256 devices providing similar service, you should > >>most likely use load-balancing and then you would have a single (or a > >>few) paths. There is some discussion going on LB. > >> > >>=46rom a data plane perspective, the path is ultimately defined by the > >>SFFs traversed and services provided, not by a specific IP:port that > >>the device providing the service sits on. Well, at least from a > >>GPE+NSH perspective. > >> > >> > >>On 12/4/14, 12:57 PM, "Srini Addepalli" wrote= : > >> > >>>If I take a chain with 5 services with each service say having 256 > >>>instances for scale-out, possible number of paths are > >>>256*256*256*256*256 > >>>=3D 0xFF FF FF FF FF. One requires 33 bits in this case. If there are > >>>more services in the chain or more chains or more instances for > >>>scale-out, then it could go to big number very fast. > >>> > >>>As I mentioned my preference is to make the path ID size flexible for > >>>future growth. If that is perceived as complex, then going for 64bit > >>>is safer bet. > >>> > >>>Thanks > >>>Srini > >>> > >>> > >>>-----Original Message----- > >>>From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >>>Sent: Thursday, December 04, 2014 12:05 PM > >>>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org > >>>Cc: NS Srinivasa Murthy-B37840 > >>>Subject: Re: [sfc] Comments on SCH Draft > >>>(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > >>> > >>>A controller (or other decision logic) can certainly be aware of such > >>>concerns. > >>>But the number of service function paths is not related to the number > >>>of flows or the number of tenants. It is related to the number of > >>>combinations of services and the policies for service function > >>>selection. > >>> While that can be a large number, I sure hope it does not come close > >>>to saturating 24 bits. > >>> > >>>Having said that, if we think that 24 bits is only just enough, then > >>>we ought to use 32. =46rom where I sit, I would normally expect 16 > >>>bits to be more than sufficient, which is why I am comfortable with > >>>24. Having said that, the field size is not a big deal to me. > >>> > >>>Yours, > >>>Joel > >>> > >>>On 12/4/14, 2:01 PM, Srini Addepalli wrote: > >>>> > >>>> I was not implying that path ID should have information in regards > >>>>to tenant/controller/flow/scale-out. But SFC controllers should > >>>>keep these > >>>>in mind to assign the path ID. A deployment can have multiple > >>>>tenants, each tenant can have multiple networks, there could be > >>>>millions of flows in each of those networks. And considering all > >>>>these, > >>>> 24 bit path ID may not be able to represent paths for these flows. > >>>>Hence, I was wondering whether path ID can be extended to 64 bits or > >>>>make it flexible. > >>>> > >>>> Thanks > >>>> Srini > >>>> > >>>> ________________________________________ > >>>> From: Joel M. Halpern > >>>> Sent: Thursday, December 4, 2014 7:42 AM > >>>> To: Addepalli Srini-B22160; sfc@ietf.org > >>>> Cc: NS Srinivasa Murthy-B37840 > >>>> Subject: Re: [sfc] Comments on SCH Draft > >>>> (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > >>>> > >>>> The Index is not just for loop prevention. In the case of > >>>>ambiguity, the index tells the SFF where in the path the packet > >>>>currently resides. > >>>> There are multiple ways such ambiguity can occur. > >>>> > >>>> The Path Identifier is specifically not expected to include > >>>> controller ID or Tenant ID. While a deployer can have a path per > >>>> tenant, the architecture still does not treat the path ID as a > >>>> tenant ID. Tenant ID, controller ID, and other non-path-specifying > >>>> information is to be carried in metadata. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 12/4/14, 10:02 AM, Srini Addepalli wrote: > >>>>> Two comments : > >>>>> > >>>>> > >>>>> 1. SF Index : Since it is meant for loop detection, wouldn't > >>>>> better to rename this as "TTL"? > >>>>> > >>>>> 2. Path Identifier : 24 bit path identifier seems to be too less= . > >>>>> Based on our experience in traffic steering, this path identifier=20= > >>>>>needs to encode good amount of information to make it unique. For > >>>>>example, > >>>>> this identifier needs to encode (in our case) some information=20= > >>>>>representing the distributed controller ID, tenant ID, flow ID, > >>>>> Service function instance (in case of scale-out) and few more.. > >>>>> One suggestion is to make it 64 bits value or to make it even > >>>>>extendable, > >>>>> it is good if path identifier is also represented in TLV form. > >>>>> > >>>>> > >>>>> Thanks > >>>>> > >>>>> Srini > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > =20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > =20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail-8537282D-FB07-4B98-96D1-A0D4999E2174 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I very much agree with ken's comments b= elow. There is no reason to merge the drafts other than waste everyone's tim= e. If you have something substantive to contribute, go head and specify that= very specific change. However, coming up with a draft that is what appears t= o be %95 the same as the other one does not seem like a good reason to merge= drafts. You typically only do this when there are two very different approa= ches that the WG wants combined. This does not seem like that to me.

Tom 




On Feb 3, 2= 015, at 7:20 PM, Ken Gray (kegray) <k= egray@cisco.com> wrote:

Respectfully, I don=E2=80=99t think TLVs were a unique proposition, as t= hese were discussed informally in meetings (that I did attend) =E2=80=A6 hav= e to search the list for =E2=80=9CTLV=E2=80=9D uniqueness.  Regardless,= we shouldn=E2=80=99t have had to read three iterations of another document just to get that addition.  

Regarding remaining differences =E2=80=A6 I don=E2=80=99t really see an= y, which makes =E2=80=9Cmerge=E2=80=9D a really inappropriate word for what=E2= =80=99s required.

If =E2=80=9Cmerge=E2=80=9D means =E2=80=9Ctime=E2=80=9D, I see no reaso= n to delay a call for support of the nsh draft.

On 2/3/15, 5:27 PM, "Zarny, Myo" <Myo.Zarny@gs.com> wrote:

Hi Ken,
  • IETF90 minutes explain t= he differences then.
  • Yes, the drafts are now v= ery similar because the NSH draft has incorporated the TLV portion.
  • The generic context block is t= o accommodate NSH's four mandatory context header fields.
  • The chairs are actively w= orking on a merged document with a section for remaining differences.
    • Thanks,
     
    -----Original Message-----
    From: sfc [mailto:sfc-bounces@ietf.o= rg] On Behalf Of Cathy Zhang
    Sent: 3 February 2015 4:54 PM
    To: Ken Gray (kegray); Srini Addepalli; Reinaldo Penno (repenno); Joel M. Ha= lpern; 'sfc@ietf.org'; Cathy Zhang
    Cc: nsmurthy@freescale.com
    = Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch= -02)
     
    Hi Ken,
     
    Please see inline.
     
    Thanks,
    Cathy
     
    -----Original Message-----
    From: Ken Gray (kegray) [mailto:keg= ray@cisco.com]
    Sent: Tuesday, February 03, 2015 10:09 AM
    To: Cathy Zhang; Srini Addepalli; Reinaldo Penno (repenno); Joel M. Hal= pern; 'sfc@ietf.org'
     
    As a general comment on this submission (and perhaps life in the curren= t IETF).  I have a REALLY hard time differentiating this draft from the= quinn draft (which pre-dates it by quite a bit).  Why are we pursuing a= separate draft when the suggestions, IMHO, seem incremental at best?
     
     
    Cathy> The original motivation for drafting the SCH is to provide an= alternative to draft-quinn-nsh to address the following perceived issues:
    1. Mandatory fixed-sized metadata. We think they should not be mandator= y since the 4-word context fields are not needed in many scenarios 2. No var= iable length metadata. We think metadata should be optional and TLV format s= hould be used to define metadata 3. No organizationally defined metadata 4. No Version field. 
    When we uploaded SCH 1st version (3/24/2014), NSH version did not have t= he TLV metadata and version field (they were added in its later version).
     
     
     
    I have reach out to the chairs here . we have a lot to read. Aren't dra= fts supposed to offer significantly different views if they are to persist (= without that, a "call to adopt" becomes a beauty contest, IMO)?  No off= ense to the authors, but we're in revision 3 and I don't see that here.
     
     
    Regarding the changes in this document:
     
    I do not find the flow ID functionally different than the use context h= eaders in the nsh draft, which seem to be a more multi-purpose concept.
     
    Cathy> Different people have different viewpoints. RSP ID is not def= ined in NSH and from Paul (NSH author)'s reply, it seems he does not feel th= e need of an RSP ID.
    Cathy> We see the need for RSP ID and thus defined it in SCH for ope= n discussion and would like to see the community's feedback on it. 
     
    The B bit suggestion can cause a conflict in control and create an aven= ue for undesirable behavior, IMO.  I've been working from the assumptio= n that a minimum requirement of a function is that it be manageable (if for n= o other reason than effective elasticity and cohesive/predictable delivery of service), so I have little sympathy fo= r those that are not - be they virtual or physical (even less sympathy for v= irtual functions that are unmanageable, frankly).  A self-management op= tion in the SFC scenario has low value and the corruption or misuse of the bit can cause chaos (an extra level of "= fail").
     
    Cathy> Could you clarify what you mean by "cause a conflict in contr= ol"?
     
     
    The Generic Context Block is confusing in light of the already extant o= ptional/variable metadata TLVs (why wouldn't you leverage one of them)?
     
    Cathy> I am not sure if I understand your point. The Generic Context= Block is one type of metadata which is in TLV format and is optional.
     
    Thanks,
    Cathy
     
     
    On 1/29/15, 2:44 PM, "Cathy Zhang" <Cathy.H.Zhang@huawei.com> wrote:
     
    >Hi everyone,
    >
    >We have uploaded a new SCH version (3) which adds definition of a n= ew
    >metadata type for the flow ID to support load balancing among SF
    >instances and mitigate the potential issue of "not enough path ID".= The
    >flow ID is named "rendered service path ID" in the draft. Please re= fer
    >to section 4.3.2 of
    >for detail description.
    >
    >
    >In its previous version, SCH defines a "Bypass bit" in the base hea= der.
    >This bit enables the SF to provide feedback/notification via the da= ta
    >path to its connecting SFF about whether the remaining packets of t= he
    >SFC should bypass that SF. This is useful in the case that only the=
    >first few packets of a flow need to go to a SF (such as a DPI or FW= or
    >IDS) and remaining packets can bypass that SF, thus saving the
    >expensive SF resource and reducing data path latency.
    >
    >B bit: The B (Bypass) bit, when set to 1, it is used by a Service
    >       Function to signal to its Serv= ice Function Forwarder that no
    >       further packets are to be sent= to it for the flow specified in
    >encapsulated packet.
    >
    >In addition, SCH defines a metadata type for Generic Context Block,=
    >which is optional and can be used if needed to carry any vendor's <= /div>
    >specific "Context Header".
    >
    >
    >Any comments on these new additions?
    >
    >Thanks,
    >Cathy
    >
    >-----Original Message-----
    >From: sfc [mailto:sfc-bounc= es@ietf.org] On Behalf Of Cathy Zhang
    >Sent: Friday, December 05, 2014 11:47 AM
    >To: Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern;
    >Subject: Re: [sfc] Comments on SCH Draft
    >
    >Ron, Louis, Myo and I have been discussing off line last few weeks <= /div>
    >about defining a metadata type for flow ID in addition to the path I= D
    >of the main header to support load balancing among SF instances. We=
    >will define a TLV type for the flow ID. The combination of "path ID= + flow ID"
    >specifies a realized service chain instance path. It is left to the=
    >design/implementation whether to use a centralized method or a
    >distributed method to bind the flow ID to a realized service instan= ce
    >path although our original thought is for distributed LB usage. I a= m
    >not sure if we need a bit in the header to denote whether there are=
    >more path ID bits (we call it flow ID) in the metadata fields since=
    >when you parse the TLV metadata, you will know whether there are fl= ow ID bits or not.
    >Note that if multiple sessions share the same realized service inst= ance
    >path, they will share the same "path ID+ flow ID".  We can als= o
    >consider extending the number of bits to 32 if that is the consensu= s.
    >We will post an updated draft describing these soon.
    >
    >Thanks,
    >Cathy
    >
    >-----Original Message-----
    >From: sfc [mailto:sfc-bounc= es@ietf.org] On Behalf Of Srini Addepalli
    >Sent: Friday, December 05, 2014 7:17 AM
    >To: Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf.org'
    >Subject: Re: [sfc] Comments on SCH Draft
    >
    >
    >[RP] Data plane efficiency.
    >
    >SRINI> I am not so sure about data plane efficiency.  Most o= f the
    >processors work good if the number of bits are either 32 or 64.&nbs= p; If it
    >is
    >24 bits, then one needs to do masking and shifting before the value= is
    >used to do any lookup.   But, this discussion can go into= different
    >direction :-), it may not be good to go in that direction.
    >
    >Where do we draw the line? 32-bits, 64-bits,
    >128 bits? I think we should have a sensible value in the Service Pa= th
    >header and if you need to convey more bits you need to use the cont= ext
    >headers.
    >
    >SRINI> This is a good point.  This should work fine as long= as there is
    >way to convey in the main header that the extension to path ID is <= /div>
    >available in so and so TLV field.  That should work too.
    =
    >
    >Thanks
    >Srini
    >
    >________________________________________
    >From: Reinaldo Penno (repenno) <repenno@cisco.com>
    >Sent: Friday, December 5, 2014 7:08 AM
    >To: Addepalli Srini-B22160; Joel M. Halpern; 'sfc@ietf.org'
    >Cc: NS Srinivasa Murthy-B37840
    >Subject: Re: [sfc] Comments on SCH Draft
    >
    >On 12/5/14, 6:54 AM, "Srini Addepalli" <saddepalli@freescale.com> wrote:
    >
    >>
    >>In real deployments, number of active path IDs are very lesser t= han
    >>2^64, but there is a good possibility of the number being more t= han 2^24 (16M).
    >> I think bigger point is that why restrict this in the standard= s? What
    >>advantage do we have restricting this size to 24 bits?
    >
    >[RP] Data plane efficiency. Where do we draw the line? 32-bits,
    >64-bits,
    >128 bits? I think we should have a sensible value in the Service Pa= th
    >header and if you need to convey more bits you need to use the cont= ext
    >headers.
    >
    >
    >>
    >>There can be deployments, where SFC controller (Logically centr= al, but
    >>distributed)  itself can do the SF instance selection on p= er
    >>connection/session basis, thereby avoiding the LBs for services= .   In my
    >>view, assumption that there will be LB SF for each scale-out se= rvice
    >>in the chain is not valid in all cases.
    >>
    >>Thanks
    >>Srini
    >>
    >>________________________________________
    >>From: Reinaldo Penno (repenno) <repenno@cisco.com>
    >>Sent: Thursday, December 4, 2014 1:17 PM
    >>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org
    >>Cc: NS Srinivasa Murthy-B37840
    >>Subject: Re: [sfc] Comments on SCH Draft
    >>
    >>If I understood you, I do not think this is realistic. Are you s= aying
    >>you need 64-bits of paths and then will monitor them all? Do fa= ult
    >>tolerance and OAM for 2^64-bits worth of paths? Just for compar= ison,
    >>it=C2=B9s like managing and monitoring the entire IPv6 host ran= ge, one-by-one.
    >>
    >>Anyway, I do not expect every single permutations to be a diffe= rent path.
    >>
    >>If each service has 256 devices providing similar service, you s= hould
    >>most likely use load-balancing and then you would have a single= (or a
    >>few) paths. There is some discussion going on LB.
    >>
    >>=46rom a data plane perspective, the path is ultimately defined= by the
    >>SFFs traversed and services provided, not by a specific IP:port= that
    >>the device providing the service sits on. Well, at least from a=
    >>GPE+NSH perspective.
    >>
    >>
    >>On 12/4/14, 12:57 PM, "Srini Addepalli" <saddepalli@freescale.com> wrote:
    >>
    >>>If I take a chain with 5 services with each service  s= ay having 256
    >>>instances for scale-out, possible number of paths are
    =
    >>>256*256*256*256*256
    >>>=3D 0xFF FF FF FF FF. One requires 33 bits in this case.&nb= sp; If there are
    >>>more services in the chain or more chains or more instances= for
    >>>scale-out, then it could go to big number very fast.
    >>>
    >>>As I mentioned my preference is to make the path ID size fl= exible for
    >>>future growth. If that is perceived as complex, then going f= or 64bit
    >>>is safer bet.
    >>>
    >>>Thanks
    >>>Srini
    >>>
    >>>
    >>>-----Original Message-----
    >>>From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
    >>>Sent: Thursday, December 04, 2014 12:05 PM
    >>>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org
    >>>Cc: NS Srinivasa Murthy-B37840
    >>>Subject: Re: [sfc] Comments on SCH Draft
    >>>
    >>>A controller (or other decision logic) can certainly be awa= re of such
    >>>concerns.
    >>>But the number of service function paths is not related to t= he number
    >>>of flows or the number of tenants.  It is related to t= he number of
    >>>combinations of services and the policies for service funct= ion
    >>>selection.
    >>> While that can be a large number, I sure hope it does not c= ome close
    >>>to saturating 24 bits.
    >>>
    >>>Having said that, if we think that 24 bits is only just eno= ugh, then
    >>>we ought to use 32.  =46rom where I sit, I would norma= lly expect 16
    >>>bits to be more than sufficient, which is why I am comforta= ble with
    >>>24.  Having said that, the field size is not a big dea= l to me.
    >>>
    >>>Yours,
    >>>Joel
    >>>
    >>>On 12/4/14, 2:01 PM, Srini Addepalli wrote:
    >>>>
    >>>> I was not implying that path ID should have informatio= n in regards
    >>>>to tenant/controller/flow/scale-out.  But SFC cont= rollers should
    >>>>keep these
    >>>>in mind to assign the path ID.    A depl= oyment can have multiple
    >>>>tenants, each tenant can have multiple networks,  t= here could be
    >>>>millions of flows in each of those networks.  And c= onsidering all
    >>>>these,
    >>>> 24 bit path ID may not be able to represent paths for t= hese flows.
    >>>>Hence, I was wondering whether path ID can be extended t= o 64 bits or
    >>>>make it flexible.
    >>>>
    >>>> Thanks
    >>>> Srini
    >>>>
    >>>> ________________________________________
    >>>> From: Joel M. Halpern <jmh@joelhalpern.com>
    >>>> Sent: Thursday, December 4, 2014 7:42 AM
    >>>> To: Addepalli Srini-B22160; sfc@ietf.org
    >>>> Cc: NS Srinivasa Murthy-B37840
    >>>> Subject: Re: [sfc] Comments on SCH Draft
    >>>>
    >>>> The Index is not just for loop prevention.  In th= e case of
    >>>>ambiguity,  the index tells the SFF where in the p= ath the packet
    >>>>currently resides.
    >>>>    There are multiple ways such ambigui= ty can occur.
    >>>>
    >>>> The Path Identifier is specifically not expected to in= clude
    >>>> controller ID or Tenant ID.  While a deployer can= have a path per
    >>>> tenant, the architecture still does not treat the path= ID as a
    >>>> tenant ID.  Tenant ID, controller ID, and other n= on-path-specifying
    >>>> information is to be carried in metadata.
    >>>>
    >>>> Yours,
    >>>> Joel
    >>>>
    >>>> On 12/4/14, 10:02 AM, Srini Addepalli wrote:
    >>>>> Two comments :
    >>>>>
    >>>>>
    >>>>> 1.  SF Index :  Since it is meant for lo= op detection,  wouldn't
    >>>>> better to rename this as "TTL"?
    >>>>>
    >>>>> 2.  Path Identifier :    24 bi= t path identifier seems to be too less.
    >>>>> Based on our experience in traffic steering, = this path identifier 
    >>>>>needs to encode good amount of information to make i= t unique.  For
    >>>>>example,
    >>>>>    this identifier needs to encode (= in our case) some information 
    >>>>>representing the distributed controller ID,  t= enant ID,  flow ID,
    >>>>>    Service function instance (in ca= se of scale-out) and few more..
    >>>>> One suggestion is to make it 64 bits value  o= r to make it even
    >>>>>extendable,
    >>>>>    it is good if path identifier is= also represented in TLV form.
    >>>>>
    >>>>>
    >>>>> Thanks
    >>>>>
    >>>>> Srini
    >>>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>> _______________________________________________
    >>>>> sfc mailing list
    >>>>> sfc@ietf.org
    >>>>>
    >>>
    >>>_______________________________________________
    >>>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/lis= tinfo/sfc
= --Apple-Mail-8537282D-FB07-4B98-96D1-A0D4999E2174-- From nobody Tue Feb 3 16:56:44 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 3456D1A8700 for ; Tue, 3 Feb 2015 16:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, 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 r2BPYCasog2s for ; Tue, 3 Feb 2015 16:56:39 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DBB1A82E2 for ; Tue, 3 Feb 2015 16:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1423011399; x=1454547399; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=VV839HuJmUhRqXmkS/4VC1lMvSoElyhHQYsk+wFYJXU=; b=gMG+CasfY/IjyPLeGEMQwmwvV0cICXnkbvkblYOZ0xeYx9tqVSyvMHuG 2PAJHwqItjh+zeMCsXkBS5ehFKxy73xbjBWCIb4TVb010C4Y1/MSzdieY B53gDE4DHWwEIcRDT+tMWz5iqmaSQ2QWt/0zFX8jitbGwPZ46oR0/pSE8 0=; X-IronPort-AV: E=Sophos;i="5.09,516,1418083200"; d="scan'208";a="147819769" X-IPAS-Result: AsIHAO5t0VTAqArr/2dsb2JhbABQCoNYWQSCNkfBXyEKhXECHIFAAQEBAQEBfIQMAQEBAQMBAQEJFxEgEQIHCwwEAgEGAhEBAwEBAQICIwMCAgIlCxQBAgYIAgQBDQWIOqMEnGyWTwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGIbYUHBykIEBYFBwICAoJigUEFklpjhgyDA4sIgz2CJBwUgTxvAYFDfgEBAQ Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 04 Feb 2015 00:56:26 +0000 Received: from SEAEXCHMBX05.olympus.F5Net.com (192.168.15.227) by SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 3 Feb 2015 16:56:25 -0800 Received: from SEAEXCHMBX05.olympus.F5Net.com ([fe80::7117:d67:574f:bdd3]) by SEAEXCHMBX05.olympus.F5Net.com ([fe80::7117:d67:574f:bdd3%21]) with mapi id 15.00.0995.028; Tue, 3 Feb 2015 16:56:25 -0800 From: Sumandra Majee To: Cathy Zhang , Nicolas BOUTHORS , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZyAGG+AgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgD//7j7oIBVIj4ggALqPwCAADaLgIAEqiHQgAHBmoA= Date: Wed, 4 Feb 2015 00:56:25 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.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.3.9.131030 x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-ID: <6CED2C322C47E543BF95D2C79F0B5B05@F5.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Jerome TOLLET Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 04 Feb 2015 00:56:43 -0000 Q2F0aHk+IFJTUCBJRCBpcyB1c2VkIGJ5IFNGRiB0byBpZGVudGlmeSBhIHJlbmRlcmVkIHBhdGgg b2Ygc2VydmljZQ0KaW5zdGFuY2VzLiBTbyBFdmVuIFNGRiBoYXZlIHRoZSBiZXN0IGtub3dsZWRn ZSB0byBzZWxlY3QgdGhlIFNGeCwNCkNhdGh5PiBhZnRlciB0aGUgU0ZGIHNlbGVjdHMgdGhlIFNG eCBhbmQgYmluZHMgaXQgdG8gdGhlIFJTUCBJRCwgZm9sbG93LW9uDQpwYWNrZXRzIGNhbiBqdXN0 IGJlIGZvcndhcmRlZCBiYXNlZCBvbiBSU1AgSUQuDQoNCg0KDQpTbyBSU1AgSVMgaXMgYSBzdGF0 ZSB0aGF0IGlzIGxvY2FsIHRvIFNGRih4KS4gTXkgcG9pbnQgaXMgdGhhdCBpbiB0aGF0DQpjYXNl IHRoZXJlIGlzIG5vIHJlYXNvbiB0byAqU0hBUkUqIHRoZSBzdGF0ZS4gSWYgeW91IGFyZSBsb29r aW5nIHRvIGJpbmQNCmFsbCBwa3RzIGZvciBnaXZlbiBmbG93L2FwcC90cmFuc2FjdGlvbiBldGMu IHRoZW4gcGxlYXNlIGxvb2sgYXQNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWd1aWNoYXJkLXNmYy1uc2gtZGMtYWxsb2NhdGlvbiBhbmQNCm1vcmUgc3BlY2lmaWNhbGx5 IGF0IFNlcnZpY2VUYWcgcG9ydGlvbiBvZiBpdA0KDQpUaGlzIGlzIGFuIGV4YW1wbGUgb24gaG93 IHRvIGNhcnZlIG91dCB0aGUgc2hhcmVkIGNvbnRleHQgYW5kIHRhZyBmbG93cw0KZXRjLiANCg0K SWYgYSBjb250cm9sbGVyIHdhbnRzIHRvIHByZXNlbGVjdCBhIHBhcnRpY3VsYXIgU0YoeCkgaW5z dGFuY2UgdGhlbiBpdCBjYW4NCnVzZSBOU0ggc2hhcmVkIGNvbnRleHQgaWYgbmVjZXNzYXJ5Lg0K DQpPbiAyLzIvMTUsIDI6NDIgUE0sICJDYXRoeSBaaGFuZyIgPENhdGh5LkguWmhhbmdAaHVhd2Vp LmNvbT4gd3JvdGU6DQoNCj5IaSBTdW1hbmRyYSwNCj4NCj5UaGFuayB5b3UgZm9yIHlvdXIgY29t bWVudHMuIFBsZWFzZSBzZWUgaW5saW5lLg0KPg0KPkNhdGh5DQo+DQo+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj5Gcm9tOiBTdW1hbmRyYSBNYWplZSBbbWFpbHRvOlMuTWFqZWVARjUuY29t XQ0KPlNlbnQ6IEZyaWRheSwgSmFudWFyeSAzMCwgMjAxNSAyOjUzIFBNDQo+VG86IE5pY29sYXMg Qk9VVEhPUlM7IENhdGh5IFpoYW5nOyAnc2ZjQGlldGYub3JnJw0KPkNjOiBKZXJvbWUgVE9MTEVU DQo+U3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPihodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4NCj5IZWxsbywNCj4N Cj5UaGlzIGlzIGFuIGludGVyZXN0aW5nIGRpc2N1c3Npb24gYW5kIEkgd291bGQgbGlrZSB0byB1 bmRlcnN0YW5kIHRoZQ0KPm1vdGl2YXRpb24gb2YgYmV0dGVyLiBUaGUgdHJvdWJsZSB3aXRoIGEg cHJvdG9jb2wgZG9jdW1lbnQgaXMgdGhhdCBpdCBpcw0KPnR5cGljYWxseSBoYXMgaW5hZGVxdWF0 ZSBkZXRhaWwgYWJvdXQgdGhlIGxvZ2ljLiBTbyB0byBjYXN0IHRoaXMgaW50bw0KPnNvbWV3aGF0 IG9mIGEgY29uY3JldGUgdGVybXMsIGNvbnNpZGVyIHRoZSBmb2xsb3dpbmcuDQo+DQo+DQo+ICAg IA0KPiAgICAgICBTRkYoeCkgIHsgU2Z4KDEpIFNmeCgyKeKAplNmeChuKSB9ICAg4oCU4oCU4oCU 4oCUPiAgIFNGRih5KSB7IFNmeSgxKSBTZnkoMikNCj7igKYuIFNmeShtKSB9ICAgOjogTG9naWNh bCBDaGFpbiBpbiBPTkUgZGlyZWN0aW9uIG9ubHkuDQo+ICAgICAgIA0KPiAgICAgICBQSFlTSUNB TCBXT1JMRDoNCj4gICAgICAgICAgQSkgdGhlIFNGRiBjb3VsZCBiZSBhDQo+ICAgICAgICAgICAg LSBjb21wb25lbnQgb2YgVlNXSVRDSCAocGljayB5b3VyIGZhdiBwcm90b2NvbCBmb3IgY29uZmln dXJpbmcNCj50aG9zZSBlbnRpdGllcyB9DQo+ICAgICAgICAgICAgLSBBIGxvYWQgYmFsYW5jZXIN Cj4gICAgICAgICAgICAtIEEgSFcgc3dpdGNoL3JvdXRlciBzb21lIEwyL0wzIGNvbWJvDQo+DQo+ ICAgICAgICAgIEIpIFNmIGluc3RhbmNlIGNvdWxkIGJlLA0KPiAgICAgICAgICAgICAgIC0gVmly dHVhbCBtYWNoaW5lLCAjTiBvZiB0aG9zZQ0KPiAgICAgICAgICAgICAgIC0gcGh5c2ljYWwNCj4g ICAgICAgICAgICAgICAtIENvbnRhaW5lciAjTSB3aGljaCBpcyBvZnRlbiA1IG9yIG1vcmUgeCAj Tg0KPiAgICAgICAgICAgICAgIC0gQ2x1c3RlciB0aGF0IHdlIGRvbuKAmXQga25vdw0KPg0KPkl0 IGlzIHBvc3NpYmxlIHRvIGhhdmUgbXVsdGlwbGUgcGh5c2ljYWwgU0ZGKHgpIGFsc28uDQo+DQo+ QSBzZWxlY3Rpb24gb2YgYSBnaXZlbiBTRiAoc2VydmljZSkoaW5zdGFuY2UpIGlzIGEgY2FuIGJl IHNpbXBsZSBvcg0KPmNvbXBsZXguIEZvciBleGFtcGxlIFNGRih4KSBtYXkgaGF2ZSB0aGUgYmVz dCBrbm93bGVkZ2UgdG8gc2VsZWN0IFNmeCgxKQ0KPmJhZWQgb24gYSBnaXZlbiBjcml0ZXJpb24g KHdoaWNoIGNvdWxkIGJlIHBhcnQgb2YgdGhlIHBvbGljeSkuICBUaGVuIEkNCj5kb27igJl0IHNl ZSBhIHJlYXNvbiB0byBoYXZlIFJTUC4NCj4NCj5DYXRoeT4gUlNQIElEIGlzIHVzZWQgYnkgU0ZG IHRvIGlkZW50aWZ5IGEgcmVuZGVyZWQgcGF0aCBvZiBzZXJ2aWNlDQo+aW5zdGFuY2VzLiBTbyBF dmVuIFNGRiBoYXZlIHRoZSBiZXN0IGtub3dsZWRnZSB0byBzZWxlY3QgdGhlIFNGeCwNCj5DYXRo eT4gYWZ0ZXIgdGhlIFNGRiBzZWxlY3RzIHRoZSBTRnggYW5kIGJpbmRzIGl0IHRvIHRoZSBSU1Ag SUQsDQo+Zm9sbG93LW9uIHBhY2tldHMgY2FuIGp1c3QgYmUgZm9yd2FyZGVkIGJhc2VkIG9uIFJT UCBJRC4NCj4NCj5JdCBpcyBwb3NzaWJsZSB0aGF0IGxvb2t1cCAocGF0aCkgQCBTRkYoeCkgcHJv ZHVjZXMgYSBzcGVjaWZpYyBpbnN0YW5jZSBvZg0KPlNmeSBhbmQgeWVzIHRoZW4gc29tZXRoaW5n IGxpa2UgUlNQIHdvdWxkIGJlIHJlcXVpcmVkLiBCdXQgSSB3b3VsZCBhcmd1ZQ0KPnRoYXQgam9i IFNGRih5KSBjYW4gYWxzbyBiZSBzdWJzdW1lZCBieSBTRkYoeCkuDQo+DQo+Q2F0aHk+IEkgZG8g bm90IGdldCB3aGF0IHlvdSBtZWFuIGhlcmUuIENvdWxkIHlvdSBjbGFyaWZ5Pw0KPg0KPklzIGl0 IHBvc3NpYmxlIGZvciBhIGNlbnRyYWwgY29udHJvbGxlciB0byBwaWNrIGVhY2ggaW5zdGFuY2Ug b2Ygc2VydmljZSwNCj5idXQgc3VjaCBhbiBpbXBsZW1lbnRhdGlvbiB0ZW5kcyB0byBzY2FsZSBw b29ybHkuIFRoZSBhbW91bnQgb2Ygc3RhdGUsDQo+cHJvYmFiaWxpdHkgb2YgYSBpbnN0YW5jZSBn b2luZyBkb3duIGJldHdlZW4gc2VsZWN0aW9uIGFuZCBmbG93IGFycml2YWwNCj5nb2VzIHVwLiAN Cj4NCj5SZWdhcmRzLg0KPg0KPlN1bWFuZHJhDQo+DQo+DQo+DQo+T24gMS8zMC8xNSwgMzozOCBB TSwgIk5pY29sYXMgQk9VVEhPUlMiIDxOaWNvbGFzLkJPVVRIT1JTQHFvc21vcy5jb20+DQo+d3Jv dGU6DQo+DQo+PkhlbGxvIENhdGh5LA0KPj4NCj4+SW5kZWVkIHRoZSBub3Rpb24gb2YgInJlbmRl cmVkIHNlcnZpY2UgcGF0aCBJRCIoUlNQIElEKSBzZWVtcyByZWxldmFudCBhcw0KPj50aGUgYXJj aGl0ZWN0dXJlIGRvY3VtZW50IHN0aXB1bGF0ZXMgdGhhdCB0aGUgU2VydmljZSBGdW5jdGlvbiBQ YXRoIChTRlApDQo+PnByb3ZpZGVzIGFuIGFic3RyYWN0IG5vdGlvbiBvZiBhIHNlcnZpY2UgY2hh aW4sIHdoaWxlIHRoZSBSU1AgaXMgYQ0KPj5jb25zdHJhaW5lZCBsaXN0IG9mIGxvY2F0aW9ucy4N Cj4+DQo+PlNGQyBoZWFkZXIgIlNlcnZpY2UgUGF0aCBJZGVudGlmaWVyIiAoU1BJKSAgaXMgdXNl ZCBpbiBib3RoIE5TSCBhbmQgU0NIDQo+PnByb3RvY29sIGFuZCBpbiBib3RoIGNhc2Ugc2VlbSB0 byBpZGVudGlmeSB0byBhIHBhcnRpY3VsYXIgU0ZQLg0KPj4NCj4+TlNIKHY1KSBmb3IgZXhhbXBs ZSBzdGF0ZXMgdGhhdA0KPj4iIEFzIGRlc2NyaWJlZCBhYm92ZSwgTlNIIGNvbnRhaW5zIGEgc2Vy dmljZSBwYXRoIGlkZW50aWZpZXIgKFNQSSkgYW5kDQo+PiAgIGEgc2VydmljZSBpbmRleCAoU0kp LiAgVGhlIFNQSSBpcywgYXMgcGVyIGl0cyBuYW1lLCBhbiBpZGVudGlmaWVyLg0KPj4gICBUaGUg U1BJIGFsb25lIGNhbm5vdCBiZSB1c2VkIHRvIGZvcndhcmQgcGFja2V0cyBhbG9uZyBhIHNlcnZp Y2UgcGF0aC4NCj4+ICAgUmF0aGVyIHRoZSBTUEkgcHJvdmlkZSBhIGxldmVsIG9mIGluZGlyZWN0 aW9uIGJldHdlZW4gdGhlIHNlcnZpY2UNCj4+ICAgcGF0aC90b3BvbG9neSBhbmQgdGhlIHRoZSBu ZXR3b3JrIHRyYW5zcG9ydC4gIEZ1cnRoZXJtb3JlLCB0aGVyZSBpcw0KPj4gICBubyByZXF1aXJl bWVudCwgb3IgZXhwZWN0YXRpb24gb2YgYW4gU1BJIGJlaW5nIGJvdW5kIHRvIGEgcHJlLQ0KPj4g ICBkZXRlcm1pbmVkIG9yIHN0YXRpYyBuZXR3b3JrIHBhdGguIg0KPj4NCj4+U3RpbGwgTlNIKHY1 KSAgc2hvd3MgdGhhdCBTUEkgKG5vdCBhIFJTUCBJRCkgIHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBr ZXkNCj4+ZWxlbWVudCBvZiBhbiBTRkYgdG8gbG9va3VwIG9uIGZvcndhcmRpbmcgdGFibGVzLiAg QnV0IEkgY291bGQgbm90IGZpbmQNCj4+aW4gTlNIICBob3cgdG8gdXNlIHRoZSBub3Rpb24gb2YN Cj4+UmVuZGVyZWQgc2VydmljZSBwYXRoIHdoaWNoIHdhcyBkZWZpbmVkIGluIHRoZSBhcmNoaXRl Y3R1cmUgZG9jdW1lbnQuDQo+Pg0KPj5Zb3UgcHJvcG9zYWwgc2VlbXMgdG8gbWUgdmVyeSB1c2Vm dWwsDQo+Pg0KPj5BbiBSU1AgSUQgKGluZGVwZW5kZW50IG9mIHRoZSBTUEkgYnV0IHBhcnQgb2Yg dGhlIHNhbWUgbmFtZSBzcGFjZSkgY291bGQNCj4+YmUgdXNlZCB0aGUgc2FtZSB3YXkgYXMgU1BJ IGJ5IFNGRiBmb3IgZXhhbXBsZSwgYWxsb3dpbmcgYSBTZXJ2aWNlDQo+PkNsYXNzaWZpZXIgdG8g Y29udHJvbCByZW1vdGUgbG9hZCBiYWxhbmNpbmcgZm9yIGV4YW1wbGUuDQo+Pg0KPj5UaGlzIHNh aWQgdGhlIFJTUCBJRCB2YWx1ZXMgY291bGQgYmUgcmVsYXRpdmUgdG8gYSBwYXJ0aWN1bGFyIFNl cnZpY2UNCj4+UGF0aCwgd2hpY2ggd291bGQgcmV2ZW50IHVzaW5nIHRoZW0gYXMgd2UgZG8gZm9y IFNQSSBpbiBTRkYgZm9yd2FyZGluZw0KPj50YWJsZXMuDQo+Pg0KPj5XZSBtYXkgd2FudCB0byBw cmVjaXNlIGlmIHRoZSBSU1AgSUQgaXMgdG8gYmUgcmVsYXRpdmUgb2YgYWJzb2x1dGUsIGFzIGl0 DQo+PnNob3VsZCBoYXZlIGFuIGltcGFjdCBvbiBmb3J3YXJkaW5nIHRhYmxlIHN0cnVjdHVyZSBp ZiB3ZSBkZWNpZGUgdG8gdXNlDQo+PnRoaXMgY29uY2VwdC4NCj4+DQo+PlBlcnNvbmFsbHkgSSBs aWtlIHRoZSBub3Rpb24gb2YgYSByZWxhdGl2ZSBSU1AgSUQsIGFzIHdlIGNvdWxkIHRoZW4gdXNl DQo+PnNvbWUgY29udmVudGlvbnMsIHN0cnVjdHVyZSBpdCwgcG9zc2libHkgZXh0ZW5kaW5nIGl0 cyB1c2UuDQo+Pg0KPj5OaWNvbGFzDQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj5Gcm9tOiBDYXRoeSBaaGFuZyBbbWFpbHRvOkNhdGh5LkguWmhhbmdAaHVhd2VpLmNvbV0NCj4+ U2VudDogamV1ZGkgMjkgamFudmllciAyMDE1IDIwOjQ0DQo+PlRvOiBDYXRoeSBaaGFuZzsgU3Jp bmkgQWRkZXBhbGxpOyBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4NCj4+SGFscGVy bjsgJ3NmY0BpZXRmLm9yZycNCj4+Q2M6IG5zbXVydGh5QGZyZWVzY2FsZS5jb20NCj4+U3ViamVj dDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4oaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+Pg0KPj5IaSBldmVyeW9uZSwNCj4+ DQo+PldlIGhhdmUgdXBsb2FkZWQgYSBuZXcgU0NIIHZlcnNpb24gKDMpIHdoaWNoIGFkZHMgZGVm aW5pdGlvbiBvZiBhIG5ldw0KPj5tZXRhZGF0YSB0eXBlIGZvciB0aGUgZmxvdyBJRCB0byBzdXBw b3J0IGxvYWQgYmFsYW5jaW5nIGFtb25nIFNGDQo+Pmluc3RhbmNlcyBhbmQgbWl0aWdhdGUgdGhl IHBvdGVudGlhbCBpc3N1ZSBvZiAibm90IGVub3VnaCBwYXRoIElEIi4gVGhlDQo+PmZsb3cgSUQg aXMgbmFtZWQgInJlbmRlcmVkIHNlcnZpY2UgcGF0aCBJRCIgaW4gdGhlIGRyYWZ0LiBQbGVhc2Ug cmVmZXIgdG8NCj4+c2VjdGlvbiA0LjMuMiBvZiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC16aGFuZy1zZmMtc2NoLw0KPj5mb3IgZGV0YWlsIGRlc2NyaXB0aW9uLg0KPj4N Cj4+SW4gaXRzIHByZXZpb3VzIHZlcnNpb24sIFNDSCBkZWZpbmVzIGEgIkJ5cGFzcyBiaXQiIGlu IHRoZSBiYXNlIGhlYWRlci4NCj4+VGhpcyBiaXQgZW5hYmxlcyB0aGUgU0YgdG8gcHJvdmlkZSBm ZWVkYmFjay9ub3RpZmljYXRpb24gdmlhIHRoZSBkYXRhDQo+PnBhdGggdG8gaXRzIGNvbm5lY3Rp bmcgU0ZGIGFib3V0IHdoZXRoZXIgdGhlIHJlbWFpbmluZyBwYWNrZXRzIG9mIHRoZSBTRkMNCj4+ c2hvdWxkIGJ5cGFzcyB0aGF0IFNGLiBUaGlzIGlzIHVzZWZ1bCBpbiB0aGUgY2FzZSB0aGF0IG9u bHkgdGhlIGZpcnN0IGZldw0KPj5wYWNrZXRzIG9mIGEgZmxvdyBuZWVkIHRvIGdvIHRvIGEgU0Yg KHN1Y2ggYXMgYSBEUEkgb3IgRlcgb3IgSURTKSBhbmQNCj4+cmVtYWluaW5nIHBhY2tldHMgY2Fu IGJ5cGFzcyB0aGF0IFNGLCB0aHVzIHNhdmluZyB0aGUgZXhwZW5zaXZlIFNGDQo+PnJlc291cmNl IGFuZCByZWR1Y2luZyBkYXRhIHBhdGggbGF0ZW5jeS4NCj4+DQo+PkIgYml0OiBUaGUgQiAoQnlw YXNzKSBiaXQsIHdoZW4gc2V0IHRvIDEsIGl0IGlzIHVzZWQgYnkgYSBTZXJ2aWNlDQo+PiAgICAg ICBGdW5jdGlvbiB0byBzaWduYWwgdG8gaXRzIFNlcnZpY2UgRnVuY3Rpb24gRm9yd2FyZGVyIHRo YXQgbm8NCj4+ICAgICAgIGZ1cnRoZXIgcGFja2V0cyBhcmUgdG8gYmUgc2VudCB0byBpdCBmb3Ig dGhlIGZsb3cgc3BlY2lmaWVkIGluDQo+PmVuY2Fwc3VsYXRlZCBwYWNrZXQuDQo+Pg0KPj5JbiBh ZGRpdGlvbiwgU0NIIGRlZmluZXMgYSBtZXRhZGF0YSB0eXBlIGZvciBHZW5lcmljIENvbnRleHQg QmxvY2ssIHdoaWNoDQo+PmlzIG9wdGlvbmFsIGFuZCBjYW4gYmUgdXNlZCBpZiBuZWVkZWQgdG8g Y2FycnkgYW55IHZlbmRvcidzIHNwZWNpZmljDQo+PiJDb250ZXh0IEhlYWRlciIuDQo+Pg0KPj5B bnkgY29tbWVudHMgb24gdGhlc2UgbmV3IGFkZGl0aW9ucz8NCj4+DQo+PlRoYW5rcywNCj4+Q2F0 aHkNCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IHNmYyBbbWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2F0aHkgWmhhbmcNCj4+U2VudDog RnJpZGF5LCBEZWNlbWJlciAwNSwgMjAxNCAxMTo0NyBBTQ0KPj5UbzogU3JpbmkgQWRkZXBhbGxp OyBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4gSGFscGVybjsNCj4+J3NmY0BpZXRm Lm9yZycNCj4+Q2M6IG5zbXVydGh5QGZyZWVzY2FsZS5jb20NCj4+U3ViamVjdDogUmU6IFtzZmNd IENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+Pg0KPj5Sb24sIExvdWlzLCBNeW8gYW5kIEkgaGF2ZSBi ZWVuIGRpc2N1c3Npbmcgb2ZmIGxpbmUgbGFzdCBmZXcgd2Vla3MgYWJvdXQNCj4+ZGVmaW5pbmcg YSBtZXRhZGF0YSB0eXBlIGZvciBmbG93IElEIGluIGFkZGl0aW9uIHRvIHRoZSBwYXRoIElEIG9m IHRoZQ0KPj5tYWluIGhlYWRlciB0byBzdXBwb3J0IGxvYWQgYmFsYW5jaW5nIGFtb25nIFNGIGlu c3RhbmNlcy4gV2Ugd2lsbCBkZWZpbmUNCj4+YSBUTFYgdHlwZSBmb3IgdGhlIGZsb3cgSUQuIFRo ZSBjb21iaW5hdGlvbiBvZiAicGF0aCBJRCArIGZsb3cgSUQiDQo+PnNwZWNpZmllcyBhIHJlYWxp emVkIHNlcnZpY2UgY2hhaW4gaW5zdGFuY2UgcGF0aC4gSXQgaXMgbGVmdCB0byB0aGUNCj4+ZGVz aWduL2ltcGxlbWVudGF0aW9uIHdoZXRoZXIgdG8gdXNlIGEgY2VudHJhbGl6ZWQgbWV0aG9kIG9y IGENCj4+ZGlzdHJpYnV0ZWQgbWV0aG9kIHRvIGJpbmQgdGhlIGZsb3cgSUQgdG8gYSByZWFsaXpl ZCBzZXJ2aWNlIGluc3RhbmNlDQo+PnBhdGggYWx0aG91Z2ggb3VyIG9yaWdpbmFsIHRob3VnaHQg aXMgZm9yIGRpc3RyaWJ1dGVkIExCIHVzYWdlLiBJIGFtIG5vdA0KPj5zdXJlIGlmIHdlIG5lZWQg YSBiaXQgaW4gdGhlIGhlYWRlciB0byBkZW5vdGUgd2hldGhlciB0aGVyZSBhcmUgbW9yZSBwYXRo DQo+PklEIGJpdHMgKHdlIGNhbGwgaXQgZmxvdyBJRCkgaW4gdGhlIG1ldGFkYXRhIGZpZWxkcyBz aW5jZSB3aGVuIHlvdSBwYXJzZQ0KPj50aGUgVExWIG1ldGFkYXRhLCB5b3Ugd2lsbCBrbm93IHdo ZXRoZXIgdGhlcmUgYXJlIGZsb3cgSUQgYml0cyBvciBub3QuDQo+Pk5vdGUgdGhhdCBpZiBtdWx0 aXBsZSBzZXNzaW9ucyBzaGFyZSB0aGUgc2FtZSByZWFsaXplZCBzZXJ2aWNlIGluc3RhbmNlDQo+ PnBhdGgsIHRoZXkgd2lsbCBzaGFyZSB0aGUgc2FtZSAicGF0aCBJRCsgZmxvdyBJRCIuICBXZSBj YW4gYWxzbyBjb25zaWRlcg0KPj5leHRlbmRpbmcgdGhlIG51bWJlciBvZiBiaXRzIHRvIDMyIGlm IHRoYXQgaXMgdGhlIGNvbnNlbnN1cy4gV2Ugd2lsbCBwb3N0DQo+PmFuIHVwZGF0ZWQgZHJhZnQg ZGVzY3JpYmluZyB0aGVzZSBzb29uLg0KPj4NCj4+VGhhbmtzLA0KPj5DYXRoeQ0KPj4NCj4+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTcmluaSBBZGRlcGFsbGkNCj4+U2VudDogRnJpZGF5LCBE ZWNlbWJlciAwNSwgMjAxNCA3OjE3IEFNDQo+PlRvOiBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7 IEpvZWwgTS4gSGFscGVybjsgJ3NmY0BpZXRmLm9yZycNCj4+Q2M6IG5zbXVydGh5QGZyZWVzY2Fs ZS5jb20NCj4+U3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4oaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+Pg0KPj4N Cj4+W1JQXSBEYXRhIHBsYW5lIGVmZmljaWVuY3kuDQo+Pg0KPj5TUklOST4gSSBhbSBub3Qgc28g c3VyZSBhYm91dCBkYXRhIHBsYW5lIGVmZmljaWVuY3kuICBNb3N0IG9mIHRoZQ0KPj5wcm9jZXNz b3JzIHdvcmsgZ29vZCBpZiB0aGUgbnVtYmVyIG9mIGJpdHMgYXJlIGVpdGhlciAzMiBvciA2NC4g IElmIGl0IGlzDQo+PjI0IGJpdHMsIHRoZW4gb25lIG5lZWRzIHRvIGRvIG1hc2tpbmcgYW5kIHNo aWZ0aW5nIGJlZm9yZSB0aGUgdmFsdWUgaXMNCj4+dXNlZCB0byBkbyBhbnkgbG9va3VwLiAgIEJ1 dCwgdGhpcyBkaXNjdXNzaW9uIGNhbiBnbyBpbnRvIGRpZmZlcmVudA0KPj5kaXJlY3Rpb24gOi0p LCBpdCBtYXkgbm90IGJlIGdvb2QgdG8gZ28gaW4gdGhhdCBkaXJlY3Rpb24uDQo+Pg0KPj5XaGVy ZSBkbyB3ZSBkcmF3IHRoZSBsaW5lPyAzMi1iaXRzLCA2NC1iaXRzLA0KPj4xMjggYml0cz8gSSB0 aGluayB3ZSBzaG91bGQgaGF2ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRoZSBTZXJ2aWNlIFBhdGgN Cj4+aGVhZGVyIGFuZCBpZiB5b3UgbmVlZCB0byBjb252ZXkgbW9yZSBiaXRzIHlvdSBuZWVkIHRv IHVzZSB0aGUgY29udGV4dA0KPj5oZWFkZXJzLg0KPj4NCj4+U1JJTkk+IFRoaXMgaXMgYSBnb29k IHBvaW50LiAgVGhpcyBzaG91bGQgd29yayBmaW5lIGFzIGxvbmcgYXMgdGhlcmUgaXMNCj4+d2F5 IHRvIGNvbnZleSBpbiB0aGUgbWFpbiBoZWFkZXIgdGhhdCB0aGUgZXh0ZW5zaW9uIHRvIHBhdGgg SUQgaXMNCj4+YXZhaWxhYmxlIGluIHNvIGFuZCBzbyBUTFYgZmllbGQuICBUaGF0IHNob3VsZCB3 b3JrIHRvby4NCj4+DQo+PlRoYW5rcw0KPj5TcmluaQ0KPj4NCj4+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj5Gcm9tOiBSZWluYWxkbyBQZW5ubyAocmVwZW5ubykg PHJlcGVubm9AY2lzY28uY29tPg0KPj5TZW50OiBGcmlkYXksIERlY2VtYmVyIDUsIDIwMTQgNzow OCBBTQ0KPj5UbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2MDsgSm9lbCBNLiBIYWxwZXJuOyAnc2Zj QGlldGYub3JnJw0KPj5DYzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDANCj4+U3ViamVjdDog UmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4oaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+Pg0KPj5PbiAxMi81LzE0LCA2OjU0IEFN LCAiU3JpbmkgQWRkZXBhbGxpIiA8c2FkZGVwYWxsaUBmcmVlc2NhbGUuY29tPiB3cm90ZToNCj4+ DQo+Pj4NCj4+PkluIHJlYWwgZGVwbG95bWVudHMsIG51bWJlciBvZiBhY3RpdmUgcGF0aCBJRHMg YXJlIHZlcnkgbGVzc2VyIHRoYW4NCj4+PjJeNjQsIGJ1dCB0aGVyZSBpcyBhIGdvb2QgcG9zc2li aWxpdHkgb2YgdGhlIG51bWJlciBiZWluZyBtb3JlIHRoYW4gMl4yNA0KPj4+KDE2TSkuDQo+Pj4g SSB0aGluayBiaWdnZXIgcG9pbnQgaXMgdGhhdCB3aHkgcmVzdHJpY3QgdGhpcyBpbiB0aGUgc3Rh bmRhcmRzPyBXaGF0DQo+Pj5hZHZhbnRhZ2UgZG8gd2UgaGF2ZSByZXN0cmljdGluZyB0aGlzIHNp emUgdG8gMjQgYml0cz8NCj4+DQo+PltSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5LiBXaGVyZSBk byB3ZSBkcmF3IHRoZSBsaW5lPyAzMi1iaXRzLCA2NC1iaXRzLA0KPj4xMjggYml0cz8gSSB0aGlu ayB3ZSBzaG91bGQgaGF2ZSBhIHNlbnNpYmxlIHZhbHVlIGluIHRoZSBTZXJ2aWNlIFBhdGgNCj4+ aGVhZGVyIGFuZCBpZiB5b3UgbmVlZCB0byBjb252ZXkgbW9yZSBiaXRzIHlvdSBuZWVkIHRvIHVz ZSB0aGUgY29udGV4dA0KPj5oZWFkZXJzLg0KPj4NCj4+DQo+Pj4NCj4+PlRoZXJlIGNhbiBiZSBk ZXBsb3ltZW50cywgd2hlcmUgU0ZDIGNvbnRyb2xsZXIgKExvZ2ljYWxseSBjZW50cmFsLCBidXQN Cj4+PmRpc3RyaWJ1dGVkKSAgaXRzZWxmIGNhbiBkbyB0aGUgU0YgaW5zdGFuY2Ugc2VsZWN0aW9u IG9uIHBlcg0KPj4+Y29ubmVjdGlvbi9zZXNzaW9uIGJhc2lzLCB0aGVyZWJ5IGF2b2lkaW5nIHRo ZSBMQnMgZm9yIHNlcnZpY2VzLiAgIEluIG15DQo+Pj52aWV3LCBhc3N1bXB0aW9uIHRoYXQgdGhl cmUgd2lsbCBiZSBMQiBTRiBmb3IgZWFjaCBzY2FsZS1vdXQgc2VydmljZSBpbg0KPj4+dGhlIGNo YWluIGlzIG5vdCB2YWxpZCBpbiBhbGwgY2FzZXMuDQo+Pj4NCj4+PlRoYW5rcw0KPj4+U3JpbmkN Cj4+Pg0KPj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+RnJv bTogUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pIDxyZXBlbm5vQGNpc2NvLmNvbT4NCj4+PlNlbnQ6 IFRodXJzZGF5LCBEZWNlbWJlciA0LCAyMDE0IDE6MTcgUE0NCj4+PlRvOiBBZGRlcGFsbGkgU3Jp bmktQjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47IHNmY0BpZXRmLm9yZw0KPj4+Q2M6IE5TIFNyaW5p dmFzYSBNdXJ0aHktQjM3ODQwDQo+Pj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NI IERyYWZ0DQo+Pj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1z Y2gtMDIpDQo+Pj4NCj4+PklmIEkgdW5kZXJzdG9vZCB5b3UsIEkgZG8gbm90IHRoaW5rIHRoaXMg aXMgcmVhbGlzdGljLiBBcmUgeW91IHNheWluZw0KPj4+eW91IG5lZWQgNjQtYml0cyBvZiBwYXRo cyBhbmQgdGhlbiB3aWxsIG1vbml0b3IgdGhlbSBhbGw/IERvIGZhdWx0DQo+Pj50b2xlcmFuY2Ug YW5kIE9BTSBmb3IgMl42NC1iaXRzIHdvcnRoIG9mIHBhdGhzPyBKdXN0IGZvciBjb21wYXJpc29u LA0KPj4+aXTCuXMgbGlrZSBtYW5hZ2luZyBhbmQgbW9uaXRvcmluZyB0aGUgZW50aXJlIElQdjYg aG9zdCByYW5nZSwNCj4+Pm9uZS1ieS1vbmUuDQo+Pj4NCj4+PkFueXdheSwgSSBkbyBub3QgZXhw ZWN0IGV2ZXJ5IHNpbmdsZSBwZXJtdXRhdGlvbnMgdG8gYmUgYSBkaWZmZXJlbnQNCj4+PnBhdGgu DQo+Pj4NCj4+PklmIGVhY2ggc2VydmljZSBoYXMgMjU2IGRldmljZXMgcHJvdmlkaW5nIHNpbWls YXIgc2VydmljZSwgeW91IHNob3VsZA0KPj4+bW9zdCBsaWtlbHkgdXNlIGxvYWQtYmFsYW5jaW5n IGFuZCB0aGVuIHlvdSB3b3VsZCBoYXZlIGEgc2luZ2xlIChvciBhDQo+Pj5mZXcpIHBhdGhzLiBU aGVyZSBpcyBzb21lIGRpc2N1c3Npb24gZ29pbmcgb24gTEIuDQo+Pj4NCj4+PkZyb20gYSBkYXRh IHBsYW5lIHBlcnNwZWN0aXZlLCB0aGUgcGF0aCBpcyB1bHRpbWF0ZWx5IGRlZmluZWQgYnkgdGhl DQo+Pj5TRkZzIHRyYXZlcnNlZCBhbmQgc2VydmljZXMgcHJvdmlkZWQsIG5vdCBieSBhIHNwZWNp ZmljIElQOnBvcnQgdGhhdA0KPj4+dGhlIGRldmljZSBwcm92aWRpbmcgdGhlIHNlcnZpY2Ugc2l0 cyBvbi4gV2VsbCwgYXQgbGVhc3QgZnJvbSBhIEdQRStOU0gNCj4+PnBlcnNwZWN0aXZlLg0KPj4+ DQo+Pj4NCj4+Pk9uIDEyLzQvMTQsIDEyOjU3IFBNLCAiU3JpbmkgQWRkZXBhbGxpIiA8c2FkZGVw YWxsaUBmcmVlc2NhbGUuY29tPg0KPj4+d3JvdGU6DQo+Pj4NCj4+Pj5JZiBJIHRha2UgYSBjaGFp biB3aXRoIDUgc2VydmljZXMgd2l0aCBlYWNoIHNlcnZpY2UgIHNheSBoYXZpbmcgMjU2DQo+Pj4+ aW5zdGFuY2VzIGZvciBzY2FsZS1vdXQsIHBvc3NpYmxlIG51bWJlciBvZiBwYXRocyBhcmUNCj4+ Pj4yNTYqMjU2KjI1NioyNTYqMjU2ID0gMHhGRiBGRiBGRiBGRiBGRi4gT25lIHJlcXVpcmVzIDMz IGJpdHMgaW4gdGhpcw0KPj4+PmNhc2UuICBJZiB0aGVyZSBhcmUgbW9yZSBzZXJ2aWNlcyBpbiB0 aGUgY2hhaW4gb3IgbW9yZSBjaGFpbnMgb3IgbW9yZQ0KPj4+Pmluc3RhbmNlcyBmb3Igc2NhbGUt b3V0LCB0aGVuIGl0IGNvdWxkIGdvIHRvIGJpZyBudW1iZXIgdmVyeSBmYXN0Lg0KPj4+Pg0KPj4+ PkFzIEkgbWVudGlvbmVkIG15IHByZWZlcmVuY2UgaXMgdG8gbWFrZSB0aGUgcGF0aCBJRCBzaXpl IGZsZXhpYmxlIGZvcg0KPj4+PmZ1dHVyZSBncm93dGguIElmIHRoYXQgaXMgcGVyY2VpdmVkIGFz IGNvbXBsZXgsIHRoZW4gZ29pbmcgZm9yIDY0Yml0DQo+Pj4+aXMgc2FmZXIgYmV0Lg0KPj4+Pg0K Pj4+PlRoYW5rcw0KPj4+PlNyaW5pDQo+Pj4+DQo+Pj4+DQo+Pj4+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+Pj5Gcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBl cm4uY29tXQ0KPj4+PlNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwNCwgMjAxNCAxMjowNSBQTQ0K Pj4+PlRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47IHNmY0BpZXRm Lm9yZw0KPj4+PkNjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPj4+PlN1YmplY3Q6IFJl OiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4+Pj4oaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+Pj4+DQo+Pj4+QSBjb250cm9sbGVyIChv ciBvdGhlciBkZWNpc2lvbiBsb2dpYykgY2FuIGNlcnRhaW5seSBiZSBhd2FyZSBvZiBzdWNoDQo+ Pj4+Y29uY2VybnMuDQo+Pj4+QnV0IHRoZSBudW1iZXIgb2Ygc2VydmljZSBmdW5jdGlvbiBwYXRo cyBpcyBub3QgcmVsYXRlZCB0byB0aGUgbnVtYmVyDQo+Pj4+b2YgZmxvd3Mgb3IgdGhlIG51bWJl ciBvZiB0ZW5hbnRzLiAgSXQgaXMgcmVsYXRlZCB0byB0aGUgbnVtYmVyIG9mDQo+Pj4+Y29tYmlu YXRpb25zIG9mIHNlcnZpY2VzIGFuZCB0aGUgcG9saWNpZXMgZm9yIHNlcnZpY2UgZnVuY3Rpb24N Cj4+Pj5zZWxlY3Rpb24uDQo+Pj4+IFdoaWxlIHRoYXQgY2FuIGJlIGEgbGFyZ2UgbnVtYmVyLCBJ IHN1cmUgaG9wZSBpdCBkb2VzIG5vdCBjb21lIGNsb3NlDQo+Pj4+dG8gc2F0dXJhdGluZyAyNCBi aXRzLg0KPj4+Pg0KPj4+PkhhdmluZyBzYWlkIHRoYXQsIGlmIHdlIHRoaW5rIHRoYXQgMjQgYml0 cyBpcyBvbmx5IGp1c3QgZW5vdWdoLCB0aGVuDQo+Pj4+d2Ugb3VnaHQgdG8gdXNlIDMyLiAgRnJv bSB3aGVyZSBJIHNpdCwgSSB3b3VsZCBub3JtYWxseSBleHBlY3QgMTYgYml0cw0KPj4+PnRvIGJl IG1vcmUgdGhhbiBzdWZmaWNpZW50LCB3aGljaCBpcyB3aHkgSSBhbSBjb21mb3J0YWJsZSB3aXRo IDI0Lg0KPj4+PkhhdmluZyBzYWlkIHRoYXQsIHRoZSBmaWVsZCBzaXplIGlzIG5vdCBhIGJpZyBk ZWFsIHRvIG1lLg0KPj4+Pg0KPj4+PllvdXJzLA0KPj4+PkpvZWwNCj4+Pj4NCj4+Pj5PbiAxMi80 LzE0LCAyOjAxIFBNLCBTcmluaSBBZGRlcGFsbGkgd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4gSSB3YXMg bm90IGltcGx5aW5nIHRoYXQgcGF0aCBJRCBzaG91bGQgaGF2ZSBpbmZvcm1hdGlvbiBpbiByZWdh cmRzDQo+Pj4+PnRvIHRlbmFudC9jb250cm9sbGVyL2Zsb3cvc2NhbGUtb3V0LiAgQnV0IFNGQyBj b250cm9sbGVycyBzaG91bGQga2VlcA0KPj4+Pj50aGVzZQ0KPj4+Pj5pbiBtaW5kIHRvIGFzc2ln biB0aGUgcGF0aCBJRC4gICAgQSBkZXBsb3ltZW50IGNhbiBoYXZlIG11bHRpcGxlDQo+Pj4+PnRl bmFudHMsIGVhY2ggdGVuYW50IGNhbiBoYXZlIG11bHRpcGxlIG5ldHdvcmtzLCAgdGhlcmUgY291 bGQgYmUNCj4+Pj4+bWlsbGlvbnMgb2YgZmxvd3MgaW4gZWFjaCBvZiB0aG9zZSBuZXR3b3Jrcy4g IEFuZCBjb25zaWRlcmluZyBhbGwNCj4+Pj4+dGhlc2UsDQo+Pj4+PiAyNCBiaXQgcGF0aCBJRCBt YXkgbm90IGJlIGFibGUgdG8gcmVwcmVzZW50IHBhdGhzIGZvciB0aGVzZSBmbG93cy4NCj4+Pj4+ SGVuY2UsIEkgd2FzIHdvbmRlcmluZyB3aGV0aGVyIHBhdGggSUQgY2FuIGJlIGV4dGVuZGVkIHRv IDY0IGJpdHMgb3INCj4+Pj4+bWFrZSBpdCBmbGV4aWJsZS4NCj4+Pj4+DQo+Pj4+PiBUaGFua3MN Cj4+Pj4+IFNyaW5pDQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4u Y29tPg0KPj4+Pj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDQsIDIwMTQgNzo0MiBBTQ0KPj4+ Pj4gVG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IHNmY0BpZXRmLm9yZw0KPj4+Pj4gQ2M6IE5T IFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+Pj4+PiBTdWJqZWN0OiBSZTogW3NmY10gQ29tbWVu dHMgb24gU0NIIERyYWZ0DQo+Pj4+PiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXpoYW5nLXNmYy1zY2gtMDIpDQo+Pj4+Pg0KPj4+Pj4gVGhlIEluZGV4IGlzIG5vdCBqdXN0IGZv ciBsb29wIHByZXZlbnRpb24uICBJbiB0aGUgY2FzZSBvZg0KPj4+Pj4gYW1iaWd1aXR5LCB0aGUg aW5kZXggdGVsbHMgdGhlIFNGRiB3aGVyZSBpbiB0aGUgcGF0aCB0aGUgcGFja2V0DQo+Pj4+PmN1 cnJlbnRseSByZXNpZGVzLg0KPj4+Pj4gICAgVGhlcmUgYXJlIG11bHRpcGxlIHdheXMgc3VjaCBh bWJpZ3VpdHkgY2FuIG9jY3VyLg0KPj4+Pj4NCj4+Pj4+IFRoZSBQYXRoIElkZW50aWZpZXIgaXMg c3BlY2lmaWNhbGx5IG5vdCBleHBlY3RlZCB0byBpbmNsdWRlDQo+Pj4+PiBjb250cm9sbGVyIElE IG9yIFRlbmFudCBJRC4gIFdoaWxlIGEgZGVwbG95ZXIgY2FuIGhhdmUgYSBwYXRoIHBlcg0KPj4+ Pj4gdGVuYW50LCB0aGUgYXJjaGl0ZWN0dXJlIHN0aWxsIGRvZXMgbm90IHRyZWF0IHRoZSBwYXRo IElEIGFzIGENCj4+Pj4+IHRlbmFudCBJRC4gIFRlbmFudCBJRCwgY29udHJvbGxlciBJRCwgYW5k IG90aGVyIG5vbi1wYXRoLXNwZWNpZnlpbmcNCj4+Pj4+IGluZm9ybWF0aW9uIGlzIHRvIGJlIGNh cnJpZWQgaW4gbWV0YWRhdGEuDQo+Pj4+Pg0KPj4+Pj4gWW91cnMsDQo+Pj4+PiBKb2VsDQo+Pj4+ Pg0KPj4+Pj4gT24gMTIvNC8xNCwgMTA6MDIgQU0sIFNyaW5pIEFkZGVwYWxsaSB3cm90ZToNCj4+ Pj4+PiBUd28gY29tbWVudHMgOg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiAxLiAgU0YgSW5kZXgg OiAgU2luY2UgaXQgaXMgbWVhbnQgZm9yIGxvb3AgZGV0ZWN0aW9uLCAgd291bGRuJ3QNCj4+Pj4+ PiBiZXR0ZXIgdG8gcmVuYW1lIHRoaXMgYXMgIlRUTCI/DQo+Pj4+Pj4NCj4+Pj4+PiAyLiAgUGF0 aCBJZGVudGlmaWVyIDogICAgMjQgYml0IHBhdGggaWRlbnRpZmllciBzZWVtcyB0byBiZSB0b28N Cj4+Pj4+Pmxlc3MuDQo+Pj4+Pj4gQmFzZWQgb24gb3VyIGV4cGVyaWVuY2UgaW4gdHJhZmZpYyBz dGVlcmluZywgIHRoaXMgcGF0aCBpZGVudGlmaWVyDQo+Pj4+Pj5uZWVkcyB0byBlbmNvZGUgZ29v ZCBhbW91bnQgb2YgaW5mb3JtYXRpb24gdG8gbWFrZSBpdCB1bmlxdWUuICBGb3INCj4+Pj4+PmV4 YW1wbGUsDQo+Pj4+Pj4gICAgdGhpcyBpZGVudGlmaWVyIG5lZWRzIHRvIGVuY29kZSAoaW4gb3Vy IGNhc2UpIHNvbWUgaW5mb3JtYXRpb24NCj4+Pj4+PnJlcHJlc2VudGluZyB0aGUgZGlzdHJpYnV0 ZWQgY29udHJvbGxlciBJRCwgIHRlbmFudCBJRCwgIGZsb3cgSUQsDQo+Pj4+Pj4gICAgU2Vydmlj ZSBmdW5jdGlvbiBpbnN0YW5jZSAoaW4gY2FzZSBvZiBzY2FsZS1vdXQpIGFuZCBmZXcgbW9yZS4u DQo+Pj4+Pj4gT25lIHN1Z2dlc3Rpb24gaXMgdG8gbWFrZSBpdCA2NCBiaXRzIHZhbHVlICBvciB0 byBtYWtlIGl0IGV2ZW4NCj4+Pj4+PmV4dGVuZGFibGUsDQo+Pj4+Pj4gICAgaXQgaXMgZ29vZCBp ZiBwYXRoIGlkZW50aWZpZXIgaXMgYWxzbyByZXByZXNlbnRlZCBpbiBUTFYgZm9ybS4NCj4+Pj4+ Pg0KPj4+Pj4+DQo+Pj4+Pj4gVGhhbmtzDQo+Pj4+Pj4NCj4+Pj4+PiBTcmluaQ0KPj4+Pj4+DQo+ Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gc2Zj QGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z ZmMNCj4+Pj4+Pg0KPj4+Pg0KPj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pj4+c2ZjIG1haWxpbmcgbGlzdA0KPj4+PnNmY0BpZXRmLm9yZw0KPj4+ Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4NCj4+DQo+Pg0K Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5zZmMg bWFpbGluZyBsaXN0DQo+PnNmY0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NmYw0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+c2ZjIG1haWxpbmcgbGlzdA0KPj5zZmNAaWV0Zi5vcmcNCj4+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+DQo+Pg0KPj5UaGlzIG1l c3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyAodGhlICJtZXNzYWdlIikgYXJlIGNvbmZpZGVudGlh bCwNCj4+aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2Vlcy4gSWYgeW91IGFyZSBub3Qg dGhlIGludGVuZGVkDQo+PnJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVsZXRlIHRoaXMNCj4+bWVzc2FnZSBmcm9tIHlvdXIgc3lz dGVtLiBJbiB0aGlzIGNhc2UsIHlvdSBhcmUgbm90IGF1dGhvcml6ZWQgdG8gdXNlLA0KPj5jb3B5 IHRoaXMgbWVzc2FnZSBhbmQvb3IgZGlzY2xvc2UgdGhlIGNvbnRlbnQgdG8gYW55IG90aGVyIHBl cnNvbi4NCj4+RS1tYWlscyBhcmUgc3VzY2VwdGlibGUgdG8gYWx0ZXJhdGlvbi4gTmVpdGhlciBR b3Ntb3Mgbm9yIGFueSBvZiBpdHMNCj4+c3Vic2lkaWFyaWVzIG9yIGFmZmlsaWF0ZXMgc2hhbGwg YmUgbGlhYmxlIGZvciB0aGUgbWVzc2FnZSBpZiBhbHRlcmVkLA0KPj5jaGFuZ2VkIG9yIGZhbHNp ZmllZC4NCj4+DQo+PkNlIG1lc3NhZ2UgZXQgdG91dGVzIHNlcyBwacOoY2VzIGpvaW50ZXMgKGNp LWFwcsOocyBsZSAibWVzc2FnZSIpc29udA0KPj5jb25maWRlbnRpZWxzIGV0IMOpdGFibGlzIMOg IGwnaW50ZW50aW9uIGV4Y2x1c2l2ZSBkZSBzZXMgZGVzdGluYXRhaXJlcy4gU2kNCj4+dm91cyBh dmV6IHJlw6d1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgbWVyY2kgZOKAmWVuIGluZm9ybWVyIGlt bcOpZGlhdGVtZW50DQo+PnNvbiDDqW1ldHRldXIgcGFyIGNvdXJyaWVyIMOpbGVjdHJvbmlxdWUg ZXQgZOKAmWVmZmFjZXIgY2UgbWVzc2FnZSBkZSB2b3RyZQ0KPj5zeXN0w6htZS4gRGFucyBjZXR0 ZSBoeXBvdGjDqHNlLCB2b3VzIG7igJnDqnRlcyBwYXMgYXV0b3Jpc8OpIMOgIHV0aWxpc2VyLA0K Pj5jb3BpZXIgY2UgbWVzc2FnZSBldC9vdSBlbiBkaXZ1bGd1ZXIgbGUgY29udGVudSDDoCB1biB0 aWVycy4gVG91dCBtZXNzYWdlDQo+PsOpbGVjdHJvbmlxdWUgZXN0IHN1c2NlcHRpYmxlIGQnYWx0 w6lyYXRpb24uIFFvc21vcyBldCBzZXMgZmlsaWFsZXMNCj4+ZMOpY2xpbmVudCB0b3V0ZSByZXNw b25zYWJpbGl0w6kgYXUgdGl0cmUgZGUgY2UgbWVzc2FnZSBzJ2lsIGEgw6l0w6kgYWx0w6lyw6ks DQo+PmTDqWZvcm3DqSBvdSBmYWxzaWZpw6kuDQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PnNmYyBtYWlsaW5nIGxpc3QNCj4+c2ZjQGlldGYub3Jn DQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQoNCg== From nobody Tue Feb 3 16:59:22 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 F2F091A8749 for ; Tue, 3 Feb 2015 16:59:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, 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 Lb92BwV7VGvC for ; Tue, 3 Feb 2015 16:59:17 -0800 (PST) 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 76FC71A875B for ; Tue, 3 Feb 2015 16:59:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22206; q=dns/txt; s=iport; t=1423011557; x=1424221157; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=5v8UlCO4YuiHxnsNI+bdqaZetcCYSOvIiicRpuBPQh8=; b=YLtXOKxR8gyrXSEGIRwYQMEeCv6mREDXGWhLaxLOwA5Nn6e6vVe0tkL0 Qa2TH5GrvFlNupVXrgfxU38mlkWKUCI61tGcP/cj7swZI/y2R8xfFQYdJ XJOZ9UU6ns6scl4E1SXcek52+T6dDBmx+jcw1EjqWzimEfMdz0BWSt4te Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ChBQCpbtFU/5tdJa1agmQiUlkEgn3CAAqFcQIcfUMBAQEBAX2EDAEBAQQBAQExMwcLDAQCAQgRAQMBAQEEIwUCAiULFAMGCAIEAQ0FFAWIFAEMon2cZAaWVwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgRuIc4UHFRsIEBsHAgICglyBRwEEjwyDToVYgReDA4JFiEODPSKCAhwUgTxvAYFDfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,516,1418083200"; d="scan'208";a="120284061" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-7.cisco.com with ESMTP; 04 Feb 2015 00:59:10 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t140xAUi013674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Feb 2015 00:59:10 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 18:59:09 -0600 From: "Ken Gray (kegray)" To: Cathy Zhang , Srini Addepalli , "Reinaldo Penno (repenno)" , "Joel M. Halpern" , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZx/9uiAgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgCAAEtwAIBWb4+AgAdtFgCAAJLygP//38sA Date: Wed, 4 Feb 2015 00:59:08 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.23.212] Content-Type: text/plain; charset="euc-kr" Content-ID: <71F9F764751B2D4E897CD3F0F0C1B37D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "nsmurthy@freescale.com" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 04 Feb 2015 00:59:21 -0000 SW4sIGxpbmUgoaYuDQoNCk9uIDIvMy8xNSwgNDo1NCBQTSwgIkNhdGh5IFpoYW5nIiA8Q2F0aHku SC5aaGFuZ0BodWF3ZWkuY29tPiB3cm90ZToNCg0KPkhpIEtlbiwNCj4NCj5QbGVhc2Ugc2VlIGlu bGluZS4NCj4NCj5UaGFua3MsDQo+Q2F0aHkNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPkZyb206IEtlbiBHcmF5IChrZWdyYXkpIFttYWlsdG86a2VncmF5QGNpc2NvLmNvbV0NCj5T ZW50OiBUdWVzZGF5LCBGZWJydWFyeSAwMywgMjAxNSAxMDowOSBBTQ0KPlRvOiBDYXRoeSBaaGFu ZzsgU3JpbmkgQWRkZXBhbGxpOyBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4NCj5I YWxwZXJuOyAnc2ZjQGlldGYub3JnJw0KPkNjOiBuc211cnRoeUBmcmVlc2NhbGUuY29tDQo+U3Vi amVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPihodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4NCj5BcyBhIGdlbmVyYWwgY29t bWVudCBvbiB0aGlzIHN1Ym1pc3Npb24gKGFuZCBwZXJoYXBzIGxpZmUgaW4gdGhlIGN1cnJlbnQN Cj5JRVRGKS4gIEkgaGF2ZSBhIFJFQUxMWSBoYXJkIHRpbWUgZGlmZmVyZW50aWF0aW5nIHRoaXMg ZHJhZnQgZnJvbSB0aGUNCj5xdWlubiBkcmFmdCAod2hpY2ggcHJlLWRhdGVzIGl0IGJ5IHF1aXRl IGEgYml0KS4gIFdoeSBhcmUgd2UgcHVyc3VpbmcgYQ0KPnNlcGFyYXRlIGRyYWZ0IHdoZW4gdGhl IHN1Z2dlc3Rpb25zLCBJTUhPLCBzZWVtIGluY3JlbWVudGFsIGF0IGJlc3Q/DQo+DQo+DQo+Q2F0 aHk+IFRoZSBvcmlnaW5hbCBtb3RpdmF0aW9uIGZvciBkcmFmdGluZyB0aGUgU0NIIGlzIHRvIHBy b3ZpZGUgYW4NCj5hbHRlcm5hdGl2ZSB0byBkcmFmdC1xdWlubi1uc2ggdG8gYWRkcmVzcyB0aGUg Zm9sbG93aW5nIHBlcmNlaXZlZCBpc3N1ZXM6DQo+MS4gTWFuZGF0b3J5IGZpeGVkLXNpemVkIG1l dGFkYXRhLiBXZSB0aGluayB0aGV5IHNob3VsZCBub3QgYmUgbWFuZGF0b3J5DQo+c2luY2UgdGhl IDQtd29yZCBjb250ZXh0IGZpZWxkcyBhcmUgbm90IG5lZWRlZCBpbiBtYW55IHNjZW5hcmlvcw0K PjIuIE5vIHZhcmlhYmxlIGxlbmd0aCBtZXRhZGF0YS4gV2UgdGhpbmsgbWV0YWRhdGEgc2hvdWxk IGJlIG9wdGlvbmFsIGFuZA0KPlRMViBmb3JtYXQgc2hvdWxkIGJlIHVzZWQgdG8gZGVmaW5lIG1l dGFkYXRhDQo+My4gTm8gb3JnYW5pemF0aW9uYWxseSBkZWZpbmVkIG1ldGFkYXRhDQo+NC4gTm8g VmVyc2lvbiBmaWVsZC4NCj5XaGVuIHdlIHVwbG9hZGVkIFNDSCAxc3QgdmVyc2lvbiAoMy8yNC8y MDE0KSwgTlNIIHZlcnNpb24gZGlkIG5vdCBoYXZlDQo+dGhlIFRMViBtZXRhZGF0YSBhbmQgdmVy c2lvbiBmaWVsZCAodGhleSB3ZXJlIGFkZGVkIGluIGl0cyBsYXRlciB2ZXJzaW9uKS4NCg0KPGtl Zz4gVGhpcyBjb3VsZCBoYXZlIGJlZW4gaXJvbmVkIG91dCB3aXRoIHRoZSBhdXRob3JzIG9uIHRo ZSBsaXN0IHdpdGhvdXQNCmEgc2VwYXJhdGUgZG9jdW1lbnQuICBUaGUgYXV0aG9ycyB3ZXJlIHBy ZS1kaXNwb3NlZCB0byB0aGUgaWRlYSBvZg0Kb3B0aW9uYWwvdmFyaWFibGUgbWV0YWRhdGEgZWFy bHkgb24gLSBJIGtub3cgYmVjYXVzZSB0aGlzIHdhcyBkaXNjdXNzZWQNCmR1cmluZyBpbmZvcm1h bCByZXZpZXcgd2hpbGUgSSB3YXMgaW4gYW5vdGhlciBjb21wYW55LiAgVGhleSBoYWQgYWdyZWVk IHRvDQphZGRyZXNzIGl0IGluIGEgbGF0ZXIgcmVsZWFzZSBpZiBpdCB3YXMgc3VwcG9ydGVkIG9u IHRoZSBsaXN0LiAgSaGvbSBwcmV0dHkNCnN1cmUgSSB3YXMgbm90IHRoZSBvbmx5IG9uZSB0byBw cm92aWRlIHRoYXQgZmVlZGJhY2suDQoNCj4NCj4NCj4NCj5JIGhhdmUgcmVhY2ggb3V0IHRvIHRo ZSBjaGFpcnMgaGVyZSAuIHdlIGhhdmUgYSBsb3QgdG8gcmVhZC4gQXJlbid0IGRyYWZ0cw0KPnN1 cHBvc2VkIHRvIG9mZmVyIHNpZ25pZmljYW50bHkgZGlmZmVyZW50IHZpZXdzIGlmIHRoZXkgYXJl IHRvIHBlcnNpc3QNCj4od2l0aG91dCB0aGF0LCBhICJjYWxsIHRvIGFkb3B0IiBiZWNvbWVzIGEg YmVhdXR5IGNvbnRlc3QsIElNTyk/ICBObw0KPm9mZmVuc2UgdG8gdGhlIGF1dGhvcnMsIGJ1dCB3 ZSdyZSBpbiByZXZpc2lvbiAzIGFuZCBJIGRvbid0IHNlZSB0aGF0IGhlcmUuDQo+IA0KPg0KPlJl Z2FyZGluZyB0aGUgY2hhbmdlcyBpbiB0aGlzIGRvY3VtZW50Og0KPg0KPkkgZG8gbm90IGZpbmQg dGhlIGZsb3cgSUQgZnVuY3Rpb25hbGx5IGRpZmZlcmVudCB0aGFuIHRoZSB1c2UgY29udGV4dA0K PmhlYWRlcnMgaW4gdGhlIG5zaCBkcmFmdCwgd2hpY2ggc2VlbSB0byBiZSBhIG1vcmUgbXVsdGkt cHVycG9zZSBjb25jZXB0Lg0KPg0KPkNhdGh5PiBEaWZmZXJlbnQgcGVvcGxlIGhhdmUgZGlmZmVy ZW50IHZpZXdwb2ludHMuIFJTUCBJRCBpcyBub3QgZGVmaW5lZA0KPmluIE5TSCBhbmQgZnJvbSBQ YXVsIChOU0ggYXV0aG9yKSdzIHJlcGx5LCBpdCBzZWVtcyBoZSBkb2VzIG5vdCBmZWVsIHRoZQ0K Pm5lZWQgb2YgYW4gUlNQIElELg0KPkNhdGh5PiBXZSBzZWUgdGhlIG5lZWQgZm9yIFJTUCBJRCBh bmQgdGh1cyBkZWZpbmVkIGl0IGluIFNDSCBmb3Igb3Blbg0KPmRpc2N1c3Npb24gYW5kIHdvdWxk IGxpa2UgdG8gc2VlIHRoZSBjb21tdW5pdHkncyBmZWVkYmFjayBvbiBpdC4NCg0KPGtlZz4gSWYg dGhlcmUgYXJlIHZhcnlpbmcgb3BpbmlvbnMgYWJvdXQgaXQsIHRoYXShr3MgZXZlbiBhIHN0cm9u Z2VyDQphcmd1bWVudCB0byB1c2UgdGhlIE5ldHdvcmsgQ29udGV4dCByYXRoZXIgdGhhbiBhIGRl ZGljYXRlZCBmaWVsZCwgSU1PLg0KDQo+DQo+VGhlIEIgYml0IHN1Z2dlc3Rpb24gY2FuIGNhdXNl IGEgY29uZmxpY3QgaW4gY29udHJvbCBhbmQgY3JlYXRlIGFuIGF2ZW51ZQ0KPmZvciB1bmRlc2ly YWJsZSBiZWhhdmlvciwgSU1PLiAgSSd2ZSBiZWVuIHdvcmtpbmcgZnJvbSB0aGUgYXNzdW1wdGlv biB0aGF0DQo+YSBtaW5pbXVtIHJlcXVpcmVtZW50IG9mIGEgZnVuY3Rpb24gaXMgdGhhdCBpdCBi ZSBtYW5hZ2VhYmxlIChpZiBmb3Igbm8NCj5vdGhlciByZWFzb24gdGhhbiBlZmZlY3RpdmUgZWxh c3RpY2l0eSBhbmQgY29oZXNpdmUvcHJlZGljdGFibGUgZGVsaXZlcnkNCj5vZiBzZXJ2aWNlKSwg c28gSSBoYXZlIGxpdHRsZSBzeW1wYXRoeSBmb3IgdGhvc2UgdGhhdCBhcmUgbm90IC0gYmUgdGhl eQ0KPnZpcnR1YWwgb3IgcGh5c2ljYWwgKGV2ZW4gbGVzcyBzeW1wYXRoeSBmb3IgdmlydHVhbCBm dW5jdGlvbnMgdGhhdCBhcmUNCj51bm1hbmFnZWFibGUsIGZyYW5rbHkpLiAgQSBzZWxmLW1hbmFn ZW1lbnQgb3B0aW9uIGluIHRoZSBTRkMgc2NlbmFyaW8gaGFzDQo+bG93IHZhbHVlIGFuZCB0aGUg Y29ycnVwdGlvbiBvciBtaXN1c2Ugb2YgdGhlIGJpdCBjYW4gY2F1c2UgY2hhb3MgKGFuDQo+ZXh0 cmEgbGV2ZWwgb2YgImZhaWwiKS4NCj4NCj5DYXRoeT4gQ291bGQgeW91IGNsYXJpZnkgd2hhdCB5 b3UgbWVhbiBieSAiY2F1c2UgYSBjb25mbGljdCBpbiBjb250cm9sIj8NCg0KPGtlZz4gSWYgdGhl IHByZW1pc2Ugb2YgdGhlIHN5c3RlbSBpcyB0aGF0IHRoZSBlbGVtZW50IGlzIG1hbmFnZWQgKHdp dGhpbg0KYSBjaGFpbikgZm9yIHRoZSBwdXJwb3NlcyBvZiBhZ2lsaXR5L2VsYXN0aWNpdHkvZ29v ZG5lc3MtYW5kLWxpZ2h0IGFuZA0KdGhhdCBhIGhpZ2hlciBwb3dlciBpcyBtYW5hZ2luZyB0aGUg c2V0dXAgb2YgZmxvd3MsIGhhdmluZyB0aGUgYWJpbGl0eSBmb3INCnRoZSBub2RlIHRvIGF1dG9u b21vdXNseSByZW1vdmUgaXRzZWxmIGlzIHVubmVjZXNzYXJ5IGFuZCBkYW5nZXJvdXMuICBJdA0K YWxsb3dzIHRoZSBub2RlIHRvIGRvIHRoaW5ncyB0aGUgbWFuYWdlbWVudCBzeXN0ZW0gbWF5IG5v dCBleHBlY3Qgb3IgcmVhY3QNCnRvIChvciBiZSBjYXBhYmxlIG9mIHJlYWN0aW5nIHRvKSBjcmVh dGluZyBhIGNvbmZsaWN0IG92ZXIgd2hvL3doYXQNCmFjdHVhbGx5IGNvbnRyb2xzIHRoZSBlZmZp Y2FjeSBvZiB0aGUgY2hhaW4uDQoNCj4NCj4NCj5UaGUgR2VuZXJpYyBDb250ZXh0IEJsb2NrIGlz IGNvbmZ1c2luZyBpbiBsaWdodCBvZiB0aGUgYWxyZWFkeSBleHRhbnQNCj5vcHRpb25hbC92YXJp YWJsZSBtZXRhZGF0YSBUTFZzICh3aHkgd291bGRuJ3QgeW91IGxldmVyYWdlIG9uZSBvZiB0aGVt KT8NCj4NCj5DYXRoeT4gSSBhbSBub3Qgc3VyZSBpZiBJIHVuZGVyc3RhbmQgeW91ciBwb2ludC4g VGhlIEdlbmVyaWMgQ29udGV4dA0KPkJsb2NrIGlzIG9uZSB0eXBlIG9mIG1ldGFkYXRhIHdoaWNo IGlzIGluIFRMViBmb3JtYXQgYW5kIGlzIG9wdGlvbmFsLg0KDQo8a2VnPiBXaHkgZG8gd2UgbmVl ZCB0byBkZWZpbmUgdGhlIG9wdGlvbmFsIG1ldGFkYXRhIGFuZCBob3cgaXMgaXQNCnNpZ25pZmlj YW50bHkgZGlmZmVyZW50IGZyb20gdGhlIGNvbnRleHQgYmxvY2sgYWxyZWFkeSBwcm9wb3NlZCBp biBuc2g/DQoNCj4gDQo+DQo+VGhhbmtzLA0KPkNhdGh5DQo+DQo+DQo+T24gMS8yOS8xNSwgMjo0 NCBQTSwgIkNhdGh5IFpoYW5nIiA8Q2F0aHkuSC5aaGFuZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4N Cj4+SGkgZXZlcnlvbmUsDQo+Pg0KPj5XZSBoYXZlIHVwbG9hZGVkIGEgbmV3IFNDSCB2ZXJzaW9u ICgzKSB3aGljaCBhZGRzIGRlZmluaXRpb24gb2YgYSBuZXcNCj4+bWV0YWRhdGEgdHlwZSBmb3Ig dGhlIGZsb3cgSUQgdG8gc3VwcG9ydCBsb2FkIGJhbGFuY2luZyBhbW9uZyBTRg0KPj5pbnN0YW5j ZXMgYW5kIG1pdGlnYXRlIHRoZSBwb3RlbnRpYWwgaXNzdWUgb2YgIm5vdCBlbm91Z2ggcGF0aCBJ RCIuIFRoZQ0KPj5mbG93IElEIGlzIG5hbWVkICJyZW5kZXJlZCBzZXJ2aWNlIHBhdGggSUQiIGlu IHRoZSBkcmFmdC4gUGxlYXNlIHJlZmVyIHRvDQo+PnNlY3Rpb24gNC4zLjIgb2YgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctc2ZjLXNjaC8NCj4+Zm9yIGRldGFp bCBkZXNjcmlwdGlvbi4NCj4+IA0KPj4NCj4+SW4gaXRzIHByZXZpb3VzIHZlcnNpb24sIFNDSCBk ZWZpbmVzIGEgIkJ5cGFzcyBiaXQiIGluIHRoZSBiYXNlIGhlYWRlci4NCj4+VGhpcyBiaXQgZW5h YmxlcyB0aGUgU0YgdG8gcHJvdmlkZSBmZWVkYmFjay9ub3RpZmljYXRpb24gdmlhIHRoZSBkYXRh DQo+PnBhdGggdG8gaXRzIGNvbm5lY3RpbmcgU0ZGIGFib3V0IHdoZXRoZXIgdGhlIHJlbWFpbmlu ZyBwYWNrZXRzIG9mIHRoZSBTRkMNCj4+c2hvdWxkIGJ5cGFzcyB0aGF0IFNGLiBUaGlzIGlzIHVz ZWZ1bCBpbiB0aGUgY2FzZSB0aGF0IG9ubHkgdGhlIGZpcnN0IGZldw0KPj5wYWNrZXRzIG9mIGEg ZmxvdyBuZWVkIHRvIGdvIHRvIGEgU0YgKHN1Y2ggYXMgYSBEUEkgb3IgRlcgb3IgSURTKSBhbmQN Cj4+cmVtYWluaW5nIHBhY2tldHMgY2FuIGJ5cGFzcyB0aGF0IFNGLCB0aHVzIHNhdmluZyB0aGUg ZXhwZW5zaXZlIFNGDQo+PnJlc291cmNlIGFuZCByZWR1Y2luZyBkYXRhIHBhdGggbGF0ZW5jeS4N Cj4+DQo+PkIgYml0OiBUaGUgQiAoQnlwYXNzKSBiaXQsIHdoZW4gc2V0IHRvIDEsIGl0IGlzIHVz ZWQgYnkgYSBTZXJ2aWNlDQo+PiAgICAgICBGdW5jdGlvbiB0byBzaWduYWwgdG8gaXRzIFNlcnZp Y2UgRnVuY3Rpb24gRm9yd2FyZGVyIHRoYXQgbm8NCj4+ICAgICAgIGZ1cnRoZXIgcGFja2V0cyBh cmUgdG8gYmUgc2VudCB0byBpdCBmb3IgdGhlIGZsb3cgc3BlY2lmaWVkIGluDQo+PmVuY2Fwc3Vs YXRlZCBwYWNrZXQuDQo+Pg0KPj5JbiBhZGRpdGlvbiwgU0NIIGRlZmluZXMgYSBtZXRhZGF0YSB0 eXBlIGZvciBHZW5lcmljIENvbnRleHQgQmxvY2ssIHdoaWNoDQo+PmlzIG9wdGlvbmFsIGFuZCBj YW4gYmUgdXNlZCBpZiBuZWVkZWQgdG8gY2FycnkgYW55IHZlbmRvcidzIHNwZWNpZmljDQo+PiJD b250ZXh0IEhlYWRlciIuDQo+PiANCj4+DQo+PkFueSBjb21tZW50cyBvbiB0aGVzZSBuZXcgYWRk aXRpb25zPw0KPj4NCj4+VGhhbmtzLA0KPj5DYXRoeQ0KPj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBDYXRoeSBaaGFuZw0KPj5TZW50OiBGcmlkYXksIERlY2VtYmVyIDA1LCAyMDE0IDEx OjQ3IEFNDQo+PlRvOiBTcmluaSBBZGRlcGFsbGk7IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsg Sm9lbCBNLiBIYWxwZXJuOw0KPj4nc2ZjQGlldGYub3JnJw0KPj5DYzogbnNtdXJ0aHlAZnJlZXNj YWxlLmNvbQ0KPj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+Piho dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4+DQo+ PlJvbiwgTG91aXMsIE15byBhbmQgSSBoYXZlIGJlZW4gZGlzY3Vzc2luZyBvZmYgbGluZSBsYXN0 IGZldyB3ZWVrcyBhYm91dA0KPj5kZWZpbmluZyBhIG1ldGFkYXRhIHR5cGUgZm9yIGZsb3cgSUQg aW4gYWRkaXRpb24gdG8gdGhlIHBhdGggSUQgb2YgdGhlDQo+Pm1haW4gaGVhZGVyIHRvIHN1cHBv cnQgbG9hZCBiYWxhbmNpbmcgYW1vbmcgU0YgaW5zdGFuY2VzLiBXZSB3aWxsIGRlZmluZQ0KPj5h IFRMViB0eXBlIGZvciB0aGUgZmxvdyBJRC4gVGhlIGNvbWJpbmF0aW9uIG9mICJwYXRoIElEICsg ZmxvdyBJRCINCj4+c3BlY2lmaWVzIGEgcmVhbGl6ZWQgc2VydmljZSBjaGFpbiBpbnN0YW5jZSBw YXRoLiBJdCBpcyBsZWZ0IHRvIHRoZQ0KPj5kZXNpZ24vaW1wbGVtZW50YXRpb24gd2hldGhlciB0 byB1c2UgYSBjZW50cmFsaXplZCBtZXRob2Qgb3IgYQ0KPj5kaXN0cmlidXRlZCBtZXRob2QgdG8g YmluZCB0aGUgZmxvdyBJRCB0byBhIHJlYWxpemVkIHNlcnZpY2UgaW5zdGFuY2UNCj4+cGF0aCBh bHRob3VnaCBvdXIgb3JpZ2luYWwgdGhvdWdodCBpcyBmb3IgZGlzdHJpYnV0ZWQgTEIgdXNhZ2Uu IEkgYW0gbm90DQo+PnN1cmUgaWYgd2UgbmVlZCBhIGJpdCBpbiB0aGUgaGVhZGVyIHRvIGRlbm90 ZSB3aGV0aGVyIHRoZXJlIGFyZSBtb3JlIHBhdGgNCj4+SUQgYml0cyAod2UgY2FsbCBpdCBmbG93 IElEKSBpbiB0aGUgbWV0YWRhdGEgZmllbGRzIHNpbmNlIHdoZW4geW91IHBhcnNlDQo+PnRoZSBU TFYgbWV0YWRhdGEsIHlvdSB3aWxsIGtub3cgd2hldGhlciB0aGVyZSBhcmUgZmxvdyBJRCBiaXRz IG9yIG5vdC4NCj4+Tm90ZSB0aGF0IGlmIG11bHRpcGxlIHNlc3Npb25zIHNoYXJlIHRoZSBzYW1l IHJlYWxpemVkIHNlcnZpY2UgaW5zdGFuY2UNCj4+cGF0aCwgdGhleSB3aWxsIHNoYXJlIHRoZSBz YW1lICJwYXRoIElEKyBmbG93IElEIi4gIFdlIGNhbiBhbHNvIGNvbnNpZGVyDQo+PmV4dGVuZGlu ZyB0aGUgbnVtYmVyIG9mIGJpdHMgdG8gMzIgaWYgdGhhdCBpcyB0aGUgY29uc2Vuc3VzLiBXZSB3 aWxsIHBvc3QNCj4+YW4gdXBkYXRlZCBkcmFmdCBkZXNjcmliaW5nIHRoZXNlIHNvb24uDQo+Pg0K Pj5UaGFua3MsDQo+PkNhdGh5DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5G cm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFNyaW5p IEFkZGVwYWxsaQ0KPj5TZW50OiBGcmlkYXksIERlY2VtYmVyIDA1LCAyMDE0IDc6MTcgQU0NCj4+ VG86IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgSm9lbCBNLiBIYWxwZXJuOyAnc2ZjQGlldGYu b3JnJw0KPj5DYzogbnNtdXJ0aHlAZnJlZXNjYWxlLmNvbQ0KPj5TdWJqZWN0OiBSZTogW3NmY10g Q29tbWVudHMgb24gU0NIIERyYWZ0DQo+PihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtemhhbmctc2ZjLXNjaC0wMikNCj4+DQo+Pg0KPj5bUlBdIERhdGEgcGxhbmUgZWZmaWNpZW5j eS4NCj4+DQo+PlNSSU5JPiBJIGFtIG5vdCBzbyBzdXJlIGFib3V0IGRhdGEgcGxhbmUgZWZmaWNp ZW5jeS4gIE1vc3Qgb2YgdGhlDQo+PnByb2Nlc3NvcnMgd29yayBnb29kIGlmIHRoZSBudW1iZXIg b2YgYml0cyBhcmUgZWl0aGVyIDMyIG9yIDY0LiAgSWYgaXQgaXMNCj4+MjQgYml0cywgdGhlbiBv bmUgbmVlZHMgdG8gZG8gbWFza2luZyBhbmQgc2hpZnRpbmcgYmVmb3JlIHRoZSB2YWx1ZSBpcw0K Pj51c2VkIHRvIGRvIGFueSBsb29rdXAuICAgQnV0LCB0aGlzIGRpc2N1c3Npb24gY2FuIGdvIGlu dG8gZGlmZmVyZW50DQo+PmRpcmVjdGlvbiA6LSksIGl0IG1heSBub3QgYmUgZ29vZCB0byBnbyBp biB0aGF0IGRpcmVjdGlvbi4NCj4+DQo+PldoZXJlIGRvIHdlIGRyYXcgdGhlIGxpbmU/IDMyLWJp dHMsIDY0LWJpdHMsDQo+PjEyOCBiaXRzPyBJIHRoaW5rIHdlIHNob3VsZCBoYXZlIGEgc2Vuc2li bGUgdmFsdWUgaW4gdGhlIFNlcnZpY2UgUGF0aA0KPj5oZWFkZXIgYW5kIGlmIHlvdSBuZWVkIHRv IGNvbnZleSBtb3JlIGJpdHMgeW91IG5lZWQgdG8gdXNlIHRoZSBjb250ZXh0DQo+PmhlYWRlcnMu DQo+Pg0KPj5TUklOST4gVGhpcyBpcyBhIGdvb2QgcG9pbnQuICBUaGlzIHNob3VsZCB3b3JrIGZp bmUgYXMgbG9uZyBhcyB0aGVyZSBpcw0KPj53YXkgdG8gY29udmV5IGluIHRoZSBtYWluIGhlYWRl ciB0aGF0IHRoZSBleHRlbnNpb24gdG8gcGF0aCBJRCBpcw0KPj5hdmFpbGFibGUgaW4gc28gYW5k IHNvIFRMViBmaWVsZC4gIFRoYXQgc2hvdWxkIHdvcmsgdG9vLg0KPj4NCj4+VGhhbmtzDQo+PlNy aW5pDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PkZy b206IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKSA8cmVwZW5ub0BjaXNjby5jb20+DQo+PlNlbnQ6 IEZyaWRheSwgRGVjZW1iZXIgNSwgMjAxNCA3OjA4IEFNDQo+PlRvOiBBZGRlcGFsbGkgU3Jpbmkt QjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47ICdzZmNAaWV0Zi5vcmcnDQo+PkNjOiBOUyBTcmluaXZh c2EgTXVydGh5LUIzNzg0MA0KPj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERy YWZ0DQo+PihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0w MikNCj4+DQo+Pk9uIDEyLzUvMTQsIDY6NTQgQU0sICJTcmluaSBBZGRlcGFsbGkiIDxzYWRkZXBh bGxpQGZyZWVzY2FsZS5jb20+IHdyb3RlOg0KPj4NCj4+Pg0KPj4+SW4gcmVhbCBkZXBsb3ltZW50 cywgbnVtYmVyIG9mIGFjdGl2ZSBwYXRoIElEcyBhcmUgdmVyeSBsZXNzZXIgdGhhbg0KPj4+Ml42 NCwNCj4+PmJ1dCB0aGVyZSBpcyBhIGdvb2QgcG9zc2liaWxpdHkgb2YgdGhlIG51bWJlciBiZWlu ZyBtb3JlIHRoYW4gMl4yNA0KPj4+KDE2TSkuDQo+Pj4gSSB0aGluayBiaWdnZXIgcG9pbnQgaXMg dGhhdCB3aHkgcmVzdHJpY3QgdGhpcyBpbiB0aGUgc3RhbmRhcmRzPyBXaGF0DQo+Pj5hZHZhbnRh Z2UgZG8gd2UgaGF2ZSByZXN0cmljdGluZyB0aGlzIHNpemUgdG8gMjQgYml0cz8NCj4+DQo+PltS UF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5LiBXaGVyZSBkbyB3ZSBkcmF3IHRoZSBsaW5lPyAzMi1i aXRzLCA2NC1iaXRzLA0KPj4xMjggYml0cz8gSSB0aGluayB3ZSBzaG91bGQgaGF2ZSBhIHNlbnNp YmxlIHZhbHVlIGluIHRoZSBTZXJ2aWNlIFBhdGgNCj4+aGVhZGVyIGFuZCBpZiB5b3UgbmVlZCB0 byBjb252ZXkgbW9yZSBiaXRzIHlvdSBuZWVkIHRvIHVzZSB0aGUgY29udGV4dA0KPj5oZWFkZXJz Lg0KPj4NCj4+DQo+Pj4NCj4+PlRoZXJlIGNhbiBiZSBkZXBsb3ltZW50cywgd2hlcmUgU0ZDIGNv bnRyb2xsZXIgKExvZ2ljYWxseSBjZW50cmFsLCBidXQNCj4+PmRpc3RyaWJ1dGVkKSAgaXRzZWxm IGNhbiBkbyB0aGUgU0YgaW5zdGFuY2Ugc2VsZWN0aW9uIG9uIHBlcg0KPj4+Y29ubmVjdGlvbi9z ZXNzaW9uIGJhc2lzLCB0aGVyZWJ5IGF2b2lkaW5nIHRoZSBMQnMgZm9yIHNlcnZpY2VzLiAgIElu IG15DQo+Pj52aWV3LCBhc3N1bXB0aW9uIHRoYXQgdGhlcmUgd2lsbCBiZSBMQiBTRiBmb3IgZWFj aCBzY2FsZS1vdXQgc2VydmljZSBpbg0KPj4+dGhlIGNoYWluIGlzIG5vdCB2YWxpZCBpbiBhbGwg Y2FzZXMuDQo+Pj4NCj4+PlRoYW5rcw0KPj4+U3JpbmkNCj4+Pg0KPj4+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+RnJvbTogUmVpbmFsZG8gUGVubm8gKHJlcGVu bm8pIDxyZXBlbm5vQGNpc2NvLmNvbT4NCj4+PlNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciA0LCAy MDE0IDE6MTcgUE0NCj4+PlRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhhbHBl cm47IHNmY0BpZXRmLm9yZw0KPj4+Q2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3ODQwDQo+Pj5T dWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+Pj4oaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+Pj4NCj4+PklmIEkgdW5k ZXJzdG9vZCB5b3UsIEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgcmVhbGlzdGljLiBBcmUgeW91IHNh eWluZw0KPj4+eW91DQo+Pj5uZWVkIDY0LWJpdHMgb2YgcGF0aHMgYW5kIHRoZW4gd2lsbCBtb25p dG9yIHRoZW0gYWxsPyBEbyBmYXVsdCB0b2xlcmFuY2UNCj4+PmFuZCBPQU0gZm9yIDJeNjQtYml0 cyB3b3J0aCBvZiBwYXRocz8gSnVzdCBmb3IgY29tcGFyaXNvbiwgaXSp9nMgbGlrZQ0KPj4+bWFu YWdpbmcgYW5kIG1vbml0b3JpbmcgdGhlIGVudGlyZSBJUHY2IGhvc3QgcmFuZ2UsIG9uZS1ieS1v bmUuDQo+Pj4NCj4+PkFueXdheSwgSSBkbyBub3QgZXhwZWN0IGV2ZXJ5IHNpbmdsZSBwZXJtdXRh dGlvbnMgdG8gYmUgYSBkaWZmZXJlbnQNCj4+PnBhdGguDQo+Pj4NCj4+PklmIGVhY2ggc2Vydmlj ZSBoYXMgMjU2IGRldmljZXMgcHJvdmlkaW5nIHNpbWlsYXIgc2VydmljZSwgeW91IHNob3VsZA0K Pj4+bW9zdA0KPj4+bGlrZWx5IHVzZSBsb2FkLWJhbGFuY2luZyBhbmQgdGhlbiB5b3Ugd291bGQg aGF2ZSBhIHNpbmdsZSAob3IgYSBmZXcpDQo+Pj5wYXRocy4gVGhlcmUgaXMgc29tZSBkaXNjdXNz aW9uIGdvaW5nIG9uIExCLg0KPj4+DQo+Pj5Gcm9tIGEgZGF0YSBwbGFuZSBwZXJzcGVjdGl2ZSwg dGhlIHBhdGggaXMgdWx0aW1hdGVseSBkZWZpbmVkIGJ5IHRoZQ0KPj4+U0ZGcw0KPj4+dHJhdmVy c2VkIGFuZCBzZXJ2aWNlcyBwcm92aWRlZCwgbm90IGJ5IGEgc3BlY2lmaWMgSVA6cG9ydCB0aGF0 IHRoZQ0KPj4+ZGV2aWNlDQo+Pj5wcm92aWRpbmcgdGhlIHNlcnZpY2Ugc2l0cyBvbi4gV2VsbCwg YXQgbGVhc3QgZnJvbSBhIEdQRStOU0gNCj4+PnBlcnNwZWN0aXZlLg0KPj4+DQo+Pj4NCj4+Pk9u IDEyLzQvMTQsIDEyOjU3IFBNLCAiU3JpbmkgQWRkZXBhbGxpIiA8c2FkZGVwYWxsaUBmcmVlc2Nh bGUuY29tPg0KPj4+d3JvdGU6DQo+Pj4NCj4+Pj5JZiBJIHRha2UgYSBjaGFpbiB3aXRoIDUgc2Vy dmljZXMgd2l0aCBlYWNoIHNlcnZpY2UgIHNheSBoYXZpbmcgMjU2DQo+Pj4+aW5zdGFuY2VzIGZv ciBzY2FsZS1vdXQsIHBvc3NpYmxlIG51bWJlciBvZiBwYXRocyBhcmUNCj4+Pj4yNTYqMjU2KjI1 NioyNTYqMjU2DQo+Pj4+PSAweEZGIEZGIEZGIEZGIEZGLiBPbmUgcmVxdWlyZXMgMzMgYml0cyBp biB0aGlzIGNhc2UuICBJZiB0aGVyZSBhcmUNCj4+Pj5tb3JlDQo+Pj4+c2VydmljZXMgaW4gdGhl IGNoYWluIG9yIG1vcmUgY2hhaW5zIG9yIG1vcmUgaW5zdGFuY2VzIGZvciBzY2FsZS1vdXQsDQo+ Pj4+dGhlbiBpdCBjb3VsZCBnbyB0byBiaWcgbnVtYmVyIHZlcnkgZmFzdC4NCj4+Pj4NCj4+Pj5B cyBJIG1lbnRpb25lZCBteSBwcmVmZXJlbmNlIGlzIHRvIG1ha2UgdGhlIHBhdGggSUQgc2l6ZSBm bGV4aWJsZSBmb3INCj4+Pj5mdXR1cmUgZ3Jvd3RoLiBJZiB0aGF0IGlzIHBlcmNlaXZlZCBhcyBj b21wbGV4LCB0aGVuIGdvaW5nIGZvciA2NGJpdCBpcw0KPj4+PnNhZmVyIGJldC4NCj4+Pj4NCj4+ Pj5UaGFua3MNCj4+Pj5TcmluaQ0KPj4+Pg0KPj4+Pg0KPj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+RnJvbTogSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJu LmNvbV0NCj4+Pj5TZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMDQsIDIwMTQgMTI6MDUgUE0NCj4+ Pj5UbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2MDsgSm9lbCBNLiBIYWxwZXJuOyBzZmNAaWV0Zi5v cmcNCj4+Pj5DYzogTlMgU3Jpbml2YXNhIE11cnRoeS1CMzc4NDANCj4+Pj5TdWJqZWN0OiBSZTog W3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+Pj4+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4+Pg0KPj4+PkEgY29udHJvbGxlciAob3Ig b3RoZXIgZGVjaXNpb24gbG9naWMpIGNhbiBjZXJ0YWlubHkgYmUgYXdhcmUgb2Ygc3VjaA0KPj4+ PmNvbmNlcm5zLg0KPj4+PkJ1dCB0aGUgbnVtYmVyIG9mIHNlcnZpY2UgZnVuY3Rpb24gcGF0aHMg aXMgbm90IHJlbGF0ZWQgdG8gdGhlIG51bWJlcg0KPj4+Pm9mDQo+Pj4+Zmxvd3Mgb3IgdGhlIG51 bWJlciBvZiB0ZW5hbnRzLiAgSXQgaXMgcmVsYXRlZCB0byB0aGUgbnVtYmVyIG9mDQo+Pj4+Y29t YmluYXRpb25zIG9mIHNlcnZpY2VzIGFuZCB0aGUgcG9saWNpZXMgZm9yIHNlcnZpY2UgZnVuY3Rp b24NCj4+Pj5zZWxlY3Rpb24uDQo+Pj4+IFdoaWxlIHRoYXQgY2FuIGJlIGEgbGFyZ2UgbnVtYmVy LCBJIHN1cmUgaG9wZSBpdCBkb2VzIG5vdCBjb21lIGNsb3NlDQo+Pj4+dG8NCj4+Pj5zYXR1cmF0 aW5nIDI0IGJpdHMuDQo+Pj4+DQo+Pj4+SGF2aW5nIHNhaWQgdGhhdCwgaWYgd2UgdGhpbmsgdGhh dCAyNCBiaXRzIGlzIG9ubHkganVzdCBlbm91Z2gsIHRoZW4gd2UNCj4+Pj5vdWdodCB0byB1c2Ug MzIuICBGcm9tIHdoZXJlIEkgc2l0LCBJIHdvdWxkIG5vcm1hbGx5IGV4cGVjdCAxNiBiaXRzIHRv DQo+Pj4+YmUNCj4+Pj5tb3JlIHRoYW4gc3VmZmljaWVudCwgd2hpY2ggaXMgd2h5IEkgYW0gY29t Zm9ydGFibGUgd2l0aCAyNC4gIEhhdmluZw0KPj4+PnNhaWQNCj4+Pj50aGF0LCB0aGUgZmllbGQg c2l6ZSBpcyBub3QgYSBiaWcgZGVhbCB0byBtZS4NCj4+Pj4NCj4+Pj5Zb3VycywNCj4+Pj5Kb2Vs DQo+Pj4+DQo+Pj4+T24gMTIvNC8xNCwgMjowMSBQTSwgU3JpbmkgQWRkZXBhbGxpIHdyb3RlOg0K Pj4+Pj4NCj4+Pj4+IEkgd2FzIG5vdCBpbXBseWluZyB0aGF0IHBhdGggSUQgc2hvdWxkIGhhdmUg aW5mb3JtYXRpb24gaW4gcmVnYXJkcyB0bw0KPj4+Pj50ZW5hbnQvY29udHJvbGxlci9mbG93L3Nj YWxlLW91dC4gIEJ1dCBTRkMgY29udHJvbGxlcnMgc2hvdWxkIGtlZXANCj4+Pj4+dGhlc2UNCj4+ Pj4+aW4gbWluZCB0byBhc3NpZ24gdGhlIHBhdGggSUQuICAgIEEgZGVwbG95bWVudCBjYW4gaGF2 ZSBtdWx0aXBsZQ0KPj4+Pj50ZW5hbnRzLCBlYWNoIHRlbmFudCBjYW4gaGF2ZSBtdWx0aXBsZSBu ZXR3b3JrcywgIHRoZXJlIGNvdWxkIGJlDQo+Pj4+Pm1pbGxpb25zIG9mIGZsb3dzIGluIGVhY2gg b2YgdGhvc2UgbmV0d29ya3MuICBBbmQgY29uc2lkZXJpbmcgYWxsDQo+Pj4+PnRoZXNlLA0KPj4+ Pj4gMjQgYml0IHBhdGggSUQgbWF5IG5vdCBiZSBhYmxlIHRvIHJlcHJlc2VudCBwYXRocyBmb3Ig dGhlc2UgZmxvd3MuDQo+Pj4+PkhlbmNlLCBJIHdhcyB3b25kZXJpbmcgd2hldGhlciBwYXRoIElE IGNhbiBiZSBleHRlbmRlZCB0byA2NCBiaXRzIG9yDQo+Pj4+Pm1ha2UgaXQgZmxleGlibGUuDQo+ Pj4+Pg0KPj4+Pj4gVGhhbmtzDQo+Pj4+PiBTcmluaQ0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IEZyb206IEpvZWwgTS4gSGFscGVy biA8am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciA0 LCAyMDE0IDc6NDIgQU0NCj4+Pj4+IFRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBzZmNAaWV0 Zi5vcmcNCj4+Pj4+IENjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPj4+Pj4gU3ViamVj dDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4+Pj4gKGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4+Pj4NCj4+Pj4+IFRoZSBJ bmRleCBpcyBub3QganVzdCBmb3IgbG9vcCBwcmV2ZW50aW9uLiAgSW4gdGhlIGNhc2Ugb2YgYW1i aWd1aXR5LA0KPj4+Pj4gdGhlIGluZGV4IHRlbGxzIHRoZSBTRkYgd2hlcmUgaW4gdGhlIHBhdGgg dGhlIHBhY2tldCBjdXJyZW50bHkNCj4+Pj4+cmVzaWRlcy4NCj4+Pj4+ICAgIFRoZXJlIGFyZSBt dWx0aXBsZSB3YXlzIHN1Y2ggYW1iaWd1aXR5IGNhbiBvY2N1ci4NCj4+Pj4+DQo+Pj4+PiBUaGUg UGF0aCBJZGVudGlmaWVyIGlzIHNwZWNpZmljYWxseSBub3QgZXhwZWN0ZWQgdG8gaW5jbHVkZQ0K Pj4+Pj5jb250cm9sbGVyDQo+Pj4+PiBJRCBvciBUZW5hbnQgSUQuICBXaGlsZSBhIGRlcGxveWVy IGNhbiBoYXZlIGEgcGF0aCBwZXIgdGVuYW50LCB0aGUNCj4+Pj4+IGFyY2hpdGVjdHVyZSBzdGls bCBkb2VzIG5vdCB0cmVhdCB0aGUgcGF0aCBJRCBhcyBhIHRlbmFudCBJRC4gIFRlbmFudA0KPj4+ Pj4gSUQsIGNvbnRyb2xsZXIgSUQsIGFuZCBvdGhlciBub24tcGF0aC1zcGVjaWZ5aW5nIGluZm9y bWF0aW9uIGlzIHRvIGJlDQo+Pj4+PiBjYXJyaWVkIGluIG1ldGFkYXRhLg0KPj4+Pj4NCj4+Pj4+ IFlvdXJzLA0KPj4+Pj4gSm9lbA0KPj4+Pj4NCj4+Pj4+IE9uIDEyLzQvMTQsIDEwOjAyIEFNLCBT cmluaSBBZGRlcGFsbGkgd3JvdGU6DQo+Pj4+Pj4gVHdvIGNvbW1lbnRzIDoNCj4+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+Pj4gMS4gIFNGIEluZGV4IDogIFNpbmNlIGl0IGlzIG1lYW50IGZvciBsb29wIGRl dGVjdGlvbiwgIHdvdWxkbid0DQo+Pj4+Pj4gYmV0dGVyIHRvIHJlbmFtZSB0aGlzIGFzICJUVEwi Pw0KPj4+Pj4+DQo+Pj4+Pj4gMi4gIFBhdGggSWRlbnRpZmllciA6ICAgIDI0IGJpdCBwYXRoIGlk ZW50aWZpZXIgc2VlbXMgdG8gYmUgdG9vDQo+Pj4+Pj5sZXNzLg0KPj4+Pj4+IEJhc2VkIG9uIG91 ciBleHBlcmllbmNlIGluIHRyYWZmaWMgc3RlZXJpbmcsICB0aGlzIHBhdGggaWRlbnRpZmllcg0K Pj4+Pj4+IG5lZWRzIHRvIGVuY29kZSBnb29kIGFtb3VudCBvZiBpbmZvcm1hdGlvbiB0byBtYWtl IGl0IHVuaXF1ZS4gIEZvcg0KPj4+Pj4+ZXhhbXBsZSwNCj4+Pj4+PiAgICB0aGlzIGlkZW50aWZp ZXIgbmVlZHMgdG8gZW5jb2RlIChpbiBvdXIgY2FzZSkgc29tZSBpbmZvcm1hdGlvbg0KPj4+Pj4+ IHJlcHJlc2VudGluZyB0aGUgZGlzdHJpYnV0ZWQgY29udHJvbGxlciBJRCwgIHRlbmFudCBJRCwg IGZsb3cgSUQsDQo+Pj4+Pj4gICAgU2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZSAoaW4gY2FzZSBv ZiBzY2FsZS1vdXQpIGFuZCBmZXcgbW9yZS4uDQo+Pj4+Pj4gT25lIHN1Z2dlc3Rpb24gaXMgdG8g bWFrZSBpdCA2NCBiaXRzIHZhbHVlICBvciB0byBtYWtlIGl0IGV2ZW4NCj4+Pj4+PmV4dGVuZGFi bGUsDQo+Pj4+Pj4gICAgaXQgaXMgZ29vZCBpZiBwYXRoIGlkZW50aWZpZXIgaXMgYWxzbyByZXBy ZXNlbnRlZCBpbiBUTFYgZm9ybS4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gVGhhbmtzDQo+Pj4+ Pj4NCj4+Pj4+PiBTcmluaQ0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBz ZmMgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gc2ZjQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+Pg0KPj4+Pg0KPj4+Pl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+c2ZjIG1haWxpbmcg bGlzdA0KPj4+PnNmY0BpZXRmLm9yZw0KPj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjDQo+Pj4NCj4+DQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPj5zZmMgbWFpbGluZyBsaXN0DQo+PnNmY0BpZXRmLm9yZw0K Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCj4+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+c2ZjIG1haWxpbmcg bGlzdA0KPj5zZmNAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PnNmYyBtYWlsaW5nIGxpc3QNCj4+c2ZjQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQoNCg== From nobody Tue Feb 3 17:00: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 4A7C11A871B for ; Tue, 3 Feb 2015 17:00:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEfBKZMetRv1 for ; Tue, 3 Feb 2015 17:00:34 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F9D11A8749 for ; Tue, 3 Feb 2015 17:00:16 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id DF12E43983E4A; Wed, 4 Feb 2015 01:00:07 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t1410AmE010837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Feb 2015 20:00:10 -0500 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.112]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Tue, 3 Feb 2015 20:00:10 -0500 From: "Dolganow, Andrew (Andrew)" To: Thomas Nadeau Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZx/9uiAgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgCAAEtwAIBWb4+AgAdtFgCAAJLygIAACR6A///L/gCAAEVHgP//tOuv Date: Wed, 4 Feb 2015 01:00:09 +0000 Message-ID: <6DFA52DC-DECF-45AA-93F0-F140EAC5E25E@alcatel-lucent.com> References: <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> , <7AE1FFB3-9A5F-41BC-B5F8-70DD6CBFB4AD@lucidvision.com> In-Reply-To: <7AE1FFB3-9A5F-41BC-B5F8-70DD6CBFB4AD@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_6DFA52DCDECF45AA93F0F140EAC5E25Ealcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: "Ken Gray \(kegray\)" , "sfc@ietf.org" , Cathy Zhang , "Zarny, Myo" , "nsmurthy@freescale.com" , Srini Addepalli , "Joel M. Halpern" , "Reinaldo Penno \(repenno\)" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 04 Feb 2015 01:00:40 -0000 --_000_6DFA52DCDECF45AA93F0F140EAC5E25Ealcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have to second Ken and Tom. If there is functionality that is not support= ed by draft Quinn, I propose the additional functions be brought to the li= st/group as additional proposals to extend draft Quinn. We can then discuss= those additions. The authors have been working with others, myself included, to build broad = consensus the draft Quinn represents. Thus, I see no reason to delay the ca= ll for support of the NSH draft. Andrew Sent from my iPhone On Feb 3, 2015, at 7:29 PM, Thomas Nadeau > wrote: I very much agree with ken's comments below. There is no reason to merge th= e drafts other than waste everyone's time. If you have something substantiv= e to contribute, go head and specify that very specific change. However, co= ming up with a draft that is what appears to be %95 the same as the other o= ne does not seem like a good reason to merge drafts. You typically only do = this when there are two very different approaches that the WG wants combine= d. This does not seem like that to me. Tom On Feb 3, 2015, at 7:20 PM, Ken Gray (kegray) > wrote: Respectfully, I don=92t think TLVs were a unique proposition, as these were= discussed informally in meetings (that I did attend) =85 have to search th= e list for =93TLV=94 uniqueness. Regardless, we shouldn=92t have had to re= ad three iterations of another document just to get that addition. Regarding remaining differences =85 I don=92t really see any, which makes = =93merge=94 a really inappropriate word for what=92s required. If =93merge=94 means =93time=94, I see no reason to delay a call for suppor= t of the nsh draft. On 2/3/15, 5:27 PM, "Zarny, Myo" = > wrote: Hi Ken, * IETF90 minutes explain the differences then. * Yes, the drafts are now very similar because the NSH draft has incorp= orated the TLV portion. * The generic context block is to accommodate NSH's four mandatory cont= ext header fields. * The chairs are actively working on a merged document with a section f= or remaining differences. Thanks, -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Cathy Zhang Sent: 3 February 2015 4:54 PM To: Ken Gray (kegray); Srini Addepalli; Reinaldo Penno (repenno); Joel M. H= alpern; 'sfc@ietf.org'; Cathy Zhang Cc: nsmurthy@freescale.com Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) Hi Ken, Please see inline. Thanks, Cathy -----Original Message----- From: Ken Gray (kegray) [mailto:kegray@cisco.com] Sent: Tuesday, February 03, 2015 10:09 AM To: Cathy Zhang; Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern= ; 'sfc@ietf.org' Cc: nsmurthy@freescale.com Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) As a general comment on this submission (and perhaps life in the current IE= TF). I have a REALLY hard time differentiating this draft from the quinn d= raft (which pre-dates it by quite a bit). Why are we pursuing a separate d= raft when the suggestions, IMHO, seem incremental at best? Cathy> The original motivation for drafting the SCH is to provide an altern= ative to draft-quinn-nsh to address the following perceived issues: 1. Mandatory fixed-sized metadata. We think they should not be mandatory si= nce the 4-word context fields are not needed in many scenarios 2. No variab= le length metadata. We think metadata should be optional and TLV format sho= uld be used to define metadata 3. No organizationally defined metadata 4. N= o Version field. When we uploaded SCH 1st version (3/24/2014), NSH version did not have the = TLV metadata and version field (they were added in its later version). I have reach out to the chairs here . we have a lot to read. Aren't drafts = supposed to offer significantly different views if they are to persist (wit= hout that, a "call to adopt" becomes a beauty contest, IMO)? No offense to= the authors, but we're in revision 3 and I don't see that here. Regarding the changes in this document: I do not find the flow ID functionally different than the use context heade= rs in the nsh draft, which seem to be a more multi-purpose concept. Cathy> Different people have different viewpoints. RSP ID is not defined in= NSH and from Paul (NSH author)'s reply, it seems he does not feel the need= of an RSP ID. Cathy> We see the need for RSP ID and thus defined it in SCH for open discu= ssion and would like to see the community's feedback on it. The B bit suggestion can cause a conflict in control and create an avenue f= or undesirable behavior, IMO. I've been working from the assumption that a= minimum requirement of a function is that it be manageable (if for no othe= r reason than effective elasticity and cohesive/predictable delivery of ser= vice), so I have little sympathy for those that are not - be they virtual o= r physical (even less sympathy for virtual functions that are unmanageable,= frankly). A self-management option in the SFC scenario has low value and = the corruption or misuse of the bit can cause chaos (an extra level of "fai= l"). Cathy> Could you clarify what you mean by "cause a conflict in control"? The Generic Context Block is confusing in light of the already extant optio= nal/variable metadata TLVs (why wouldn't you leverage one of them)? Cathy> I am not sure if I understand your point. The Generic Context Block = is one type of metadata which is in TLV format and is optional. Thanks, Cathy On 1/29/15, 2:44 PM, "Cathy Zhang" > wrote: >Hi everyone, > >We have uploaded a new SCH version (3) which adds definition of a new >metadata type for the flow ID to support load balancing among SF >instances and mitigate the potential issue of "not enough path ID". The >flow ID is named "rendered service path ID" in the draft. Please refer >to section 4.3.2 of >https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ >for detail description. > > >In its previous version, SCH defines a "Bypass bit" in the base header. >This bit enables the SF to provide feedback/notification via the data >path to its connecting SFF about whether the remaining packets of the >SFC should bypass that SF. This is useful in the case that only the >first few packets of a flow need to go to a SF (such as a DPI or FW or >IDS) and remaining packets can bypass that SF, thus saving the >expensive SF resource and reducing data path latency. > >B bit: The B (Bypass) bit, when set to 1, it is used by a Service > Function to signal to its Service Function Forwarder that no > further packets are to be sent to it for the flow specified in >encapsulated packet. > >In addition, SCH defines a metadata type for Generic Context Block, >which is optional and can be used if needed to carry any vendor's >specific "Context Header". > > >Any comments on these new additions? > >Thanks, >Cathy > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Cathy Zhang >Sent: Friday, December 05, 2014 11:47 AM >To: Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern; >'sfc@ietf.org' >Cc: nsmurthy@freescale.com >Subject: Re: [sfc] Comments on SCH Draft >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > >Ron, Louis, Myo and I have been discussing off line last few weeks >about defining a metadata type for flow ID in addition to the path ID >of the main header to support load balancing among SF instances. We >will define a TLV type for the flow ID. The combination of "path ID + flow= ID" >specifies a realized service chain instance path. It is left to the >design/implementation whether to use a centralized method or a >distributed method to bind the flow ID to a realized service instance >path although our original thought is for distributed LB usage. I am >not sure if we need a bit in the header to denote whether there are >more path ID bits (we call it flow ID) in the metadata fields since >when you parse the TLV metadata, you will know whether there are flow ID b= its or not. >Note that if multiple sessions share the same realized service instance >path, they will share the same "path ID+ flow ID". We can also >consider extending the number of bits to 32 if that is the consensus. >We will post an updated draft describing these soon. > >Thanks, >Cathy > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Srini Addepalli >Sent: Friday, December 05, 2014 7:17 AM >To: Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf.org' >Cc: nsmurthy@freescale.com >Subject: Re: [sfc] Comments on SCH Draft >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > > >[RP] Data plane efficiency. > >SRINI> I am not so sure about data plane efficiency. Most of the >processors work good if the number of bits are either 32 or 64. If it >is >24 bits, then one needs to do masking and shifting before the value is >used to do any lookup. But, this discussion can go into different >direction :-), it may not be good to go in that direction. > >Where do we draw the line? 32-bits, 64-bits, >128 bits? I think we should have a sensible value in the Service Path >header and if you need to convey more bits you need to use the context >headers. > >SRINI> This is a good point. This should work fine as long as there is >way to convey in the main header that the extension to path ID is >available in so and so TLV field. That should work too. > >Thanks >Srini > >________________________________________ >From: Reinaldo Penno (repenno) > >Sent: Friday, December 5, 2014 7:08 AM >To: Addepalli Srini-B22160; Joel M. Halpern; 'sfc@ietf.org' >Cc: NS Srinivasa Murthy-B37840 >Subject: Re: [sfc] Comments on SCH Draft >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > >On 12/5/14, 6:54 AM, "Srini Addepalli" > wrote: > >> >>In real deployments, number of active path IDs are very lesser than >>2^64, but there is a good possibility of the number being more than 2^24 = (16M). >> I think bigger point is that why restrict this in the standards? What >>advantage do we have restricting this size to 24 bits? > >[RP] Data plane efficiency. Where do we draw the line? 32-bits, >64-bits, >128 bits? I think we should have a sensible value in the Service Path >header and if you need to convey more bits you need to use the context >headers. > > >> >>There can be deployments, where SFC controller (Logically central, but >>distributed) itself can do the SF instance selection on per >>connection/session basis, thereby avoiding the LBs for services. In my >>view, assumption that there will be LB SF for each scale-out service >>in the chain is not valid in all cases. >> >>Thanks >>Srini >> >>________________________________________ >>From: Reinaldo Penno (repenno) > >>Sent: Thursday, December 4, 2014 1:17 PM >>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org >>Cc: NS Srinivasa Murthy-B37840 >>Subject: Re: [sfc] Comments on SCH Draft >>(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >> >>If I understood you, I do not think this is realistic. Are you saying >>you need 64-bits of paths and then will monitor them all? Do fault >>tolerance and OAM for 2^64-bits worth of paths? Just for comparison, >>it=B9s like managing and monitoring the entire IPv6 host range, one-by-on= e. >> >>Anyway, I do not expect every single permutations to be a different path. >> >>If each service has 256 devices providing similar service, you should >>most likely use load-balancing and then you would have a single (or a >>few) paths. There is some discussion going on LB. >> >>From a data plane perspective, the path is ultimately defined by the >>SFFs traversed and services provided, not by a specific IP:port that >>the device providing the service sits on. Well, at least from a >>GPE+NSH perspective. >> >> >>On 12/4/14, 12:57 PM, "Srini Addepalli" > wrote: >> >>>If I take a chain with 5 services with each service say having 256 >>>instances for scale-out, possible number of paths are >>>256*256*256*256*256 >>>=3D 0xFF FF FF FF FF. One requires 33 bits in this case. If there are >>>more services in the chain or more chains or more instances for >>>scale-out, then it could go to big number very fast. >>> >>>As I mentioned my preference is to make the path ID size flexible for >>>future growth. If that is perceived as complex, then going for 64bit >>>is safer bet. >>> >>>Thanks >>>Srini >>> >>> >>>-----Original Message----- >>>From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>Sent: Thursday, December 04, 2014 12:05 PM >>>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org >>>Cc: NS Srinivasa Murthy-B37840 >>>Subject: Re: [sfc] Comments on SCH Draft >>>(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >>> >>>A controller (or other decision logic) can certainly be aware of such >>>concerns. >>>But the number of service function paths is not related to the number >>>of flows or the number of tenants. It is related to the number of >>>combinations of services and the policies for service function >>>selection. >>> While that can be a large number, I sure hope it does not come close >>>to saturating 24 bits. >>> >>>Having said that, if we think that 24 bits is only just enough, then >>>we ought to use 32. From where I sit, I would normally expect 16 >>>bits to be more than sufficient, which is why I am comfortable with >>>24. Having said that, the field size is not a big deal to me. >>> >>>Yours, >>>Joel >>> >>>On 12/4/14, 2:01 PM, Srini Addepalli wrote: >>>> >>>> I was not implying that path ID should have information in regards >>>>to tenant/controller/flow/scale-out. But SFC controllers should >>>>keep these >>>>in mind to assign the path ID. A deployment can have multiple >>>>tenants, each tenant can have multiple networks, there could be >>>>millions of flows in each of those networks. And considering all >>>>these, >>>> 24 bit path ID may not be able to represent paths for these flows. >>>>Hence, I was wondering whether path ID can be extended to 64 bits or >>>>make it flexible. >>>> >>>> Thanks >>>> Srini >>>> >>>> ________________________________________ >>>> From: Joel M. Halpern = > >>>> Sent: Thursday, December 4, 2014 7:42 AM >>>> To: Addepalli Srini-B22160; sfc@ietf.org >>>> Cc: NS Srinivasa Murthy-B37840 >>>> Subject: Re: [sfc] Comments on SCH Draft >>>> (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >>>> >>>> The Index is not just for loop prevention. In the case of >>>>ambiguity, the index tells the SFF where in the path the packet >>>>currently resides. >>>> There are multiple ways such ambiguity can occur. >>>> >>>> The Path Identifier is specifically not expected to include >>>> controller ID or Tenant ID. While a deployer can have a path per >>>> tenant, the architecture still does not treat the path ID as a >>>> tenant ID. Tenant ID, controller ID, and other non-path-specifying >>>> information is to be carried in metadata. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 12/4/14, 10:02 AM, Srini Addepalli wrote: >>>>> Two comments : >>>>> >>>>> >>>>> 1. SF Index : Since it is meant for loop detection, wouldn't >>>>> better to rename this as "TTL"? >>>>> >>>>> 2. Path Identifier : 24 bit path identifier seems to be too less. >>>>> Based on our experience in traffic steering, this path identifier >>>>>needs to encode good amount of information to make it unique. For >>>>>example, >>>>> this identifier needs to encode (in our case) some information >>>>>representing the distributed controller ID, tenant ID, flow ID, >>>>> Service function instance (in case of scale-out) and few more.. >>>>> One suggestion is to make it 64 bits value or to make it even >>>>>extendable, >>>>> it is good if path identifier is also represented in TLV form. >>>>> >>>>> >>>>> Thanks >>>>> >>>>> Srini >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 _______________________________________________ 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 --_000_6DFA52DCDECF45AA93F0F140EAC5E25Ealcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I have to second Ken and Tom. If there is functionality that is not su= pported by draft Quinn, I propose the additional functions  be brought= to the list/group as additional proposals to extend draft Quinn. We can th= en discuss those additions. 

The authors have been working with others, myself included, to build b= road consensus the draft Quinn represents. Thus, I see no reason to delay the call for = support of the NSH draft. 

Andrew

Sent from my iPhone

On Feb 3, 2015, at 7:29 PM, Thomas Nadeau <tnadeau@lucidvision.com> wrote:

I very much agree with ken's comments below. There is no reason to mer= ge the drafts other than waste everyone's time. If you have something subst= antive to contribute, go head and specify that very specific change. Howeve= r, coming up with a draft that is what appears to be %95 the same as the other one does not seem like a good= reason to merge drafts. You typically only do this when there are two very= different approaches that the WG wants combined. This does not seem like t= hat to me.

Tom 




On Feb 3, 2015, at 7:20 PM, Ken Gray (kegray) <kegray@cisco.com> wrote:

Respectfully, I don=92t think TLVs were a unique proposition, as these= were discussed informally in meetings (that I did attend) =85 have to sear= ch the list for =93TLV=94 uniqueness.  Regardless, we shouldn=92t have= had to read three iterations of another document just to get that addition.  

Regarding remaining differences =85 I don=92t really see any, which ma= kes =93merge=94 a really inappropriate word for what=92s required.

If =93merge=94 means =93time=94, I see no reason to delay a call for s= upport of the nsh draft.

On 2/3/15, 5:27 PM, "Zarny, Myo" <Myo.Zarny@gs.com> wrote:

Hi Ken,
  • IETF90 minutes explain = the differences then.
  • Yes, the drafts are now= very similar because the NSH draft has incorporated the TLV portion.
    • <= li style=3D"margin-top: 5pt; margin-bottom: 5pt; ">The generic context bloc= k is to accommodate NSH's four mandatory context header fields.
  • The chairs are actively= working on a merged document with a section for remaining differences.
Thanks,
 
-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.= org] On Behalf Of Cathy Zhang
Sent: 3 February 2015 4:54 PM
To: Ken Gray (kegray); Srini Addepalli; Reinaldo Penno (repenno); Joel M. H= alpern; 'sfc@ietf.org'; Cathy Zhang
Cc: nsmurthy@freescale.com Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-s= ch-02)
 
Hi Ken,
 
Please see inline.
 
Thanks,
Cathy
 
-----Original Message-----
From: Ken Gray (kegray) [mailto:ke= gray@cisco.com]
Sent: Tuesday, February 03, 2015 10:09 AM
To: Cathy Zhang; Srini Addepalli; Reinaldo Penno (repenno); Joel M. Ha= lpern; 'sfc@ietf.org'
 
As a general comment on this submission (and perhaps life in the curre= nt IETF).  I have a REALLY hard time differentiating this draft from t= he quinn draft (which pre-dates it by quite a bit).  Why are we pursui= ng a separate draft when the suggestions, IMHO, seem incremental at best?
 
 
Cathy> The original motivation for drafting the SCH is to provide a= n alternative to draft-quinn-nsh to address the following perceived issues:=
1. Mandatory fixed-sized metadata. We think they should not be mandato= ry since the 4-word context fields are not needed in many scenarios 2. No v= ariable length metadata. We think metadata should be optional and TLV forma= t should be used to define metadata 3. No organizationally defined metadata 4. No Version field. 
When we uploaded SCH 1st version (3/24/2014), NSH version did not have= the TLV metadata and version field (they were added in its later version).=
 
 
 
I have reach out to the chairs here . we have a lot to read. Aren't dr= afts supposed to offer significantly different views if they are to persist= (without that, a "call to adopt" becomes a beauty contest, IMO)?=   No offense to the authors, but we're in revision 3 and I don't see that here.
 
 
Regarding the changes in this document:
 
I do not find the flow ID functionally different than the use context = headers in the nsh draft, which seem to be a more multi-purpose concept.
 
Cathy> Different people have different viewpoints. RSP ID is not de= fined in NSH and from Paul (NSH author)'s reply, it seems he does not feel = the need of an RSP ID.
Cathy> We see the need for RSP ID and thus defined it in SCH for op= en discussion and would like to see the community's feedback on it. 
 
The B bit suggestion can cause a conflict in control and create an ave= nue for undesirable behavior, IMO.  I've been working from the assumpt= ion that a minimum requirement of a function is that it be manageable (if f= or no other reason than effective elasticity and cohesive/predictable delivery of service), so I have little sympathy f= or those that are not - be they virtual or physical (even less sympathy for= virtual functions that are unmanageable, frankly).  A self-management= option in the SFC scenario has low value and the corruption or misuse of the bit can cause chaos (an extra level of= "fail").
 
Cathy> Could you clarify what you mean by "cause a conflict in= control"?
 
 
The Generic Context Block is confusing in light of the already extant = optional/variable metadata TLVs (why wouldn't you leverage one of them)?
 
Cathy> I am not sure if I understand your point. The Generic Contex= t Block is one type of metadata which is in TLV format and is optional.
 
Thanks,
Cathy
 
 
On 1/29/15, 2:44 PM, "Cathy Zhang" <Cathy.H.Zhang@huawei.com> wrote:
 
>Hi everyone,
>
>We have uploaded a new SCH version (3) which adds definition of a = new
>metadata type for the flow ID to support load balancing among SF <= /div>
>instances and mitigate the potential issue of "not enough pat= h ID". The
>flow ID is named "rendered service path ID" in the draft= . Please refer
>to section 4.3.2 of
>for detail description.
>
>
>In its previous version, SCH defines a "Bypass bit" in t= he base header.
>This bit enables the SF to provide feedback/notification via the d= ata
>path to its connecting SFF about whether the remaining packets of = the
>SFC should bypass that SF. This is useful in the case that only th= e
>first few packets of a flow need to go to a SF (such as a DPI or F= W or
>IDS) and remaining packets can bypass that SF, thus saving the
>expensive SF resource and reducing data path latency.
>
>B bit: The B (Bypass) bit, when set to 1, it is used by a Service<= /div>
>       Function to signal to its Ser= vice Function Forwarder that no
>       further packets are to be sen= t to it for the flow specified in
>encapsulated packet.
>
>In addition, SCH defines a metadata type for Generic Context Block= ,
>which is optional and can be used if needed to carry any vendor's =
>specific "Context Header".
>
>
>Any comments on these new additions?
>
>Thanks,
>Cathy
>
>-----Original Message-----
>From: sfc [mailto:sfc-boun= ces@ietf.org] On Behalf Of Cathy Zhang
>Sent: Friday, December 05, 2014 11:47 AM
>To: Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern;
>Subject: Re: [sfc] Comments on SCH Draft
>
>Ron, Louis, Myo and I have been discussing off line last few weeks=
>about defining a metadata type for flow ID in addition to the path= ID
>of the main header to support load balancing among SF instances. W= e
>will define a TLV type for the flow ID. The combination of "p= ath ID + flow ID"
>specifies a realized service chain instance path. It is left to th= e
>design/implementation whether to use a centralized method or a
>distributed method to bind the flow ID to a realized service insta= nce
>path although our original thought is for distributed LB usage. I = am
>not sure if we need a bit in the header to denote whether there ar= e
>more path ID bits (we call it flow ID) in the metadata fields sinc= e
>when you parse the TLV metadata, you will know whether there are f= low ID bits or not.
>Note that if multiple sessions share the same realized service ins= tance
>path, they will share the same "path ID+ flow ID".&n= bsp; We can also
>consider extending the number of bits to 32 if that is the consens= us.
>We will post an updated draft describing these soon.
>
>Thanks,
>Cathy
>
>-----Original Message-----
>From: sfc [mailto:sfc-boun= ces@ietf.org] On Behalf Of Srini Addepalli
>Sent: Friday, December 05, 2014 7:17 AM
>To: Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf.org'
>Subject: Re: [sfc] Comments on SCH Draft
>
>
>[RP] Data plane efficiency.
>
>SRINI> I am not so sure about data plane efficiency.  Most= of the
>processors work good if the number of bits are either 32 or 64.&nb= sp; If it
>is
>24 bits, then one needs to do masking and shifting before the valu= e is
>used to do any lookup.   But, this discussion can go int= o different
>direction :-), it may not be good to go in that direction.
>
>Where do we draw the line? 32-bits, 64-bits,
>128 bits? I think we should have a sensible value in the Service P= ath
>header and if you need to convey more bits you need to use the con= text
>headers.
>
>SRINI> This is a good point.  This should work fine as lon= g as there is
>way to convey in the main header that the extension to path ID is =
>available in so and so TLV field.  That should work too.
>
>Thanks
>Srini
>
>________________________________________
>From: Reinaldo Penno (repenno) <repenno@cisco.com>
>Sent: Friday, December 5, 2014 7:08 AM
>To: Addepalli Srini-B22160; Joel M. Halpern; 'sfc@ietf.org'
>Cc: NS Srinivasa Murthy-B37840
>Subject: Re: [sfc] Comments on SCH Draft
>
>On 12/5/14, 6:54 AM, "Srini Addepalli" <saddepalli@freescale.com> wrote:
>
>>
>>In real deployments, number of active path IDs are very lesser= than
>>2^64, but there is a good possibility of the number being more= than 2^24 (16M).
>> I think bigger point is that why restrict this in the standar= ds? What
>>advantage do we have restricting this size to 24 bits?
>
>[RP] Data plane efficiency. Where do we draw the line? 32-bits,
>64-bits,
>128 bits? I think we should have a sensible value in the Service P= ath
>header and if you need to convey more bits you need to use the con= text
>headers.
>
>
>>
>>There can be deployments, where SFC controller (Logically cent= ral, but
>>distributed)  itself can do the SF instance selection on = per
>>connection/session basis, thereby avoiding the LBs for service= s.   In my
>>view, assumption that there will be LB SF for each scale-out s= ervice
>>in the chain is not valid in all cases.
>>
>>Thanks
>>Srini
>>
>>________________________________________
>>From: Reinaldo Penno (repenno) <repenno@cisco.com>
>>Sent: Thursday, December 4, 2014 1:17 PM
>>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org
>>Cc: NS Srinivasa Murthy-B37840
>>Subject: Re: [sfc] Comments on SCH Draft
>>
>>If I understood you, I do not think this is realistic. Are you= saying
>>you need 64-bits of paths and then will monitor them all? Do f= ault
>>tolerance and OAM for 2^64-bits worth of paths? Just for compa= rison,
>>it=B9s like managing and monitoring the entire IPv6 host range= , one-by-one.
>>
>>Anyway, I do not expect every single permutations to be a diff= erent path.
>>
>>If each service has 256 devices providing similar service, you= should
>>most likely use load-balancing and then you would have a singl= e (or a
>>few) paths. There is some discussion going on LB.
>>
>>From a data plane perspective, the path is ultimately defined = by the
>>SFFs traversed and services provided, not by a specific IP:por= t that
>>the device providing the service sits on. Well, at least from = a
>>GPE+NSH perspective.
>>
>>
>>On 12/4/14, 12:57 PM, "Srini Addepalli" <saddepalli@freescale.com> wrote= :
>>
>>>If I take a chain with 5 services with each service  = say having 256
>>>instances for scale-out, possible number of paths are
>>>256*256*256*256*256
>>>=3D 0xFF FF FF FF FF. One requires 33 bits in this case.&n= bsp; If there are
>>>more services in the chain or more chains or more instance= s for
>>>scale-out, then it could go to big number very fast.
>>>
>>>As I mentioned my preference is to make the path ID size f= lexible for
>>>future growth. If that is perceived as complex, then going= for 64bit
>>>is safer bet.
>>>
>>>Thanks
>>>Srini
>>>
>>>
>>>-----Original Message-----
>>>From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>>Sent: Thursday, December 04, 2014 12:05 PM
>>>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org
>>>Cc: NS Srinivasa Murthy-B37840
>>>Subject: Re: [sfc] Comments on SCH Draft
>>>
>>>A controller (or other decision logic) can certainly be aw= are of such
>>>concerns.
>>>But the number of service function paths is not related to= the number
>>>of flows or the number of tenants.  It is related to = the number of
>>>combinations of services and the policies for service func= tion
>>>selection.
>>> While that can be a large number, I sure hope it does not= come close
>>>to saturating 24 bits.
>>>
>>>Having said that, if we think that 24 bits is only just en= ough, then
>>>we ought to use 32.  From where I sit, I would normal= ly expect 16
>>>bits to be more than sufficient, which is why I am comfort= able with
>>>24.  Having said that, the field size is not a big de= al to me.
>>>
>>>Yours,
>>>Joel
>>>
>>>On 12/4/14, 2:01 PM, Srini Addepalli wrote:
>>>>
>>>> I was not implying that path ID should have informati= on in regards
>>>>to tenant/controller/flow/scale-out.  But SFC con= trollers should
>>>>keep these
>>>>in mind to assign the path ID.    A dep= loyment can have multiple
>>>>tenants, each tenant can have multiple networks, = there could be
>>>>millions of flows in each of those networks.  And= considering all
>>>>these,
>>>> 24 bit path ID may not be able to represent paths for= these flows.
>>>>Hence, I was wondering whether path ID can be extended= to 64 bits or
>>>>make it flexible.
>>>>
>>>> Thanks
>>>> Srini
>>>>
>>>> ________________________________________
>>>> From: Joel M. Halpern <jmh@joelhalpern.com>
>>>> Sent: Thursday, December 4, 2014 7:42 AM
>>>> To: Addepalli Srini-B22160; sfc@ietf.org
>>>> Cc: NS Srinivasa Murthy-B37840
>>>> Subject: Re: [sfc] Comments on SCH Draft
>>>>
>>>> The Index is not just for loop prevention.  In t= he case of
>>>>ambiguity,  the index tells the SFF where in the = path the packet
>>>>currently resides.
>>>>    There are multiple ways such ambigu= ity can occur.
>>>>
>>>> The Path Identifier is specifically not expected to i= nclude
>>>> controller ID or Tenant ID.  While a deployer ca= n have a path per
>>>> tenant, the architecture still does not treat the pat= h ID as a
>>>> tenant ID.  Tenant ID, controller ID, and other = non-path-specifying
>>>> information is to be carried in metadata.
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 12/4/14, 10:02 AM, Srini Addepalli wrote:
>>>>> Two comments :
>>>>>
>>>>>
>>>>> 1.  SF Index :  Since it is meant for l= oop detection,  wouldn't
>>>>> better to rename this as "TTL"?
>>>>>
>>>>> 2.  Path Identifier :    24 b= it path identifier seems to be too less.
>>>>> Based on our experience in traffic steering, = ; this path identifier 
>>>>>needs to encode good amount of information to make= it unique.  For
>>>>>example,
>>>>>    this identifier needs to encode= (in our case) some information 
>>>>>representing the distributed controller ID,  = tenant ID,  flow ID,
>>>>>    Service function instance (in c= ase of scale-out) and few more..
>>>>> One suggestion is to make it 64 bits value  = or to make it even
>>>>>extendable,
>>>>>    it is good if path identifier i= s also represented in TLV form.
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> Srini
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> sfc mailing list
>>>>> sfc@ietf.org<= /div>
>>>>>
>>>
>>>_______________________________________________
>>>sfc mailing list
>>
>
>
>_______________________________________________
>sfc mailing list
>
>_______________________________________________
>sfc mailing list
>
>_______________________________________________
>sfc mailing list
 
_______________________________________________
sfc mailing list
 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
--_000_6DFA52DCDECF45AA93F0F140EAC5E25Ealcatellucentcom_-- From nobody Wed Feb 4 08:12:45 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA2F1A8A9D for ; Wed, 4 Feb 2015 08:12:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZg6RuaRvIpS for ; Wed, 4 Feb 2015 08:12:40 -0800 (PST) Received: from mc26.lon.server.colt.net (mc26.lon.server.colt.net [212.74.77.106]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2851A8A4C for ; Wed, 4 Feb 2015 08:12:39 -0800 (PST) Received: from mc26.lon.server.colt.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B904EC009A for ; Wed, 4 Feb 2015 16:12:37 +0000 (UTC) Received: from mx3.qosmos.com (unknown [195.68.92.43]) by mc26.lon.server.colt.net (Postfix) with ESMTP id 8B8A1C0098 for ; Wed, 4 Feb 2015 16:12:37 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.09,518,1418079600"; d="scan'208";a="1514792" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 04 Feb 2015 17:12:37 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.51]) with mapi id 14.01.0438.000; Wed, 4 Feb 2015 17:12:36 +0100 From: Nicolas BOUTHORS To: Sumandra Majee , "'sfc@ietf.org'" , Cathy Zhang Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQO/5DH/wTNyDwgkS9ydl+3/sIXZzYeC9AgAC+I4CABLPaAIABt+CAgAEC0rA= Date: Wed, 4 Feb 2015 16:12:36 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D7D2CE5@LILAS.jungle.qosmos.com> References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> <76B41B8FACE1514795D30EC137FF391D7D1EE1@LILAS.jungle.qosmos.com> In-Reply-To: Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.14.1.85] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSVA-8.2.0.1679-7.5.0.1018-21304.000 X-TM-AS-Result: No--29.584-5.0-31-10 X-imss-scan-details: No--29.584-5.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-Version: IMSVA-8.2.0.1679-7.5.1018-21304.000 X-TMASE-Result: 10--29.583700-5.000000 X-TMASE-MatchedRID: l4bxV8Hot0EpwNTiG5IsErTTMie9o0Hd8GRhP/nTHNZnnK6mXN72m1PW us3yxQNWO1NNIxUUzbJ2RsuknD8OTytg+qZmq1X/TVa+L3Zgqc55y+Nu7/EOOgQLUvnBZL2KK93 7aFdF5XN29unsuRhoRDoUfa5EHPr2CnaJFV4XoXYtMfCdg6KRDSyV46Sc0EjTN2WxgvaD/zuJD1 0rEIivxgIne7QPu6d0ydUpugSvGW/51WNA1rE6t51U1lojafr/oSs220phCBfouUQSyt/Qyw4L5 wKZMQQFH8v35IbNkM6NeTCCHycaNZeHpCXvaaghvHKClHGjjr069SYlyUD4CoWJP3XdGAwuyRSE pZz6DA9ffzU9brcHlOuE2+PTEY9B0cTnofRVtgrsEjYqO+DyaB9fNWA7SFWqUzivBO6uvDXTvNp VkSD4M8B6+Ezq6YRlrApPd1rifOVk2mScVL/tBogQP9GwUC5r5TpDO1WKs2mWSyNgdonoDtQ/WY dCGipDuMMXUPHDoLWetuUPqzH1D9ee6yiQro3rjWe5HOFKvuM026H7nOZLrzCmUYns3FLTS0eiO srXcTjs+4BUXGOShNvT8jVXQhXrmA3J4bWPS3RGypC5CVFOHwXXmzqmsIi7qDs5oIeZkOuOPqa3 WX8UZp2rgJPOobJCUeFll3OD5wM31SSnyvm0TpN3sInxtjDT4+ZcrqvCDkGxW4YXFsTUDtozbeO DnXpl2sTjL9QSvDbuKSKH6UdotRKwwliN4mNuz5r5y9mouSC5pw2tsxj4tAdoubREUGy0QQ/s9v EJJnfCFE73Tfq2v1ntnspX3jsSFrC7JkTvr3eeAiCmPx4NwMFrpUbb72MU1B0Hk1Q1KyJGNS8BP La+j7ew1twePJJB3QfwsVk0UbslCGssfkpInQ== Archived-At: Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 04 Feb 2015 16:12:44 -0000 VGhlIE9ORiAsIGFzIHdlbGwgYXMgT3BlbnN0YWNrIHNoYXJlIHRoZSBpZGVhIG9mIGRlZmluaW5n IGFidHJhY3QgY2hhaW5zLCB3aGljaCB0aGVuIGdldCBpbnN0YW5jaWF0ZWQgaW4gY29uY3JldGUg aW5zdGFuY2UgbWFueSB0aW1lcy4NCg0KU28gaXQgaXMgbGlrZWx5IHRoYXQgdGhleSBjYW4gZ2Vu ZXJhdGUgaWRlbnRpZmllcnMgYm90aCB0aGUgU2VydmljZSBQYXRoIGFuZCBhIFJlbmRlcmVkIFNl cnZpY2UgUGF0aC4gIEkgdGhpbmsgd2Ugc2hvdWxkIHRha2UgYmVuZWZpdCBvZiB0aGlzIGFsaWdu bWVudCwgYW5kIGF2b2lkIGdlbmVyYXRpbmcgYSBuZXcgY29uY2VwdHMgc3VjaCBhcyBhIFNlcnZp Y2UgVGFnIG9yIFNlcnZpY2UgQ2xhc3MsIGxpbWl0ZWQgdG8gYSBwYXJ0aWN1bGFyIHVzZSBjYXNl Lg0KDQpUaGUgaGVhZGVyIGRlZmluZWQgaW4gZHJhZnQtZ3VpY2hhcmQtc2ZjLW5zaC1kYy1hbGxv Y2F0aW9uIGlzIHVzZWZ1bCBpbiBtYW55IHdheXMsIGJ1dCBoYXMgbWFueSBpbXBsaWNhdGlvbnMg aW4gaG93IHRoZSBwb2xpY2llcyBkZXBsb3llZCBpbiBhIERDIGFyZSBvcmdhbml6ZWQuICBJdCBp cyBtZW50aW9uZWQgZm9yIGV4YW1wbGUgdGhhdCBTZXJ2aWNlVGFnIGNhbiBiZSB1c2VkIGZvciBt dWx0aXBsZSBwdXJwb3NlcyBvcnRob2dvbmFsIG9uZSB0byB0aGUgb3RoZXJzLiBIb3cgd291bGQg YW4gU0ZGIGtub3cgdGhhdCB0aGUgc2VydmljZSBjbGFzcyBzaG91bGQgYmUgdXNlZCBmb3IgbG9h ZCBiYWxhbmNpbmcgcHVycG9zZXMgPw0KDQpXZSBoYXZlIHdpdGggdGhlIFJTUCBJRCBhIGNsZWFy IGNvbmNlcHQsIG1vcmUgcHJlY2lzZSB0aGFuIHRoZSBTUEkgZXZlbi4gV2Uga25vdyBjYW4gYmUg ZmlsbGVkIGJ5IHVwcGVyIGxldmVsIGVudGl0aWVzLCBhbmQgdGhhdCBzb21lIHVzZSBjYXNlcyBs aWtlIGVuYWJsaW5nIHJlbW90ZSBsb2FkIGJhbGFuY2luZyBjb3VsZCB0YWtlIGFkdmFudGFnZSBv ZiBpdC4gV2h5IG5vdCBtYWtlIGl0IGF2YWlsYWJsZSBjbGVhcmx5ID8NCg0KQmVzaWRlcyByZW1v dGUgbG9hZCBiYWxhbmNpbmcsIGFuIFJTUCBJRCBjYW4gYmUgdXNlZnVsIHdoZW4gYSBzZXJ2aWNl IGNoYWluIGlzIHNldHVwIGJldHdlZW4gdHdvIG9yZ2FuaXphdGlvbnMgKGVhY2ggd2l0aCBpdHMg T3JjaGVzdHJhdGlvbiBsYXllcikuIE5vIG5lZWQgdG8gcGFzcyBhZGRpdGlvbmFsIGluZm9ybWF0 aW9uICh0ZW5hbnQgSWQsIC4uLikgdG8gcmVjb3ZlciBhIGxvY2FsIGNvbnRleHQuDQoNCk5pY29s YXMNCg0KUmVtb3RlIExCUzogICBBbGxvdyBhIFNlcnZpY2UgIEZ1bmN0aW9uIG9yIHRoZSBDbGFz c2lmaWVyIHRvIGxvYWQgYmFsYW5jZSB0cmFmZmljIHdpdGhpbiBhIFNlcnZpY2UgQ2hhaW4gKHNh bWUgU1BJKSBieSBkaXN0cmlidXRpbmcgdGhlIHRyYWZmaWMgdG8gdmFyaW91cyBSZW5kZXJlZCBT ZXJ2aWNlIFBhdGggKFJTUCBJRCkgYmFzZWQgb24gaXRzIG93biBpbnRlcm5hbCBjcml0ZXJpYSwg c28gdGhhdCBhIHJlbW90ZSBTRkYgZW5kcyB1cCBmb3J3YXJkaW5nIHRoZSB0cmFmZmljIHRvIGNv cnJlc3BvbmRpbmcgU2VydmljZSBGdW5jdGlvbiBJbnN0YW5jZXMuDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBTdW1hbmRyYSBNYWplZSBbbWFpbHRvOlMuTWFqZWVARjUuY29t XQ0KU2VudDogbWVyY3JlZGkgNCBmw6l2cmllciAyMDE1IDAxOjU2DQpUbzogQ2F0aHkgWmhhbmc7 IE5pY29sYXMgQk9VVEhPUlM7ICdzZmNAaWV0Zi5vcmcnDQpDYzogSmVyb21lIFRPTExFVA0KU3Vi amVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdCAoaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQoNCkNhdGh5PiBSU1AgSUQgaXMgdXNl ZCBieSBTRkYgdG8gaWRlbnRpZnkgYSByZW5kZXJlZCBwYXRoIG9mIHNlcnZpY2UNCmluc3RhbmNl cy4gU28gRXZlbiBTRkYgaGF2ZSB0aGUgYmVzdCBrbm93bGVkZ2UgdG8gc2VsZWN0IHRoZSBTRngs DQpDYXRoeT4gYWZ0ZXIgdGhlIFNGRiBzZWxlY3RzIHRoZSBTRnggYW5kIGJpbmRzIGl0IHRvIHRo ZSBSU1AgSUQsDQpDYXRoeT4gZm9sbG93LW9uDQpwYWNrZXRzIGNhbiBqdXN0IGJlIGZvcndhcmRl ZCBiYXNlZCBvbiBSU1AgSUQuDQoNCg0KDQpTbyBSU1AgSVMgaXMgYSBzdGF0ZSB0aGF0IGlzIGxv Y2FsIHRvIFNGRih4KS4gTXkgcG9pbnQgaXMgdGhhdCBpbiB0aGF0IGNhc2UgdGhlcmUgaXMgbm8g cmVhc29uIHRvICpTSEFSRSogdGhlIHN0YXRlLiBJZiB5b3UgYXJlIGxvb2tpbmcgdG8gYmluZCBh bGwgcGt0cyBmb3IgZ2l2ZW4gZmxvdy9hcHAvdHJhbnNhY3Rpb24gZXRjLiB0aGVuIHBsZWFzZSBs b29rIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWd1aWNoYXJkLXNm Yy1uc2gtZGMtYWxsb2NhdGlvbiBhbmQgbW9yZSBzcGVjaWZpY2FsbHkgYXQgU2VydmljZVRhZyBw b3J0aW9uIG9mIGl0DQoNClRoaXMgaXMgYW4gZXhhbXBsZSBvbiBob3cgdG8gY2FydmUgb3V0IHRo ZSBzaGFyZWQgY29udGV4dCBhbmQgdGFnIGZsb3dzIGV0Yy4NCg0KSWYgYSBjb250cm9sbGVyIHdh bnRzIHRvIHByZXNlbGVjdCBhIHBhcnRpY3VsYXIgU0YoeCkgaW5zdGFuY2UgdGhlbiBpdCBjYW4g dXNlIE5TSCBzaGFyZWQgY29udGV4dCBpZiBuZWNlc3NhcnkuDQoNCk9uIDIvMi8xNSwgMjo0MiBQ TSwgIkNhdGh5IFpoYW5nIiA8Q2F0aHkuSC5aaGFuZ0BodWF3ZWkuY29tPiB3cm90ZToNCg0KPkhp IFN1bWFuZHJhLA0KPg0KPlRoYW5rIHlvdSBmb3IgeW91ciBjb21tZW50cy4gUGxlYXNlIHNlZSBp bmxpbmUuDQo+DQo+Q2F0aHkNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206 IFN1bWFuZHJhIE1hamVlIFttYWlsdG86Uy5NYWplZUBGNS5jb21dDQo+U2VudDogRnJpZGF5LCBK YW51YXJ5IDMwLCAyMDE1IDI6NTMgUE0NCj5UbzogTmljb2xhcyBCT1VUSE9SUzsgQ2F0aHkgWmhh bmc7ICdzZmNAaWV0Zi5vcmcnDQo+Q2M6IEplcm9tZSBUT0xMRVQNCj5TdWJqZWN0OiBSZTogW3Nm Y10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPg0KPkhlbGxvLA0KPg0KPlRoaXMgaXMgYW4gaW50ZXJl c3RpbmcgZGlzY3Vzc2lvbiBhbmQgSSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQgdGhlDQo+bW90 aXZhdGlvbiBvZiBiZXR0ZXIuIFRoZSB0cm91YmxlIHdpdGggYSBwcm90b2NvbCBkb2N1bWVudCBp cyB0aGF0IGl0DQo+aXMgdHlwaWNhbGx5IGhhcyBpbmFkZXF1YXRlIGRldGFpbCBhYm91dCB0aGUg bG9naWMuIFNvIHRvIGNhc3QgdGhpcw0KPmludG8gc29tZXdoYXQgb2YgYSBjb25jcmV0ZSB0ZXJt cywgY29uc2lkZXIgdGhlIGZvbGxvd2luZy4NCj4NCj4NCj4NCj4gICAgICAgU0ZGKHgpICB7IFNm eCgxKSBTZngoMinigKZTZngobikgfSAgIOKAlOKAlOKAlOKAlD4gICBTRkYoeSkgeyBTZnkoMSkg U2Z5KDIpDQo+4oCmLiBTZnkobSkgfSAgIDo6IExvZ2ljYWwgQ2hhaW4gaW4gT05FIGRpcmVjdGlv biBvbmx5Lg0KPg0KPiAgICAgICBQSFlTSUNBTCBXT1JMRDoNCj4gICAgICAgICAgQSkgdGhlIFNG RiBjb3VsZCBiZSBhDQo+ICAgICAgICAgICAgLSBjb21wb25lbnQgb2YgVlNXSVRDSCAocGljayB5 b3VyIGZhdiBwcm90b2NvbCBmb3INCj5jb25maWd1cmluZyB0aG9zZSBlbnRpdGllcyB9DQo+ICAg ICAgICAgICAgLSBBIGxvYWQgYmFsYW5jZXINCj4gICAgICAgICAgICAtIEEgSFcgc3dpdGNoL3Jv dXRlciBzb21lIEwyL0wzIGNvbWJvDQo+DQo+ICAgICAgICAgIEIpIFNmIGluc3RhbmNlIGNvdWxk IGJlLA0KPiAgICAgICAgICAgICAgIC0gVmlydHVhbCBtYWNoaW5lLCAjTiBvZiB0aG9zZQ0KPiAg ICAgICAgICAgICAgIC0gcGh5c2ljYWwNCj4gICAgICAgICAgICAgICAtIENvbnRhaW5lciAjTSB3 aGljaCBpcyBvZnRlbiA1IG9yIG1vcmUgeCAjTg0KPiAgICAgICAgICAgICAgIC0gQ2x1c3RlciB0 aGF0IHdlIGRvbuKAmXQga25vdw0KPg0KPkl0IGlzIHBvc3NpYmxlIHRvIGhhdmUgbXVsdGlwbGUg cGh5c2ljYWwgU0ZGKHgpIGFsc28uDQo+DQo+QSBzZWxlY3Rpb24gb2YgYSBnaXZlbiBTRiAoc2Vy dmljZSkoaW5zdGFuY2UpIGlzIGEgY2FuIGJlIHNpbXBsZSBvcg0KPmNvbXBsZXguIEZvciBleGFt cGxlIFNGRih4KSBtYXkgaGF2ZSB0aGUgYmVzdCBrbm93bGVkZ2UgdG8gc2VsZWN0DQo+U2Z4KDEp IGJhZWQgb24gYSBnaXZlbiBjcml0ZXJpb24gKHdoaWNoIGNvdWxkIGJlIHBhcnQgb2YgdGhlIHBv bGljeSkuDQo+VGhlbiBJIGRvbuKAmXQgc2VlIGEgcmVhc29uIHRvIGhhdmUgUlNQLg0KPg0KPkNh dGh5PiBSU1AgSUQgaXMgdXNlZCBieSBTRkYgdG8gaWRlbnRpZnkgYSByZW5kZXJlZCBwYXRoIG9m IHNlcnZpY2UNCj5pbnN0YW5jZXMuIFNvIEV2ZW4gU0ZGIGhhdmUgdGhlIGJlc3Qga25vd2xlZGdl IHRvIHNlbGVjdCB0aGUgU0Z4LA0KPkNhdGh5PiBhZnRlciB0aGUgU0ZGIHNlbGVjdHMgdGhlIFNG eCBhbmQgYmluZHMgaXQgdG8gdGhlIFJTUCBJRCwNCj5mb2xsb3ctb24gcGFja2V0cyBjYW4ganVz dCBiZSBmb3J3YXJkZWQgYmFzZWQgb24gUlNQIElELg0KPg0KPkl0IGlzIHBvc3NpYmxlIHRoYXQg bG9va3VwIChwYXRoKSBAIFNGRih4KSBwcm9kdWNlcyBhIHNwZWNpZmljIGluc3RhbmNlDQo+b2Yg U2Z5IGFuZCB5ZXMgdGhlbiBzb21ldGhpbmcgbGlrZSBSU1Agd291bGQgYmUgcmVxdWlyZWQuIEJ1 dCBJIHdvdWxkDQo+YXJndWUgdGhhdCBqb2IgU0ZGKHkpIGNhbiBhbHNvIGJlIHN1YnN1bWVkIGJ5 IFNGRih4KS4NCj4NCj5DYXRoeT4gSSBkbyBub3QgZ2V0IHdoYXQgeW91IG1lYW4gaGVyZS4gQ291 bGQgeW91IGNsYXJpZnk/DQo+DQo+SXMgaXQgcG9zc2libGUgZm9yIGEgY2VudHJhbCBjb250cm9s bGVyIHRvIHBpY2sgZWFjaCBpbnN0YW5jZSBvZg0KPnNlcnZpY2UsIGJ1dCBzdWNoIGFuIGltcGxl bWVudGF0aW9uIHRlbmRzIHRvIHNjYWxlIHBvb3JseS4gVGhlIGFtb3VudA0KPm9mIHN0YXRlLCBw cm9iYWJpbGl0eSBvZiBhIGluc3RhbmNlIGdvaW5nIGRvd24gYmV0d2VlbiBzZWxlY3Rpb24gYW5k DQo+ZmxvdyBhcnJpdmFsIGdvZXMgdXAuDQo+DQo+UmVnYXJkcy4NCj4NCj5TdW1hbmRyYQ0KPg0K Pg0KPg0KPk9uIDEvMzAvMTUsIDM6MzggQU0sICJOaWNvbGFzIEJPVVRIT1JTIiA8Tmljb2xhcy5C T1VUSE9SU0Bxb3Ntb3MuY29tPg0KPndyb3RlOg0KPg0KPj5IZWxsbyBDYXRoeSwNCj4+DQo+Pklu ZGVlZCB0aGUgbm90aW9uIG9mICJyZW5kZXJlZCBzZXJ2aWNlIHBhdGggSUQiKFJTUCBJRCkgc2Vl bXMgcmVsZXZhbnQNCj4+YXMgdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudCBzdGlwdWxhdGVzIHRo YXQgdGhlIFNlcnZpY2UgRnVuY3Rpb24gUGF0aA0KPj4oU0ZQKSBwcm92aWRlcyBhbiBhYnN0cmFj dCBub3Rpb24gb2YgYSBzZXJ2aWNlIGNoYWluLCB3aGlsZSB0aGUgUlNQIGlzDQo+PmEgY29uc3Ry YWluZWQgbGlzdCBvZiBsb2NhdGlvbnMuDQo+Pg0KPj5TRkMgaGVhZGVyICJTZXJ2aWNlIFBhdGgg SWRlbnRpZmllciIgKFNQSSkgIGlzIHVzZWQgaW4gYm90aCBOU0ggYW5kDQo+PlNDSCBwcm90b2Nv bCBhbmQgaW4gYm90aCBjYXNlIHNlZW0gdG8gaWRlbnRpZnkgdG8gYSBwYXJ0aWN1bGFyIFNGUC4N Cj4+DQo+Pk5TSCh2NSkgZm9yIGV4YW1wbGUgc3RhdGVzIHRoYXQNCj4+IiBBcyBkZXNjcmliZWQg YWJvdmUsIE5TSCBjb250YWlucyBhIHNlcnZpY2UgcGF0aCBpZGVudGlmaWVyIChTUEkpIGFuZA0K Pj4gICBhIHNlcnZpY2UgaW5kZXggKFNJKS4gIFRoZSBTUEkgaXMsIGFzIHBlciBpdHMgbmFtZSwg YW4gaWRlbnRpZmllci4NCj4+ICAgVGhlIFNQSSBhbG9uZSBjYW5ub3QgYmUgdXNlZCB0byBmb3J3 YXJkIHBhY2tldHMgYWxvbmcgYSBzZXJ2aWNlIHBhdGguDQo+PiAgIFJhdGhlciB0aGUgU1BJIHBy b3ZpZGUgYSBsZXZlbCBvZiBpbmRpcmVjdGlvbiBiZXR3ZWVuIHRoZSBzZXJ2aWNlDQo+PiAgIHBh dGgvdG9wb2xvZ3kgYW5kIHRoZSB0aGUgbmV0d29yayB0cmFuc3BvcnQuICBGdXJ0aGVybW9yZSwg dGhlcmUgaXMNCj4+ICAgbm8gcmVxdWlyZW1lbnQsIG9yIGV4cGVjdGF0aW9uIG9mIGFuIFNQSSBi ZWluZyBib3VuZCB0byBhIHByZS0NCj4+ICAgZGV0ZXJtaW5lZCBvciBzdGF0aWMgbmV0d29yayBw YXRoLiINCj4+DQo+PlN0aWxsIE5TSCh2NSkgIHNob3dzIHRoYXQgU1BJIChub3QgYSBSU1AgSUQp ICBzaG91bGQgYmUgcGFydCBvZiB0aGUNCj4+a2V5IGVsZW1lbnQgb2YgYW4gU0ZGIHRvIGxvb2t1 cCBvbiBmb3J3YXJkaW5nIHRhYmxlcy4gIEJ1dCBJIGNvdWxkIG5vdA0KPj5maW5kIGluIE5TSCAg aG93IHRvIHVzZSB0aGUgbm90aW9uIG9mIFJlbmRlcmVkIHNlcnZpY2UgcGF0aCB3aGljaCB3YXMN Cj4+ZGVmaW5lZCBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50Lg0KPj4NCj4+WW91IHByb3Bv c2FsIHNlZW1zIHRvIG1lIHZlcnkgdXNlZnVsLA0KPj4NCj4+QW4gUlNQIElEIChpbmRlcGVuZGVu dCBvZiB0aGUgU1BJIGJ1dCBwYXJ0IG9mIHRoZSBzYW1lIG5hbWUgc3BhY2UpDQo+PmNvdWxkIGJl IHVzZWQgdGhlIHNhbWUgd2F5IGFzIFNQSSBieSBTRkYgZm9yIGV4YW1wbGUsIGFsbG93aW5nIGEN Cj4+U2VydmljZSBDbGFzc2lmaWVyIHRvIGNvbnRyb2wgcmVtb3RlIGxvYWQgYmFsYW5jaW5nIGZv ciBleGFtcGxlLg0KPj4NCj4+VGhpcyBzYWlkIHRoZSBSU1AgSUQgdmFsdWVzIGNvdWxkIGJlIHJl bGF0aXZlIHRvIGEgcGFydGljdWxhciBTZXJ2aWNlDQo+PlBhdGgsIHdoaWNoIHdvdWxkIHJldmVu dCB1c2luZyB0aGVtIGFzIHdlIGRvIGZvciBTUEkgaW4gU0ZGIGZvcndhcmRpbmcNCj4+dGFibGVz Lg0KPj4NCj4+V2UgbWF5IHdhbnQgdG8gcHJlY2lzZSBpZiB0aGUgUlNQIElEIGlzIHRvIGJlIHJl bGF0aXZlIG9mIGFic29sdXRlLCBhcw0KPj5pdCBzaG91bGQgaGF2ZSBhbiBpbXBhY3Qgb24gZm9y d2FyZGluZyB0YWJsZSBzdHJ1Y3R1cmUgaWYgd2UgZGVjaWRlIHRvDQo+PnVzZSB0aGlzIGNvbmNl cHQuDQo+Pg0KPj5QZXJzb25hbGx5IEkgbGlrZSB0aGUgbm90aW9uIG9mIGEgcmVsYXRpdmUgUlNQ IElELCBhcyB3ZSBjb3VsZCB0aGVuDQo+PnVzZSBzb21lIGNvbnZlbnRpb25zLCBzdHJ1Y3R1cmUg aXQsIHBvc3NpYmx5IGV4dGVuZGluZyBpdHMgdXNlLg0KPj4NCj4+Tmljb2xhcw0KPj4NCj4+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogQ2F0aHkgWmhhbmcgW21haWx0bzpDYXRo eS5ILlpoYW5nQGh1YXdlaS5jb21dDQo+PlNlbnQ6IGpldWRpIDI5IGphbnZpZXIgMjAxNSAyMDo0 NA0KPj5UbzogQ2F0aHkgWmhhbmc7IFNyaW5pIEFkZGVwYWxsaTsgUmVpbmFsZG8gUGVubm8gKHJl cGVubm8pOyBKb2VsIE0uDQo+PkhhbHBlcm47ICdzZmNAaWV0Zi5vcmcnDQo+PkNjOiBuc211cnRo eUBmcmVlc2NhbGUuY29tDQo+PlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJh ZnQNCj4+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAy KQ0KPj4NCj4+SGkgZXZlcnlvbmUsDQo+Pg0KPj5XZSBoYXZlIHVwbG9hZGVkIGEgbmV3IFNDSCB2 ZXJzaW9uICgzKSB3aGljaCBhZGRzIGRlZmluaXRpb24gb2YgYSBuZXcNCj4+bWV0YWRhdGEgdHlw ZSBmb3IgdGhlIGZsb3cgSUQgdG8gc3VwcG9ydCBsb2FkIGJhbGFuY2luZyBhbW9uZyBTRg0KPj5p bnN0YW5jZXMgYW5kIG1pdGlnYXRlIHRoZSBwb3RlbnRpYWwgaXNzdWUgb2YgIm5vdCBlbm91Z2gg cGF0aCBJRCIuDQo+PlRoZSBmbG93IElEIGlzIG5hbWVkICJyZW5kZXJlZCBzZXJ2aWNlIHBhdGgg SUQiIGluIHRoZSBkcmFmdC4gUGxlYXNlDQo+PnJlZmVyIHRvIHNlY3Rpb24gNC4zLjIgb2YNCj4+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhhbmctc2ZjLXNjaC8NCj4+ Zm9yIGRldGFpbCBkZXNjcmlwdGlvbi4NCj4+DQo+PkluIGl0cyBwcmV2aW91cyB2ZXJzaW9uLCBT Q0ggZGVmaW5lcyBhICJCeXBhc3MgYml0IiBpbiB0aGUgYmFzZSBoZWFkZXIuDQo+PlRoaXMgYml0 IGVuYWJsZXMgdGhlIFNGIHRvIHByb3ZpZGUgZmVlZGJhY2svbm90aWZpY2F0aW9uIHZpYSB0aGUg ZGF0YQ0KPj5wYXRoIHRvIGl0cyBjb25uZWN0aW5nIFNGRiBhYm91dCB3aGV0aGVyIHRoZSByZW1h aW5pbmcgcGFja2V0cyBvZiB0aGUNCj4+U0ZDIHNob3VsZCBieXBhc3MgdGhhdCBTRi4gVGhpcyBp cyB1c2VmdWwgaW4gdGhlIGNhc2UgdGhhdCBvbmx5IHRoZQ0KPj5maXJzdCBmZXcgcGFja2V0cyBv ZiBhIGZsb3cgbmVlZCB0byBnbyB0byBhIFNGIChzdWNoIGFzIGEgRFBJIG9yIEZXIG9yDQo+PklE UykgYW5kIHJlbWFpbmluZyBwYWNrZXRzIGNhbiBieXBhc3MgdGhhdCBTRiwgdGh1cyBzYXZpbmcg dGhlDQo+PmV4cGVuc2l2ZSBTRiByZXNvdXJjZSBhbmQgcmVkdWNpbmcgZGF0YSBwYXRoIGxhdGVu Y3kuDQo+Pg0KPj5CIGJpdDogVGhlIEIgKEJ5cGFzcykgYml0LCB3aGVuIHNldCB0byAxLCBpdCBp cyB1c2VkIGJ5IGEgU2VydmljZQ0KPj4gICAgICAgRnVuY3Rpb24gdG8gc2lnbmFsIHRvIGl0cyBT ZXJ2aWNlIEZ1bmN0aW9uIEZvcndhcmRlciB0aGF0IG5vDQo+PiAgICAgICBmdXJ0aGVyIHBhY2tl dHMgYXJlIHRvIGJlIHNlbnQgdG8gaXQgZm9yIHRoZSBmbG93IHNwZWNpZmllZCBpbg0KPj5lbmNh cHN1bGF0ZWQgcGFja2V0Lg0KPj4NCj4+SW4gYWRkaXRpb24sIFNDSCBkZWZpbmVzIGEgbWV0YWRh dGEgdHlwZSBmb3IgR2VuZXJpYyBDb250ZXh0IEJsb2NrLA0KPj53aGljaCBpcyBvcHRpb25hbCBh bmQgY2FuIGJlIHVzZWQgaWYgbmVlZGVkIHRvIGNhcnJ5IGFueSB2ZW5kb3Incw0KPj5zcGVjaWZp YyAiQ29udGV4dCBIZWFkZXIiLg0KPj4NCj4+QW55IGNvbW1lbnRzIG9uIHRoZXNlIG5ldyBhZGRp dGlvbnM/DQo+Pg0KPj5UaGFua3MsDQo+PkNhdGh5DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj5Gcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIENhdGh5IFpoYW5nDQo+PlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDUsIDIwMTQgMTE6 NDcgQU0NCj4+VG86IFNyaW5pIEFkZGVwYWxsaTsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBK b2VsIE0uIEhhbHBlcm47DQo+PidzZmNAaWV0Zi5vcmcnDQo+PkNjOiBuc211cnRoeUBmcmVlc2Nh bGUuY29tDQo+PlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4+KGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4NCj4+ Um9uLCBMb3VpcywgTXlvIGFuZCBJIGhhdmUgYmVlbiBkaXNjdXNzaW5nIG9mZiBsaW5lIGxhc3Qg ZmV3IHdlZWtzDQo+PmFib3V0IGRlZmluaW5nIGEgbWV0YWRhdGEgdHlwZSBmb3IgZmxvdyBJRCBp biBhZGRpdGlvbiB0byB0aGUgcGF0aCBJRA0KPj5vZiB0aGUgbWFpbiBoZWFkZXIgdG8gc3VwcG9y dCBsb2FkIGJhbGFuY2luZyBhbW9uZyBTRiBpbnN0YW5jZXMuIFdlDQo+PndpbGwgZGVmaW5lIGEg VExWIHR5cGUgZm9yIHRoZSBmbG93IElELiBUaGUgY29tYmluYXRpb24gb2YgInBhdGggSUQgKyBm bG93IElEIg0KPj5zcGVjaWZpZXMgYSByZWFsaXplZCBzZXJ2aWNlIGNoYWluIGluc3RhbmNlIHBh dGguIEl0IGlzIGxlZnQgdG8gdGhlDQo+PmRlc2lnbi9pbXBsZW1lbnRhdGlvbiB3aGV0aGVyIHRv IHVzZSBhIGNlbnRyYWxpemVkIG1ldGhvZCBvciBhDQo+PmRpc3RyaWJ1dGVkIG1ldGhvZCB0byBi aW5kIHRoZSBmbG93IElEIHRvIGEgcmVhbGl6ZWQgc2VydmljZSBpbnN0YW5jZQ0KPj5wYXRoIGFs dGhvdWdoIG91ciBvcmlnaW5hbCB0aG91Z2h0IGlzIGZvciBkaXN0cmlidXRlZCBMQiB1c2FnZS4g SSBhbQ0KPj5ub3Qgc3VyZSBpZiB3ZSBuZWVkIGEgYml0IGluIHRoZSBoZWFkZXIgdG8gZGVub3Rl IHdoZXRoZXIgdGhlcmUgYXJlDQo+Pm1vcmUgcGF0aCBJRCBiaXRzICh3ZSBjYWxsIGl0IGZsb3cg SUQpIGluIHRoZSBtZXRhZGF0YSBmaWVsZHMgc2luY2UNCj4+d2hlbiB5b3UgcGFyc2UgdGhlIFRM ViBtZXRhZGF0YSwgeW91IHdpbGwga25vdyB3aGV0aGVyIHRoZXJlIGFyZSBmbG93IElEIGJpdHMg b3Igbm90Lg0KPj5Ob3RlIHRoYXQgaWYgbXVsdGlwbGUgc2Vzc2lvbnMgc2hhcmUgdGhlIHNhbWUg cmVhbGl6ZWQgc2VydmljZQ0KPj5pbnN0YW5jZSBwYXRoLCB0aGV5IHdpbGwgc2hhcmUgdGhlIHNh bWUgInBhdGggSUQrIGZsb3cgSUQiLiAgV2UgY2FuDQo+PmFsc28gY29uc2lkZXIgZXh0ZW5kaW5n IHRoZSBudW1iZXIgb2YgYml0cyB0byAzMiBpZiB0aGF0IGlzIHRoZQ0KPj5jb25zZW5zdXMuIFdl IHdpbGwgcG9zdCBhbiB1cGRhdGVkIGRyYWZ0IGRlc2NyaWJpbmcgdGhlc2Ugc29vbi4NCj4+DQo+ PlRoYW5rcywNCj4+Q2F0aHkNCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZy b206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3Jpbmkg QWRkZXBhbGxpDQo+PlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDUsIDIwMTQgNzoxNyBBTQ0KPj5U bzogUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBKb2VsIE0uIEhhbHBlcm47ICdzZmNAaWV0Zi5v cmcnDQo+PkNjOiBuc211cnRoeUBmcmVlc2NhbGUuY29tDQo+PlN1YmplY3Q6IFJlOiBbc2ZjXSBD b21tZW50cyBvbiBTQ0ggRHJhZnQNCj4+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4NCj4+DQo+PltSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5 Lg0KPj4NCj4+U1JJTkk+IEkgYW0gbm90IHNvIHN1cmUgYWJvdXQgZGF0YSBwbGFuZSBlZmZpY2ll bmN5LiAgTW9zdCBvZiB0aGUNCj4+cHJvY2Vzc29ycyB3b3JrIGdvb2QgaWYgdGhlIG51bWJlciBv ZiBiaXRzIGFyZSBlaXRoZXIgMzIgb3IgNjQuICBJZiBpdA0KPj5pcw0KPj4yNCBiaXRzLCB0aGVu IG9uZSBuZWVkcyB0byBkbyBtYXNraW5nIGFuZCBzaGlmdGluZyBiZWZvcmUgdGhlIHZhbHVlIGlz DQo+PnVzZWQgdG8gZG8gYW55IGxvb2t1cC4gICBCdXQsIHRoaXMgZGlzY3Vzc2lvbiBjYW4gZ28g aW50byBkaWZmZXJlbnQNCj4+ZGlyZWN0aW9uIDotKSwgaXQgbWF5IG5vdCBiZSBnb29kIHRvIGdv IGluIHRoYXQgZGlyZWN0aW9uLg0KPj4NCj4+V2hlcmUgZG8gd2UgZHJhdyB0aGUgbGluZT8gMzIt Yml0cywgNjQtYml0cywNCj4+MTI4IGJpdHM/IEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgYSBzZW5z aWJsZSB2YWx1ZSBpbiB0aGUgU2VydmljZSBQYXRoDQo+PmhlYWRlciBhbmQgaWYgeW91IG5lZWQg dG8gY29udmV5IG1vcmUgYml0cyB5b3UgbmVlZCB0byB1c2UgdGhlIGNvbnRleHQNCj4+aGVhZGVy cy4NCj4+DQo+PlNSSU5JPiBUaGlzIGlzIGEgZ29vZCBwb2ludC4gIFRoaXMgc2hvdWxkIHdvcmsg ZmluZSBhcyBsb25nIGFzIHRoZXJlDQo+PlNSSU5JPiBpcw0KPj53YXkgdG8gY29udmV5IGluIHRo ZSBtYWluIGhlYWRlciB0aGF0IHRoZSBleHRlbnNpb24gdG8gcGF0aCBJRCBpcw0KPj5hdmFpbGFi bGUgaW4gc28gYW5kIHNvIFRMViBmaWVsZC4gIFRoYXQgc2hvdWxkIHdvcmsgdG9vLg0KPj4NCj4+ VGhhbmtzDQo+PlNyaW5pDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PkZyb206IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKSA8cmVwZW5ub0BjaXNjby5j b20+DQo+PlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgNSwgMjAxNCA3OjA4IEFNDQo+PlRvOiBBZGRl cGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47ICdzZmNAaWV0Zi5vcmcnDQo+PkNj OiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVu dHMgb24gU0NIIERyYWZ0DQo+PihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhh bmctc2ZjLXNjaC0wMikNCj4+DQo+Pk9uIDEyLzUvMTQsIDY6NTQgQU0sICJTcmluaSBBZGRlcGFs bGkiIDxzYWRkZXBhbGxpQGZyZWVzY2FsZS5jb20+IHdyb3RlOg0KPj4NCj4+Pg0KPj4+SW4gcmVh bCBkZXBsb3ltZW50cywgbnVtYmVyIG9mIGFjdGl2ZSBwYXRoIElEcyBhcmUgdmVyeSBsZXNzZXIg dGhhbg0KPj4+Ml42NCwgYnV0IHRoZXJlIGlzIGEgZ29vZCBwb3NzaWJpbGl0eSBvZiB0aGUgbnVt YmVyIGJlaW5nIG1vcmUgdGhhbg0KPj4+Ml4yNCAoMTZNKS4NCj4+PiBJIHRoaW5rIGJpZ2dlciBw b2ludCBpcyB0aGF0IHdoeSByZXN0cmljdCB0aGlzIGluIHRoZSBzdGFuZGFyZHM/DQo+Pj5XaGF0 IGFkdmFudGFnZSBkbyB3ZSBoYXZlIHJlc3RyaWN0aW5nIHRoaXMgc2l6ZSB0byAyNCBiaXRzPw0K Pj4NCj4+W1JQXSBEYXRhIHBsYW5lIGVmZmljaWVuY3kuIFdoZXJlIGRvIHdlIGRyYXcgdGhlIGxp bmU/IDMyLWJpdHMsDQo+PjY0LWJpdHMsDQo+PjEyOCBiaXRzPyBJIHRoaW5rIHdlIHNob3VsZCBo YXZlIGEgc2Vuc2libGUgdmFsdWUgaW4gdGhlIFNlcnZpY2UgUGF0aA0KPj5oZWFkZXIgYW5kIGlm IHlvdSBuZWVkIHRvIGNvbnZleSBtb3JlIGJpdHMgeW91IG5lZWQgdG8gdXNlIHRoZSBjb250ZXh0 DQo+PmhlYWRlcnMuDQo+Pg0KPj4NCj4+Pg0KPj4+VGhlcmUgY2FuIGJlIGRlcGxveW1lbnRzLCB3 aGVyZSBTRkMgY29udHJvbGxlciAoTG9naWNhbGx5IGNlbnRyYWwsDQo+Pj5idXQNCj4+PmRpc3Ry aWJ1dGVkKSAgaXRzZWxmIGNhbiBkbyB0aGUgU0YgaW5zdGFuY2Ugc2VsZWN0aW9uIG9uIHBlcg0K Pj4+Y29ubmVjdGlvbi9zZXNzaW9uIGJhc2lzLCB0aGVyZWJ5IGF2b2lkaW5nIHRoZSBMQnMgZm9y IHNlcnZpY2VzLiAgIEluIG15DQo+Pj52aWV3LCBhc3N1bXB0aW9uIHRoYXQgdGhlcmUgd2lsbCBi ZSBMQiBTRiBmb3IgZWFjaCBzY2FsZS1vdXQgc2VydmljZQ0KPj4+aW4gdGhlIGNoYWluIGlzIG5v dCB2YWxpZCBpbiBhbGwgY2FzZXMuDQo+Pj4NCj4+PlRoYW5rcw0KPj4+U3JpbmkNCj4+Pg0KPj4+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+RnJvbTogUmVpbmFs ZG8gUGVubm8gKHJlcGVubm8pIDxyZXBlbm5vQGNpc2NvLmNvbT4NCj4+PlNlbnQ6IFRodXJzZGF5 LCBEZWNlbWJlciA0LCAyMDE0IDE6MTcgUE0NCj4+PlRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYw OyBKb2VsIE0uIEhhbHBlcm47IHNmY0BpZXRmLm9yZw0KPj4+Q2M6IE5TIFNyaW5pdmFzYSBNdXJ0 aHktQjM3ODQwDQo+Pj5TdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+ Pj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+ Pj4NCj4+PklmIEkgdW5kZXJzdG9vZCB5b3UsIEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgcmVhbGlz dGljLiBBcmUgeW91IHNheWluZw0KPj4+eW91IG5lZWQgNjQtYml0cyBvZiBwYXRocyBhbmQgdGhl biB3aWxsIG1vbml0b3IgdGhlbSBhbGw/IERvIGZhdWx0DQo+Pj50b2xlcmFuY2UgYW5kIE9BTSBm b3IgMl42NC1iaXRzIHdvcnRoIG9mIHBhdGhzPyBKdXN0IGZvciBjb21wYXJpc29uLA0KPj4+aXTC uXMgbGlrZSBtYW5hZ2luZyBhbmQgbW9uaXRvcmluZyB0aGUgZW50aXJlIElQdjYgaG9zdCByYW5n ZSwNCj4+Pm9uZS1ieS1vbmUuDQo+Pj4NCj4+PkFueXdheSwgSSBkbyBub3QgZXhwZWN0IGV2ZXJ5 IHNpbmdsZSBwZXJtdXRhdGlvbnMgdG8gYmUgYSBkaWZmZXJlbnQNCj4+PnBhdGguDQo+Pj4NCj4+ PklmIGVhY2ggc2VydmljZSBoYXMgMjU2IGRldmljZXMgcHJvdmlkaW5nIHNpbWlsYXIgc2Vydmlj ZSwgeW91IHNob3VsZA0KPj4+bW9zdCBsaWtlbHkgdXNlIGxvYWQtYmFsYW5jaW5nIGFuZCB0aGVu IHlvdSB3b3VsZCBoYXZlIGEgc2luZ2xlIChvciBhDQo+Pj5mZXcpIHBhdGhzLiBUaGVyZSBpcyBz b21lIGRpc2N1c3Npb24gZ29pbmcgb24gTEIuDQo+Pj4NCj4+PkZyb20gYSBkYXRhIHBsYW5lIHBl cnNwZWN0aXZlLCB0aGUgcGF0aCBpcyB1bHRpbWF0ZWx5IGRlZmluZWQgYnkgdGhlDQo+Pj5TRkZz IHRyYXZlcnNlZCBhbmQgc2VydmljZXMgcHJvdmlkZWQsIG5vdCBieSBhIHNwZWNpZmljIElQOnBv cnQgdGhhdA0KPj4+dGhlIGRldmljZSBwcm92aWRpbmcgdGhlIHNlcnZpY2Ugc2l0cyBvbi4gV2Vs bCwgYXQgbGVhc3QgZnJvbSBhDQo+Pj5HUEUrTlNIIHBlcnNwZWN0aXZlLg0KPj4+DQo+Pj4NCj4+ Pk9uIDEyLzQvMTQsIDEyOjU3IFBNLCAiU3JpbmkgQWRkZXBhbGxpIiA8c2FkZGVwYWxsaUBmcmVl c2NhbGUuY29tPg0KPj4+d3JvdGU6DQo+Pj4NCj4+Pj5JZiBJIHRha2UgYSBjaGFpbiB3aXRoIDUg c2VydmljZXMgd2l0aCBlYWNoIHNlcnZpY2UgIHNheSBoYXZpbmcgMjU2DQo+Pj4+aW5zdGFuY2Vz IGZvciBzY2FsZS1vdXQsIHBvc3NpYmxlIG51bWJlciBvZiBwYXRocyBhcmUNCj4+Pj4yNTYqMjU2 KjI1NioyNTYqMjU2ID0gMHhGRiBGRiBGRiBGRiBGRi4gT25lIHJlcXVpcmVzIDMzIGJpdHMgaW4g dGhpcw0KPj4+PmNhc2UuICBJZiB0aGVyZSBhcmUgbW9yZSBzZXJ2aWNlcyBpbiB0aGUgY2hhaW4g b3IgbW9yZSBjaGFpbnMgb3INCj4+Pj5tb3JlIGluc3RhbmNlcyBmb3Igc2NhbGUtb3V0LCB0aGVu IGl0IGNvdWxkIGdvIHRvIGJpZyBudW1iZXIgdmVyeSBmYXN0Lg0KPj4+Pg0KPj4+PkFzIEkgbWVu dGlvbmVkIG15IHByZWZlcmVuY2UgaXMgdG8gbWFrZSB0aGUgcGF0aCBJRCBzaXplIGZsZXhpYmxl DQo+Pj4+Zm9yIGZ1dHVyZSBncm93dGguIElmIHRoYXQgaXMgcGVyY2VpdmVkIGFzIGNvbXBsZXgs IHRoZW4gZ29pbmcgZm9yDQo+Pj4+NjRiaXQgaXMgc2FmZXIgYmV0Lg0KPj4+Pg0KPj4+PlRoYW5r cw0KPj4+PlNyaW5pDQo+Pj4+DQo+Pj4+DQo+Pj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+Pj5Gcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0K Pj4+PlNlbnQ6IFRodXJzZGF5LCBEZWNlbWJlciAwNCwgMjAxNCAxMjowNSBQTQ0KPj4+PlRvOiBB ZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBKb2VsIE0uIEhhbHBlcm47IHNmY0BpZXRmLm9yZw0KPj4+ PkNjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPj4+PlN1YmplY3Q6IFJlOiBbc2ZjXSBD b21tZW50cyBvbiBTQ0ggRHJhZnQNCj4+Pj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+Pj4+DQo+Pj4+QSBjb250cm9sbGVyIChvciBvdGhlciBk ZWNpc2lvbiBsb2dpYykgY2FuIGNlcnRhaW5seSBiZSBhd2FyZSBvZg0KPj4+PnN1Y2ggY29uY2Vy bnMuDQo+Pj4+QnV0IHRoZSBudW1iZXIgb2Ygc2VydmljZSBmdW5jdGlvbiBwYXRocyBpcyBub3Qg cmVsYXRlZCB0byB0aGUNCj4+Pj5udW1iZXIgb2YgZmxvd3Mgb3IgdGhlIG51bWJlciBvZiB0ZW5h bnRzLiAgSXQgaXMgcmVsYXRlZCB0byB0aGUNCj4+Pj5udW1iZXIgb2YgY29tYmluYXRpb25zIG9m IHNlcnZpY2VzIGFuZCB0aGUgcG9saWNpZXMgZm9yIHNlcnZpY2UNCj4+Pj5mdW5jdGlvbiBzZWxl Y3Rpb24uDQo+Pj4+IFdoaWxlIHRoYXQgY2FuIGJlIGEgbGFyZ2UgbnVtYmVyLCBJIHN1cmUgaG9w ZSBpdCBkb2VzIG5vdCBjb21lDQo+Pj4+Y2xvc2UgdG8gc2F0dXJhdGluZyAyNCBiaXRzLg0KPj4+ Pg0KPj4+PkhhdmluZyBzYWlkIHRoYXQsIGlmIHdlIHRoaW5rIHRoYXQgMjQgYml0cyBpcyBvbmx5 IGp1c3QgZW5vdWdoLCB0aGVuDQo+Pj4+d2Ugb3VnaHQgdG8gdXNlIDMyLiAgRnJvbSB3aGVyZSBJ IHNpdCwgSSB3b3VsZCBub3JtYWxseSBleHBlY3QgMTYNCj4+Pj5iaXRzIHRvIGJlIG1vcmUgdGhh biBzdWZmaWNpZW50LCB3aGljaCBpcyB3aHkgSSBhbSBjb21mb3J0YWJsZSB3aXRoIDI0Lg0KPj4+ PkhhdmluZyBzYWlkIHRoYXQsIHRoZSBmaWVsZCBzaXplIGlzIG5vdCBhIGJpZyBkZWFsIHRvIG1l Lg0KPj4+Pg0KPj4+PllvdXJzLA0KPj4+PkpvZWwNCj4+Pj4NCj4+Pj5PbiAxMi80LzE0LCAyOjAx IFBNLCBTcmluaSBBZGRlcGFsbGkgd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4gSSB3YXMgbm90IGltcGx5 aW5nIHRoYXQgcGF0aCBJRCBzaG91bGQgaGF2ZSBpbmZvcm1hdGlvbiBpbiByZWdhcmRzDQo+Pj4+ PnRvIHRlbmFudC9jb250cm9sbGVyL2Zsb3cvc2NhbGUtb3V0LiAgQnV0IFNGQyBjb250cm9sbGVy cyBzaG91bGQNCj4+Pj4+a2VlcCB0aGVzZQ0KPj4+Pj5pbiBtaW5kIHRvIGFzc2lnbiB0aGUgcGF0 aCBJRC4gICAgQSBkZXBsb3ltZW50IGNhbiBoYXZlIG11bHRpcGxlDQo+Pj4+PnRlbmFudHMsIGVh Y2ggdGVuYW50IGNhbiBoYXZlIG11bHRpcGxlIG5ldHdvcmtzLCAgdGhlcmUgY291bGQgYmUNCj4+ Pj4+bWlsbGlvbnMgb2YgZmxvd3MgaW4gZWFjaCBvZiB0aG9zZSBuZXR3b3Jrcy4gIEFuZCBjb25z aWRlcmluZyBhbGwNCj4+Pj4+dGhlc2UsDQo+Pj4+PiAyNCBiaXQgcGF0aCBJRCBtYXkgbm90IGJl IGFibGUgdG8gcmVwcmVzZW50IHBhdGhzIGZvciB0aGVzZSBmbG93cy4NCj4+Pj4+SGVuY2UsIEkg d2FzIHdvbmRlcmluZyB3aGV0aGVyIHBhdGggSUQgY2FuIGJlIGV4dGVuZGVkIHRvIDY0IGJpdHMN Cj4+Pj4+b3IgbWFrZSBpdCBmbGV4aWJsZS4NCj4+Pj4+DQo+Pj4+PiBUaGFua3MNCj4+Pj4+IFNy aW5pDQo+Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPg0KPj4+ Pj4gU2VudDogVGh1cnNkYXksIERlY2VtYmVyIDQsIDIwMTQgNzo0MiBBTQ0KPj4+Pj4gVG86IEFk ZGVwYWxsaSBTcmluaS1CMjIxNjA7IHNmY0BpZXRmLm9yZw0KPj4+Pj4gQ2M6IE5TIFNyaW5pdmFz YSBNdXJ0aHktQjM3ODQwDQo+Pj4+PiBTdWJqZWN0OiBSZTogW3NmY10gQ29tbWVudHMgb24gU0NI IERyYWZ0DQo+Pj4+PiAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNm Yy1zY2gtMDIpDQo+Pj4+Pg0KPj4+Pj4gVGhlIEluZGV4IGlzIG5vdCBqdXN0IGZvciBsb29wIHBy ZXZlbnRpb24uICBJbiB0aGUgY2FzZSBvZg0KPj4+Pj5hbWJpZ3VpdHksIHRoZSBpbmRleCB0ZWxs cyB0aGUgU0ZGIHdoZXJlIGluIHRoZSBwYXRoIHRoZSBwYWNrZXQNCj4+Pj4+Y3VycmVudGx5IHJl c2lkZXMuDQo+Pj4+PiAgICBUaGVyZSBhcmUgbXVsdGlwbGUgd2F5cyBzdWNoIGFtYmlndWl0eSBj YW4gb2NjdXIuDQo+Pj4+Pg0KPj4+Pj4gVGhlIFBhdGggSWRlbnRpZmllciBpcyBzcGVjaWZpY2Fs bHkgbm90IGV4cGVjdGVkIHRvIGluY2x1ZGUNCj4+Pj4+IGNvbnRyb2xsZXIgSUQgb3IgVGVuYW50 IElELiAgV2hpbGUgYSBkZXBsb3llciBjYW4gaGF2ZSBhIHBhdGggcGVyDQo+Pj4+PiB0ZW5hbnQs IHRoZSBhcmNoaXRlY3R1cmUgc3RpbGwgZG9lcyBub3QgdHJlYXQgdGhlIHBhdGggSUQgYXMgYQ0K Pj4+Pj4gdGVuYW50IElELiAgVGVuYW50IElELCBjb250cm9sbGVyIElELCBhbmQgb3RoZXINCj4+ Pj4+IG5vbi1wYXRoLXNwZWNpZnlpbmcgaW5mb3JtYXRpb24gaXMgdG8gYmUgY2FycmllZCBpbiBt ZXRhZGF0YS4NCj4+Pj4+DQo+Pj4+PiBZb3VycywNCj4+Pj4+IEpvZWwNCj4+Pj4+DQo+Pj4+PiBP biAxMi80LzE0LCAxMDowMiBBTSwgU3JpbmkgQWRkZXBhbGxpIHdyb3RlOg0KPj4+Pj4+IFR3byBj b21tZW50cyA6DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IDEuICBTRiBJbmRleCA6ICBTaW5jZSBp dCBpcyBtZWFudCBmb3IgbG9vcCBkZXRlY3Rpb24sICB3b3VsZG4ndA0KPj4+Pj4+IGJldHRlciB0 byByZW5hbWUgdGhpcyBhcyAiVFRMIj8NCj4+Pj4+Pg0KPj4+Pj4+IDIuICBQYXRoIElkZW50aWZp ZXIgOiAgICAyNCBiaXQgcGF0aCBpZGVudGlmaWVyIHNlZW1zIHRvIGJlIHRvbw0KPj4+Pj4+bGVz cy4NCj4+Pj4+PiBCYXNlZCBvbiBvdXIgZXhwZXJpZW5jZSBpbiB0cmFmZmljIHN0ZWVyaW5nLCAg dGhpcyBwYXRoDQo+Pj4+Pj5pZGVudGlmaWVyIG5lZWRzIHRvIGVuY29kZSBnb29kIGFtb3VudCBv ZiBpbmZvcm1hdGlvbiB0byBtYWtlIGl0DQo+Pj4+Pj51bmlxdWUuICBGb3IgZXhhbXBsZSwNCj4+ Pj4+PiAgICB0aGlzIGlkZW50aWZpZXIgbmVlZHMgdG8gZW5jb2RlIChpbiBvdXIgY2FzZSkgc29t ZSBpbmZvcm1hdGlvbg0KPj4+Pj4+cmVwcmVzZW50aW5nIHRoZSBkaXN0cmlidXRlZCBjb250cm9s bGVyIElELCAgdGVuYW50IElELCAgZmxvdyBJRCwNCj4+Pj4+PiAgICBTZXJ2aWNlIGZ1bmN0aW9u IGluc3RhbmNlIChpbiBjYXNlIG9mIHNjYWxlLW91dCkgYW5kIGZldyBtb3JlLi4NCj4+Pj4+PiBP bmUgc3VnZ2VzdGlvbiBpcyB0byBtYWtlIGl0IDY0IGJpdHMgdmFsdWUgIG9yIHRvIG1ha2UgaXQg ZXZlbg0KPj4+Pj4+ZXh0ZW5kYWJsZSwNCj4+Pj4+PiAgICBpdCBpcyBnb29kIGlmIHBhdGggaWRl bnRpZmllciBpcyBhbHNvIHJlcHJlc2VudGVkIGluIFRMViBmb3JtLg0KPj4+Pj4+DQo+Pj4+Pj4N Cj4+Pj4+PiBUaGFua3MNCj4+Pj4+Pg0KPj4+Pj4+IFNyaW5pDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBzZmNAaWV0Zi5vcmcN Cj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+Pj4+ DQo+Pj4+DQo+Pj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj5zZmMgbWFpbGluZyBsaXN0DQo+Pj4+c2ZjQGlldGYub3JnDQo+Pj4+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pg0KPj4NCj4+DQo+Pl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PnNmYyBtYWlsaW5nIGxp c3QNCj4+c2ZjQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj5zZmMgbWFpbGluZyBsaXN0DQo+PnNmY0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCj4+DQo+PlRoaXMgbWVzc2FnZSBhbmQg YW55IGF0dGFjaG1lbnRzICh0aGUgIm1lc3NhZ2UiKSBhcmUgY29uZmlkZW50aWFsLA0KPj5pbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNzZWVzLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQNCj4+cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkg ZS1tYWlsIGFuZCBkZWxldGUNCj4+dGhpcyBtZXNzYWdlIGZyb20geW91ciBzeXN0ZW0uIEluIHRo aXMgY2FzZSwgeW91IGFyZSBub3QgYXV0aG9yaXplZCB0bw0KPj51c2UsIGNvcHkgdGhpcyBtZXNz YWdlIGFuZC9vciBkaXNjbG9zZSB0aGUgY29udGVudCB0byBhbnkgb3RoZXIgcGVyc29uLg0KPj5F LW1haWxzIGFyZSBzdXNjZXB0aWJsZSB0byBhbHRlcmF0aW9uLiBOZWl0aGVyIFFvc21vcyBub3Ig YW55IG9mIGl0cw0KPj5zdWJzaWRpYXJpZXMgb3IgYWZmaWxpYXRlcyBzaGFsbCBiZSBsaWFibGUg Zm9yIHRoZSBtZXNzYWdlIGlmIGFsdGVyZWQsDQo+PmNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPj4N Cj4+Q2UgbWVzc2FnZSBldCB0b3V0ZXMgc2VzIHBpw6hjZXMgam9pbnRlcyAoY2ktYXByw6hzIGxl ICJtZXNzYWdlIilzb250DQo+PmNvbmZpZGVudGllbHMgZXQgw6l0YWJsaXMgw6AgbCdpbnRlbnRp b24gZXhjbHVzaXZlIGRlIHNlcyBkZXN0aW5hdGFpcmVzLg0KPj5TaSB2b3VzIGF2ZXogcmXDp3Ug Y2UgbWVzc2FnZSBwYXIgZXJyZXVyLCBtZXJjaSBk4oCZZW4gaW5mb3JtZXINCj4+aW1tw6lkaWF0 ZW1lbnQgc29uIMOpbWV0dGV1ciBwYXIgY291cnJpZXIgw6lsZWN0cm9uaXF1ZSBldCBk4oCZZWZm YWNlciBjZQ0KPj5tZXNzYWdlIGRlIHZvdHJlIHN5c3TDqG1lLiBEYW5zIGNldHRlIGh5cG90aMOo c2UsIHZvdXMgbuKAmcOqdGVzIHBhcw0KPj5hdXRvcmlzw6kgw6AgdXRpbGlzZXIsIGNvcGllciBj ZSBtZXNzYWdlIGV0L291IGVuIGRpdnVsZ3VlciBsZSBjb250ZW51IMOgDQo+PnVuIHRpZXJzLiBU b3V0IG1lc3NhZ2Ugw6lsZWN0cm9uaXF1ZSBlc3Qgc3VzY2VwdGlibGUgZCdhbHTDqXJhdGlvbi4N Cj4+UW9zbW9zIGV0IHNlcyBmaWxpYWxlcyBkw6ljbGluZW50IHRvdXRlIHJlc3BvbnNhYmlsaXTD qSBhdSB0aXRyZSBkZSBjZQ0KPj5tZXNzYWdlIHMnaWwgYSDDqXTDqSBhbHTDqXLDqSwgZMOpZm9y bcOpIG91IGZhbHNpZmnDqS4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+c2ZjIG1haWxpbmcgbGlzdA0KPj5zZmNAaWV0Zi5vcmcNCj4+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4NCg0KVGhpcyBtZXNzYWdlIGFu ZCBhbnkgYXR0YWNobWVudHMgKHRoZSAibWVzc2FnZSIpIGFyZSBjb25maWRlbnRpYWwsIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZXMuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1h aWwgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgZnJvbSB5b3VyIHN5c3RlbS4gSW4gdGhpcyBjYXNl LCB5b3UgYXJlIG5vdCBhdXRob3JpemVkIHRvIHVzZSwgY29weSB0aGlzIG1lc3NhZ2UgYW5kL29y IGRpc2Nsb3NlIHRoZSBjb250ZW50IHRvIGFueSBvdGhlciBwZXJzb24uIEUtbWFpbHMgYXJlIHN1 c2NlcHRpYmxlIHRvIGFsdGVyYXRpb24uIE5laXRoZXIgUW9zbW9zIG5vciBhbnkgb2YgaXRzIHN1 YnNpZGlhcmllcyBvciBhZmZpbGlhdGVzIHNoYWxsIGJlIGxpYWJsZSBmb3IgdGhlIG1lc3NhZ2Ug aWYgYWx0ZXJlZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNCkNlIG1lc3NhZ2UgZXQgdG91dGVz IHNlcyBwacOoY2VzIGpvaW50ZXMgKGNpLWFwcsOocyBsZSAibWVzc2FnZSIpc29udCBjb25maWRl bnRpZWxzIGV0IMOpdGFibGlzIMOgIGwnaW50ZW50aW9uIGV4Y2x1c2l2ZSBkZSBzZXMgZGVzdGlu YXRhaXJlcy4gU2kgdm91cyBhdmV6IHJlw6d1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgbWVyY2kg ZOKAmWVuIGluZm9ybWVyIGltbcOpZGlhdGVtZW50IHNvbiDDqW1ldHRldXIgcGFyIGNvdXJyaWVy IMOpbGVjdHJvbmlxdWUgZXQgZOKAmWVmZmFjZXIgY2UgbWVzc2FnZSBkZSB2b3RyZSBzeXN0w6ht ZS4gRGFucyBjZXR0ZSBoeXBvdGjDqHNlLCB2b3VzIG7igJnDqnRlcyBwYXMgYXV0b3Jpc8OpIMOg IHV0aWxpc2VyLCBjb3BpZXIgY2UgbWVzc2FnZSBldC9vdSBlbiBkaXZ1bGd1ZXIgbGUgY29udGVu dSDDoCB1biB0aWVycy4gVG91dCBtZXNzYWdlIMOpbGVjdHJvbmlxdWUgZXN0IHN1c2NlcHRpYmxl IGQnYWx0w6lyYXRpb24uIFFvc21vcyBldCBzZXMgZmlsaWFsZXMgZMOpY2xpbmVudCB0b3V0ZSBy ZXNwb25zYWJpbGl0w6kgYXUgdGl0cmUgZGUgY2UgbWVzc2FnZSBzJ2lsIGEgw6l0w6kgYWx0w6ly w6ksIGTDqWZvcm3DqSBvdSBmYWxzaWZpw6kuDQo= From nobody Wed Feb 4 09:06:24 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2CA1A8BB3 for ; Wed, 4 Feb 2015 09:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.601 X-Spam-Level: * X-Spam-Status: No, score=1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 QCGLOHeK28QK for ; Wed, 4 Feb 2015 09:06:19 -0800 (PST) Received: from mc28.lon.server.colt.net (mc28.lon.server.colt.net [212.74.77.108]) by ietfa.amsl.com (Postfix) with ESMTP id 019091A8AFB for ; Wed, 4 Feb 2015 09:06:16 -0800 (PST) Received: from mc28.lon.server.colt.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 889BBF0064 for ; Wed, 4 Feb 2015 17:06:15 +0000 (UTC) Received: from mx3.qosmos.com (unknown [195.68.92.43]) by mc28.lon.server.colt.net (Postfix) with ESMTP id 69B15F0015 for ; Wed, 4 Feb 2015 17:06:15 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.09,519,1418079600"; d="scan'208,217";a="1514947" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 04 Feb 2015 18:06:04 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.51]) with mapi id 14.01.0438.000; Wed, 4 Feb 2015 18:06:03 +0100 From: Nicolas BOUTHORS To: "'sfc@ietf.org'" Thread-Topic: draft-quinn-sfc-nsh-05, optional headers Thread-Index: AdBAmYhGpM3EkfNlQ4eMZ3oRb+Ov2Q== Date: Wed, 4 Feb 2015 17:06:03 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D7D2D2F@LILAS.jungle.qosmos.com> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.0.22] Content-Type: multipart/alternative; boundary="_000_76B41B8FACE1514795D30EC137FF391D7D2D2FLILASjungleqosmos_" MIME-Version: 1.0 X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSVA-8.2.0.1679-7.5.0.1018-21304.001 X-TM-AS-Result: No--10.057-5.0-31-10 X-imss-scan-details: No--10.057-5.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-Version: IMSVA-8.2.0.1679-7.5.1018-21304.001 X-TMASE-Result: 10--10.056900-5.000000 X-TMASE-MatchedRID: 4Zrz7AlLtnGGeTbGWdRz1pN3sInxtjDTu2rcU2ygxCBElaZ44wdr5Dmh 3EGpa3BQgT79ArsC4nDWp8dUVzIXrsXahuIx/HflHcQQBuf4ZFs4v0EQeJuGyC3uO0xwI7o/Z1H cplu19khywhyObtgtZJRehsBUYvv8qBA65KM+yMjrCGphOvOmDoB84MMvKleaVWoi/SaO4wY9E8 qGZBv0/XHHvM3MIz1JHdvJ//UlR8GCHDCr0YAJt7MjW/sniEQKj0Ch4H3a2gQCkW7cq1gGf/vMA qZVsxNrvj5kiwoD05egW8O7NNeH5YQt5fgfsxmoCPKPqEbU3ZPtpwT3I/obSQeLCIX046iBjNLx rcxKViUihgJVrNniBWrEBfVjKK6u1lfDCm9+EZVYKMMlFh4BnYfsPVs/8Vw6EfKzCAntKpDzMbP rnKd2TP/55Kkc+9/6c91xMYNqHkV7qToVEfwBPHuTVkeYosXtveEm5pElaXQIV1QinP8sFYvslv cBaUPtf5JFD2c52m+IUx6DAQEyFBrzyjDCLn+vNNHZMWDTEbecpmcfy1aA8lP6gCNWf17QuSSlt 7usGU3qO4O3VzNCsP++gjOGfzBm5UcZtwNsCroURSScn+QSXtivpTdmVCR2bGVEmIfjf3uy/GDT e97Ht7VLL6pJ0xbZhNoU9Ed5gV6KDZrsHHBemhck/603/n3oMvckE8BfMnpNKUgW2akMMpgvQBC GqtS9fF1vuCDJVzg= Archived-At: Subject: [sfc] draft-quinn-sfc-nsh-05, optional headers 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, 04 Feb 2015 17:06:21 -0000 --_000_76B41B8FACE1514795D30EC137FF391D7D2D2FLILASjungleqosmos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is great to have the possibility to add optional headers in NSH. However= , the mechanism proposed suppose that a specific header type (the MD Type= =3D0x2) is used in the base header when optional metadata are used. As a result: 1. The base header type 0x1 cannot be used with optional headers. Which= my make sense for performance point of view 2. Nor when using header MD type x2 can the "mandatory context headers= " be present. Case 2 can be worked around by defining an optional header that represents = the mandatory context header. Which is awkward as SFFs will have to decode = the same information in two different ways. Not particularly beautiful ! Why not have a flag (F2)stating that no optional Metadata are present and a= nother one (F1) stating that (what is now called) the mandatory context hea= der is present or not. We can then specify that the combinations F2=3DFalse implies F1=3DTrue F1=3DTrue, F2=3DTrue is allowed F1=3D False, F2=3DTrue is allowed It seems cleaner. When present, the "mandatory context headers" would alway= s be at the same place in the packet. Nicolas This message and any attachments (the "message") are confidential, intended= solely for the addressees. If you are not the intended recipient, please n= otify the sender immediately by e-mail and delete this message from your sy= stem. In this case, you are not authorized to use, copy this message and/or= disclose the content to any other person. E-mails are susceptible to alter= ation. Neither Qosmos nor any of its subsidiaries or affiliates shall be li= able for the message if altered, changed or falsified. Ce message et toutes ses pi?ces jointes (ci-apr?s le "message")sont confide= ntiels et ?tablis ? l'intention exclusive de ses destinataires. Si vous ave= z re?u ce message par erreur, merci d'en informer imm?diatement son ?metteu= r par courrier ?lectronique et d'effacer ce message de votre syst?me. Dans = cette hypoth?se, vous n'?tes pas autoris? ? utiliser, copier ce message et/= ou en divulguer le contenu ? un tiers. Tout message ?lectronique est suscep= tible d'alt?ration. Qosmos et ses filiales d?clinent toute responsabilit? a= u titre de ce message s'il a ?t? alt?r?, d?form? ou falsifi?. --_000_76B41B8FACE1514795D30EC137FF391D7D2D2FLILASjungleqosmos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
It is great to have the possibil=
ity to add optional headers in NSH. However, the mechanism proposed suppose=
 that a specific header type (the  MD Type=
=3D0x2) is used in the base header when optional metadata are used.<=
/span>
 

As a result:

 

1.     The base header type 0x1 ca= nnot be used with optional headers. Which my make sense for performance poi= nt of view

 

2.     Nor when using header MD ty= pe x2  can the “mandatory context headers” be present.

 

 

Case 2 can be worked arou= nd by defining an optional header that represents the mandatory context hea= der. Which is awkward as SFFs will have to decode the same information in two different ways. Not particularly beautiful !

 

Why not have a flag (F2)s= tating that no optional Metadata are present and another one (F1) stating t= hat (what is now called) the mandatory context header is present or not.

 

We can then specify that = the combinations

F2=3DFalse implies F1=3DT= rue

F1=3DTrue, F2=3DTrue is a= llowed

F1=3D False, F2=3DTrue is= allowed

 

It seems cleaner. When pr= esent, the “mandatory context headers” would always be at the s= ame place in the packet.

 

Nicolas

This message and any attachments (the "message") are confidential= , intended solely for the addressees. If you are not the intended recipient= , please notify the sender immediately by e-mail and delete this message fr= om your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any ot= her person. E-mails are susceptible to alteration. Neither Qosmos nor any o= f its subsidiaries or affiliates shall be liable for the message if altered= , changed or falsified.

Ce message et toutes ses pièces jointes (ci-après le "me= ssage")sont confidentiels et établis à l'intention exclu= sive de ses destinataires. Si vous avez reçu ce message par erreur, = merci d’en informer immédiatement son émetteur par cour= rier électronique et d’effacer ce message de votre système. Dans cette hypothèse, vous n= 217;êtes pas autorisé à utiliser, copier ce message et/= ou en divulguer le contenu à un tiers. Tout message électroni= que est susceptible d'altération. Qosmos et ses filiales décl= inent toute responsabilité au titre de ce message s'il a été altéré, d&ea= cute;formé ou falsifié.

--_000_76B41B8FACE1514795D30EC137FF391D7D2D2FLILASjungleqosmos_-- From nobody Wed Feb 4 09:25: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 63CD21A1A8D for ; Wed, 4 Feb 2015 09:25:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTrN-8xmJQgk for ; Wed, 4 Feb 2015 09:24:58 -0800 (PST) Received: from mc24.lon.server.colt.net (mc24.lon.server.colt.net [212.74.77.104]) by ietfa.amsl.com (Postfix) with ESMTP id 984B11A1A63 for ; Wed, 4 Feb 2015 09:24:57 -0800 (PST) Received: from mc24.lon.server.colt.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5759E1E0096 for ; Wed, 4 Feb 2015 17:24:56 +0000 (UTC) Received: from mx3.qosmos.com (unknown [195.68.92.43]) by mc24.lon.server.colt.net (Postfix) with ESMTP id 353311E004D for ; Wed, 4 Feb 2015 17:24:56 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.09,519,1418079600"; d="scan'208,217";a="1514998" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 04 Feb 2015 18:24:56 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.51]) with mapi id 14.01.0438.000; Wed, 4 Feb 2015 18:24:55 +0100 From: Nicolas BOUTHORS To: "'sfc@ietf.org'" Thread-Topic: draft-quinn-sfc-nsh-05 RSP_ID Role Thread-Index: AdBAnXBLlb1rPahXSY61x+lKn5E1yw== Date: Wed, 4 Feb 2015 17:24:54 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D7D2D4E@LILAS.jungle.qosmos.com> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.0.22] Content-Type: multipart/alternative; boundary="_000_76B41B8FACE1514795D30EC137FF391D7D2D4ELILASjungleqosmos_" MIME-Version: 1.0 X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSVA-8.2.0.1679-7.5.0.1018-21304.001 X-TM-AS-Result: No--11.467-5.0-31-10 X-imss-scan-details: No--11.467-5.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-Version: IMSVA-8.2.0.1679-7.5.1018-21304.001 X-TMASE-Result: 10--11.467200-5.000000 X-TMASE-MatchedRID: +weQV4wwN1sAc7Km7SS5rMRYU+wwS3nwbWouL55hGj3fUZT83lbkECnz /ouzbimK8p796sClznL6fOgyABZ+62KplHd7ThK19Ib/6w+1lWRd7K6NvtpeBEYx760ONDcWTsi kIK/5ZtxIHZkyKr/9iO5cRJg5lR7gi/KN1EqscVrMDCVnzDRQYLWJGLAWl35tDO+DX+rUwfaJ9n khOqcHs/d1nUKDxNHdZlTIOsCImsbm6E2uD55SErwfXVYjoVWNe6pYwozL4gQlqHlBOnK7Ur5xC 88ZlkDNlYPciEe2qTazKsEhH1QY/3XZ29PKwetsaDgPZBX/bMvqvccKLF+4p2mvvIHvstY7hAru eyGV6mKnblWEGY+BkgFk6w4YcqmhSOWjYlTyoLGYcl4BgqVyk3G1ZiUO5FClj2iyfwmt0k9o4tO BMzo2OL4y0FPJSJicky6S6Qx42n7IDNhlBZb72oHrpolLX+q0m/y00tE9Stb5N0o2THGRZHNDkb UsR4/KZipMsTQzH+IjGtzozoJsm40OLVogriN6BxsweNg3EaGFkCkkB0UMNpsoi2XrUn/JlR1cT 9YafQXGlDvsLUDW2m9go1P3rNNNOjY6hC4ay83XGd7sILJqqcGbZJgtkk1N2EgBUomUXG5n4tRO A9l0fLdoMrIGZbIHqp0OGyioDrWw9HNrcu/pBX1xbFVnASu5 Archived-At: Subject: [sfc] draft-quinn-sfc-nsh-05 RSP_ID Role 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, 04 Feb 2015 17:25:00 -0000 --_000_76B41B8FACE1514795D30EC137FF391D7D2D4ELILASjungleqosmos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have this discussion on RSP_ID, and as I review the NSH(5) proposal I s= ee: Since the SPI is an representation of the service path, the lookup may return more than one possible next-hop within a service path for a given SF, essentially a series of weighted (equally or otherwise) overlay links to be used (for load distribution, redundancy or policy),.. The table example is then : +----------------------------------+ | SPI | SI | NH | Metric | +----------------------------------+ | 10 | 3 | 10.1.1.1 | 1 | | | | 10.1.1.2 | 1 | | | | | | | 20 | 12 | 192.168.1.1 | 1 | | | | 10.2.2.2 | 1 | | | | | | | 30 | 7 | 10.2.2.3 | 10 | | | | 10.3.3.3 | 5 | +----------------------------------+ (encap type omitted for formatting) This shows clearly that an SFF can take local forwarding decision based on = SPI /SI and its routing table. However, there is an limitation in proceeding like that when provisioning a= chain this way. How can you have 2 SFF take a coordinated decision for some traffic: SSFx forwards to SFx(1) whe= n SFFy forwards to SFy(1) ? It is not necessarily a load balancing decision here. It can be a decision = based some criteria known to the Classifier (think of the number of information available about a subscriber in a GI LA= N). I can see how an RSP_ID could help here, if we allow such a parameter to be= part of the routing table as well. Nicolas This message and any attachments (the "message") are confidential, intended= solely for the addressees. If you are not the intended recipient, please n= otify the sender immediately by e-mail and delete this message from your sy= stem. In this case, you are not authorized to use, copy this message and/or= disclose the content to any other person. E-mails are susceptible to alter= ation. Neither Qosmos nor any of its subsidiaries or affiliates shall be li= able for the message if altered, changed or falsified. Ce message et toutes ses pi?ces jointes (ci-apr?s le "message")sont confide= ntiels et ?tablis ? l'intention exclusive de ses destinataires. Si vous ave= z re?u ce message par erreur, merci d'en informer imm?diatement son ?metteu= r par courrier ?lectronique et d'effacer ce message de votre syst?me. Dans = cette hypoth?se, vous n'?tes pas autoris? ? utiliser, copier ce message et/= ou en divulguer le contenu ? un tiers. Tout message ?lectronique est suscep= tible d'alt?ration. Qosmos et ses filiales d?clinent toute responsabilit? a= u titre de ce message s'il a ?t? alt?r?, d?form? ou falsifi?. --_000_76B41B8FACE1514795D30EC137FF391D7D2D4ELILASjungleqosmos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We have this discussion on RSP_ID, and as I review the NSH= (5) proposal  I see:

=  

= Since the SPI is an representation of the service path, the lookup

= may return more than one possible next-hop within a service path for=

= a given SF, essentially a series of weighted (equally or otherwise)<= /p>

= overlay links to be used (for load distribution, redundancy or

policy),..

 

The table example is then = :

     +--------=
--------------------------+
  &=
nbsp;  | SPI | SI |   NH      =
  |  Metric |
  &=
nbsp;  +----------------------------------+
  &=
nbsp;  | 10  |  3 | 10.1.1.1    |  1&nbs=
p;     |
  &=
nbsp;  |     |    | 10.1.1.2 &=
nbsp;  |  1      |
  &=
nbsp;  |     |    |  &nbs=
p;          |   =
;      |
  &=
nbsp;  | 20  | 12 | 192.168.1.1 |  1     =
; |
  &=
nbsp;  |     |    | 10.2.2.2 &=
nbsp;  |  1      |
  &=
nbsp;  |     |    |  &nbs=
p;          |   =
;      |
  &=
nbsp;  | 30  |  7 | 10.2.2.3    |  10&nb=
sp;    |
  &=
nbsp;  |     |    | 10.3.3.3 &=
nbsp;  |  5      |
  &=
nbsp;  +----------------------------------+
  &=
nbsp;  (encap type omitted for formatting)

 

This shows clearly that an SFF = can take local forwarding decision based on SPI /SI and its routing table.<= /span>

 

However, there is an limitation= in proceeding like that when provisioning a chain this way. How can you ha= ve 2 SFF

take a coordinated decision for= some traffic:  SSFx  forwards to SFx(1) when SFFy forwards to SF= y(1) ?

 

It is not necessarily a load ba= lancing decision here. It can be a decision based some criteria known to th= e Classifier

(think of the number of informa= tion available about a subscriber in a GI LAN).

 

I can see how an RSP_ID could h= elp here, if we allow such a parameter to be part of the routing table as w= ell.

 

 

 

Nicolas

This message and any attachments (the "message") are confidential= , intended solely for the addressees. If you are not the intended recipient= , please notify the sender immediately by e-mail and delete this message fr= om your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any ot= her person. E-mails are susceptible to alteration. Neither Qosmos nor any o= f its subsidiaries or affiliates shall be liable for the message if altered= , changed or falsified.

Ce message et toutes ses pièces jointes (ci-après le "me= ssage")sont confidentiels et établis à l'intention exclu= sive de ses destinataires. Si vous avez reçu ce message par erreur, = merci d’en informer immédiatement son émetteur par cour= rier électronique et d’effacer ce message de votre système. Dans cette hypothèse, vous n= 217;êtes pas autorisé à utiliser, copier ce message et/= ou en divulguer le contenu à un tiers. Tout message électroni= que est susceptible d'altération. Qosmos et ses filiales décl= inent toute responsabilité au titre de ce message s'il a été altéré, d&ea= cute;formé ou falsifié.

--_000_76B41B8FACE1514795D30EC137FF391D7D2D4ELILASjungleqosmos_-- From nobody Wed Feb 4 09:47:46 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 84D251A1BFA for ; Wed, 4 Feb 2015 09:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCaERoJ3Kq62 for ; Wed, 4 Feb 2015 09:47:41 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7D51A1B4F for ; Wed, 4 Feb 2015 09:47:40 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0174.001; Wed, 4 Feb 2015 09:47:40 -0800 From: Ron Parker To: Nicolas BOUTHORS , "'sfc@ietf.org'" Thread-Topic: draft-quinn-sfc-nsh-05 RSP_ID Role Thread-Index: AdBAnXBLlb1rPahXSY61x+lKn5E1ywABEYhQ Date: Wed, 4 Feb 2015 17:47:39 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D7D2D4E@LILAS.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D7D2D4E@LILAS.jungle.qosmos.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: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B2E7EE81DMBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-quinn-sfc-nsh-05 RSP_ID Role 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, 04 Feb 2015 17:47:45 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B2E7EE81DMBX021W3CA2exch_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nicolas, I agree with your analysis that RSP ID is fundamental to the hop-by-hop for= warding and will ultimately be part of a classifier's and SFF's forwarding = table. There are 2 use cases I can foresee, here. In the first, the fu= lly concrete RSP's are calculated by some sort of central orchestrator. I= n this case, it would be necessary for the encapsulation to carry only the = RSP ID (the SFP ID, which is not necessarily concrete, is not necessary at = all) - in practice, you simply rename the current "SFP ID" to be "RSP ID". In a second use case, the fully concrete path is nailed up on a hop-by-hop = "trail-blazed" basis (i.e., classifier makes a decision as to which is the = first SFF, first SFF decides upon local SF instance invocation and/or secon= d SFF, etc.). In this case, the encapsulation would be required to carry = both the SFP ID and the RSP ID. I believe that both use cases are covered by the architecture and that both= are entirely valid. Thanks. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Nicolas BOUTHORS Sent: Wednesday, February 4, 2015 12:25 PM To: 'sfc@ietf.org' Subject: [sfc] draft-quinn-sfc-nsh-05 RSP_ID Role We have this discussion on RSP_ID, and as I review the NSH(5) proposal I s= ee: Since the SPI is an representation of the service path, the lookup may return more than one possible next-hop within a service path for a given SF, essentially a series of weighted (equally or otherwise) overlay links to be used (for load distribution, redundancy or policy),.. The table example is then : +----------------------------------+ | SPI | SI | NH | Metric | +----------------------------------+ | 10 | 3 | 10.1.1.1 | 1 | | | | 10.1.1.2 | 1 | | | | | | | 20 | 12 | 192.168.1.1 | 1 | | | | 10.2.2.2 | 1 | | | | | | | 30 | 7 | 10.2.2.3 | 10 | | | | 10.3.3.3 | 5 | +----------------------------------+ (encap type omitted for formatting) This shows clearly that an SFF can take local forwarding decision based on = SPI /SI and its routing table. However, there is an limitation in proceeding like that when provisioning a= chain this way. How can you have 2 SFF take a coordinated decision for some traffic: SSFx forwards to SFx(1) whe= n SFFy forwards to SFy(1) ? It is not necessarily a load balancing decision here. It can be a decision = based some criteria known to the Classifier (think of the number of information available about a subscriber in a GI LA= N). I can see how an RSP_ID could help here, if we allow such a parameter to be= part of the routing table as well. Nicolas This message and any attachments (the "message") are confidential, intended= solely for the addressees. If you are not the intended recipient, please n= otify the sender immediately by e-mail and delete this message from your sy= stem. In this case, you are not authorized to use, copy this message and/or= disclose the content to any other person. E-mails are susceptible to alter= ation. Neither Qosmos nor any of its subsidiaries or affiliates shall be li= able for the message if altered, changed or falsified. Ce message et toutes ses pi=E8ces jointes (ci-apr=E8s le "message")sont con= fidentiels et =E9tablis =E0 l'intention exclusive de ses destinataires. Si = vous avez re=E7u ce message par erreur, merci d'en informer imm=E9diatement= son =E9metteur par courrier =E9lectronique et d'effacer ce message de votr= e syst=E8me. Dans cette hypoth=E8se, vous n'=EAtes pas autoris=E9 =E0 utili= ser, copier ce message et/ou en divulguer le contenu =E0 un tiers. Tout mes= sage =E9lectronique est susceptible d'alt=E9ration. Qosmos et ses filiales = d=E9clinent toute responsabilit=E9 au titre de ce message s'il a =E9t=E9 al= t=E9r=E9, d=E9form=E9 ou falsifi=E9. --_000_CDF2F015F4429F458815ED2A6C2B6B0B2E7EE81DMBX021W3CA2exch_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Nicolas,

 

I agree with your anal= ysis that RSP ID is fundamental to the hop-by-hop forwarding and will ultim= ately be part of a classifier’s and SFF’s forwarding table.&nbs= p;   There are 2 use cases I can foresee, here.   In the first, the fully concrete RSP’s are calculated by some sort of c= entral orchestrator.   In this case, it would be necessary for th= e encapsulation to carry only the RSP ID (the SFP ID, which is not necessar= ily concrete, is not necessary at all) – in practice, you simply rename the current “SFP ID” to be “RSP IDR= 21;.

 

In a second use case, = the fully concrete path is nailed up on a hop-by-hop “trail-blazed= 221; basis (i.e., classifier makes a decision as to which is the first SFF,= first SFF decides upon local SF instance invocation and/or second SFF, etc.).   In this case, the encapsulation woul= d be required to carry both the SFP ID and the RSP ID.

 

I believe that both us= e cases are covered by the architecture and that both are entirely valid.

 

Thanks.

 

    Ron=

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On= Behalf Of Nicolas BOUTHORS
Sent: Wednesday, February 4, 2015 12:25 PM
To: 'sfc@ietf.org'
Subject: [sfc] draft-quinn-sfc-nsh-05 RSP_ID Role

 

We have this= discussion on RSP_ID, and as I review the NSH(5) proposal  I see:

 

Since the SPI is = an representation of the service path, the lookup<= o:p>

may return more t= han one possible next-hop within a service path for

a given SF, essen= tially a series of weighted (equally or otherwise)=

overlay links to = be used (for load distribution, redundancy or=

polic= y),..

 

The table example is then :

  &=
nbsp;  +-----------=
-----------------------+

&=
nbsp;    | SPI | SI |   NH    =
    |  Metric |


&=
nbsp;    +----------------------------------+=



&=
nbsp;    | 10  |  3 | 10.1.1.1    |=
  1      |


&=
nbsp;    |     |    | 10.=
1.1.2    |  1      |


&=
nbsp;    |     |    |&nbs=
p;            | =
;        |=



&=
nbsp;    | 20  | 12 | 192.168.1.1 |  1   =
;   |


&=
nbsp;    |     |    | 10.=
2.2.2    |  1      |


&=
nbsp;    |     |    |&nbs=
p;            | =
;        |=



&=
nbsp;    | 30  |  7 | 10.2.2.3    |=
  10     |


&=
nbsp;    |     |    | 10.=
3.3.3    |  5      |


&=
nbsp;    +----------------------------------+=



&=
nbsp;    (encap type omitted for formatting)


 


This shows clearly that an SFF can take local forwar=
ding decision based on SPI /SI and its routing table.


 


However, there is an limitation in proceeding like t=
hat when provisioning a chain this way. How can you have 2 SFF


take a coordinated decision for some traffic:  =
SSFx  forwards to SFx(1) when SFFy forwards to SFy(1) ?



 


It is not necessarily a load balancing decision here=
. It can be a decision based some criteria known to the Classifier



(think of the number of information available about =
a subscriber in a GI LAN).


 


I can see how an RSP_ID could help here, if we allow=
 such a parameter to be part of the routing table as well.


 


 


 


Nicolas

This message and any attachments (the= "message") are confidential, intended solely for the addressees.= If you are not the intended recipient, please notify the sender immediately by e-mail and delete this message from your system. In = this case, you are not authorized to use, copy this message and/or disclose= the content to any other person. E-mails are susceptible to alteration. Ne= ither Qosmos nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsi= fied.

Ce message et toutes ses pi=E8ces joi= ntes (ci-apr=E8s le "message")sont confidentiels et =E9tablis =E0= l'intention exclusive de ses destinataires. Si vous avez re=E7u ce message par erreur, merci d’en informer imm=E9diatement son =E9mette= ur par courrier =E9lectronique et d’effacer ce message de votre syst= =E8me. Dans cette hypoth=E8se, vous n’=EAtes pas autoris=E9 =E0 utili= ser, copier ce message et/ou en divulguer le contenu =E0 un tiers. Tout message =E9lectronique est susceptible d'alt=E9ration. Qosmos et ses filia= les d=E9clinent toute responsabilit=E9 au titre de ce message s'il a =E9t= =E9 alt=E9r=E9, d=E9form=E9 ou falsifi=E9.

--_000_CDF2F015F4429F458815ED2A6C2B6B0B2E7EE81DMBX021W3CA2exch_-- From nobody Wed Feb 4 13:16: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 712CB1A8821 for ; Wed, 4 Feb 2015 13:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFLKqpeuvBsy for ; Wed, 4 Feb 2015 13:16:24 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7DE1A1AE1 for ; Wed, 4 Feb 2015 13:16:24 -0800 (PST) Received: from [85.158.136.83] by server-7.bemta-5.messagelabs.com id C8/00-03736-72C82D45; Wed, 04 Feb 2015 21:16:23 +0000 X-Env-Sender: walter.haeffner@vodafone.com X-Msg-Ref: server-10.tower-36.messagelabs.com!1423084583!14775412!1 X-Originating-IP: [195.232.224.79] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16358 invoked from network); 4 Feb 2015 21:16:23 -0000 Received: from mailout10.vodafone.com (HELO mailout10.vodafone.com) (195.232.224.79) by server-10.tower-36.messagelabs.com with SMTP; 4 Feb 2015 21:16:23 -0000 Received: from mailint10.vodafone.com (localhost [127.0.0.1]) by mailout10.vodafone.com (Postfix) with ESMTP id DC31F300318 for ; Wed, 4 Feb 2015 22:16:22 +0100 (CET) Received: from VOEXC05W.internal.vodafone.com (voexc05w.dc-ratingen.de [145.230.101.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint10.vodafone.com (Postfix) with ESMTPS id C57F93002E1; Wed, 4 Feb 2015 22:16:22 +0100 (CET) Received: from VOEXC09W.internal.vodafone.com (145.230.101.29) by VOEXC05W.internal.vodafone.com (145.230.101.25) with Microsoft SMTP Server (TLS) id 14.3.181.6; Wed, 4 Feb 2015 22:16:22 +0100 Received: from VOEXM20W.internal.vodafone.com ([169.254.4.178]) by VOEXC09W.internal.vodafone.com ([145.230.101.29]) with mapi id 14.03.0181.006; Wed, 4 Feb 2015 22:16:21 +0100 From: "Haeffner, Walter, Vodafone DE" To: Dave Dolson , "'sfc@ietf.org'" , "jenapper@cisco.com" , "mls.ietf@gmail.com" , "diego@tid.es" , "uttaro@att.com" Thread-Topic: Mobile use cases draft-ietf-sfc-use-case-mobility-03 Thread-Index: AdA5i9PHaEFtXImRQvatdBwSl/7IsAGMvTuQ Date: Wed, 4 Feb 2015 21:16:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Mobile use cases draft-ietf-sfc-use-case-mobility-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 21:16:27 -0000 Hi Dave, Thanks for your comment. You are right. We have to explain the associated f= lows in some more detail. Our figure 5 indeed is very abstract just showing= the connectivity of the functions. In our drawing 5 our [Appls] are locat= ed somewhere in the internet or in a carrier's datacenter. Idea was to show= that different Applications may use different SFCs and a TDF can make this= more granular. Means the [Appls] itself are not part of a SFC (For sure, a= SFC may also contain Value Added Services just considered to be a SF). We currently think about how to draw/describe the picture more precisely.=20 On logical level we could say the SFC (set of SFs) is sandwiched by two log= ical classifier functions: SFC-up Up------->class-up ----- -----class-down<-----down SFC-down Where class-up and class-down indeed may be components of one and the same = classifier. Sometimes you need these two, sometimes one is sufficient. Some= times we have a symmetric (bi-directional) SFC, in some cases the SFC may b= e unidirectional. Further, TDF could reside within or outside a P-GW.=20 Unfortunately we use different fonts in our email systems. Therefore I had = to reconstruct your figure. Hope this figure reflects somehow your origina= l drawing (when using the appropriate font). But I do not fully understand = the details of your figure: +------------------------------------+ | PCRF | +----+------------------------+-----+ | | Gx-IF Sd-IF | | | +--------------+-------------= -----------------+ | | [TDF] = | | | +-------------------= -------------+ | +----+-----+ | | = | | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO [PCEF] | | O---[SFC 1] ---- = [Appl. 1]---O | | | | O---[SFC 2] ---- [App= l. 2]---O |-------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO P-GW O---O O---[SFC 3] ---- [Ap= pl. 3]---O | | | | O---[SFC 4] ---- [App= l. 4]---O | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO | | O---[SFC n] = ---- [Appl. n]---O | +-----------+ +-----+ = +-----+ * = * 3GPP Bearer SGi = SGi I rather had drawn the figure somehow the following way arguing the TDF cla= ssifier is the "horse shoe" around the SFCs. Maybe you had the same in mind= . +------------------------------------+ | PCRF | +----+------------------------+-----+ | | Gx-IF Sd-IF | | | +--------------+-------------= -----------------+ | | [TDF] = | | | +-------------------= -------------+ | +----+-----+ | | = | | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO [PCEF] | | O---[SFC 1] -----= --------------O | ---- [Appl. 1] | | | O---[SFC 2] ---------= ---------O |-------- ---- [Appl. 2] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO P-GW O---O O---[SFC 3] --------= ----------O | ---- [Appl. 3] | | | O---[SFC 4] ---------= ---------O | ---- [Appl. 4] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO | | O---[SFC n] = ---- -------------O | ---- [Appl. n] +-----------+ +-----+ = +-----+ * = * 3GPP Bearer SGi = SGi What do you think? Best regards, Walter -----Urspr=FCngliche Nachricht----- Von: Dave Dolson [mailto:ddolson@sandvine.com]=20 Gesendet: Montag, 26. Januar 2015 18:17 An: 'sfc@ietf.org'; Haeffner, Walter, Vodafone DE; jenapper@cisco.com; mls.= ietf@gmail.com; diego@tid.es; uttaro@att.com Betreff: Mobile use cases draft-ietf-sfc-use-case-mobility-03 Authors of draft-ietf-sfc-use-case-mobility, You make explicit reference (in section 2.2) to the care to be taken with b= idirectional flows, which I agree with. So, referring to your figure 5: +-------------------------+ | PCRF | +----+--------------+-----+ | | Gx-IF Sd-IF | | +----+-----+ +----+-----+ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO [PCEF] | | O--------[SFC 1]= ---- [Appl. 1] | | | O--------[SFC 2] ---- [Appl. 2] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO P-GW O---O [TDF] O--------[SFC 3]= ---- [Appl. 3] | | | O--------[SFC 4] ---- [Appl. 4] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO | | O--------[SFC n]= ---- [Appl. n] +----------+ +----------+ * * 3GPP Bearer SGi SGi It isn't clear what device is selecting the chains for down-link traffic. Given that the TDF is making application-specific decisions, how would one = ensure the down-link traffic is classified to the same service functions as= the up-link traffic, something very critical for many of the use cases? * a TDF can classify traffic using a wide variety of methods,=20 including signature-matching that uses fields only available at=20 the start of a flow, likely only appearing in one direction; (classification based solely on port number is rather weak).=20 So in the general case, decisions are made for TCP connections,=20 not for packets. I propose that the picture is more like the following, with the TDF book-en= ding the service chains to ensure consistent classification of both up-link= and down-link traffic for a given transport connection. +-------------------------+ | PCRF | +----+--------------+-----+ | | Gx-IF Sd-IF | | | +----+------------------------------------+ | | [TDF] | | | +----------------------------+ | +----+-----+ | | | | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO [PCEF] | | O---[SFC 1] ---- [A= ppl. 1]---O | | | | O---[SFC 2] ---- [Appl. 2]---O |--- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO P-GW O---O O---[SFC 3] ---- [A= ppl. 3]---O | | | | O---[SFC 4] ---- [Appl. 4]---O | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO | | O---[SFC n] ---- [A= ppl. n]---O | +----------+ +-------+ +----+ * * 3GPP Bearer SGi SGi Perhaps this is what you intended. Is this what you had in mind? David Dolson Senior Software Architect, Sandvine Inc. From nobody Wed Feb 4 19:24: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 A8BE51A038D for ; Wed, 4 Feb 2015 19:24:32 -0800 (PST) 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 OPPhDIMsLX-6 for ; Wed, 4 Feb 2015 19:24:29 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id E80311A0393 for ; Wed, 4 Feb 2015 19:24:28 -0800 (PST) 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; Wed, 4 Feb 2015 22:24:27 -0500 From: Dave Dolson To: "Haeffner, Walter, Vodafone DE" , "'sfc@ietf.org'" , "jenapper@cisco.com" , "mls.ietf@gmail.com" , "diego@tid.es" , "uttaro@att.com" Thread-Topic: Mobile use cases draft-ietf-sfc-use-case-mobility-03 Thread-Index: AdA5i9PHaEFtXImRQvatdBwSl/7IsAGMvTuQAEyWPOE= Date: Thu, 5 Feb 2015 03:24:25 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.194.252] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Mobile use cases draft-ietf-sfc-use-case-mobility-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 03:24:32 -0000 Walter,=0A= Thanks for the response. Yes, there are font problems. I think you'll find = the email archives show my email formatted properly: http://www.ietf.org/ma= il-archive/web/sfc/current/msg03012.html=0A= =0A= Unfortunately your drawing didn't come through properly at my end, but I th= ink "horseshoe" describes my intention. =0A= =0A= I am primarily concerned with the special case of the bidirectional service= chains, such as when service functions require both directions of a TCP fl= ow.=0A= =0A= Indeed, class-up and class-down should be within the same device when local= decisions are made flow-by-flow.=0A= =0A= I think it is fairly important to point this out in your document, since it= changes how one thinks about the network architecture. In particular, the = rules deployed to the TDF from the PCRF need to act on both up-link and dow= n-link traffic.=0A= =0A= -Dave=0A= =0A= =0A= ________________________________________=0A= From: Haeffner, Walter, Vodafone DE [walter.haeffner@vodafone.com]=0A= Sent: Wednesday, February 04, 2015 4:16 PM=0A= To: Dave Dolson; 'sfc@ietf.org'; jenapper@cisco.com; mls.ietf@gmail.com; di= ego@tid.es; uttaro@att.com=0A= Subject: AW: Mobile use cases draft-ietf-sfc-use-case-mobility-03=0A= =0A= Hi Dave,=0A= =0A= Thanks for your comment. You are right. We have to explain the associated f= lows in some more detail. Our figure 5 indeed is very abstract just showing= the connectivity of the functions. In our drawing 5 our [Appls] are locat= ed somewhere in the internet or in a carrier's datacenter. Idea was to show= that different Applications may use different SFCs and a TDF can make this= more granular. Means the [Appls] itself are not part of a SFC (For sure, a= SFC may also contain Value Added Services just considered to be a SF).=0A= =0A= We currently think about how to draw/describe the picture more precisely.= =0A= =0A= On logical level we could say the SFC (set of SFs) is sandwiched by two log= ical classifier functions:=0A= =0A= SFC-up=0A= Up------->class-up ----- -----class-down<-----down=0A= SFC-down=0A= =0A= Where class-up and class-down indeed may be components of one and the same = classifier. Sometimes you need these two, sometimes one is sufficient. Some= times we have a symmetric (bi-directional) SFC, in some cases the SFC may b= e unidirectional.=0A= =0A= Further, TDF could reside within or outside a P-GW.=0A= =0A= Unfortunately we use different fonts in our email systems. Therefore I had = to reconstruct your figure. Hope this figure reflects somehow your origina= l drawing (when using the appropriate font). But I do not fully understand = the details of your figure:=0A= =0A= +------------------------------------+=0A= | PCRF |=0A= +----+------------------------+-----+=0A= | |=0A= Gx-IF Sd-IF=0A= | |=0A= | +--------------+-------------= -----------------+=0A= | | [TDF] = |=0A= | | +-------------------= -------------+ |=0A= +----+-----+ | | = | |=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO [PCEF] | | O---[SFC 1] ---- = [Appl. 1]---O |=0A= | | | O---[SFC 2] ---- [App= l. 2]---O |--------=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO P-GW O---O O---[SFC 3] ---- [Ap= pl. 3]---O |=0A= | | | O---[SFC 4] ---- [App= l. 4]---O |=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO | | O---[SFC n] = ---- [Appl. n]---O |=0A= +-----------+ +-----+ = +-----+=0A= * = *=0A= 3GPP Bearer SGi = SGi=0A= =0A= I rather had drawn the figure somehow the following way arguing the TDF cla= ssifier is the "horse shoe" around the SFCs. Maybe you had the same in mind= .=0A= =0A= +------------------------------------+=0A= | PCRF |=0A= +----+------------------------+-----+=0A= | |=0A= Gx-IF Sd-IF=0A= | |=0A= | +--------------+-------------= -----------------+=0A= | | [TDF] = |=0A= | | +-------------------= -------------+ |=0A= +----+-----+ | | = | |=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO [PCEF] | | O---[SFC 1] -----= --------------O | ---- [Appl. 1]=0A= | | | O---[SFC 2] ---------= ---------O |-------- ---- [Appl. 2]=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO P-GW O---O O---[SFC 3] --------= ----------O | ---- [Appl. 3]=0A= | | | O---[SFC 4] ---------= ---------O | ---- [Appl. 4]=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO | | O---[SFC n] = ---- -------------O | ---- [Appl. n]=0A= +-----------+ +-----+ = +-----+=0A= * = *=0A= 3GPP Bearer SGi = SGi=0A= =0A= What do you think?=0A= =0A= Best regards,=0A= Walter=0A= =0A= -----Urspr=FCngliche Nachricht-----=0A= Von: Dave Dolson [mailto:ddolson@sandvine.com]=0A= Gesendet: Montag, 26. Januar 2015 18:17=0A= An: 'sfc@ietf.org'; Haeffner, Walter, Vodafone DE; jenapper@cisco.com; mls.= ietf@gmail.com; diego@tid.es; uttaro@att.com=0A= Betreff: Mobile use cases draft-ietf-sfc-use-case-mobility-03=0A= =0A= Authors of draft-ietf-sfc-use-case-mobility,=0A= =0A= You make explicit reference (in section 2.2) to the care to be taken with b= idirectional flows, which I agree with.=0A= =0A= So, referring to your figure 5:=0A= =0A= +-------------------------+=0A= | PCRF |=0A= +----+--------------+-----+=0A= | |=0A= Gx-IF Sd-IF=0A= | |=0A= +----+-----+ +----+-----+=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO [PCEF] | | O--------[SFC 1]= ---- [Appl. 1]=0A= | | | O--------[SFC 2] ---- [Appl. 2]=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO P-GW O---O [TDF] O--------[SFC 3]= ---- [Appl. 3]=0A= | | | O--------[SFC 4] ---- [Appl. 4]=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO | | O--------[SFC n]= ---- [Appl. n]=0A= +----------+ +----------+=0A= * *=0A= 3GPP Bearer SGi SGi=0A= =0A= It isn't clear what device is selecting the chains for down-link traffic.= =0A= =0A= Given that the TDF is making application-specific decisions, how would one = ensure the down-link traffic is classified to the same service functions as= the up-link traffic, something very critical for many of the use cases?=0A= =0A= * a TDF can classify traffic using a wide variety of methods,=0A= including signature-matching that uses fields only available at=0A= the start of a flow, likely only appearing in one direction;=0A= (classification based solely on port number is rather weak).=0A= So in the general case, decisions are made for TCP connections,=0A= not for packets.=0A= =0A= I propose that the picture is more like the following, with the TDF book-en= ding the service chains to ensure consistent classification of both up-link= and down-link traffic for a given transport connection.=0A= =0A= =0A= +-------------------------+=0A= | PCRF |=0A= +----+--------------+-----+=0A= | |=0A= Gx-IF Sd-IF=0A= | |=0A= | +----+------------------------------------+=0A= | | [TDF] |=0A= | | +----------------------------+ |=0A= +----+-----+ | | | |=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO [PCEF] | | O---[SFC 1] ---- [A= ppl. 1]---O |=0A= | | | O---[SFC 2] ---- [Appl. 2]---O |---= =0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO P-GW O---O O---[SFC 3] ---- [A= ppl. 3]---O |=0A= | | | O---[SFC 4] ---- [Appl. 4]---O |=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3DO | | O---[SFC n] ---- [A= ppl. n]---O |=0A= +----------+ +-------+ +----+=0A= * *= =0A= 3GPP Bearer SGi SGi= =0A= =0A= =0A= Perhaps this is what you intended. Is this what you had in mind?=0A= =0A= =0A= David Dolson=0A= Senior Software Architect, Sandvine Inc.=0A= =0A= From nobody Wed Feb 4 21:46:25 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 A27961A037A for ; Wed, 4 Feb 2015 21:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.311 X-Spam-Level: X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, 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 GjEMagApUKjZ for ; Wed, 4 Feb 2015 21:46:17 -0800 (PST) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by ietfa.amsl.com (Postfix) with ESMTP id D16031A0104 for ; Wed, 4 Feb 2015 21:46:16 -0800 (PST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP; 04 Feb 2015 21:41:33 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,522,1418112000"; d="scan'208";a="681176178" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by orsmga002.jf.intel.com with ESMTP; 04 Feb 2015 21:46:16 -0800 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.100]) by ORSMSX102.amr.corp.intel.com ([169.254.1.165]) with mapi id 14.03.0195.001; Wed, 4 Feb 2015 21:46:15 -0800 From: "Elzur, Uri" To: Cathy Zhang , "Ken Gray (kegray)" , Srini Addepalli , "Reinaldo Penno (repenno)" , "Joel M. Halpern" , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZx/9uiAgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgCAAEtwAIBWb4+AgAdtFgCAALR5gIABZ2FQ Date: Thu, 5 Feb 2015 05:46:14 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B89958581B66406@ORSMSX114.amr.corp.intel.com> References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "nsmurthy@freescale.com" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 05 Feb 2015 05:46:20 -0000 Assuming the issues listed below are the complete set of "delta" between th= e drafts, it makes sense to reach out to NSH authors and try to reach an ac= ceptable compromise, which is part of the standardization process. I do not= see in that list a fundamentally different approach that warrants another = draft, it seems like feature level disagreement/ preference difference etc.= It can also be discussed on the ml or during the next meeting I'll join other who mentioned we should go ahead w NSH draft Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Cathy Zhang Sent: Tuesday, February 3, 2015 1:54 PM To: Ken Gray (kegray); Srini Addepalli; Reinaldo Penno (repenno); Joel M. H= alpern; 'sfc@ietf.org'; Cathy Zhang Cc: nsmurthy@freescale.com Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) Hi Ken, Please see inline. Thanks, Cathy -----Original Message----- From: Ken Gray (kegray) [mailto:kegray@cisco.com] Sent: Tuesday, February 03, 2015 10:09 AM To: Cathy Zhang; Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern= ; 'sfc@ietf.org' Cc: nsmurthy@freescale.com Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft= -zhang-sfc-sch-02) As a general comment on this submission (and perhaps life in the current IE= TF). I have a REALLY hard time differentiating this draft from the quinn d= raft (which pre-dates it by quite a bit). Why are we pursuing a separate d= raft when the suggestions, IMHO, seem incremental at best? Cathy> The original motivation for drafting the SCH is to provide an altern= ative to draft-quinn-nsh to address the following perceived issues: 1. Mandatory fixed-sized metadata. We think they should not be mandatory si= nce the 4-word context fields are not needed in many scenarios 2. No variab= le length metadata. We think metadata should be optional and TLV format sho= uld be used to define metadata 3. No organizationally defined metadata 4. N= o Version field. =20 When we uploaded SCH 1st version (3/24/2014), NSH version did not have the = TLV metadata and version field (they were added in its later version). I have reach out to the chairs here . we have a lot to read. Aren't drafts = supposed to offer significantly different views if they are to persist (wit= hout that, a "call to adopt" becomes a beauty contest, IMO)? No offense to= the authors, but we're in revision 3 and I don't see that here. =20 Regarding the changes in this document: I do not find the flow ID functionally different than the use context heade= rs in the nsh draft, which seem to be a more multi-purpose concept. Cathy> Different people have different viewpoints. RSP ID is not defined in= NSH and from Paul (NSH author)'s reply, it seems he does not feel the need= of an RSP ID.=20 Cathy> We see the need for RSP ID and thus defined it in SCH for open discu= ssion and would like to see the community's feedback on it. =20 The B bit suggestion can cause a conflict in control and create an avenue f= or undesirable behavior, IMO. I've been working from the assumption that a= minimum requirement of a function is that it be manageable (if for no othe= r reason than effective elasticity and cohesive/predictable delivery of ser= vice), so I have little sympathy for those that are not - be they virtual o= r physical (even less sympathy for virtual functions that are unmanageable,= frankly). A self-management option in the SFC scenario has low value and = the corruption or misuse of the bit can cause chaos (an extra level of "fai= l"). Cathy> Could you clarify what you mean by "cause a conflict in control"?=20 The Generic Context Block is confusing in light of the already extant optio= nal/variable metadata TLVs (why wouldn't you leverage one of them)? Cathy> I am not sure if I understand your point. The Generic Context Block = is one type of metadata which is in TLV format and is optional.=20 Thanks, Cathy On 1/29/15, 2:44 PM, "Cathy Zhang" wrote: >Hi everyone, > >We have uploaded a new SCH version (3) which adds definition of a new=20 >metadata type for the flow ID to support load balancing among SF=20 >instances and mitigate the potential issue of "not enough path ID". The=20 >flow ID is named "rendered service path ID" in the draft. Please refer=20 >to section 4.3.2 of=20 >https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/ >for detail description. >=20 > >In its previous version, SCH defines a "Bypass bit" in the base header. >This bit enables the SF to provide feedback/notification via the data=20 >path to its connecting SFF about whether the remaining packets of the=20 >SFC should bypass that SF. This is useful in the case that only the=20 >first few packets of a flow need to go to a SF (such as a DPI or FW or=20 >IDS) and remaining packets can bypass that SF, thus saving the=20 >expensive SF resource and reducing data path latency. > >B bit: The B (Bypass) bit, when set to 1, it is used by a Service > Function to signal to its Service Function Forwarder that no > further packets are to be sent to it for the flow specified in=20 >encapsulated packet. > >In addition, SCH defines a metadata type for Generic Context Block,=20 >which is optional and can be used if needed to carry any vendor's=20 >specific "Context Header". >=20 > >Any comments on these new additions? > >Thanks, >Cathy > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Cathy Zhang >Sent: Friday, December 05, 2014 11:47 AM >To: Srini Addepalli; Reinaldo Penno (repenno); Joel M. Halpern;=20 >'sfc@ietf.org' >Cc: nsmurthy@freescale.com >Subject: Re: [sfc] Comments on SCH Draft >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > >Ron, Louis, Myo and I have been discussing off line last few weeks=20 >about defining a metadata type for flow ID in addition to the path ID=20 >of the main header to support load balancing among SF instances. We=20 >will define a TLV type for the flow ID. The combination of "path ID + flow= ID" >specifies a realized service chain instance path. It is left to the=20 >design/implementation whether to use a centralized method or a=20 >distributed method to bind the flow ID to a realized service instance=20 >path although our original thought is for distributed LB usage. I am=20 >not sure if we need a bit in the header to denote whether there are=20 >more path ID bits (we call it flow ID) in the metadata fields since=20 >when you parse the TLV metadata, you will know whether there are flow ID b= its or not. >Note that if multiple sessions share the same realized service instance=20 >path, they will share the same "path ID+ flow ID". We can also=20 >consider extending the number of bits to 32 if that is the consensus.=20 >We will post an updated draft describing these soon. > >Thanks, >Cathy > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Srini Addepalli >Sent: Friday, December 05, 2014 7:17 AM >To: Reinaldo Penno (repenno); Joel M. Halpern; 'sfc@ietf.org' >Cc: nsmurthy@freescale.com >Subject: Re: [sfc] Comments on SCH Draft >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > > >[RP] Data plane efficiency. > >SRINI> I am not so sure about data plane efficiency. Most of the >processors work good if the number of bits are either 32 or 64. If it=20 >is >24 bits, then one needs to do masking and shifting before the value is >used to do any lookup. But, this discussion can go into different >direction :-), it may not be good to go in that direction. > >Where do we draw the line? 32-bits, 64-bits, >128 bits? I think we should have a sensible value in the Service Path=20 >header and if you need to convey more bits you need to use the context=20 >headers. > >SRINI> This is a good point. This should work fine as long as there is >way to convey in the main header that the extension to path ID is=20 >available in so and so TLV field. That should work too. > >Thanks >Srini > >________________________________________ >From: Reinaldo Penno (repenno) >Sent: Friday, December 5, 2014 7:08 AM >To: Addepalli Srini-B22160; Joel M. Halpern; 'sfc@ietf.org' >Cc: NS Srinivasa Murthy-B37840 >Subject: Re: [sfc] Comments on SCH Draft >(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) > >On 12/5/14, 6:54 AM, "Srini Addepalli" wrote: > >> >>In real deployments, number of active path IDs are very lesser than=20 >>2^64, but there is a good possibility of the number being more than 2^24 = (16M). >> I think bigger point is that why restrict this in the standards? What=20 >>advantage do we have restricting this size to 24 bits? > >[RP] Data plane efficiency. Where do we draw the line? 32-bits,=20 >64-bits, >128 bits? I think we should have a sensible value in the Service Path=20 >header and if you need to convey more bits you need to use the context=20 >headers. > > >> >>There can be deployments, where SFC controller (Logically central, but >>distributed) itself can do the SF instance selection on per >>connection/session basis, thereby avoiding the LBs for services. In my >>view, assumption that there will be LB SF for each scale-out service=20 >>in the chain is not valid in all cases. >> >>Thanks >>Srini >> >>________________________________________ >>From: Reinaldo Penno (repenno) >>Sent: Thursday, December 4, 2014 1:17 PM >>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org >>Cc: NS Srinivasa Murthy-B37840 >>Subject: Re: [sfc] Comments on SCH Draft >>(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >> >>If I understood you, I do not think this is realistic. Are you saying=20 >>you need 64-bits of paths and then will monitor them all? Do fault=20 >>tolerance and OAM for 2^64-bits worth of paths? Just for comparison,=20 >>it=B9s like managing and monitoring the entire IPv6 host range, one-by-on= e. >> >>Anyway, I do not expect every single permutations to be a different path. >> >>If each service has 256 devices providing similar service, you should=20 >>most likely use load-balancing and then you would have a single (or a=20 >>few) paths. There is some discussion going on LB. >> >>From a data plane perspective, the path is ultimately defined by the=20 >>SFFs traversed and services provided, not by a specific IP:port that=20 >>the device providing the service sits on. Well, at least from a=20 >>GPE+NSH perspective. >> >> >>On 12/4/14, 12:57 PM, "Srini Addepalli" wrote: >> >>>If I take a chain with 5 services with each service say having 256=20 >>>instances for scale-out, possible number of paths are >>>256*256*256*256*256 >>>=3D 0xFF FF FF FF FF. One requires 33 bits in this case. If there are=20 >>>more services in the chain or more chains or more instances for=20 >>>scale-out, then it could go to big number very fast. >>> >>>As I mentioned my preference is to make the path ID size flexible for=20 >>>future growth. If that is perceived as complex, then going for 64bit=20 >>>is safer bet. >>> >>>Thanks >>>Srini >>> >>> >>>-----Original Message----- >>>From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>Sent: Thursday, December 04, 2014 12:05 PM >>>To: Addepalli Srini-B22160; Joel M. Halpern; sfc@ietf.org >>>Cc: NS Srinivasa Murthy-B37840 >>>Subject: Re: [sfc] Comments on SCH Draft >>>(https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >>> >>>A controller (or other decision logic) can certainly be aware of such=20 >>>concerns. >>>But the number of service function paths is not related to the number=20 >>>of flows or the number of tenants. It is related to the number of=20 >>>combinations of services and the policies for service function=20 >>>selection. >>> While that can be a large number, I sure hope it does not come close=20 >>>to saturating 24 bits. >>> >>>Having said that, if we think that 24 bits is only just enough, then=20 >>>we ought to use 32. From where I sit, I would normally expect 16=20 >>>bits to be more than sufficient, which is why I am comfortable with=20 >>>24. Having said that, the field size is not a big deal to me. >>> >>>Yours, >>>Joel >>> >>>On 12/4/14, 2:01 PM, Srini Addepalli wrote: >>>> >>>> I was not implying that path ID should have information in regards=20 >>>>to tenant/controller/flow/scale-out. But SFC controllers should=20 >>>>keep these >>>>in mind to assign the path ID. A deployment can have multiple >>>>tenants, each tenant can have multiple networks, there could be=20 >>>>millions of flows in each of those networks. And considering all=20 >>>>these, >>>> 24 bit path ID may not be able to represent paths for these flows. >>>>Hence, I was wondering whether path ID can be extended to 64 bits or=20 >>>>make it flexible. >>>> >>>> Thanks >>>> Srini >>>> >>>> ________________________________________ >>>> From: Joel M. Halpern >>>> Sent: Thursday, December 4, 2014 7:42 AM >>>> To: Addepalli Srini-B22160; sfc@ietf.org >>>> Cc: NS Srinivasa Murthy-B37840 >>>> Subject: Re: [sfc] Comments on SCH Draft >>>> (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) >>>> >>>> The Index is not just for loop prevention. In the case of=20 >>>>ambiguity, the index tells the SFF where in the path the packet=20 >>>>currently resides. >>>> There are multiple ways such ambiguity can occur. >>>> >>>> The Path Identifier is specifically not expected to include=20 >>>> controller ID or Tenant ID. While a deployer can have a path per=20 >>>> tenant, the architecture still does not treat the path ID as a=20 >>>> tenant ID. Tenant ID, controller ID, and other non-path-specifying=20 >>>> information is to be carried in metadata. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 12/4/14, 10:02 AM, Srini Addepalli wrote: >>>>> Two comments : >>>>> >>>>> >>>>> 1. SF Index : Since it is meant for loop detection, wouldn't=20 >>>>> better to rename this as "TTL"? >>>>> >>>>> 2. Path Identifier : 24 bit path identifier seems to be too less. >>>>> Based on our experience in traffic steering, this path identifier =20 >>>>>needs to encode good amount of information to make it unique. For=20 >>>>>example, >>>>> this identifier needs to encode (in our case) some information =20 >>>>>representing the distributed controller ID, tenant ID, flow ID, >>>>> Service function instance (in case of scale-out) and few more.. >>>>> One suggestion is to make it 64 bits value or to make it even=20 >>>>>extendable, >>>>> it is good if path identifier is also represented in TLV form. >>>>> >>>>> >>>>> Thanks >>>>> >>>>> Srini >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Feb 5 08:38:56 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 D32011A8981 for ; Thu, 5 Feb 2015 08:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 n834X1-CMnjk for ; Thu, 5 Feb 2015 08:38:52 -0800 (PST) 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 02FCB1A897F for ; Thu, 5 Feb 2015 08:38:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D80261C019A; Thu, 5 Feb 2015 08:38:51 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-12.clppva.east.verizon.net [70.106.134.12]) (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 1409B1C05CE; Thu, 5 Feb 2015 08:38:50 -0800 (PST) Message-ID: <54D39C93.8050704@joelhalpern.com> Date: Thu, 05 Feb 2015 11:38:43 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Nicolas BOUTHORS , "'sfc@ietf.org'" References: <76B41B8FACE1514795D30EC137FF391D7D2D2F@LILAS.jungle.qosmos.com> In-Reply-To: <76B41B8FACE1514795D30EC137FF391D7D2D2F@LILAS.jungle.qosmos.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers 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, 05 Feb 2015 16:38:54 -0000 The metadata is (generally) for the aService Functions, not for the SFF. So the quesiton of programming the SFF to process the information seems not especially major. More significantly, given that the 16 byte type 1 field may carry different things in different cases, the SFs will have to be flexible about processing the information anyway. So anything which can handle the type 2 information can be reasoanably expected to handle the same kinds of information from TLVs (whether one TLV or many). It therefore seems cleaner to me to recognize that type 1 and type 2 are different ways of carrying information, and just use the mechanism each supports. Yours, Joel On 2/4/15 12:06 PM, Nicolas BOUTHORS wrote: > It is great to have the possibility to add optional headers in NSH. However, the mechanism proposed suppose that a specific header type (the MD Type=0x2)is used in the base header when optional metadata are used. > > > > As a result: > > 1.The base header type 0x1 cannot be used with optional headers. Which > my make sense for performance point of view > > 2.Nor when using header MD type x2 can the “mandatory context headers” > be present. > > Case 2 can be worked around by defining an optional header that > represents the mandatory context header. Which is awkward as SFFs will > have to decode the same information in two different ways. Not > particularly beautiful ! > > Why not have a flag (F2)stating that no optional Metadata are present > and another one (F1) stating that (what is now called) the mandatory > context header is present or not. > > We can then specify that the combinations > > F2=False implies F1=True > > F1=True, F2=True is allowed > > F1= False, F2=True is allowed > > It seems cleaner. When present, the “mandatory context headers” would > always be at the same place in the packet. > > Nicolas > > This message and any attachments (the "message") are confidential, > intended solely for the addressees. If you are not the intended > recipient, please notify the sender immediately by e-mail and delete > this message from your system. In this case, you are not authorized to > use, copy this message and/or disclose the content to any other person. > E-mails are susceptible to alteration. Neither Qosmos nor any of its > subsidiaries or affiliates shall be liable for the message if altered, > changed or falsified. > > Ce message et toutes ses pičces jointes (ci-aprčs le "message")sont > confidentiels et établis ŕ l'intention exclusive de ses destinataires. > Si vous avez reçu ce message par erreur, merci d’en informer > immédiatement son émetteur par courrier électronique et d’effacer ce > message de votre systčme. Dans cette hypothčse, vous n’ętes pas autorisé > ŕ utiliser, copier ce message et/ou en divulguer le contenu ŕ un tiers. > Tout message électronique est susceptible d'altération. Qosmos et ses > filiales déclinent toute responsabilité au titre de ce message s'il a > été altéré, déformé ou falsifié. > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Feb 5 08:57: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 AD4D31A00CA for ; Thu, 5 Feb 2015 08:57:28 -0800 (PST) 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 6eB9_iL6OizM for ; Thu, 5 Feb 2015 08:57:24 -0800 (PST) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370051A88CF for ; Thu, 5 Feb 2015 08:57:20 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0123.003; Thu, 5 Feb 2015 08:57:19 -0800 From: Ron Parker To: "Joel M. Halpern" , Nicolas BOUTHORS , "'sfc@ietf.org'" Thread-Topic: [sfc] draft-quinn-sfc-nsh-05, optional headers Thread-Index: AdBAmYhGpM3EkfNlQ4eMZ3oRb+Ov2QBC7nyAABBDrQA= Date: Thu, 5 Feb 2015 16:57:18 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D7D2D2F@LILAS.jungle.qosmos.com> <54D39C93.8050704@joelhalpern.com> In-Reply-To: <54D39C93.8050704@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers 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, 05 Feb 2015 16:57:29 -0000 Joel, I think you are reinforcing a key assumption here -- if the SFF needs the i= nformation to do its job, then that information should be neither in Type 1= nor Type 2 metadata. As an example... depending on how our continuing = discussion on RSP ID goes (i.e, to enable both centralized concrete RSP det= ermination and distributed hop-by-hop "trail-blazed" RSP determination), we= may want to "promote" RSP ID from metadata to the standard header. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Thursday, February 5, 2015 11:39 AM To: Nicolas BOUTHORS; 'sfc@ietf.org' Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers The metadata is (generally) for the aService Functions, not for the SFF.=20 So the quesiton of programming the SFF to process the information seems n= ot especially major. More significantly, given that the 16 byte type 1 field may carry different= things in different cases, the SFs will have to be flexible about processi= ng the information anyway. So anything which can handle the type 2 informa= tion can be reasoanably expected to handle the same kinds of information fr= om TLVs (whether one TLV or many). It therefore seems cleaner to me to recognize that type 1 and type 2 are di= fferent ways of carrying information, and just use the mechanism each suppo= rts. Yours, Joel On 2/4/15 12:06 PM, Nicolas BOUTHORS wrote: > It is great to have the possibility to add optional headers in NSH. Howev= er, the mechanism proposed suppose that a specific header type (the MD Typ= e=3D0x2)is used in the base header when optional metadata are used. > > > > As a result: > > 1.The base header type 0x1 cannot be used with optional headers. Which=20 > my make sense for performance point of view > > 2.Nor when using header MD type x2 can the "mandatory context headers" > be present. > > Case 2 can be worked around by defining an optional header that=20 > represents the mandatory context header. Which is awkward as SFFs will=20 > have to decode the same information in two different ways. Not=20 > particularly beautiful ! > > Why not have a flag (F2)stating that no optional Metadata are present=20 > and another one (F1) stating that (what is now called) the mandatory=20 > context header is present or not. > > We can then specify that the combinations > > F2=3DFalse implies F1=3DTrue > > F1=3DTrue, F2=3DTrue is allowed > > F1=3D False, F2=3DTrue is allowed > > It seems cleaner. When present, the "mandatory context headers" would=20 > always be at the same place in the packet. > > Nicolas > > This message and any attachments (the "message") are confidential,=20 > intended solely for the addressees. If you are not the intended=20 > recipient, please notify the sender immediately by e-mail and delete=20 > this message from your system. In this case, you are not authorized to=20 > use, copy this message and/or disclose the content to any other person. > E-mails are susceptible to alteration. Neither Qosmos nor any of its=20 > subsidiaries or affiliates shall be liable for the message if altered,=20 > changed or falsified. > > Ce message et toutes ses pi=E8ces jointes (ci-apr=E8s le "message")sont=20 > confidentiels et =E9tablis =E0 l'intention exclusive de ses destinataires= . > Si vous avez re=E7u ce message par erreur, merci d'en informer=20 > imm=E9diatement son =E9metteur par courrier =E9lectronique et d'effacer c= e=20 > message de votre syst=E8me. Dans cette hypoth=E8se, vous n'=EAtes pas=20 > autoris=E9 =E0 utiliser, copier ce message et/ou en divulguer le contenu = =E0 un tiers. > Tout message =E9lectronique est susceptible d'alt=E9ration. Qosmos et ses= =20 > filiales d=E9clinent toute responsabilit=E9 au titre de ce message s'il a= =20 > =E9t=E9 alt=E9r=E9, d=E9form=E9 ou falsifi=E9. > > > > _______________________________________________ > 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 Thu Feb 5 16:25: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 B48871A002A for ; Thu, 5 Feb 2015 16:25:03 -0800 (PST) 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 HaXm0hKvHkJe for ; Thu, 5 Feb 2015 16:25:00 -0800 (PST) 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 B122E1A0032 for ; Thu, 5 Feb 2015 16:24:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7924; q=dns/txt; s=iport; t=1423182299; x=1424391899; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=OffwPanG1JhE0AQ9He60l73PLozKo+T16nWCTDj0Ukc=; b=YFLOq1ftR0wu8Wxiqs/JmhW7XLwjKTo3mDcYYXLd2wsSs5XU7JB7CmgT ++mIon2R9UCwocCCiWfRSwp4AZUZI7/TLSH8t4+3fNy01CSE4MfunzSa6 U5e3Q4q7urGX7NDJPWy0PJhPeNY8kNyQD3jbbCmtoZXozhFLH6FzYaQjX 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAL4I1FStJV2T/2dsb2JhbABagmQiUlkEwkQKhXECgR9DAQEBAQF9hAwBAQEEAQEBCUgRCRcEAgEIEQEDAQEBJwcnCxQDBggBAQQBEogtAQzWHgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEj0UIMgIEhCMFjTWBY4QzhHmBF4MDgkaITYM+IoNub4FEfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,526,1418083200"; d="scan'208";a="393935862" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP; 06 Feb 2015 00:24:58 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t160Ow4W029112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Feb 2015 00:24:58 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Thu, 5 Feb 2015 18:24:58 -0600 From: "Ken Gray (kegray)" To: Ron Parker , "Joel M. Halpern" , Nicolas BOUTHORS , "'sfc@ietf.org'" Thread-Topic: [sfc] draft-quinn-sfc-nsh-05, optional headers Thread-Index: AdBAmYhGpM3EkfNlQ4eMZ3oRb+Ov2QA+vZmAAACmJgAABSfyAA== Date: Fri, 6 Feb 2015 00:24:57 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D7D2D2F@LILAS.jungle.qosmos.com> <54D39C93.8050704@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.24.215.220] Content-Type: text/plain; charset="Windows-1252" Content-ID: <6E46E0ACF7BABE43B893ECADA2B2EA25@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers 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, 06 Feb 2015 00:25:03 -0000 I think there=B9s a disconnection here (could be me) between the idea of an abstract and specific path. I thought it was pretty clear (and there was significant talk about it here on the list) that you can't mandate a specific model of function elasticity - we couldn=B9t declare load balancing devices or functions =B3dead=B2 but instead assumed that elasticity could be done locally as a S= F, as part of a composite function where the load balancer exists as part of the logical function being rendered or centrally/statically. We had similar dialogues about the need to remain abstract around HA techniques as well.=20 These things make AN individual path, which represents a chain that fits a specific policy ruleset =8A variable =8A and we didn=B9t want to unnecessar= ily define multiple discrete chains to cover this sort of function variance (which can become quite large, if for example the function X at site Y is actually 1000 parallel instances to accommodate load, with HA add a multiplier, per function more multipliers =8Afor a single path that at the abstract level, traversed the same sites =8Aboom). These dialogues are captured in the architecture document. So, when I read the NSH draft, I interpreted the treatment of the SPI and the Resolved Path as very compatible with that abstraction/concept. It makes multiple deployment contexts understandable and possible without overly defining the header with potentially useless fields for every iterable case. (Editorial - Kind of an art form that we should celebrate, IMO, if people are going about designing protocols.) For example, the SFF can be seeded with one and only one NH for the SI/SPI match - thus the path is resolved and the SI/SPI path IS the rendered path. The =B3directed=B2 graph that some wanted (where each individual element in a locally elastic pool is individually addressable and set at classification) is really a derivative of the same case. If there is more than one NH seeded for the SI/SPI, then the SFF either will treat the forwarding as ECMP (e.g. stateless to an anycast pool - SI/SPI IS the rendered path), or have a local policy to perform an explicit mapping. The SFF may also be just handing the packet w/NSH header off to a local integrated function (like a load balancer) or an attached composite function that is handling an explicit mapping to function instances it fronts (and managing same somewhat obliquely to the SFF and the path itself). These new contexts don=B9t NEED and shouldn=B9t GET a separate field in the general header. IF, for example, the resolution/mapping of either the local SFF policy (or the oblique function) is a policy keyed to classification info like flowID, tenantID, sessionID, something proprietary - well, you=B9ve just redefined the need for metadata (one of our goals was to be able to preserve classifier info in metadata to avoid excessive classification), which we all agreed to already - and we know where to find such a key so there=B9s no need to move it. (Editorial - Not= e also the potential for variance of the key source/value across implementations.) You shouldn't NEED an explicit RSP ID in the fixed header. That seems to work back against the original implicit design goal of the header. I dunno, if it=B9s just me, I haven=B9t done protocol design since college = =8A maybe I=B9m rusty or I need something stronger to drink. =20 Cheers. On 2/5/15, 11:57 AM, "Ron Parker" wrote: >Joel, > >I think you are reinforcing a key assumption here -- if the SFF needs the >information to do its job, then that information should be neither in >Type 1 nor Type 2 metadata. As an example... depending on how our >continuing discussion on RSP ID goes (i.e, to enable both centralized >concrete RSP determination and distributed hop-by-hop "trail-blazed" RSP >determination), we may want to "promote" RSP ID from metadata to the >standard header. > > Ron > > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >Sent: Thursday, February 5, 2015 11:39 AM >To: Nicolas BOUTHORS; 'sfc@ietf.org' >Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers > >The metadata is (generally) for the aService Functions, not for the SFF. > So the quesiton of programming the SFF to process the information seems >not especially major. > >More significantly, given that the 16 byte type 1 field may carry >different things in different cases, the SFs will have to be flexible >about processing the information anyway. So anything which can handle >the type 2 information can be reasoanably expected to handle the same >kinds of information from TLVs (whether one TLV or many). > >It therefore seems cleaner to me to recognize that type 1 and type 2 are >different ways of carrying information, and just use the mechanism each >supports. > >Yours, >Joel > >On 2/4/15 12:06 PM, Nicolas BOUTHORS wrote: >> It is great to have the possibility to add optional headers in NSH. >>However, the mechanism proposed suppose that a specific header type (the >> MD Type=3D0x2)is used in the base header when optional metadata are used= . >> >> >> >> As a result: >> >> 1.The base header type 0x1 cannot be used with optional headers. Which >> my make sense for performance point of view >> >> 2.Nor when using header MD type x2 can the "mandatory context headers" >> be present. >> >> Case 2 can be worked around by defining an optional header that >> represents the mandatory context header. Which is awkward as SFFs will >> have to decode the same information in two different ways. Not >> particularly beautiful ! >> >> Why not have a flag (F2)stating that no optional Metadata are present >> and another one (F1) stating that (what is now called) the mandatory >> context header is present or not. >> >> We can then specify that the combinations >> >> F2=3DFalse implies F1=3DTrue >> >> F1=3DTrue, F2=3DTrue is allowed >> >> F1=3D False, F2=3DTrue is allowed >> >> It seems cleaner. When present, the "mandatory context headers" would >> always be at the same place in the packet. >> >> Nicolas >> >> This message and any attachments (the "message") are confidential, >> intended solely for the addressees. If you are not the intended >> recipient, please notify the sender immediately by e-mail and delete >> this message from your system. In this case, you are not authorized to >> use, copy this message and/or disclose the content to any other person. >> E-mails are susceptible to alteration. Neither Qosmos nor any of its >> subsidiaries or affiliates shall be liable for the message if altered, >> changed or falsified. >> >> Ce message et toutes ses pi=E8ces jointes (ci-apr=E8s le "message")sont >> confidentiels et =E9tablis =E0 l'intention exclusive de ses destinataire= s. >> Si vous avez re=E7u ce message par erreur, merci d'en informer >> imm=E9diatement son =E9metteur par courrier =E9lectronique et d'effacer = ce >> message de votre syst=E8me. Dans cette hypoth=E8se, vous n'=EAtes pas >> autoris=E9 =E0 utiliser, copier ce message et/ou en divulguer le contenu= =E0 >>un tiers. >> Tout message =E9lectronique est susceptible d'alt=E9ration. Qosmos et se= s >> filiales d=E9clinent toute responsabilit=E9 au titre de ce message s'il = a >> =E9t=E9 alt=E9r=E9, d=E9form=E9 ou falsifi=E9. >> >> >> >> _______________________________________________ >> 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 Thu Feb 5 21:36:46 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 99FD11A01F2 for ; Thu, 5 Feb 2015 21:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, 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 PRb0J62EmkbE for ; Thu, 5 Feb 2015 21:36:38 -0800 (PST) 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 567D11A020D for ; Thu, 5 Feb 2015 21:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22066; q=dns/txt; s=iport; t=1423200997; x=1424410597; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6JLUKhXb0O4FNghXPfpyyoNgk1pk0YmqLQv+9wcuRVc=; b=DZcJTNtABPz8LhnzEF5vAY4taD/HFuXeY+PtlzVIIP6Egzj75lYoLy3K NV3IepNCxxmvk2EFaHCyW29EwC+Y7MPdbeTSZvQugGSAwBAuoi4OBVEeg V+7fPcKS+lhPvd+RqjOsBQ0NAEP8HdYnZYTOrqtOYjqgbRM6P1zIVuosg 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BeBQDAUdRU/4YNJK1XA4MGUlkEgn2/RwqFcQIcf0MBAQEBAX2EDAEBAQQBAQExMwcLDAQCAQgRAQMBAQEEIwUCAiULFAMGCAIEAQ0FFAWIFA2iMJxkBpYvAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBG4hzhQcwCBALEAcCAgILglGBRwWPGINQhVyBF4MDgkaITYM+IoICHBSBPG8BgUN+AQEB X-IronPort-AV: E=Sophos;i="5.09,527,1418083200"; d="scan'208";a="121092183" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 06 Feb 2015 05:36:36 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t165aZic019486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Feb 2015 05:36:35 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.220]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Thu, 5 Feb 2015 23:36:35 -0600 From: "Reinaldo Penno (repenno)" To: "Elzur, Uri" , Cathy Zhang , "Ken Gray (kegray)" , "Srini Addepalli" , "Joel M. Halpern" , "'sfc@ietf.org'" Thread-Topic: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) Thread-Index: AQHQD9FqH/wTNyDwgkS9ydl+3/sIXZx/9uiAgAA3l4CAABF6AIAADr2AgAAFm4CAASdXgIAABAoAgAACLgCAAEtwAIBWb4+AgAdtFgCAALR5gIABZ2FQgAGWwoA= Date: Fri, 6 Feb 2015 05:36:35 +0000 Message-ID: References: <1417705315845.11888@freescale.com> <54808103.8020807@joelhalpern.com> <1417719712539.38767@freescale.com> <5480BE4E.1080408@joelhalpern.com> <1417791258295.92226@freescale.com> <1417792592229.41970@freescale.com> <7E05C330D7FD6D4FAD0728C46B89958581B66406@ORSMSX114.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B89958581B66406@ORSMSX114.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.24.144.108] Content-Type: text/plain; charset="euc-kr" Content-ID: <31DEB684D8FF7C498D5DD4E517FC9883@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "nsmurthy@freescale.com" Subject: Re: [sfc] Comments on SCH Draft (https://tools.ietf.org/html/draft-zhang-sfc-sch-02) 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, 06 Feb 2015 05:36:42 -0000 U2FtZSBoZXJlLiBOb3Qgc3VyZSB3aHkgd2UgYXJlIHN0aWxsIHBsYXlpbmcgIndoZXJlJ3MgaXMg V2FsZG8/IiBhY3Jvc3MNCnRoZXNlIHR3byBkcmFmdHMuIA0KDQoNCk9uIDIvNC8xNSwgOTo0NiBQ TSwgIkVsenVyLCBVcmkiIDx1cmkuZWx6dXJAaW50ZWwuY29tPiB3cm90ZToNCg0KPkFzc3VtaW5n IHRoZSBpc3N1ZXMgbGlzdGVkIGJlbG93IGFyZSB0aGUgY29tcGxldGUgc2V0IG9mICJkZWx0YSIg YmV0d2Vlbg0KPnRoZSBkcmFmdHMsIGl0IG1ha2VzIHNlbnNlIHRvIHJlYWNoIG91dCB0byBOU0gg YXV0aG9ycyBhbmQgdHJ5IHRvIHJlYWNoDQo+YW4gYWNjZXB0YWJsZSBjb21wcm9taXNlLCB3aGlj aCBpcyBwYXJ0IG9mIHRoZSBzdGFuZGFyZGl6YXRpb24gcHJvY2Vzcy4gSQ0KPmRvIG5vdCBzZWUg aW4gdGhhdCBsaXN0IGEgZnVuZGFtZW50YWxseSBkaWZmZXJlbnQgYXBwcm9hY2ggdGhhdCB3YXJy YW50cw0KPmFub3RoZXIgZHJhZnQsIGl0IHNlZW1zIGxpa2UgZmVhdHVyZSBsZXZlbCBkaXNhZ3Jl ZW1lbnQvIHByZWZlcmVuY2UNCj5kaWZmZXJlbmNlIGV0Yy4gSXQgY2FuIGFsc28gYmUgZGlzY3Vz c2VkIG9uIHRoZSBtbCBvciBkdXJpbmcgdGhlIG5leHQNCj5tZWV0aW5nDQo+DQo+SSdsbCBqb2lu IG90aGVyIHdobyBtZW50aW9uZWQgd2Ugc2hvdWxkIGdvIGFoZWFkIHcgTlNIIGRyYWZ0DQo+VGh4 DQo+DQo+VXJpICgiT28tUmVlIikNCj5DOiA5NDktMzc4LTc1NjgNCj4NCj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQ2F0aHkgWmhhbmcNCj5TZW50OiBUdWVzZGF5LCBGZWJydWFyeSAzLCAyMDE1 IDE6NTQgUE0NCj5UbzogS2VuIEdyYXkgKGtlZ3JheSk7IFNyaW5pIEFkZGVwYWxsaTsgUmVpbmFs ZG8gUGVubm8gKHJlcGVubm8pOyBKb2VsIE0uDQo+SGFscGVybjsgJ3NmY0BpZXRmLm9yZyc7IENh dGh5IFpoYW5nDQo+Q2M6IG5zbXVydGh5QGZyZWVzY2FsZS5jb20NCj5TdWJqZWN0OiBSZTogW3Nm Y10gQ29tbWVudHMgb24gU0NIIERyYWZ0DQo+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPg0KPkhpIEtlbiwNCj4NCj5QbGVhc2Ugc2VlIGlubGlu ZS4NCj4NCj5UaGFua3MsDQo+Q2F0aHkNCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PkZyb206IEtlbiBHcmF5IChrZWdyYXkpIFttYWlsdG86a2VncmF5QGNpc2NvLmNvbV0NCj5TZW50 OiBUdWVzZGF5LCBGZWJydWFyeSAwMywgMjAxNSAxMDowOSBBTQ0KPlRvOiBDYXRoeSBaaGFuZzsg U3JpbmkgQWRkZXBhbGxpOyBSZWluYWxkbyBQZW5ubyAocmVwZW5ubyk7IEpvZWwgTS4NCj5IYWxw ZXJuOyAnc2ZjQGlldGYub3JnJw0KPkNjOiBuc211cnRoeUBmcmVlc2NhbGUuY29tDQo+U3ViamVj dDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPihodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtemhhbmctc2ZjLXNjaC0wMikNCj4NCj5BcyBhIGdlbmVyYWwgY29tbWVu dCBvbiB0aGlzIHN1Ym1pc3Npb24gKGFuZCBwZXJoYXBzIGxpZmUgaW4gdGhlIGN1cnJlbnQNCj5J RVRGKS4gIEkgaGF2ZSBhIFJFQUxMWSBoYXJkIHRpbWUgZGlmZmVyZW50aWF0aW5nIHRoaXMgZHJh ZnQgZnJvbSB0aGUNCj5xdWlubiBkcmFmdCAod2hpY2ggcHJlLWRhdGVzIGl0IGJ5IHF1aXRlIGEg Yml0KS4gIFdoeSBhcmUgd2UgcHVyc3VpbmcgYQ0KPnNlcGFyYXRlIGRyYWZ0IHdoZW4gdGhlIHN1 Z2dlc3Rpb25zLCBJTUhPLCBzZWVtIGluY3JlbWVudGFsIGF0IGJlc3Q/DQo+DQo+DQo+Q2F0aHk+ IFRoZSBvcmlnaW5hbCBtb3RpdmF0aW9uIGZvciBkcmFmdGluZyB0aGUgU0NIIGlzIHRvIHByb3Zp ZGUgYW4NCj5hbHRlcm5hdGl2ZSB0byBkcmFmdC1xdWlubi1uc2ggdG8gYWRkcmVzcyB0aGUgZm9s bG93aW5nIHBlcmNlaXZlZCBpc3N1ZXM6DQo+MS4gTWFuZGF0b3J5IGZpeGVkLXNpemVkIG1ldGFk YXRhLiBXZSB0aGluayB0aGV5IHNob3VsZCBub3QgYmUgbWFuZGF0b3J5DQo+c2luY2UgdGhlIDQt d29yZCBjb250ZXh0IGZpZWxkcyBhcmUgbm90IG5lZWRlZCBpbiBtYW55IHNjZW5hcmlvcyAyLiBO bw0KPnZhcmlhYmxlIGxlbmd0aCBtZXRhZGF0YS4gV2UgdGhpbmsgbWV0YWRhdGEgc2hvdWxkIGJl IG9wdGlvbmFsIGFuZCBUTFYNCj5mb3JtYXQgc2hvdWxkIGJlIHVzZWQgdG8gZGVmaW5lIG1ldGFk YXRhIDMuIE5vIG9yZ2FuaXphdGlvbmFsbHkgZGVmaW5lZA0KPm1ldGFkYXRhIDQuIE5vIFZlcnNp b24gZmllbGQuDQo+V2hlbiB3ZSB1cGxvYWRlZCBTQ0ggMXN0IHZlcnNpb24gKDMvMjQvMjAxNCks IE5TSCB2ZXJzaW9uIGRpZCBub3QgaGF2ZQ0KPnRoZSBUTFYgbWV0YWRhdGEgYW5kIHZlcnNpb24g ZmllbGQgKHRoZXkgd2VyZSBhZGRlZCBpbiBpdHMgbGF0ZXIgdmVyc2lvbikuDQo+DQo+DQo+DQo+ SSBoYXZlIHJlYWNoIG91dCB0byB0aGUgY2hhaXJzIGhlcmUgLiB3ZSBoYXZlIGEgbG90IHRvIHJl YWQuIEFyZW4ndA0KPmRyYWZ0cyBzdXBwb3NlZCB0byBvZmZlciBzaWduaWZpY2FudGx5IGRpZmZl cmVudCB2aWV3cyBpZiB0aGV5IGFyZSB0bw0KPnBlcnNpc3QgKHdpdGhvdXQgdGhhdCwgYSAiY2Fs bCB0byBhZG9wdCIgYmVjb21lcyBhIGJlYXV0eSBjb250ZXN0LCBJTU8pPw0KPk5vIG9mZmVuc2Ug dG8gdGhlIGF1dGhvcnMsIGJ1dCB3ZSdyZSBpbiByZXZpc2lvbiAzIGFuZCBJIGRvbid0IHNlZSB0 aGF0DQo+aGVyZS4NCj4gDQo+DQo+UmVnYXJkaW5nIHRoZSBjaGFuZ2VzIGluIHRoaXMgZG9jdW1l bnQ6DQo+DQo+SSBkbyBub3QgZmluZCB0aGUgZmxvdyBJRCBmdW5jdGlvbmFsbHkgZGlmZmVyZW50 IHRoYW4gdGhlIHVzZSBjb250ZXh0DQo+aGVhZGVycyBpbiB0aGUgbnNoIGRyYWZ0LCB3aGljaCBz ZWVtIHRvIGJlIGEgbW9yZSBtdWx0aS1wdXJwb3NlIGNvbmNlcHQuDQo+DQo+Q2F0aHk+IERpZmZl cmVudCBwZW9wbGUgaGF2ZSBkaWZmZXJlbnQgdmlld3BvaW50cy4gUlNQIElEIGlzIG5vdCBkZWZp bmVkDQo+aW4gTlNIIGFuZCBmcm9tIFBhdWwgKE5TSCBhdXRob3IpJ3MgcmVwbHksIGl0IHNlZW1z IGhlIGRvZXMgbm90IGZlZWwgdGhlDQo+bmVlZCBvZiBhbiBSU1AgSUQuDQo+Q2F0aHk+IFdlIHNl ZSB0aGUgbmVlZCBmb3IgUlNQIElEIGFuZCB0aHVzIGRlZmluZWQgaXQgaW4gU0NIIGZvciBvcGVu DQo+ZGlzY3Vzc2lvbiBhbmQgd291bGQgbGlrZSB0byBzZWUgdGhlIGNvbW11bml0eSdzIGZlZWRi YWNrIG9uIGl0Lg0KPg0KPlRoZSBCIGJpdCBzdWdnZXN0aW9uIGNhbiBjYXVzZSBhIGNvbmZsaWN0 IGluIGNvbnRyb2wgYW5kIGNyZWF0ZSBhbiBhdmVudWUNCj5mb3IgdW5kZXNpcmFibGUgYmVoYXZp b3IsIElNTy4gIEkndmUgYmVlbiB3b3JraW5nIGZyb20gdGhlIGFzc3VtcHRpb24NCj50aGF0IGEg bWluaW11bSByZXF1aXJlbWVudCBvZiBhIGZ1bmN0aW9uIGlzIHRoYXQgaXQgYmUgbWFuYWdlYWJs ZSAoaWYgZm9yDQo+bm8gb3RoZXIgcmVhc29uIHRoYW4gZWZmZWN0aXZlIGVsYXN0aWNpdHkgYW5k IGNvaGVzaXZlL3ByZWRpY3RhYmxlDQo+ZGVsaXZlcnkgb2Ygc2VydmljZSksIHNvIEkgaGF2ZSBs aXR0bGUgc3ltcGF0aHkgZm9yIHRob3NlIHRoYXQgYXJlIG5vdCAtDQo+YmUgdGhleSB2aXJ0dWFs IG9yIHBoeXNpY2FsIChldmVuIGxlc3Mgc3ltcGF0aHkgZm9yIHZpcnR1YWwgZnVuY3Rpb25zDQo+ dGhhdCBhcmUgdW5tYW5hZ2VhYmxlLCBmcmFua2x5KS4gIEEgc2VsZi1tYW5hZ2VtZW50IG9wdGlv biBpbiB0aGUgU0ZDDQo+c2NlbmFyaW8gaGFzIGxvdyB2YWx1ZSBhbmQgdGhlIGNvcnJ1cHRpb24g b3IgbWlzdXNlIG9mIHRoZSBiaXQgY2FuIGNhdXNlDQo+Y2hhb3MgKGFuIGV4dHJhIGxldmVsIG9m ICJmYWlsIikuDQo+DQo+Q2F0aHk+IENvdWxkIHlvdSBjbGFyaWZ5IHdoYXQgeW91IG1lYW4gYnkg ImNhdXNlIGEgY29uZmxpY3QgaW4gY29udHJvbCI/DQo+DQo+DQo+VGhlIEdlbmVyaWMgQ29udGV4 dCBCbG9jayBpcyBjb25mdXNpbmcgaW4gbGlnaHQgb2YgdGhlIGFscmVhZHkgZXh0YW50DQo+b3B0 aW9uYWwvdmFyaWFibGUgbWV0YWRhdGEgVExWcyAod2h5IHdvdWxkbid0IHlvdSBsZXZlcmFnZSBv bmUgb2YgdGhlbSk/DQo+DQo+Q2F0aHk+IEkgYW0gbm90IHN1cmUgaWYgSSB1bmRlcnN0YW5kIHlv dXIgcG9pbnQuIFRoZSBHZW5lcmljIENvbnRleHQNCj5CbG9jayBpcyBvbmUgdHlwZSBvZiBtZXRh ZGF0YSB3aGljaCBpcyBpbiBUTFYgZm9ybWF0IGFuZCBpcyBvcHRpb25hbC4NCj4NCj5UaGFua3Ms DQo+Q2F0aHkNCj4NCj4NCj5PbiAxLzI5LzE1LCAyOjQ0IFBNLCAiQ2F0aHkgWmhhbmciIDxDYXRo eS5ILlpoYW5nQGh1YXdlaS5jb20+IHdyb3RlOg0KPg0KPj5IaSBldmVyeW9uZSwNCj4+DQo+Pldl IGhhdmUgdXBsb2FkZWQgYSBuZXcgU0NIIHZlcnNpb24gKDMpIHdoaWNoIGFkZHMgZGVmaW5pdGlv biBvZiBhIG5ldw0KPj5tZXRhZGF0YSB0eXBlIGZvciB0aGUgZmxvdyBJRCB0byBzdXBwb3J0IGxv YWQgYmFsYW5jaW5nIGFtb25nIFNGDQo+Pmluc3RhbmNlcyBhbmQgbWl0aWdhdGUgdGhlIHBvdGVu dGlhbCBpc3N1ZSBvZiAibm90IGVub3VnaCBwYXRoIElEIi4gVGhlDQo+PmZsb3cgSUQgaXMgbmFt ZWQgInJlbmRlcmVkIHNlcnZpY2UgcGF0aCBJRCIgaW4gdGhlIGRyYWZ0LiBQbGVhc2UgcmVmZXIN Cj4+dG8gc2VjdGlvbiA0LjMuMiBvZg0KPj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC16aGFuZy1zZmMtc2NoLw0KPj5mb3IgZGV0YWlsIGRlc2NyaXB0aW9uLg0KPj4gDQo+ Pg0KPj5JbiBpdHMgcHJldmlvdXMgdmVyc2lvbiwgU0NIIGRlZmluZXMgYSAiQnlwYXNzIGJpdCIg aW4gdGhlIGJhc2UgaGVhZGVyLg0KPj5UaGlzIGJpdCBlbmFibGVzIHRoZSBTRiB0byBwcm92aWRl IGZlZWRiYWNrL25vdGlmaWNhdGlvbiB2aWEgdGhlIGRhdGENCj4+cGF0aCB0byBpdHMgY29ubmVj dGluZyBTRkYgYWJvdXQgd2hldGhlciB0aGUgcmVtYWluaW5nIHBhY2tldHMgb2YgdGhlDQo+PlNG QyBzaG91bGQgYnlwYXNzIHRoYXQgU0YuIFRoaXMgaXMgdXNlZnVsIGluIHRoZSBjYXNlIHRoYXQg b25seSB0aGUNCj4+Zmlyc3QgZmV3IHBhY2tldHMgb2YgYSBmbG93IG5lZWQgdG8gZ28gdG8gYSBT RiAoc3VjaCBhcyBhIERQSSBvciBGVyBvcg0KPj5JRFMpIGFuZCByZW1haW5pbmcgcGFja2V0cyBj YW4gYnlwYXNzIHRoYXQgU0YsIHRodXMgc2F2aW5nIHRoZQ0KPj5leHBlbnNpdmUgU0YgcmVzb3Vy Y2UgYW5kIHJlZHVjaW5nIGRhdGEgcGF0aCBsYXRlbmN5Lg0KPj4NCj4+QiBiaXQ6IFRoZSBCIChC eXBhc3MpIGJpdCwgd2hlbiBzZXQgdG8gMSwgaXQgaXMgdXNlZCBieSBhIFNlcnZpY2UNCj4+ICAg ICAgIEZ1bmN0aW9uIHRvIHNpZ25hbCB0byBpdHMgU2VydmljZSBGdW5jdGlvbiBGb3J3YXJkZXIg dGhhdCBubw0KPj4gICAgICAgZnVydGhlciBwYWNrZXRzIGFyZSB0byBiZSBzZW50IHRvIGl0IGZv ciB0aGUgZmxvdyBzcGVjaWZpZWQgaW4NCj4+ZW5jYXBzdWxhdGVkIHBhY2tldC4NCj4+DQo+Pklu IGFkZGl0aW9uLCBTQ0ggZGVmaW5lcyBhIG1ldGFkYXRhIHR5cGUgZm9yIEdlbmVyaWMgQ29udGV4 dCBCbG9jaywNCj4+d2hpY2ggaXMgb3B0aW9uYWwgYW5kIGNhbiBiZSB1c2VkIGlmIG5lZWRlZCB0 byBjYXJyeSBhbnkgdmVuZG9yJ3MNCj4+c3BlY2lmaWMgIkNvbnRleHQgSGVhZGVyIi4NCj4+IA0K Pj4NCj4+QW55IGNvbW1lbnRzIG9uIHRoZXNlIG5ldyBhZGRpdGlvbnM/DQo+Pg0KPj5UaGFua3Ms DQo+PkNhdGh5DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBzZmMg W21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENhdGh5IFpoYW5nDQo+ PlNlbnQ6IEZyaWRheSwgRGVjZW1iZXIgMDUsIDIwMTQgMTE6NDcgQU0NCj4+VG86IFNyaW5pIEFk ZGVwYWxsaTsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBKb2VsIE0uIEhhbHBlcm47DQo+Pidz ZmNAaWV0Zi5vcmcnDQo+PkNjOiBuc211cnRoeUBmcmVlc2NhbGUuY29tDQo+PlN1YmplY3Q6IFJl OiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4NCj4+Um9uLCBMb3VpcywgTXlvIGFuZCBJ IGhhdmUgYmVlbiBkaXNjdXNzaW5nIG9mZiBsaW5lIGxhc3QgZmV3IHdlZWtzDQo+PmFib3V0IGRl ZmluaW5nIGEgbWV0YWRhdGEgdHlwZSBmb3IgZmxvdyBJRCBpbiBhZGRpdGlvbiB0byB0aGUgcGF0 aCBJRA0KPj5vZiB0aGUgbWFpbiBoZWFkZXIgdG8gc3VwcG9ydCBsb2FkIGJhbGFuY2luZyBhbW9u ZyBTRiBpbnN0YW5jZXMuIFdlDQo+PndpbGwgZGVmaW5lIGEgVExWIHR5cGUgZm9yIHRoZSBmbG93 IElELiBUaGUgY29tYmluYXRpb24gb2YgInBhdGggSUQgKw0KPj5mbG93IElEIg0KPj5zcGVjaWZp ZXMgYSByZWFsaXplZCBzZXJ2aWNlIGNoYWluIGluc3RhbmNlIHBhdGguIEl0IGlzIGxlZnQgdG8g dGhlDQo+PmRlc2lnbi9pbXBsZW1lbnRhdGlvbiB3aGV0aGVyIHRvIHVzZSBhIGNlbnRyYWxpemVk IG1ldGhvZCBvciBhDQo+PmRpc3RyaWJ1dGVkIG1ldGhvZCB0byBiaW5kIHRoZSBmbG93IElEIHRv IGEgcmVhbGl6ZWQgc2VydmljZSBpbnN0YW5jZQ0KPj5wYXRoIGFsdGhvdWdoIG91ciBvcmlnaW5h bCB0aG91Z2h0IGlzIGZvciBkaXN0cmlidXRlZCBMQiB1c2FnZS4gSSBhbQ0KPj5ub3Qgc3VyZSBp ZiB3ZSBuZWVkIGEgYml0IGluIHRoZSBoZWFkZXIgdG8gZGVub3RlIHdoZXRoZXIgdGhlcmUgYXJl DQo+Pm1vcmUgcGF0aCBJRCBiaXRzICh3ZSBjYWxsIGl0IGZsb3cgSUQpIGluIHRoZSBtZXRhZGF0 YSBmaWVsZHMgc2luY2UNCj4+d2hlbiB5b3UgcGFyc2UgdGhlIFRMViBtZXRhZGF0YSwgeW91IHdp bGwga25vdyB3aGV0aGVyIHRoZXJlIGFyZSBmbG93IElEDQo+PmJpdHMgb3Igbm90Lg0KPj5Ob3Rl IHRoYXQgaWYgbXVsdGlwbGUgc2Vzc2lvbnMgc2hhcmUgdGhlIHNhbWUgcmVhbGl6ZWQgc2Vydmlj ZSBpbnN0YW5jZQ0KPj5wYXRoLCB0aGV5IHdpbGwgc2hhcmUgdGhlIHNhbWUgInBhdGggSUQrIGZs b3cgSUQiLiAgV2UgY2FuIGFsc28NCj4+Y29uc2lkZXIgZXh0ZW5kaW5nIHRoZSBudW1iZXIgb2Yg Yml0cyB0byAzMiBpZiB0aGF0IGlzIHRoZSBjb25zZW5zdXMuDQo+PldlIHdpbGwgcG9zdCBhbiB1 cGRhdGVkIGRyYWZ0IGRlc2NyaWJpbmcgdGhlc2Ugc29vbi4NCj4+DQo+PlRoYW5rcywNCj4+Q2F0 aHkNCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IHNmYyBbbWFpbHRv OnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgU3JpbmkgQWRkZXBhbGxpDQo+PlNl bnQ6IEZyaWRheSwgRGVjZW1iZXIgMDUsIDIwMTQgNzoxNyBBTQ0KPj5UbzogUmVpbmFsZG8gUGVu bm8gKHJlcGVubm8pOyBKb2VsIE0uIEhhbHBlcm47ICdzZmNAaWV0Zi5vcmcnDQo+PkNjOiBuc211 cnRoeUBmcmVlc2NhbGUuY29tDQo+PlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0gg RHJhZnQNCj4+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2No LTAyKQ0KPj4NCj4+DQo+PltSUF0gRGF0YSBwbGFuZSBlZmZpY2llbmN5Lg0KPj4NCj4+U1JJTkk+ IEkgYW0gbm90IHNvIHN1cmUgYWJvdXQgZGF0YSBwbGFuZSBlZmZpY2llbmN5LiAgTW9zdCBvZiB0 aGUNCj4+cHJvY2Vzc29ycyB3b3JrIGdvb2QgaWYgdGhlIG51bWJlciBvZiBiaXRzIGFyZSBlaXRo ZXIgMzIgb3IgNjQuICBJZiBpdA0KPj5pcw0KPj4yNCBiaXRzLCB0aGVuIG9uZSBuZWVkcyB0byBk byBtYXNraW5nIGFuZCBzaGlmdGluZyBiZWZvcmUgdGhlIHZhbHVlIGlzDQo+PnVzZWQgdG8gZG8g YW55IGxvb2t1cC4gICBCdXQsIHRoaXMgZGlzY3Vzc2lvbiBjYW4gZ28gaW50byBkaWZmZXJlbnQN Cj4+ZGlyZWN0aW9uIDotKSwgaXQgbWF5IG5vdCBiZSBnb29kIHRvIGdvIGluIHRoYXQgZGlyZWN0 aW9uLg0KPj4NCj4+V2hlcmUgZG8gd2UgZHJhdyB0aGUgbGluZT8gMzItYml0cywgNjQtYml0cywN Cj4+MTI4IGJpdHM/IEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgYSBzZW5zaWJsZSB2YWx1ZSBpbiB0 aGUgU2VydmljZSBQYXRoDQo+PmhlYWRlciBhbmQgaWYgeW91IG5lZWQgdG8gY29udmV5IG1vcmUg Yml0cyB5b3UgbmVlZCB0byB1c2UgdGhlIGNvbnRleHQNCj4+aGVhZGVycy4NCj4+DQo+PlNSSU5J PiBUaGlzIGlzIGEgZ29vZCBwb2ludC4gIFRoaXMgc2hvdWxkIHdvcmsgZmluZSBhcyBsb25nIGFz IHRoZXJlIGlzDQo+PndheSB0byBjb252ZXkgaW4gdGhlIG1haW4gaGVhZGVyIHRoYXQgdGhlIGV4 dGVuc2lvbiB0byBwYXRoIElEIGlzDQo+PmF2YWlsYWJsZSBpbiBzbyBhbmQgc28gVExWIGZpZWxk LiAgVGhhdCBzaG91bGQgd29yayB0b28uDQo+Pg0KPj5UaGFua3MNCj4+U3JpbmkNCj4+DQo+Pl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+RnJvbTogUmVpbmFsZG8g UGVubm8gKHJlcGVubm8pIDxyZXBlbm5vQGNpc2NvLmNvbT4NCj4+U2VudDogRnJpZGF5LCBEZWNl bWJlciA1LCAyMDE0IDc6MDggQU0NCj4+VG86IEFkZGVwYWxsaSBTcmluaS1CMjIxNjA7IEpvZWwg TS4gSGFscGVybjsgJ3NmY0BpZXRmLm9yZycNCj4+Q2M6IE5TIFNyaW5pdmFzYSBNdXJ0aHktQjM3 ODQwDQo+PlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4+KGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4NCj4+T24g MTIvNS8xNCwgNjo1NCBBTSwgIlNyaW5pIEFkZGVwYWxsaSIgPHNhZGRlcGFsbGlAZnJlZXNjYWxl LmNvbT4gd3JvdGU6DQo+Pg0KPj4+DQo+Pj5JbiByZWFsIGRlcGxveW1lbnRzLCBudW1iZXIgb2Yg YWN0aXZlIHBhdGggSURzIGFyZSB2ZXJ5IGxlc3NlciB0aGFuDQo+Pj4yXjY0LCBidXQgdGhlcmUg aXMgYSBnb29kIHBvc3NpYmlsaXR5IG9mIHRoZSBudW1iZXIgYmVpbmcgbW9yZSB0aGFuDQo+Pj4y XjI0ICgxNk0pLg0KPj4+IEkgdGhpbmsgYmlnZ2VyIHBvaW50IGlzIHRoYXQgd2h5IHJlc3RyaWN0 IHRoaXMgaW4gdGhlIHN0YW5kYXJkcz8gV2hhdA0KPj4+YWR2YW50YWdlIGRvIHdlIGhhdmUgcmVz dHJpY3RpbmcgdGhpcyBzaXplIHRvIDI0IGJpdHM/DQo+Pg0KPj5bUlBdIERhdGEgcGxhbmUgZWZm aWNpZW5jeS4gV2hlcmUgZG8gd2UgZHJhdyB0aGUgbGluZT8gMzItYml0cywNCj4+NjQtYml0cywN Cj4+MTI4IGJpdHM/IEkgdGhpbmsgd2Ugc2hvdWxkIGhhdmUgYSBzZW5zaWJsZSB2YWx1ZSBpbiB0 aGUgU2VydmljZSBQYXRoDQo+PmhlYWRlciBhbmQgaWYgeW91IG5lZWQgdG8gY29udmV5IG1vcmUg Yml0cyB5b3UgbmVlZCB0byB1c2UgdGhlIGNvbnRleHQNCj4+aGVhZGVycy4NCj4+DQo+Pg0KPj4+ DQo+Pj5UaGVyZSBjYW4gYmUgZGVwbG95bWVudHMsIHdoZXJlIFNGQyBjb250cm9sbGVyIChMb2dp Y2FsbHkgY2VudHJhbCwgYnV0DQo+Pj5kaXN0cmlidXRlZCkgIGl0c2VsZiBjYW4gZG8gdGhlIFNG IGluc3RhbmNlIHNlbGVjdGlvbiBvbiBwZXINCj4+PmNvbm5lY3Rpb24vc2Vzc2lvbiBiYXNpcywg dGhlcmVieSBhdm9pZGluZyB0aGUgTEJzIGZvciBzZXJ2aWNlcy4gICBJbiBteQ0KPj4+dmlldywg YXNzdW1wdGlvbiB0aGF0IHRoZXJlIHdpbGwgYmUgTEIgU0YgZm9yIGVhY2ggc2NhbGUtb3V0IHNl cnZpY2UNCj4+PmluIHRoZSBjaGFpbiBpcyBub3QgdmFsaWQgaW4gYWxsIGNhc2VzLg0KPj4+DQo+ Pj5UaGFua3MNCj4+PlNyaW5pDQo+Pj4NCj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+PkZyb206IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKSA8cmVwZW5ub0Bj aXNjby5jb20+DQo+Pj5TZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgNCwgMjAxNCAxOjE3IFBNDQo+ Pj5UbzogQWRkZXBhbGxpIFNyaW5pLUIyMjE2MDsgSm9lbCBNLiBIYWxwZXJuOyBzZmNAaWV0Zi5v cmcNCj4+PkNjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPj4+U3ViamVjdDogUmU6IFtz ZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4+KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4+DQo+Pj5JZiBJIHVuZGVyc3Rvb2QgeW91LCBJ IGRvIG5vdCB0aGluayB0aGlzIGlzIHJlYWxpc3RpYy4gQXJlIHlvdSBzYXlpbmcNCj4+PnlvdSBu ZWVkIDY0LWJpdHMgb2YgcGF0aHMgYW5kIHRoZW4gd2lsbCBtb25pdG9yIHRoZW0gYWxsPyBEbyBm YXVsdA0KPj4+dG9sZXJhbmNlIGFuZCBPQU0gZm9yIDJeNjQtYml0cyB3b3J0aCBvZiBwYXRocz8g SnVzdCBmb3IgY29tcGFyaXNvbiwNCj4+Pml0qfZzIGxpa2UgbWFuYWdpbmcgYW5kIG1vbml0b3Jp bmcgdGhlIGVudGlyZSBJUHY2IGhvc3QgcmFuZ2UsDQo+Pj5vbmUtYnktb25lLg0KPj4+DQo+Pj5B bnl3YXksIEkgZG8gbm90IGV4cGVjdCBldmVyeSBzaW5nbGUgcGVybXV0YXRpb25zIHRvIGJlIGEg ZGlmZmVyZW50DQo+Pj5wYXRoLg0KPj4+DQo+Pj5JZiBlYWNoIHNlcnZpY2UgaGFzIDI1NiBkZXZp Y2VzIHByb3ZpZGluZyBzaW1pbGFyIHNlcnZpY2UsIHlvdSBzaG91bGQNCj4+Pm1vc3QgbGlrZWx5 IHVzZSBsb2FkLWJhbGFuY2luZyBhbmQgdGhlbiB5b3Ugd291bGQgaGF2ZSBhIHNpbmdsZSAob3Ig YQ0KPj4+ZmV3KSBwYXRocy4gVGhlcmUgaXMgc29tZSBkaXNjdXNzaW9uIGdvaW5nIG9uIExCLg0K Pj4+DQo+Pj5Gcm9tIGEgZGF0YSBwbGFuZSBwZXJzcGVjdGl2ZSwgdGhlIHBhdGggaXMgdWx0aW1h dGVseSBkZWZpbmVkIGJ5IHRoZQ0KPj4+U0ZGcyB0cmF2ZXJzZWQgYW5kIHNlcnZpY2VzIHByb3Zp ZGVkLCBub3QgYnkgYSBzcGVjaWZpYyBJUDpwb3J0IHRoYXQNCj4+PnRoZSBkZXZpY2UgcHJvdmlk aW5nIHRoZSBzZXJ2aWNlIHNpdHMgb24uIFdlbGwsIGF0IGxlYXN0IGZyb20gYQ0KPj4+R1BFK05T SCBwZXJzcGVjdGl2ZS4NCj4+Pg0KPj4+DQo+Pj5PbiAxMi80LzE0LCAxMjo1NyBQTSwgIlNyaW5p IEFkZGVwYWxsaSIgPHNhZGRlcGFsbGlAZnJlZXNjYWxlLmNvbT4NCj4+Pndyb3RlOg0KPj4+DQo+ Pj4+SWYgSSB0YWtlIGEgY2hhaW4gd2l0aCA1IHNlcnZpY2VzIHdpdGggZWFjaCBzZXJ2aWNlICBz YXkgaGF2aW5nIDI1Ng0KPj4+Pmluc3RhbmNlcyBmb3Igc2NhbGUtb3V0LCBwb3NzaWJsZSBudW1i ZXIgb2YgcGF0aHMgYXJlDQo+Pj4+MjU2KjI1NioyNTYqMjU2KjI1Ng0KPj4+Pj0gMHhGRiBGRiBG RiBGRiBGRi4gT25lIHJlcXVpcmVzIDMzIGJpdHMgaW4gdGhpcyBjYXNlLiAgSWYgdGhlcmUgYXJl DQo+Pj4+bW9yZSBzZXJ2aWNlcyBpbiB0aGUgY2hhaW4gb3IgbW9yZSBjaGFpbnMgb3IgbW9yZSBp bnN0YW5jZXMgZm9yDQo+Pj4+c2NhbGUtb3V0LCB0aGVuIGl0IGNvdWxkIGdvIHRvIGJpZyBudW1i ZXIgdmVyeSBmYXN0Lg0KPj4+Pg0KPj4+PkFzIEkgbWVudGlvbmVkIG15IHByZWZlcmVuY2UgaXMg dG8gbWFrZSB0aGUgcGF0aCBJRCBzaXplIGZsZXhpYmxlIGZvcg0KPj4+PmZ1dHVyZSBncm93dGgu IElmIHRoYXQgaXMgcGVyY2VpdmVkIGFzIGNvbXBsZXgsIHRoZW4gZ29pbmcgZm9yIDY0Yml0DQo+ Pj4+aXMgc2FmZXIgYmV0Lg0KPj4+Pg0KPj4+PlRoYW5rcw0KPj4+PlNyaW5pDQo+Pj4+DQo+Pj4+ DQo+Pj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj5Gcm9tOiBKb2VsIE0uIEhhbHBl cm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXQ0KPj4+PlNlbnQ6IFRodXJzZGF5LCBEZWNl bWJlciAwNCwgMjAxNCAxMjowNSBQTQ0KPj4+PlRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBK b2VsIE0uIEhhbHBlcm47IHNmY0BpZXRmLm9yZw0KPj4+PkNjOiBOUyBTcmluaXZhc2EgTXVydGh5 LUIzNzg0MA0KPj4+PlN1YmplY3Q6IFJlOiBbc2ZjXSBDb21tZW50cyBvbiBTQ0ggRHJhZnQNCj4+ Pj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLXNmYy1zY2gtMDIpDQo+ Pj4+DQo+Pj4+QSBjb250cm9sbGVyIChvciBvdGhlciBkZWNpc2lvbiBsb2dpYykgY2FuIGNlcnRh aW5seSBiZSBhd2FyZSBvZiBzdWNoDQo+Pj4+Y29uY2VybnMuDQo+Pj4+QnV0IHRoZSBudW1iZXIg b2Ygc2VydmljZSBmdW5jdGlvbiBwYXRocyBpcyBub3QgcmVsYXRlZCB0byB0aGUgbnVtYmVyDQo+ Pj4+b2YgZmxvd3Mgb3IgdGhlIG51bWJlciBvZiB0ZW5hbnRzLiAgSXQgaXMgcmVsYXRlZCB0byB0 aGUgbnVtYmVyIG9mDQo+Pj4+Y29tYmluYXRpb25zIG9mIHNlcnZpY2VzIGFuZCB0aGUgcG9saWNp ZXMgZm9yIHNlcnZpY2UgZnVuY3Rpb24NCj4+Pj5zZWxlY3Rpb24uDQo+Pj4+IFdoaWxlIHRoYXQg Y2FuIGJlIGEgbGFyZ2UgbnVtYmVyLCBJIHN1cmUgaG9wZSBpdCBkb2VzIG5vdCBjb21lIGNsb3Nl DQo+Pj4+dG8gc2F0dXJhdGluZyAyNCBiaXRzLg0KPj4+Pg0KPj4+PkhhdmluZyBzYWlkIHRoYXQs IGlmIHdlIHRoaW5rIHRoYXQgMjQgYml0cyBpcyBvbmx5IGp1c3QgZW5vdWdoLCB0aGVuDQo+Pj4+ d2Ugb3VnaHQgdG8gdXNlIDMyLiAgRnJvbSB3aGVyZSBJIHNpdCwgSSB3b3VsZCBub3JtYWxseSBl eHBlY3QgMTYNCj4+Pj5iaXRzIHRvIGJlIG1vcmUgdGhhbiBzdWZmaWNpZW50LCB3aGljaCBpcyB3 aHkgSSBhbSBjb21mb3J0YWJsZSB3aXRoDQo+Pj4+MjQuICBIYXZpbmcgc2FpZCB0aGF0LCB0aGUg ZmllbGQgc2l6ZSBpcyBub3QgYSBiaWcgZGVhbCB0byBtZS4NCj4+Pj4NCj4+Pj5Zb3VycywNCj4+ Pj5Kb2VsDQo+Pj4+DQo+Pj4+T24gMTIvNC8xNCwgMjowMSBQTSwgU3JpbmkgQWRkZXBhbGxpIHdy b3RlOg0KPj4+Pj4NCj4+Pj4+IEkgd2FzIG5vdCBpbXBseWluZyB0aGF0IHBhdGggSUQgc2hvdWxk IGhhdmUgaW5mb3JtYXRpb24gaW4gcmVnYXJkcw0KPj4+Pj50byB0ZW5hbnQvY29udHJvbGxlci9m bG93L3NjYWxlLW91dC4gIEJ1dCBTRkMgY29udHJvbGxlcnMgc2hvdWxkDQo+Pj4+PmtlZXAgdGhl c2UNCj4+Pj4+aW4gbWluZCB0byBhc3NpZ24gdGhlIHBhdGggSUQuICAgIEEgZGVwbG95bWVudCBj YW4gaGF2ZSBtdWx0aXBsZQ0KPj4+Pj50ZW5hbnRzLCBlYWNoIHRlbmFudCBjYW4gaGF2ZSBtdWx0 aXBsZSBuZXR3b3JrcywgIHRoZXJlIGNvdWxkIGJlDQo+Pj4+Pm1pbGxpb25zIG9mIGZsb3dzIGlu IGVhY2ggb2YgdGhvc2UgbmV0d29ya3MuICBBbmQgY29uc2lkZXJpbmcgYWxsDQo+Pj4+PnRoZXNl LA0KPj4+Pj4gMjQgYml0IHBhdGggSUQgbWF5IG5vdCBiZSBhYmxlIHRvIHJlcHJlc2VudCBwYXRo cyBmb3IgdGhlc2UgZmxvd3MuDQo+Pj4+PkhlbmNlLCBJIHdhcyB3b25kZXJpbmcgd2hldGhlciBw YXRoIElEIGNhbiBiZSBleHRlbmRlZCB0byA2NCBiaXRzIG9yDQo+Pj4+Pm1ha2UgaXQgZmxleGli bGUuDQo+Pj4+Pg0KPj4+Pj4gVGhhbmtzDQo+Pj4+PiBTcmluaQ0KPj4+Pj4NCj4+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IEZyb206IEpvZWwgTS4g SGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4NCj4+Pj4+IFNlbnQ6IFRodXJzZGF5LCBEZWNl bWJlciA0LCAyMDE0IDc6NDIgQU0NCj4+Pj4+IFRvOiBBZGRlcGFsbGkgU3JpbmktQjIyMTYwOyBz ZmNAaWV0Zi5vcmcNCj4+Pj4+IENjOiBOUyBTcmluaXZhc2EgTXVydGh5LUIzNzg0MA0KPj4+Pj4g U3ViamVjdDogUmU6IFtzZmNdIENvbW1lbnRzIG9uIFNDSCBEcmFmdA0KPj4+Pj4gKGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1zZmMtc2NoLTAyKQ0KPj4+Pj4NCj4+Pj4+ IFRoZSBJbmRleCBpcyBub3QganVzdCBmb3IgbG9vcCBwcmV2ZW50aW9uLiAgSW4gdGhlIGNhc2Ug b2YNCj4+Pj4+YW1iaWd1aXR5LCAgdGhlIGluZGV4IHRlbGxzIHRoZSBTRkYgd2hlcmUgaW4gdGhl IHBhdGggdGhlIHBhY2tldA0KPj4+Pj5jdXJyZW50bHkgcmVzaWRlcy4NCj4+Pj4+ICAgIFRoZXJl IGFyZSBtdWx0aXBsZSB3YXlzIHN1Y2ggYW1iaWd1aXR5IGNhbiBvY2N1ci4NCj4+Pj4+DQo+Pj4+ PiBUaGUgUGF0aCBJZGVudGlmaWVyIGlzIHNwZWNpZmljYWxseSBub3QgZXhwZWN0ZWQgdG8gaW5j bHVkZQ0KPj4+Pj4gY29udHJvbGxlciBJRCBvciBUZW5hbnQgSUQuICBXaGlsZSBhIGRlcGxveWVy IGNhbiBoYXZlIGEgcGF0aCBwZXINCj4+Pj4+IHRlbmFudCwgdGhlIGFyY2hpdGVjdHVyZSBzdGls bCBkb2VzIG5vdCB0cmVhdCB0aGUgcGF0aCBJRCBhcyBhDQo+Pj4+PiB0ZW5hbnQgSUQuICBUZW5h bnQgSUQsIGNvbnRyb2xsZXIgSUQsIGFuZCBvdGhlciBub24tcGF0aC1zcGVjaWZ5aW5nDQo+Pj4+ PiBpbmZvcm1hdGlvbiBpcyB0byBiZSBjYXJyaWVkIGluIG1ldGFkYXRhLg0KPj4+Pj4NCj4+Pj4+ IFlvdXJzLA0KPj4+Pj4gSm9lbA0KPj4+Pj4NCj4+Pj4+IE9uIDEyLzQvMTQsIDEwOjAyIEFNLCBT cmluaSBBZGRlcGFsbGkgd3JvdGU6DQo+Pj4+Pj4gVHdvIGNvbW1lbnRzIDoNCj4+Pj4+Pg0KPj4+ Pj4+DQo+Pj4+Pj4gMS4gIFNGIEluZGV4IDogIFNpbmNlIGl0IGlzIG1lYW50IGZvciBsb29wIGRl dGVjdGlvbiwgIHdvdWxkbid0DQo+Pj4+Pj4gYmV0dGVyIHRvIHJlbmFtZSB0aGlzIGFzICJUVEwi Pw0KPj4+Pj4+DQo+Pj4+Pj4gMi4gIFBhdGggSWRlbnRpZmllciA6ICAgIDI0IGJpdCBwYXRoIGlk ZW50aWZpZXIgc2VlbXMgdG8gYmUgdG9vDQo+Pj4+Pj5sZXNzLg0KPj4+Pj4+IEJhc2VkIG9uIG91 ciBleHBlcmllbmNlIGluIHRyYWZmaWMgc3RlZXJpbmcsICB0aGlzIHBhdGggaWRlbnRpZmllcg0K Pj4+Pj4+bmVlZHMgdG8gZW5jb2RlIGdvb2QgYW1vdW50IG9mIGluZm9ybWF0aW9uIHRvIG1ha2Ug aXQgdW5pcXVlLiAgRm9yDQo+Pj4+Pj5leGFtcGxlLA0KPj4+Pj4+ICAgIHRoaXMgaWRlbnRpZmll ciBuZWVkcyB0byBlbmNvZGUgKGluIG91ciBjYXNlKSBzb21lIGluZm9ybWF0aW9uDQo+Pj4+Pj5y ZXByZXNlbnRpbmcgdGhlIGRpc3RyaWJ1dGVkIGNvbnRyb2xsZXIgSUQsICB0ZW5hbnQgSUQsICBm bG93IElELA0KPj4+Pj4+ICAgIFNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2UgKGluIGNhc2Ugb2Yg c2NhbGUtb3V0KSBhbmQgZmV3IG1vcmUuLg0KPj4+Pj4+IE9uZSBzdWdnZXN0aW9uIGlzIHRvIG1h a2UgaXQgNjQgYml0cyB2YWx1ZSAgb3IgdG8gbWFrZSBpdCBldmVuDQo+Pj4+Pj5leHRlbmRhYmxl LA0KPj4+Pj4+ICAgIGl0IGlzIGdvb2QgaWYgcGF0aCBpZGVudGlmaWVyIGlzIGFsc28gcmVwcmVz ZW50ZWQgaW4gVExWIGZvcm0uDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IFRoYW5rcw0KPj4+Pj4+ DQo+Pj4+Pj4gU3JpbmkNCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gc2Zj IG1haWxpbmcgbGlzdA0KPj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+Pj4NCj4+Pj4NCj4+Pj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PnNmYyBtYWlsaW5nIGxp c3QNCj4+Pj5zZmNAaWV0Zi5vcmcNCj4+Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NmYw0KPj4+DQo+Pg0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+c2ZjIG1haWxpbmcgbGlzdA0KPj5zZmNAaWV0Zi5vcmcNCj4+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+DQo+Pl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PnNmYyBtYWlsaW5nIGxp c3QNCj4+c2ZjQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj5zZmMgbWFpbGluZyBsaXN0DQo+PnNmY0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg== From nobody Fri Feb 6 07:29:04 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 017F31A1B53 for ; Fri, 6 Feb 2015 07:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ctKPTijyn6E for ; Fri, 6 Feb 2015 07:28:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78FF31A1B57 for ; Fri, 6 Feb 2015 07:28:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOZ27088; Fri, 06 Feb 2015 15:28:27 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 6 Feb 2015 15:28:27 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.133]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0158.001; Fri, 6 Feb 2015 07:28:19 -0800 From: Wenzhe Zhou To: "Ken Gray (kegray)" , Ron Parker , "Joel M. Halpern" , Nicolas BOUTHORS , "'sfc@ietf.org'" Thread-Topic: [sfc] draft-quinn-sfc-nsh-05, optional headers Thread-Index: AdBAmYhGpM3EkfNlQ4eMZ3oRb+Ov2QBC7nyAABBDrQAAAATGgAAOiTxw Date: Fri, 6 Feb 2015 15:28:18 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D7D2D2F@LILAS.jungle.qosmos.com> <54D39C93.8050704@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.212.244.69] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers 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, 06 Feb 2015 15:28:57 -0000 S2VuLA0KDQpJbiB5b3VyIHdvcmRzLCBtYW5kYXRvcnkgY29udGV4dCBoZWFkZXJzIHNob3VsZCBi ZSByZW1vdmVkIGZyb20gTlNILg0KDQpXZW56aGUNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgS2VuIEdyYXkgKGtlZ3JheSkNClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAwNSwgMjAxNSA0 OjI1IFBNDQpUbzogUm9uIFBhcmtlcjsgSm9lbCBNLiBIYWxwZXJuOyBOaWNvbGFzIEJPVVRIT1JT OyAnc2ZjQGlldGYub3JnJw0KU3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1uc2gt MDUsIG9wdGlvbmFsIGhlYWRlcnMNCg0KSSB0aGluayB0aGVyZcK5cyBhIGRpc2Nvbm5lY3Rpb24g aGVyZSAoY291bGQgYmUgbWUpIGJldHdlZW4gdGhlIGlkZWEgb2YgYW4NCmFic3RyYWN0IGFuZCBz cGVjaWZpYyBwYXRoLg0KDQpJIHRob3VnaHQgaXQgd2FzIHByZXR0eSBjbGVhciAoYW5kIHRoZXJl IHdhcyBzaWduaWZpY2FudCB0YWxrIGFib3V0IGl0DQpoZXJlIG9uIHRoZSBsaXN0KSB0aGF0IHlv dSBjYW4ndCBtYW5kYXRlIGEgc3BlY2lmaWMgbW9kZWwgb2YgZnVuY3Rpb24NCmVsYXN0aWNpdHkg LSB3ZSBjb3VsZG7CuXQgZGVjbGFyZSBsb2FkIGJhbGFuY2luZyBkZXZpY2VzIG9yIGZ1bmN0aW9u cw0KwrNkZWFkwrIgYnV0IGluc3RlYWQgYXNzdW1lZCB0aGF0IGVsYXN0aWNpdHkgY291bGQgYmUg ZG9uZSBsb2NhbGx5IGFzIGEgU0YsDQphcyBwYXJ0IG9mIGEgY29tcG9zaXRlIGZ1bmN0aW9uIHdo ZXJlIHRoZSBsb2FkIGJhbGFuY2VyIGV4aXN0cyBhcyBwYXJ0IG9mDQp0aGUgbG9naWNhbCBmdW5j dGlvbiBiZWluZyByZW5kZXJlZCBvciBjZW50cmFsbHkvc3RhdGljYWxseS4gIFdlIGhhZA0Kc2lt aWxhciBkaWFsb2d1ZXMgYWJvdXQgdGhlIG5lZWQgdG8gcmVtYWluIGFic3RyYWN0IGFyb3VuZCBI QSB0ZWNobmlxdWVzDQphcyB3ZWxsLiANCg0KVGhlc2UgdGhpbmdzIG1ha2UgQU4gaW5kaXZpZHVh bCBwYXRoLCB3aGljaCByZXByZXNlbnRzIGEgY2hhaW4gdGhhdCBmaXRzIGENCnNwZWNpZmljIHBv bGljeSBydWxlc2V0IMWgIHZhcmlhYmxlIMWgIGFuZCB3ZSBkaWRuwrl0IHdhbnQgdG8gdW5uZWNl c3NhcmlseQ0KZGVmaW5lIG11bHRpcGxlIGRpc2NyZXRlIGNoYWlucyB0byBjb3ZlciB0aGlzIHNv cnQgb2YgZnVuY3Rpb24gdmFyaWFuY2UNCih3aGljaCBjYW4gYmVjb21lIHF1aXRlIGxhcmdlLCBp ZiBmb3IgZXhhbXBsZSB0aGUgZnVuY3Rpb24gWCBhdCBzaXRlIFkgaXMNCmFjdHVhbGx5IDEwMDAg cGFyYWxsZWwgaW5zdGFuY2VzIHRvIGFjY29tbW9kYXRlIGxvYWQsIHdpdGggSEEgYWRkIGENCm11 bHRpcGxpZXIsIHBlciBmdW5jdGlvbiBtb3JlIG11bHRpcGxpZXJzIMWgZm9yIGEgc2luZ2xlIHBh dGggdGhhdCBhdCB0aGUNCmFic3RyYWN0IGxldmVsLCB0cmF2ZXJzZWQgdGhlIHNhbWUgc2l0ZXMg xaBib29tKS4NCg0KVGhlc2UgZGlhbG9ndWVzIGFyZSBjYXB0dXJlZCBpbiB0aGUgYXJjaGl0ZWN0 dXJlIGRvY3VtZW50Lg0KDQpTbywgd2hlbiBJIHJlYWQgdGhlIE5TSCBkcmFmdCwgSSBpbnRlcnBy ZXRlZCB0aGUgdHJlYXRtZW50IG9mIHRoZSBTUEkgYW5kDQp0aGUgUmVzb2x2ZWQgUGF0aCBhcyB2 ZXJ5IGNvbXBhdGlibGUgd2l0aCB0aGF0IGFic3RyYWN0aW9uL2NvbmNlcHQuIEl0DQptYWtlcyBt dWx0aXBsZSBkZXBsb3ltZW50IGNvbnRleHRzIHVuZGVyc3RhbmRhYmxlIGFuZCBwb3NzaWJsZSB3 aXRob3V0DQpvdmVybHkgZGVmaW5pbmcgdGhlIGhlYWRlciB3aXRoIHBvdGVudGlhbGx5IHVzZWxl c3MgZmllbGRzIGZvciBldmVyeQ0KaXRlcmFibGUgY2FzZS4gKEVkaXRvcmlhbCAtIEtpbmQgb2Yg YW4gYXJ0IGZvcm0gdGhhdCB3ZSBzaG91bGQgY2VsZWJyYXRlLA0KSU1PLCBpZiBwZW9wbGUgYXJl IGdvaW5nIGFib3V0IGRlc2lnbmluZyBwcm90b2NvbHMuKQ0KDQpGb3IgZXhhbXBsZSwgdGhlIFNG RiBjYW4gYmUgc2VlZGVkIHdpdGggb25lIGFuZCBvbmx5IG9uZSBOSCBmb3IgdGhlIFNJL1NQSQ0K bWF0Y2ggLSB0aHVzIHRoZSBwYXRoIGlzIHJlc29sdmVkIGFuZCB0aGUgU0kvU1BJIHBhdGggSVMg dGhlIHJlbmRlcmVkDQpwYXRoLiAgVGhlIMKzZGlyZWN0ZWTCsiBncmFwaCB0aGF0IHNvbWUgd2Fu dGVkICh3aGVyZSBlYWNoIGluZGl2aWR1YWwNCmVsZW1lbnQgaW4gYSBsb2NhbGx5IGVsYXN0aWMg cG9vbCBpcyBpbmRpdmlkdWFsbHkgYWRkcmVzc2FibGUgYW5kIHNldCBhdA0KY2xhc3NpZmljYXRp b24pIGlzIHJlYWxseSBhIGRlcml2YXRpdmUgb2YgdGhlIHNhbWUgY2FzZS4NCg0KSWYgdGhlcmUg aXMgbW9yZSB0aGFuIG9uZSBOSCBzZWVkZWQgZm9yIHRoZSBTSS9TUEksIHRoZW4gdGhlIFNGRiBl aXRoZXINCndpbGwgdHJlYXQgdGhlIGZvcndhcmRpbmcgYXMgRUNNUCAoZS5nLiBzdGF0ZWxlc3Mg dG8gYW4gYW55Y2FzdCBwb29sIC0NClNJL1NQSSBJUyB0aGUgcmVuZGVyZWQgcGF0aCksIG9yIGhh dmUgYSBsb2NhbCBwb2xpY3kgdG8gcGVyZm9ybSBhbg0KZXhwbGljaXQgbWFwcGluZy4gIFRoZSBT RkYgbWF5IGFsc28gYmUganVzdCBoYW5kaW5nIHRoZSBwYWNrZXQgdy9OU0gNCmhlYWRlciBvZmYg dG8gYSBsb2NhbCBpbnRlZ3JhdGVkIGZ1bmN0aW9uIChsaWtlIGEgbG9hZCBiYWxhbmNlcikgb3Ig YW4NCmF0dGFjaGVkIGNvbXBvc2l0ZSBmdW5jdGlvbiB0aGF0IGlzIGhhbmRsaW5nIGFuIGV4cGxp Y2l0IG1hcHBpbmcgdG8NCmZ1bmN0aW9uIGluc3RhbmNlcyBpdCBmcm9udHMgKGFuZCBtYW5hZ2lu ZyBzYW1lIHNvbWV3aGF0IG9ibGlxdWVseSB0byB0aGUNClNGRiBhbmQgdGhlIHBhdGggaXRzZWxm KS4NCg0KVGhlc2UgbmV3IGNvbnRleHRzIGRvbsK5dCBORUVEIGFuZCBzaG91bGRuwrl0IEdFVCBh IHNlcGFyYXRlIGZpZWxkIGluIHRoZQ0KZ2VuZXJhbCBoZWFkZXIuICBJRiwgZm9yIGV4YW1wbGUs IHRoZSByZXNvbHV0aW9uL21hcHBpbmcgb2YgZWl0aGVyIHRoZQ0KbG9jYWwgU0ZGIHBvbGljeSAo b3IgdGhlIG9ibGlxdWUgZnVuY3Rpb24pIGlzIGEgcG9saWN5IGtleWVkIHRvDQpjbGFzc2lmaWNh dGlvbiBpbmZvIGxpa2UgZmxvd0lELCB0ZW5hbnRJRCwgc2Vzc2lvbklELCBzb21ldGhpbmcNCnBy b3ByaWV0YXJ5IC0gd2VsbCwgeW91wrl2ZSBqdXN0IHJlZGVmaW5lZCB0aGUgbmVlZCBmb3IgbWV0 YWRhdGEgKG9uZSBvZg0Kb3VyIGdvYWxzIHdhcyB0byBiZSBhYmxlIHRvIHByZXNlcnZlIGNsYXNz aWZpZXIgaW5mbyBpbiBtZXRhZGF0YSB0byBhdm9pZA0KZXhjZXNzaXZlIGNsYXNzaWZpY2F0aW9u KSwgd2hpY2ggd2UgYWxsIGFncmVlZCB0byBhbHJlYWR5IC0gYW5kIHdlIGtub3cNCndoZXJlIHRv IGZpbmQgc3VjaCBhIGtleSBzbyB0aGVyZcK5cyBubyBuZWVkIHRvIG1vdmUgaXQuICAoRWRpdG9y aWFsIC0gTm90ZQ0KYWxzbyB0aGUgcG90ZW50aWFsIGZvciB2YXJpYW5jZSBvZiB0aGUga2V5IHNv dXJjZS92YWx1ZSBhY3Jvc3MNCmltcGxlbWVudGF0aW9ucy4pDQoNCllvdSBzaG91bGRuJ3QgTkVF RCBhbiBleHBsaWNpdCBSU1AgSUQgaW4gdGhlIGZpeGVkIGhlYWRlci4gIFRoYXQgc2VlbXMgdG8N CndvcmsgYmFjayBhZ2FpbnN0IHRoZSBvcmlnaW5hbCBpbXBsaWNpdCBkZXNpZ24gZ29hbCBvZiB0 aGUgaGVhZGVyLg0KDQpJIGR1bm5vLCBpZiBpdMK5cyBqdXN0IG1lLCBJIGhhdmVuwrl0IGRvbmUg cHJvdG9jb2wgZGVzaWduIHNpbmNlIGNvbGxlZ2UgxaANCm1heWJlIEnCuW0gcnVzdHkgb3IgSSBu ZWVkIHNvbWV0aGluZyBzdHJvbmdlciB0byBkcmluay4NCiAgDQoNCkNoZWVycy4NCg0KDQpPbiAy LzUvMTUsIDExOjU3IEFNLCAiUm9uIFBhcmtlciIgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jr cy5jb20+IHdyb3RlOg0KDQo+Sm9lbCwNCj4NCj5JIHRoaW5rIHlvdSBhcmUgcmVpbmZvcmNpbmcg YSBrZXkgYXNzdW1wdGlvbiBoZXJlIC0tIGlmIHRoZSBTRkYgbmVlZHMgdGhlDQo+aW5mb3JtYXRp b24gdG8gZG8gaXRzIGpvYiwgdGhlbiB0aGF0IGluZm9ybWF0aW9uIHNob3VsZCBiZSBuZWl0aGVy IGluDQo+VHlwZSAxIG5vciBUeXBlIDIgbWV0YWRhdGEuICAgIEFzIGFuIGV4YW1wbGUuLi4gIGRl cGVuZGluZyBvbiBob3cgb3VyDQo+Y29udGludWluZyBkaXNjdXNzaW9uIG9uIFJTUCBJRCBnb2Vz IChpLmUsIHRvIGVuYWJsZSBib3RoIGNlbnRyYWxpemVkDQo+Y29uY3JldGUgUlNQIGRldGVybWlu YXRpb24gYW5kIGRpc3RyaWJ1dGVkIGhvcC1ieS1ob3AgInRyYWlsLWJsYXplZCIgUlNQDQo+ZGV0 ZXJtaW5hdGlvbiksIHdlIG1heSB3YW50IHRvICJwcm9tb3RlIiBSU1AgSUQgZnJvbSBtZXRhZGF0 YSB0byB0aGUNCj5zdGFuZGFyZCBoZWFkZXIuDQo+DQo+ICAgUm9uDQo+DQo+DQo+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybg0KPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFy eSA1LCAyMDE1IDExOjM5IEFNDQo+VG86IE5pY29sYXMgQk9VVEhPUlM7ICdzZmNAaWV0Zi5vcmcn DQo+U3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1uc2gtMDUsIG9wdGlvbmFsIGhl YWRlcnMNCj4NCj5UaGUgbWV0YWRhdGEgaXMgKGdlbmVyYWxseSkgZm9yIHRoZSBhU2VydmljZSBG dW5jdGlvbnMsIG5vdCBmb3IgdGhlIFNGRi4NCj4gIFNvIHRoZSBxdWVzaXRvbiBvZiBwcm9ncmFt bWluZyB0aGUgU0ZGIHRvIHByb2Nlc3MgdGhlIGluZm9ybWF0aW9uIHNlZW1zDQo+bm90IGVzcGVj aWFsbHkgbWFqb3IuDQo+DQo+TW9yZSBzaWduaWZpY2FudGx5LCBnaXZlbiB0aGF0IHRoZSAxNiBi eXRlIHR5cGUgMSBmaWVsZCBtYXkgY2FycnkNCj5kaWZmZXJlbnQgdGhpbmdzIGluIGRpZmZlcmVu dCBjYXNlcywgdGhlIFNGcyB3aWxsIGhhdmUgdG8gYmUgZmxleGlibGUNCj5hYm91dCBwcm9jZXNz aW5nIHRoZSBpbmZvcm1hdGlvbiBhbnl3YXkuICBTbyBhbnl0aGluZyB3aGljaCBjYW4gaGFuZGxl DQo+dGhlIHR5cGUgMiBpbmZvcm1hdGlvbiBjYW4gYmUgcmVhc29hbmFibHkgZXhwZWN0ZWQgdG8g aGFuZGxlIHRoZSBzYW1lDQo+a2luZHMgb2YgaW5mb3JtYXRpb24gZnJvbSBUTFZzICh3aGV0aGVy IG9uZSBUTFYgb3IgbWFueSkuDQo+DQo+SXQgdGhlcmVmb3JlIHNlZW1zIGNsZWFuZXIgdG8gbWUg dG8gcmVjb2duaXplIHRoYXQgdHlwZSAxIGFuZCB0eXBlIDIgYXJlDQo+ZGlmZmVyZW50IHdheXMg b2YgY2FycnlpbmcgaW5mb3JtYXRpb24sIGFuZCBqdXN0IHVzZSB0aGUgbWVjaGFuaXNtIGVhY2gN Cj5zdXBwb3J0cy4NCj4NCj5Zb3VycywNCj5Kb2VsDQo+DQo+T24gMi80LzE1IDEyOjA2IFBNLCBO aWNvbGFzIEJPVVRIT1JTIHdyb3RlOg0KPj4gSXQgaXMgZ3JlYXQgdG8gaGF2ZSB0aGUgcG9zc2li aWxpdHkgdG8gYWRkIG9wdGlvbmFsIGhlYWRlcnMgaW4gTlNILg0KPj5Ib3dldmVyLCB0aGUgbWVj aGFuaXNtIHByb3Bvc2VkIHN1cHBvc2UgdGhhdCBhIHNwZWNpZmljIGhlYWRlciB0eXBlICh0aGUN Cj4+IE1EIFR5cGU9MHgyKWlzIHVzZWQgaW4gdGhlIGJhc2UgaGVhZGVyIHdoZW4gb3B0aW9uYWwg bWV0YWRhdGEgYXJlIHVzZWQuDQo+Pg0KPj4NCj4+DQo+PiBBcyBhIHJlc3VsdDoNCj4+DQo+PiAx LlRoZSBiYXNlIGhlYWRlciB0eXBlIDB4MSBjYW5ub3QgYmUgdXNlZCB3aXRoIG9wdGlvbmFsIGhl YWRlcnMuIFdoaWNoDQo+PiBteSBtYWtlIHNlbnNlIGZvciBwZXJmb3JtYW5jZSBwb2ludCBvZiB2 aWV3DQo+Pg0KPj4gMi5Ob3Igd2hlbiB1c2luZyBoZWFkZXIgTUQgdHlwZSB4MiAgY2FuIHRoZSAi bWFuZGF0b3J5IGNvbnRleHQgaGVhZGVycyINCj4+IGJlIHByZXNlbnQuDQo+Pg0KPj4gQ2FzZSAy IGNhbiBiZSB3b3JrZWQgYXJvdW5kIGJ5IGRlZmluaW5nIGFuIG9wdGlvbmFsIGhlYWRlciB0aGF0 DQo+PiByZXByZXNlbnRzIHRoZSBtYW5kYXRvcnkgY29udGV4dCBoZWFkZXIuIFdoaWNoIGlzIGF3 a3dhcmQgYXMgU0ZGcyB3aWxsDQo+PiBoYXZlIHRvIGRlY29kZSB0aGUgc2FtZSBpbmZvcm1hdGlv biBpbiB0d28gZGlmZmVyZW50IHdheXMuIE5vdA0KPj4gcGFydGljdWxhcmx5IGJlYXV0aWZ1bCAh DQo+Pg0KPj4gV2h5IG5vdCBoYXZlIGEgZmxhZyAoRjIpc3RhdGluZyB0aGF0IG5vIG9wdGlvbmFs IE1ldGFkYXRhIGFyZSBwcmVzZW50DQo+PiBhbmQgYW5vdGhlciBvbmUgKEYxKSBzdGF0aW5nIHRo YXQgKHdoYXQgaXMgbm93IGNhbGxlZCkgdGhlIG1hbmRhdG9yeQ0KPj4gY29udGV4dCBoZWFkZXIg aXMgcHJlc2VudCBvciBub3QuDQo+Pg0KPj4gV2UgY2FuIHRoZW4gc3BlY2lmeSB0aGF0IHRoZSBj b21iaW5hdGlvbnMNCj4+DQo+PiBGMj1GYWxzZSBpbXBsaWVzIEYxPVRydWUNCj4+DQo+PiBGMT1U cnVlLCBGMj1UcnVlIGlzIGFsbG93ZWQNCj4+DQo+PiBGMT0gRmFsc2UsIEYyPVRydWUgaXMgYWxs b3dlZA0KPj4NCj4+IEl0IHNlZW1zIGNsZWFuZXIuIFdoZW4gcHJlc2VudCwgdGhlICJtYW5kYXRv cnkgY29udGV4dCBoZWFkZXJzIiB3b3VsZA0KPj4gYWx3YXlzIGJlIGF0IHRoZSBzYW1lIHBsYWNl IGluIHRoZSBwYWNrZXQuDQo+Pg0KPj4gTmljb2xhcw0KPj4NCj4+IFRoaXMgbWVzc2FnZSBhbmQg YW55IGF0dGFjaG1lbnRzICh0aGUgIm1lc3NhZ2UiKSBhcmUgY29uZmlkZW50aWFsLA0KPj4gaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2Vlcy4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkDQo+PiByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBi eSBlLW1haWwgYW5kIGRlbGV0ZQ0KPj4gdGhpcyBtZXNzYWdlIGZyb20geW91ciBzeXN0ZW0uIElu IHRoaXMgY2FzZSwgeW91IGFyZSBub3QgYXV0aG9yaXplZCB0bw0KPj4gdXNlLCBjb3B5IHRoaXMg bWVzc2FnZSBhbmQvb3IgZGlzY2xvc2UgdGhlIGNvbnRlbnQgdG8gYW55IG90aGVyIHBlcnNvbi4N Cj4+IEUtbWFpbHMgYXJlIHN1c2NlcHRpYmxlIHRvIGFsdGVyYXRpb24uIE5laXRoZXIgUW9zbW9z IG5vciBhbnkgb2YgaXRzDQo+PiBzdWJzaWRpYXJpZXMgb3IgYWZmaWxpYXRlcyBzaGFsbCBiZSBs aWFibGUgZm9yIHRoZSBtZXNzYWdlIGlmIGFsdGVyZWQsDQo+PiBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4NCj4+DQo+PiBDZSBtZXNzYWdlIGV0IHRvdXRlcyBzZXMgcGnDqGNlcyBqb2ludGVzIChjaS1h cHLDqHMgbGUgIm1lc3NhZ2UiKXNvbnQNCj4+IGNvbmZpZGVudGllbHMgZXQgw6l0YWJsaXMgw6Ag bCdpbnRlbnRpb24gZXhjbHVzaXZlIGRlIHNlcyBkZXN0aW5hdGFpcmVzLg0KPj4gU2kgdm91cyBh dmV6IHJlw6d1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgbWVyY2kgZCdlbiBpbmZvcm1lcg0KPj4g aW1tw6lkaWF0ZW1lbnQgc29uIMOpbWV0dGV1ciBwYXIgY291cnJpZXIgw6lsZWN0cm9uaXF1ZSBl dCBkJ2VmZmFjZXIgY2UNCj4+IG1lc3NhZ2UgZGUgdm90cmUgc3lzdMOobWUuIERhbnMgY2V0dGUg aHlwb3Row6hzZSwgdm91cyBuJ8OqdGVzIHBhcw0KPj4gYXV0b3Jpc8OpIMOgIHV0aWxpc2VyLCBj b3BpZXIgY2UgbWVzc2FnZSBldC9vdSBlbiBkaXZ1bGd1ZXIgbGUgY29udGVudSDDoA0KPj51biB0 aWVycy4NCj4+IFRvdXQgbWVzc2FnZSDDqWxlY3Ryb25pcXVlIGVzdCBzdXNjZXB0aWJsZSBkJ2Fs dMOpcmF0aW9uLiBRb3Ntb3MgZXQgc2VzDQo+PiBmaWxpYWxlcyBkw6ljbGluZW50IHRvdXRlIHJl c3BvbnNhYmlsaXTDqSBhdSB0aXRyZSBkZSBjZSBtZXNzYWdlIHMnaWwgYQ0KPj4gw6l0w6kgYWx0 w6lyw6ksIGTDqWZvcm3DqSBvdSBmYWxzaWZpw6kuDQo+Pg0KPj4NCj4+DQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlz dA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NmYw0KPj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPnNmYyBtYWlsaW5nIGxpc3QNCj5zZmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0 DQpzZmNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2Zj DQo= From nobody Fri Feb 6 07:44: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 296EE1A1BBE for ; Fri, 6 Feb 2015 07:44:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 4QmBOTFAV1W7 for ; Fri, 6 Feb 2015 07:44:19 -0800 (PST) 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 210EE1A1BAF for ; Fri, 6 Feb 2015 07:44:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 08E0C240497; Fri, 6 Feb 2015 07:44:05 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-134-12.clppva.east.verizon.net [70.106.134.12]) (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 16BDF24DD70; Fri, 6 Feb 2015 07:44:03 -0800 (PST) Message-ID: <54D4E136.2080203@joelhalpern.com> Date: Fri, 06 Feb 2015 10:43:50 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Wenzhe Zhou , "Ken Gray (kegray)" , Ron Parker , Nicolas BOUTHORS , "'sfc@ietf.org'" References: <76B41B8FACE1514795D30EC137FF391D7D2D2F@LILAS.jungle.qosmos.com> <54D39C93.8050704@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers 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, 06 Feb 2015 15:44:20 -0000 It seems to me that another way of asking that question (which avoids putting words in anyone's mouth) is to ask which header type should be mandatory to implement (MTI). It seems clear to me that one of the types needs to be MTI in order to enable data plane interoperability, which is our goal. Yours, Joel On 2/6/15 10:28 AM, Wenzhe Zhou wrote: > Ken, > > In your words, mandatory context headers should be removed from NSH. > > Wenzhe > From nobody Fri Feb 6 08:25:36 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E128D1A6F29; Fri, 6 Feb 2015 08:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 2u6EhRIYqor9; Fri, 6 Feb 2015 08:25:28 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B5E1A1B84; Fri, 6 Feb 2015 08:25:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.10.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150206162528.22782.99542.idtracker@ietfa.amsl.com> Date: Fri, 06 Feb 2015 08:25:28 -0800 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-long-lived-flow-use-cases-03.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 16:25:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : SFC Long-lived Flow Use Cases Authors : Ram Krishnan Anoop Ghanwani Joel Halpern Sriganesh Kini Diego Lopez Filename : draft-ietf-sfc-long-lived-flow-use-cases-03.txt Pages : 10 Date : 2015-02-06 Abstract: Long-lived flows such as file transfers, video streams are common in today's networks. In the context of service function chaining, this draft suggests use cases for dynamic bypass of certain service functions for such flows. The benefit of this approach would be to avoid expensive Layer 7 service function processing for such flows based on dynamic decisions and thus improve overall performance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-long-lived-flow-use-cases/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-long-lived-flow-use-cases-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-long-lived-flow-use-cases-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 6 08:57: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 B61831A700C for ; Fri, 6 Feb 2015 08:57:06 -0800 (PST) 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 nykRB_3odLIF for ; Fri, 6 Feb 2015 08:57:04 -0800 (PST) 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 C9F7F1A7008 for ; Fri, 6 Feb 2015 08:57:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12272; q=dns/txt; s=iport; t=1423241823; x=1424451423; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7Nd2eFqp2ZOLkhJFAMX9+vSfBY7q9ps3JY4jw78rC58=; b=XJLxFeVWN3sd5++Wlv6sAUxv/RZVvuCkzIuaWlKTIHxnnUpBaTFTAnNz CgVlsPfl89lWgWsrGksqR1+AJdDp2IZaVvBuX9jXO8PLBz8z05UNDr5y+ anoErGTH5gQdZUgomMkT1aYP9A0RIOCQAkhnx7cJdJcFI4Q7/+T8Wpwsp U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DXBwD28dRU/4gNJK1agmQiUloEgjZHv1cKhXECHH1DAQEBAQF9hAwBAQEEAQEBCRcREw0RCRcEAgEGAhEBAwEBAQICIwMCAgIlCxQBAgYIAQEEARKILQEMomucbIUWkQQBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIEhjiQIMgICAoJigUEBBI0ngXOEM4R5gReDA4JGSYgFgz4ig25vgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,530,1418083200"; d="scan'208";a="121257155" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP; 06 Feb 2015 16:57:02 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t16Gv2Vl004176 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 6 Feb 2015 16:57:02 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Fri, 6 Feb 2015 10:57:02 -0600 From: "Ken Gray (kegray)" To: Wenzhe Zhou , Ron Parker , "Joel M. Halpern" , Nicolas BOUTHORS , "'sfc@ietf.org'" Thread-Topic: [sfc] draft-quinn-sfc-nsh-05, optional headers Thread-Index: AdBAmYhGpM3EkfNlQ4eMZ3oRb+Ov2QA+vZmAAACmJgAABSfyAAAqBvAA///E9gA= Date: Fri, 6 Feb 2015 16:57:01 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D7D2D2F@LILAS.jungle.qosmos.com> <54D39C93.8050704@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.24.215.220] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers 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, 06 Feb 2015 16:57:06 -0000 SW4gbXkgd29yZHMsIEkgYW0gbm90IHN1Z2dlc3RpbmcgY2hhbmdpbmcgdGhlIGRyYWZ0IGF0IGFs bC4gIEkgdGhpbmsgaXTigJlzDQpzdWZmaWNpZW50LiANCg0KDQpNeSBvcGluaW9uLCBpcyB0aGF0 IHRoZSBzdWdnZXN0ZWQgY2hhbmdlcyBpbiB0aGlzIHRocmVhZCBzaG93IGENCmZ1bmRhbWVudGFs IGZhaWx1cmUgdG8gZ3Jhc3AgdGhlIGNvbmNlcHRzIHdlIGhhc2hlZCBvdXQgaW4gdGhlDQphcmNo aXRlY3R1cmUgKHdoaWNoIEkgYXR0ZW1wdGVkIHRvIGNsYXJpZnkpLiAgSW4gbXkgb3Bpbmlvbiwg dG8gdXNlIGFuDQp1bmZvcnR1bmF0ZSBjb2xsb3F1aWFsaXNtIC0gdGhpcyBob3JzZSBpcyBkZWFk LCB3ZSBzaG91bGQgc3RvcCBiZWF0aW5nIGl0Lg0KDQpPbiAyLzYvMTUsIDEwOjI4IEFNLCAiV2Vu emhlIFpob3UiIDxXZW56aGUuWmhvdUBodWF3ZWkuY29tPiB3cm90ZToNCg0KPktlbiwNCj4NCj5J biB5b3VyIHdvcmRzLCBtYW5kYXRvcnkgY29udGV4dCBoZWFkZXJzIHNob3VsZCBiZSByZW1vdmVk IGZyb20gTlNILg0KPg0KPldlbnpoZQ0KPiANCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg S2VuIEdyYXkgKGtlZ3JheSkNCj5TZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDUsIDIwMTUgNDoy NSBQTQ0KPlRvOiBSb24gUGFya2VyOyBKb2VsIE0uIEhhbHBlcm47IE5pY29sYXMgQk9VVEhPUlM7 ICdzZmNAaWV0Zi5vcmcnDQo+U3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1uc2gt MDUsIG9wdGlvbmFsIGhlYWRlcnMNCj4NCj5JIHRoaW5rIHRoZXJlwrlzIGEgZGlzY29ubmVjdGlv biBoZXJlIChjb3VsZCBiZSBtZSkgYmV0d2VlbiB0aGUgaWRlYSBvZiBhbg0KPmFic3RyYWN0IGFu ZCBzcGVjaWZpYyBwYXRoLg0KPg0KPkkgdGhvdWdodCBpdCB3YXMgcHJldHR5IGNsZWFyIChhbmQg dGhlcmUgd2FzIHNpZ25pZmljYW50IHRhbGsgYWJvdXQgaXQNCj5oZXJlIG9uIHRoZSBsaXN0KSB0 aGF0IHlvdSBjYW4ndCBtYW5kYXRlIGEgc3BlY2lmaWMgbW9kZWwgb2YgZnVuY3Rpb24NCj5lbGFz dGljaXR5IC0gd2UgY291bGRuwrl0IGRlY2xhcmUgbG9hZCBiYWxhbmNpbmcgZGV2aWNlcyBvciBm dW5jdGlvbnMNCj7Cs2RlYWTCsiBidXQgaW5zdGVhZCBhc3N1bWVkIHRoYXQgZWxhc3RpY2l0eSBj b3VsZCBiZSBkb25lIGxvY2FsbHkgYXMgYSBTRiwNCj5hcyBwYXJ0IG9mIGEgY29tcG9zaXRlIGZ1 bmN0aW9uIHdoZXJlIHRoZSBsb2FkIGJhbGFuY2VyIGV4aXN0cyBhcyBwYXJ0IG9mDQo+dGhlIGxv Z2ljYWwgZnVuY3Rpb24gYmVpbmcgcmVuZGVyZWQgb3IgY2VudHJhbGx5L3N0YXRpY2FsbHkuICBX ZSBoYWQNCj5zaW1pbGFyIGRpYWxvZ3VlcyBhYm91dCB0aGUgbmVlZCB0byByZW1haW4gYWJzdHJh Y3QgYXJvdW5kIEhBIHRlY2huaXF1ZXMNCj5hcyB3ZWxsLiANCj4NCj5UaGVzZSB0aGluZ3MgbWFr ZSBBTiBpbmRpdmlkdWFsIHBhdGgsIHdoaWNoIHJlcHJlc2VudHMgYSBjaGFpbiB0aGF0IGZpdHMg YQ0KPnNwZWNpZmljIHBvbGljeSBydWxlc2V0IMWgIHZhcmlhYmxlIMWgIGFuZCB3ZSBkaWRuwrl0 IHdhbnQgdG8gdW5uZWNlc3NhcmlseQ0KPmRlZmluZSBtdWx0aXBsZSBkaXNjcmV0ZSBjaGFpbnMg dG8gY292ZXIgdGhpcyBzb3J0IG9mIGZ1bmN0aW9uIHZhcmlhbmNlDQo+KHdoaWNoIGNhbiBiZWNv bWUgcXVpdGUgbGFyZ2UsIGlmIGZvciBleGFtcGxlIHRoZSBmdW5jdGlvbiBYIGF0IHNpdGUgWSBp cw0KPmFjdHVhbGx5IDEwMDAgcGFyYWxsZWwgaW5zdGFuY2VzIHRvIGFjY29tbW9kYXRlIGxvYWQs IHdpdGggSEEgYWRkIGENCj5tdWx0aXBsaWVyLCBwZXIgZnVuY3Rpb24gbW9yZSBtdWx0aXBsaWVy cyDFoGZvciBhIHNpbmdsZSBwYXRoIHRoYXQgYXQgdGhlDQo+YWJzdHJhY3QgbGV2ZWwsIHRyYXZl cnNlZCB0aGUgc2FtZSBzaXRlcyDFoGJvb20pLg0KPg0KPlRoZXNlIGRpYWxvZ3VlcyBhcmUgY2Fw dHVyZWQgaW4gdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudC4NCj4NCj5Tbywgd2hlbiBJIHJlYWQg dGhlIE5TSCBkcmFmdCwgSSBpbnRlcnByZXRlZCB0aGUgdHJlYXRtZW50IG9mIHRoZSBTUEkgYW5k DQo+dGhlIFJlc29sdmVkIFBhdGggYXMgdmVyeSBjb21wYXRpYmxlIHdpdGggdGhhdCBhYnN0cmFj dGlvbi9jb25jZXB0LiBJdA0KPm1ha2VzIG11bHRpcGxlIGRlcGxveW1lbnQgY29udGV4dHMgdW5k ZXJzdGFuZGFibGUgYW5kIHBvc3NpYmxlIHdpdGhvdXQNCj5vdmVybHkgZGVmaW5pbmcgdGhlIGhl YWRlciB3aXRoIHBvdGVudGlhbGx5IHVzZWxlc3MgZmllbGRzIGZvciBldmVyeQ0KPml0ZXJhYmxl IGNhc2UuIChFZGl0b3JpYWwgLSBLaW5kIG9mIGFuIGFydCBmb3JtIHRoYXQgd2Ugc2hvdWxkIGNl bGVicmF0ZSwNCj5JTU8sIGlmIHBlb3BsZSBhcmUgZ29pbmcgYWJvdXQgZGVzaWduaW5nIHByb3Rv Y29scy4pDQo+DQo+Rm9yIGV4YW1wbGUsIHRoZSBTRkYgY2FuIGJlIHNlZWRlZCB3aXRoIG9uZSBh bmQgb25seSBvbmUgTkggZm9yIHRoZSBTSS9TUEkNCj5tYXRjaCAtIHRodXMgdGhlIHBhdGggaXMg cmVzb2x2ZWQgYW5kIHRoZSBTSS9TUEkgcGF0aCBJUyB0aGUgcmVuZGVyZWQNCj5wYXRoLiAgVGhl IMKzZGlyZWN0ZWTCsiBncmFwaCB0aGF0IHNvbWUgd2FudGVkICh3aGVyZSBlYWNoIGluZGl2aWR1 YWwNCj5lbGVtZW50IGluIGEgbG9jYWxseSBlbGFzdGljIHBvb2wgaXMgaW5kaXZpZHVhbGx5IGFk ZHJlc3NhYmxlIGFuZCBzZXQgYXQNCj5jbGFzc2lmaWNhdGlvbikgaXMgcmVhbGx5IGEgZGVyaXZh dGl2ZSBvZiB0aGUgc2FtZSBjYXNlLg0KPg0KPklmIHRoZXJlIGlzIG1vcmUgdGhhbiBvbmUgTkgg c2VlZGVkIGZvciB0aGUgU0kvU1BJLCB0aGVuIHRoZSBTRkYgZWl0aGVyDQo+d2lsbCB0cmVhdCB0 aGUgZm9yd2FyZGluZyBhcyBFQ01QIChlLmcuIHN0YXRlbGVzcyB0byBhbiBhbnljYXN0IHBvb2wg LQ0KPlNJL1NQSSBJUyB0aGUgcmVuZGVyZWQgcGF0aCksIG9yIGhhdmUgYSBsb2NhbCBwb2xpY3kg dG8gcGVyZm9ybSBhbg0KPmV4cGxpY2l0IG1hcHBpbmcuICBUaGUgU0ZGIG1heSBhbHNvIGJlIGp1 c3QgaGFuZGluZyB0aGUgcGFja2V0IHcvTlNIDQo+aGVhZGVyIG9mZiB0byBhIGxvY2FsIGludGVn cmF0ZWQgZnVuY3Rpb24gKGxpa2UgYSBsb2FkIGJhbGFuY2VyKSBvciBhbg0KPmF0dGFjaGVkIGNv bXBvc2l0ZSBmdW5jdGlvbiB0aGF0IGlzIGhhbmRsaW5nIGFuIGV4cGxpY2l0IG1hcHBpbmcgdG8N Cj5mdW5jdGlvbiBpbnN0YW5jZXMgaXQgZnJvbnRzIChhbmQgbWFuYWdpbmcgc2FtZSBzb21ld2hh dCBvYmxpcXVlbHkgdG8gdGhlDQo+U0ZGIGFuZCB0aGUgcGF0aCBpdHNlbGYpLg0KPg0KPlRoZXNl IG5ldyBjb250ZXh0cyBkb27CuXQgTkVFRCBhbmQgc2hvdWxkbsK5dCBHRVQgYSBzZXBhcmF0ZSBm aWVsZCBpbiB0aGUNCj5nZW5lcmFsIGhlYWRlci4gIElGLCBmb3IgZXhhbXBsZSwgdGhlIHJlc29s dXRpb24vbWFwcGluZyBvZiBlaXRoZXIgdGhlDQo+bG9jYWwgU0ZGIHBvbGljeSAob3IgdGhlIG9i bGlxdWUgZnVuY3Rpb24pIGlzIGEgcG9saWN5IGtleWVkIHRvDQo+Y2xhc3NpZmljYXRpb24gaW5m byBsaWtlIGZsb3dJRCwgdGVuYW50SUQsIHNlc3Npb25JRCwgc29tZXRoaW5nDQo+cHJvcHJpZXRh cnkgLSB3ZWxsLCB5b3XCuXZlIGp1c3QgcmVkZWZpbmVkIHRoZSBuZWVkIGZvciBtZXRhZGF0YSAo b25lIG9mDQo+b3VyIGdvYWxzIHdhcyB0byBiZSBhYmxlIHRvIHByZXNlcnZlIGNsYXNzaWZpZXIg aW5mbyBpbiBtZXRhZGF0YSB0byBhdm9pZA0KPmV4Y2Vzc2l2ZSBjbGFzc2lmaWNhdGlvbiksIHdo aWNoIHdlIGFsbCBhZ3JlZWQgdG8gYWxyZWFkeSAtIGFuZCB3ZSBrbm93DQo+d2hlcmUgdG8gZmlu ZCBzdWNoIGEga2V5IHNvIHRoZXJlwrlzIG5vIG5lZWQgdG8gbW92ZSBpdC4gIChFZGl0b3JpYWwg LSBOb3RlDQo+YWxzbyB0aGUgcG90ZW50aWFsIGZvciB2YXJpYW5jZSBvZiB0aGUga2V5IHNvdXJj ZS92YWx1ZSBhY3Jvc3MNCj5pbXBsZW1lbnRhdGlvbnMuKQ0KPg0KPllvdSBzaG91bGRuJ3QgTkVF RCBhbiBleHBsaWNpdCBSU1AgSUQgaW4gdGhlIGZpeGVkIGhlYWRlci4gIFRoYXQgc2VlbXMgdG8N Cj53b3JrIGJhY2sgYWdhaW5zdCB0aGUgb3JpZ2luYWwgaW1wbGljaXQgZGVzaWduIGdvYWwgb2Yg dGhlIGhlYWRlci4NCj4NCj5JIGR1bm5vLCBpZiBpdMK5cyBqdXN0IG1lLCBJIGhhdmVuwrl0IGRv bmUgcHJvdG9jb2wgZGVzaWduIHNpbmNlIGNvbGxlZ2UgxaANCj5tYXliZSBJwrltIHJ1c3R5IG9y IEkgbmVlZCBzb21ldGhpbmcgc3Ryb25nZXIgdG8gZHJpbmsuDQo+ICANCj4NCj5DaGVlcnMuDQo+ DQo+DQo+T24gMi81LzE1LCAxMTo1NyBBTSwgIlJvbiBQYXJrZXIiIDxSb25fUGFya2VyQGFmZmly bWVkbmV0d29ya3MuY29tPiB3cm90ZToNCj4NCj4+Sm9lbCwNCj4+DQo+PkkgdGhpbmsgeW91IGFy ZSByZWluZm9yY2luZyBhIGtleSBhc3N1bXB0aW9uIGhlcmUgLS0gaWYgdGhlIFNGRiBuZWVkcyB0 aGUNCj4+aW5mb3JtYXRpb24gdG8gZG8gaXRzIGpvYiwgdGhlbiB0aGF0IGluZm9ybWF0aW9uIHNo b3VsZCBiZSBuZWl0aGVyIGluDQo+PlR5cGUgMSBub3IgVHlwZSAyIG1ldGFkYXRhLiAgICBBcyBh biBleGFtcGxlLi4uICBkZXBlbmRpbmcgb24gaG93IG91cg0KPj5jb250aW51aW5nIGRpc2N1c3Np b24gb24gUlNQIElEIGdvZXMgKGkuZSwgdG8gZW5hYmxlIGJvdGggY2VudHJhbGl6ZWQNCj4+Y29u Y3JldGUgUlNQIGRldGVybWluYXRpb24gYW5kIGRpc3RyaWJ1dGVkIGhvcC1ieS1ob3AgInRyYWls LWJsYXplZCIgUlNQDQo+PmRldGVybWluYXRpb24pLCB3ZSBtYXkgd2FudCB0byAicHJvbW90ZSIg UlNQIElEIGZyb20gbWV0YWRhdGEgdG8gdGhlDQo+PnN0YW5kYXJkIGhlYWRlci4NCj4+DQo+PiAg IFJvbg0KPj4NCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IHNmYyBb bWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJu DQo+PlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSA1LCAyMDE1IDExOjM5IEFNDQo+PlRvOiBOaWNv bGFzIEJPVVRIT1JTOyAnc2ZjQGlldGYub3JnJw0KPj5TdWJqZWN0OiBSZTogW3NmY10gZHJhZnQt cXVpbm4tc2ZjLW5zaC0wNSwgb3B0aW9uYWwgaGVhZGVycw0KPj4NCj4+VGhlIG1ldGFkYXRhIGlz IChnZW5lcmFsbHkpIGZvciB0aGUgYVNlcnZpY2UgRnVuY3Rpb25zLCBub3QgZm9yIHRoZSBTRkYu DQo+PiAgU28gdGhlIHF1ZXNpdG9uIG9mIHByb2dyYW1taW5nIHRoZSBTRkYgdG8gcHJvY2VzcyB0 aGUgaW5mb3JtYXRpb24gc2VlbXMNCj4+bm90IGVzcGVjaWFsbHkgbWFqb3IuDQo+Pg0KPj5Nb3Jl IHNpZ25pZmljYW50bHksIGdpdmVuIHRoYXQgdGhlIDE2IGJ5dGUgdHlwZSAxIGZpZWxkIG1heSBj YXJyeQ0KPj5kaWZmZXJlbnQgdGhpbmdzIGluIGRpZmZlcmVudCBjYXNlcywgdGhlIFNGcyB3aWxs IGhhdmUgdG8gYmUgZmxleGlibGUNCj4+YWJvdXQgcHJvY2Vzc2luZyB0aGUgaW5mb3JtYXRpb24g YW55d2F5LiAgU28gYW55dGhpbmcgd2hpY2ggY2FuIGhhbmRsZQ0KPj50aGUgdHlwZSAyIGluZm9y bWF0aW9uIGNhbiBiZSByZWFzb2FuYWJseSBleHBlY3RlZCB0byBoYW5kbGUgdGhlIHNhbWUNCj4+ a2luZHMgb2YgaW5mb3JtYXRpb24gZnJvbSBUTFZzICh3aGV0aGVyIG9uZSBUTFYgb3IgbWFueSku DQo+Pg0KPj5JdCB0aGVyZWZvcmUgc2VlbXMgY2xlYW5lciB0byBtZSB0byByZWNvZ25pemUgdGhh dCB0eXBlIDEgYW5kIHR5cGUgMiBhcmUNCj4+ZGlmZmVyZW50IHdheXMgb2YgY2FycnlpbmcgaW5m b3JtYXRpb24sIGFuZCBqdXN0IHVzZSB0aGUgbWVjaGFuaXNtIGVhY2gNCj4+c3VwcG9ydHMuDQo+ Pg0KPj5Zb3VycywNCj4+Sm9lbA0KPj4NCj4+T24gMi80LzE1IDEyOjA2IFBNLCBOaWNvbGFzIEJP VVRIT1JTIHdyb3RlOg0KPj4+IEl0IGlzIGdyZWF0IHRvIGhhdmUgdGhlIHBvc3NpYmlsaXR5IHRv IGFkZCBvcHRpb25hbCBoZWFkZXJzIGluIE5TSC4NCj4+Pkhvd2V2ZXIsIHRoZSBtZWNoYW5pc20g cHJvcG9zZWQgc3VwcG9zZSB0aGF0IGEgc3BlY2lmaWMgaGVhZGVyIHR5cGUgKHRoZQ0KPj4+IE1E IFR5cGU9MHgyKWlzIHVzZWQgaW4gdGhlIGJhc2UgaGVhZGVyIHdoZW4gb3B0aW9uYWwgbWV0YWRh dGEgYXJlIHVzZWQuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gQXMgYSByZXN1bHQ6DQo+Pj4NCj4+PiAx LlRoZSBiYXNlIGhlYWRlciB0eXBlIDB4MSBjYW5ub3QgYmUgdXNlZCB3aXRoIG9wdGlvbmFsIGhl YWRlcnMuIFdoaWNoDQo+Pj4gbXkgbWFrZSBzZW5zZSBmb3IgcGVyZm9ybWFuY2UgcG9pbnQgb2Yg dmlldw0KPj4+DQo+Pj4gMi5Ob3Igd2hlbiB1c2luZyBoZWFkZXIgTUQgdHlwZSB4MiAgY2FuIHRo ZSAibWFuZGF0b3J5IGNvbnRleHQgaGVhZGVycyINCj4+PiBiZSBwcmVzZW50Lg0KPj4+DQo+Pj4g Q2FzZSAyIGNhbiBiZSB3b3JrZWQgYXJvdW5kIGJ5IGRlZmluaW5nIGFuIG9wdGlvbmFsIGhlYWRl ciB0aGF0DQo+Pj4gcmVwcmVzZW50cyB0aGUgbWFuZGF0b3J5IGNvbnRleHQgaGVhZGVyLiBXaGlj aCBpcyBhd2t3YXJkIGFzIFNGRnMgd2lsbA0KPj4+IGhhdmUgdG8gZGVjb2RlIHRoZSBzYW1lIGlu Zm9ybWF0aW9uIGluIHR3byBkaWZmZXJlbnQgd2F5cy4gTm90DQo+Pj4gcGFydGljdWxhcmx5IGJl YXV0aWZ1bCAhDQo+Pj4NCj4+PiBXaHkgbm90IGhhdmUgYSBmbGFnIChGMilzdGF0aW5nIHRoYXQg bm8gb3B0aW9uYWwgTWV0YWRhdGEgYXJlIHByZXNlbnQNCj4+PiBhbmQgYW5vdGhlciBvbmUgKEYx KSBzdGF0aW5nIHRoYXQgKHdoYXQgaXMgbm93IGNhbGxlZCkgdGhlIG1hbmRhdG9yeQ0KPj4+IGNv bnRleHQgaGVhZGVyIGlzIHByZXNlbnQgb3Igbm90Lg0KPj4+DQo+Pj4gV2UgY2FuIHRoZW4gc3Bl Y2lmeSB0aGF0IHRoZSBjb21iaW5hdGlvbnMNCj4+Pg0KPj4+IEYyPUZhbHNlIGltcGxpZXMgRjE9 VHJ1ZQ0KPj4+DQo+Pj4gRjE9VHJ1ZSwgRjI9VHJ1ZSBpcyBhbGxvd2VkDQo+Pj4NCj4+PiBGMT0g RmFsc2UsIEYyPVRydWUgaXMgYWxsb3dlZA0KPj4+DQo+Pj4gSXQgc2VlbXMgY2xlYW5lci4gV2hl biBwcmVzZW50LCB0aGUgIm1hbmRhdG9yeSBjb250ZXh0IGhlYWRlcnMiIHdvdWxkDQo+Pj4gYWx3 YXlzIGJlIGF0IHRoZSBzYW1lIHBsYWNlIGluIHRoZSBwYWNrZXQuDQo+Pj4NCj4+PiBOaWNvbGFz DQo+Pj4NCj4+PiBUaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyAodGhlICJtZXNzYWdl IikgYXJlIGNvbmZpZGVudGlhbCwNCj4+PiBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSBhZGRyZXNz ZWVzLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQNCj4+PiByZWNpcGllbnQsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZQ0KPj4+IHRo aXMgbWVzc2FnZSBmcm9tIHlvdXIgc3lzdGVtLiBJbiB0aGlzIGNhc2UsIHlvdSBhcmUgbm90IGF1 dGhvcml6ZWQgdG8NCj4+PiB1c2UsIGNvcHkgdGhpcyBtZXNzYWdlIGFuZC9vciBkaXNjbG9zZSB0 aGUgY29udGVudCB0byBhbnkgb3RoZXIgcGVyc29uLg0KPj4+IEUtbWFpbHMgYXJlIHN1c2NlcHRp YmxlIHRvIGFsdGVyYXRpb24uIE5laXRoZXIgUW9zbW9zIG5vciBhbnkgb2YgaXRzDQo+Pj4gc3Vi c2lkaWFyaWVzIG9yIGFmZmlsaWF0ZXMgc2hhbGwgYmUgbGlhYmxlIGZvciB0aGUgbWVzc2FnZSBp ZiBhbHRlcmVkLA0KPj4+IGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPj4+DQo+Pj4gQ2UgbWVzc2Fn ZSBldCB0b3V0ZXMgc2VzIHBpw6hjZXMgam9pbnRlcyAoY2ktYXByw6hzIGxlICJtZXNzYWdlIilz b250DQo+Pj4gY29uZmlkZW50aWVscyBldCDDqXRhYmxpcyDDoCBsJ2ludGVudGlvbiBleGNsdXNp dmUgZGUgc2VzIGRlc3RpbmF0YWlyZXMuDQo+Pj4gU2kgdm91cyBhdmV6IHJlw6d1IGNlIG1lc3Nh Z2UgcGFyIGVycmV1ciwgbWVyY2kgZCdlbiBpbmZvcm1lcg0KPj4+IGltbcOpZGlhdGVtZW50IHNv biDDqW1ldHRldXIgcGFyIGNvdXJyaWVyIMOpbGVjdHJvbmlxdWUgZXQgZCdlZmZhY2VyIGNlDQo+ Pj4gbWVzc2FnZSBkZSB2b3RyZSBzeXN0w6htZS4gRGFucyBjZXR0ZSBoeXBvdGjDqHNlLCB2b3Vz IG4nw6p0ZXMgcGFzDQo+Pj4gYXV0b3Jpc8OpIMOgIHV0aWxpc2VyLCBjb3BpZXIgY2UgbWVzc2Fn ZSBldC9vdSBlbiBkaXZ1bGd1ZXIgbGUgY29udGVudSDDoA0KPj4+dW4gdGllcnMuDQo+Pj4gVG91 dCBtZXNzYWdlIMOpbGVjdHJvbmlxdWUgZXN0IHN1c2NlcHRpYmxlIGQnYWx0w6lyYXRpb24uIFFv c21vcyBldCBzZXMNCj4+PiBmaWxpYWxlcyBkw6ljbGluZW50IHRvdXRlIHJlc3BvbnNhYmlsaXTD qSBhdSB0aXRyZSBkZSBjZSBtZXNzYWdlIHMnaWwgYQ0KPj4+IMOpdMOpIGFsdMOpcsOpLCBkw6lm b3Jtw6kgb3UgZmFsc2lmacOpLg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+ IHNmY0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2ZjDQo+Pj4NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PnNmYyBtYWlsaW5nIGxpc3QNCj4+c2ZjQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5zZmMgbWFpbGluZyBsaXN0DQo+PnNmY0Bp ZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0K Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2ZjIG1h aWxpbmcgbGlzdA0KPnNmY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2ZjDQoNCg== From nobody Fri Feb 6 08:57: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 A0FEF1A7026 for ; Fri, 6 Feb 2015 08:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 E4wQ4YvV8wyI for ; Fri, 6 Feb 2015 08:57:11 -0800 (PST) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [67.231.144.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1564F1A7018 for ; Fri, 6 Feb 2015 08:57:11 -0800 (PST) Received: from pps.filterd (m0048193.ppops.net [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.7/8.14.7) with SMTP id t16G0qwf030150 for ; Fri, 6 Feb 2015 08:57:10 -0800 Received: from hq1wp-exchub01.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1sctkns3cw-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 06 Feb 2015 08:57:10 -0800 Received: from BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) by HQ1WP-EXCHUB01.corp.brocade.com (10.70.36.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 6 Feb 2015 08:57:10 -0800 Received: from BRMWP-EXMB11.corp.brocade.com (172.16.59.77) by BRMWP-EXCHUB01.corp.brocade.com (172.16.186.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 6 Feb 2015 09:57:10 -0700 Received: from BRMWP-EXMB11.corp.brocade.com (172.16.59.77) by BRMWP-EXMB11.corp.brocade.com (172.16.59.77) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 6 Feb 2015 09:57:09 -0700 Received: from BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9]) by BRMWP-EXMB11.corp.brocade.com ([fe80::39a0:e6f2:6a5c:18a9%23]) with mapi id 15.00.1044.021; Fri, 6 Feb 2015 09:57:09 -0700 From: Ramki Krishnan To: "'sfc@ietf.org'" Thread-Topic: New Version Notification for draft-ietf-sfc-long-lived-flow-use-cases-03.txt Thread-Index: AQHQQimPHr46KYzIXUKr1AMOM6Jh7Zzj1yhA Date: Fri, 6 Feb 2015 16:57:08 +0000 Message-ID: <91d1ff5649c04e9cad134aeae640d16c@BRMWP-EXMB11.corp.brocade.com> References: <20150206162528.22782.80495.idtracker@ietfa.amsl.com> In-Reply-To: <20150206162528.22782.80495.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.16.181.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-02-06_06:2015-02-06,2015-02-06,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1502060160 Archived-At: Subject: [sfc] FW: New Version Notification for draft-ietf-sfc-long-lived-flow-use-cases-03.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2015 16:57:12 -0000 UGxlYXNlIGZpbmQgdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBhZGRyZXNzaW5nIGFs bCB0aGUgY29tbWVudHMgZXNwZWNpYWxseSB0aGUgb25lcyBmcm9tIFRpcnUuDQoNClRoYW5rcywN ClJhbWtpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogRnJp ZGF5LCBGZWJydWFyeSAwNiwgMjAxNSA4OjI1IEFNDQpUbzogU3JpZ2FuZXNoIEtpbmk7IFNyaWdh bmVzaCBLaW5pOyBKb2VsIEhhbHBlcm47IEpvZWwgTS4gSGFscGVybjsgRGllZ28gTG9wZXo7IFJh bWtpIEtyaXNobmFuOyBEaWVnbyBMb3BlejsgQW5vb3AgR2hhbndhbmk7IFJhbWtpIEtyaXNobmFu OyBBbm9vcCBHaGFud2FuaQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1pZXRmLXNmYy1sb25nLWxpdmVkLWZsb3ctdXNlLWNhc2VzLTAzLnR4dA0KDQoNCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXNmYy1sb25nLWxpdmVkLWZsb3ctdXNlLWNhc2Vz LTAzLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSByYW0gKHJhbWtpKSBr cmlzaG5hbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFm dC1pZXRmLXNmYy1sb25nLWxpdmVkLWZsb3ctdXNlLWNhc2VzDQpSZXZpc2lvbjoJMDMNClRpdGxl OgkJU0ZDIExvbmctbGl2ZWQgRmxvdyBVc2UgQ2FzZXMNCkRvY3VtZW50IGRhdGU6CTIwMTUtMDIt MDYNCkdyb3VwOgkJc2ZjDQpQYWdlczoJCTEwDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1zZmMtbG9uZy1saXZlZC1mbG93LXVz ZS1jYXNlcy0wMy50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXNmYy1sb25nLWxpdmVkLWZsb3ctdXNlLWNhc2VzLw0KSHRtbGl6 ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc2ZjLWxvbmct bGl2ZWQtZmxvdy11c2UtY2FzZXMtMDMNCkRpZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNmYy1sb25nLWxpdmVkLWZsb3ctdXNlLWNhc2Vz LTAzDQoNCkFic3RyYWN0Og0KICAgTG9uZy1saXZlZCBmbG93cyBzdWNoIGFzIGZpbGUgdHJhbnNm ZXJzLCB2aWRlbyBzdHJlYW1zIGFyZSBjb21tb24gaW4NCiAgIHRvZGF5J3MgbmV0d29ya3MuIElu IHRoZSBjb250ZXh0IG9mIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcsIHRoaXMNCiAgIGRyYWZ0 IHN1Z2dlc3RzIHVzZSBjYXNlcyBmb3IgZHluYW1pYyBieXBhc3Mgb2YgY2VydGFpbiBzZXJ2aWNl DQogICBmdW5jdGlvbnMgZm9yIHN1Y2ggZmxvd3MuIFRoZSBiZW5lZml0IG9mIHRoaXMgYXBwcm9h Y2ggd291bGQgYmUgdG8NCiAgIGF2b2lkIGV4cGVuc2l2ZSBMYXllciA3IHNlcnZpY2UgZnVuY3Rp b24gcHJvY2Vzc2luZyBmb3Igc3VjaCBmbG93cw0KICAgYmFzZWQgb24gZHluYW1pYyBkZWNpc2lv bnMgYW5kIHRodXMgaW1wcm92ZSBvdmVyYWxsIHBlcmZvcm1hbmNlLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQg dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUg SUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Fri Feb 6 10:36: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 71A631A19E3 for ; Fri, 6 Feb 2015 10:36:55 -0800 (PST) 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 PkbI42pQPksJ for ; Fri, 6 Feb 2015 10:36:52 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0283C1A1A52 for ; Fri, 6 Feb 2015 10:36:52 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0224.002; Fri, 6 Feb 2015 10:36:51 -0800 From: Ron Parker To: "Ken Gray (kegray)" , Wenzhe Zhou , "Joel M. Halpern" , "Nicolas BOUTHORS" , "'sfc@ietf.org'" Thread-Topic: [sfc] draft-quinn-sfc-nsh-05, optional headers Thread-Index: AdBAmYhGpM3EkfNlQ4eMZ3oRb+Ov2QBC7nyAABBDrQAAAATGgAAOiTxwABQciIAADeNUIA== Date: Fri, 6 Feb 2015 18:36:50 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D7D2D2F@LILAS.jungle.qosmos.com> <54D39C93.8050704@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers 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, 06 Feb 2015 18:36:55 -0000 S2VuLA0KDQpDZXJ0YWlubHksIHRoZXJlIGlzIGEgY29uY2VwdCB0aGF0IGEgbmljZSBzaW1wbGUg ZGVwbG95bWVudCBvZiBTRkMgaXMgdG8gaGF2ZSAxIGxvZ2ljYWwgaW5zdGFuY2Ugb2YgZWFjaCBz ZXJ2aWNlIGZ1bmN0aW9uIHZpc2libGUgYXQgdGhlIFNGQyBsYXllci4gICBIb3cgZWFjaCBvZiB0 aG9zZSBpbnN0YW5jZXMgc2NhbGVzIGlzIGl0cyBvd24gYnVzaW5lc3MuICAgQW5kLCBjZXJ0YWlu bHksIHRoZSBhcmNoaXRlY3R1cmUgc3VwcG9ydHMgdGhhdC4gICANCg0KQnV0LCBkb2VzIHRoYXQg YWRlcXVhdGVseSBzYXRpc2Z5IGFsbCBwb3NzaWJsZSB1c2VzIGNhc2VzIGFuZCBkZXBsb3ltZW50 IHNjZW5hcmlvcyB3ZSBjYW4gY29uc3RydWN0IGZvciBTRkM/ICAgIEhlcmUgYXJlIHNvbWUgdXNl IGNhc2VzIHRoYXQgc3VnZ2VzdCB0aGUgYWJvdmUgY29uY2VwdCBpcyBuZWNlc3NhcnkgYnV0IG5v dCBzdWZmaWNpZW50Og0KDQpXaGF0IGlmIHRoZSByZWFsLXdvcmxkIHNjYWxlIG9mIG9uZSBvZiB0 aGVzZSBpbnRlcm5hbGx5IHNjYWxhYmxlIGluc3RhbmNlcyBpcyBzdGlsbCBpbnN1ZmZpY2llbnQ/ ICANCg0KV2hhdCBpZiBhIGhpZ2hlciBsZXZlbCBvZiByZWR1bmRhbmN5IGlzIGRlc2lyZWQgYnkg ZGVwbG95aW5nIG1vcmUgdGhhbiBvbmUgb2YgdGhvc2UgaW50ZXJuYWxseSBzY2FsYWJsZSBpbnN0 YW5jZXM/ICAgTW9yZSB0aGFuIDIgb2YgdGhlbT8gICAgDQoNCldoYXQgaWYgdGhlIFNGQyBpcyBl eHRlbmRlZCBhY3Jvc3MgdGhlIE1BTiBhbmQgV0FOIChhbmQgdG8gYXZvaWQgYXJndW1lbnQsIGxl dCdzIHNheSB3ZSBhcmUgc3RpbGwgaW4gdGhlIHNhbWUgYWRtaW5pc3RyYXRpdmUgZG9tYWluKT8g ICBXaGF0IGlmIHdlIHdhbnQgdG8gYXBwbHkgbG9jYXRpb24gYXdhcmVuZXNzIHRvIGluc3RhbmNl IHNlbGVjdGlvbiBpbiBvcmRlciB0byBvcHRpbWl6ZSB0aGUgb3ZlcmFsbCBiZWhhdmlvcj8NCg0K V2hhdCBpZiB3ZSB3YW50IHRvIHN1cHBvcnQgb3RoZXIgaW5zdGFuY2Ugc2VsZWN0aW9uIGNyaXRl cmlhLCBsaWtlIGdvbGQgY3VzdG9tZXJzIGdldCBvbiB0aGUgaGlnaGVyIHBlcmZvcm1hbmNlIFJT UCBmb3IgYSBwYXJ0aWN1bGFyIGZ1bmN0aW9uYWwgY2hhaW4gYnV0IGJyb256ZSBjdXN0b21lcnMg dGhlIGxvd2VyIHBlcmZvcm1hbmNlIFJTUCBmb3IgdGhhdCBzYW1lIGZ1bmN0aW9uYWwgY2hhaW4/ DQoNCkFuZCwgYWx0aG91Z2ggaXQgaXMgbm90IGEgZnVuY3Rpb25hbCB1c2UgY2FzZSBpbiB0aGUg c2FtZSBtYW5uZXIgYXMgYWJvdmUsIHdoYXQgaWYgc29tZSBuZXR3b3JrIGRlc2lnbmVycyBkZXRl cm1pbmUgaXQgaXMgY2hlYXBlciBhbmQgc2ltcGxlciB0byBkZXBsb3kgU0ZDIHVzaW5nIHNlcnZp Y2UgZnVuY3Rpb24gaW5zdGFuY2VzIHRoYXQgYXJlIHNpbXBsZXIgYW5kIGRvbid0IGhhdmUgaW5i dWlsdCBob3Jpem9udGFsIHNjYWxlPyAgIE1vcmUgYWxvbmcgdGhlIGxpbmVzIG9mIHRoZSAiZml0 IFZORiIgYXBwcm9hY2ggKGF0dHJpYnV0aW9uIHRvIENvbnRleHRyZWFtKS4NCg0KVGhlIGdyb3Vw J3MgcHJvcG9zZWQgc29sdXRpb24gc2hvdWxkIGJlIG1lYXN1cmVkIGFnYWluc3QgdGhlIHVzZSBj YXNlcyBhbmQgYW5kIGRlcGxveW1lbnQgc2NlbmFyaW9zIHdlIGZlZWwgbmVlZCB0byBiZSBhZGRy ZXNzZWQsIGFuZCB0aGlzIGlzIHByb2JhYmx5IHRoZSBtYWluIGRpZmZlcmVuY2UgaW4gdmlld3Bv aW50LCBoZXJlLiAgICBUbyBmb2xsb3cgb24gdG8gS2VuJ3MgY29sbG9xdWlhbGlzbSwgbXkgb3Bp bmlvbiBpcyB0aGF0IHRoZSBob3JzZSBpcyBub3QgZGVhZCBhbmQgdGhhdCB0aGUgZGlmZmVyZW50 IHZpZXdwb2ludHMgZG8gbm90IHJlZmxlY3QgYSBmdW5kYW1lbnRhbCBpbmFiaWxpdHkgdG8gZ3Jh c3AgdGhlIGNvbmNlcHRzLg0KDQpUaGFua3MuDQoNCiAgIFJvbg0KDQoNCg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogS2VuIEdyYXkgKGtlZ3JheSkgW21haWx0bzprZWdyYXlA Y2lzY28uY29tXSANClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgNiwgMjAxNSAxMTo1NyBBTQ0KVG86 IFdlbnpoZSBaaG91OyBSb24gUGFya2VyOyBKb2VsIE0uIEhhbHBlcm47IE5pY29sYXMgQk9VVEhP UlM7ICdzZmNAaWV0Zi5vcmcnDQpTdWJqZWN0OiBSZTogW3NmY10gZHJhZnQtcXVpbm4tc2ZjLW5z aC0wNSwgb3B0aW9uYWwgaGVhZGVycw0KDQpJbiBteSB3b3JkcywgSSBhbSBub3Qgc3VnZ2VzdGlu ZyBjaGFuZ2luZyB0aGUgZHJhZnQgYXQgYWxsLiAgSSB0aGluayBpdOKAmXMgc3VmZmljaWVudC4g DQoNCg0KTXkgb3BpbmlvbiwgaXMgdGhhdCB0aGUgc3VnZ2VzdGVkIGNoYW5nZXMgaW4gdGhpcyB0 aHJlYWQgc2hvdyBhIGZ1bmRhbWVudGFsIGZhaWx1cmUgdG8gZ3Jhc3AgdGhlIGNvbmNlcHRzIHdl IGhhc2hlZCBvdXQgaW4gdGhlIGFyY2hpdGVjdHVyZSAod2hpY2ggSSBhdHRlbXB0ZWQgdG8gY2xh cmlmeSkuICBJbiBteSBvcGluaW9uLCB0byB1c2UgYW4gdW5mb3J0dW5hdGUgY29sbG9xdWlhbGlz bSAtIHRoaXMgaG9yc2UgaXMgZGVhZCwgd2Ugc2hvdWxkIHN0b3AgYmVhdGluZyBpdC4NCg0KT24g Mi82LzE1LCAxMDoyOCBBTSwgIldlbnpoZSBaaG91IiA8V2VuemhlLlpob3VAaHVhd2VpLmNvbT4g d3JvdGU6DQoNCj5LZW4sDQo+DQo+SW4geW91ciB3b3JkcywgbWFuZGF0b3J5IGNvbnRleHQgaGVh ZGVycyBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIE5TSC4NCj4NCj5XZW56aGUNCj4gDQo+DQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEtlbiBHcmF5IChrZWdyYXkpDQo+U2VudDogVGh1cnNkYXks IEZlYnJ1YXJ5IDA1LCAyMDE1IDQ6MjUgUE0NCj5UbzogUm9uIFBhcmtlcjsgSm9lbCBNLiBIYWxw ZXJuOyBOaWNvbGFzIEJPVVRIT1JTOyAnc2ZjQGlldGYub3JnJw0KPlN1YmplY3Q6IFJlOiBbc2Zj XSBkcmFmdC1xdWlubi1zZmMtbnNoLTA1LCBvcHRpb25hbCBoZWFkZXJzDQo+DQo+SSB0aGluayB0 aGVyZcK5cyBhIGRpc2Nvbm5lY3Rpb24gaGVyZSAoY291bGQgYmUgbWUpIGJldHdlZW4gdGhlIGlk ZWEgb2YgDQo+YW4gYWJzdHJhY3QgYW5kIHNwZWNpZmljIHBhdGguDQo+DQo+SSB0aG91Z2h0IGl0 IHdhcyBwcmV0dHkgY2xlYXIgKGFuZCB0aGVyZSB3YXMgc2lnbmlmaWNhbnQgdGFsayBhYm91dCBp dCANCj5oZXJlIG9uIHRoZSBsaXN0KSB0aGF0IHlvdSBjYW4ndCBtYW5kYXRlIGEgc3BlY2lmaWMg bW9kZWwgb2YgZnVuY3Rpb24gDQo+ZWxhc3RpY2l0eSAtIHdlIGNvdWxkbsK5dCBkZWNsYXJlIGxv YWQgYmFsYW5jaW5nIGRldmljZXMgb3IgZnVuY3Rpb25zIA0KPsKzZGVhZMKyIGJ1dCBpbnN0ZWFk IGFzc3VtZWQgdGhhdCBlbGFzdGljaXR5IGNvdWxkIGJlIGRvbmUgbG9jYWxseSBhcyBhIA0KPlNG LCBhcyBwYXJ0IG9mIGEgY29tcG9zaXRlIGZ1bmN0aW9uIHdoZXJlIHRoZSBsb2FkIGJhbGFuY2Vy IGV4aXN0cyBhcyANCj5wYXJ0IG9mIHRoZSBsb2dpY2FsIGZ1bmN0aW9uIGJlaW5nIHJlbmRlcmVk IG9yIGNlbnRyYWxseS9zdGF0aWNhbGx5LiAgDQo+V2UgaGFkIHNpbWlsYXIgZGlhbG9ndWVzIGFi b3V0IHRoZSBuZWVkIHRvIHJlbWFpbiBhYnN0cmFjdCBhcm91bmQgSEEgDQo+dGVjaG5pcXVlcyBh cyB3ZWxsLg0KPg0KPlRoZXNlIHRoaW5ncyBtYWtlIEFOIGluZGl2aWR1YWwgcGF0aCwgd2hpY2gg cmVwcmVzZW50cyBhIGNoYWluIHRoYXQgDQo+Zml0cyBhIHNwZWNpZmljIHBvbGljeSBydWxlc2V0 IMWgIHZhcmlhYmxlIMWgIGFuZCB3ZSBkaWRuwrl0IHdhbnQgdG8gDQo+dW5uZWNlc3NhcmlseSBk ZWZpbmUgbXVsdGlwbGUgZGlzY3JldGUgY2hhaW5zIHRvIGNvdmVyIHRoaXMgc29ydCBvZiANCj5m dW5jdGlvbiB2YXJpYW5jZSAod2hpY2ggY2FuIGJlY29tZSBxdWl0ZSBsYXJnZSwgaWYgZm9yIGV4 YW1wbGUgdGhlIA0KPmZ1bmN0aW9uIFggYXQgc2l0ZSBZIGlzIGFjdHVhbGx5IDEwMDAgcGFyYWxs ZWwgaW5zdGFuY2VzIHRvIGFjY29tbW9kYXRlIA0KPmxvYWQsIHdpdGggSEEgYWRkIGEgbXVsdGlw bGllciwgcGVyIGZ1bmN0aW9uIG1vcmUgbXVsdGlwbGllcnMgxaBmb3IgYSANCj5zaW5nbGUgcGF0 aCB0aGF0IGF0IHRoZSBhYnN0cmFjdCBsZXZlbCwgdHJhdmVyc2VkIHRoZSBzYW1lIHNpdGVzIMWg Ym9vbSkuDQo+DQo+VGhlc2UgZGlhbG9ndWVzIGFyZSBjYXB0dXJlZCBpbiB0aGUgYXJjaGl0ZWN0 dXJlIGRvY3VtZW50Lg0KPg0KPlNvLCB3aGVuIEkgcmVhZCB0aGUgTlNIIGRyYWZ0LCBJIGludGVy cHJldGVkIHRoZSB0cmVhdG1lbnQgb2YgdGhlIFNQSSANCj5hbmQgdGhlIFJlc29sdmVkIFBhdGgg YXMgdmVyeSBjb21wYXRpYmxlIHdpdGggdGhhdCBhYnN0cmFjdGlvbi9jb25jZXB0LiANCj5JdCBt YWtlcyBtdWx0aXBsZSBkZXBsb3ltZW50IGNvbnRleHRzIHVuZGVyc3RhbmRhYmxlIGFuZCBwb3Nz aWJsZSANCj53aXRob3V0IG92ZXJseSBkZWZpbmluZyB0aGUgaGVhZGVyIHdpdGggcG90ZW50aWFs bHkgdXNlbGVzcyBmaWVsZHMgZm9yIA0KPmV2ZXJ5IGl0ZXJhYmxlIGNhc2UuIChFZGl0b3JpYWwg LSBLaW5kIG9mIGFuIGFydCBmb3JtIHRoYXQgd2Ugc2hvdWxkIA0KPmNlbGVicmF0ZSwgSU1PLCBp ZiBwZW9wbGUgYXJlIGdvaW5nIGFib3V0IGRlc2lnbmluZyBwcm90b2NvbHMuKQ0KPg0KPkZvciBl eGFtcGxlLCB0aGUgU0ZGIGNhbiBiZSBzZWVkZWQgd2l0aCBvbmUgYW5kIG9ubHkgb25lIE5IIGZv ciB0aGUgDQo+U0kvU1BJIG1hdGNoIC0gdGh1cyB0aGUgcGF0aCBpcyByZXNvbHZlZCBhbmQgdGhl IFNJL1NQSSBwYXRoIElTIHRoZSANCj5yZW5kZXJlZCBwYXRoLiAgVGhlIMKzZGlyZWN0ZWTCsiBn cmFwaCB0aGF0IHNvbWUgd2FudGVkICh3aGVyZSBlYWNoIA0KPmluZGl2aWR1YWwgZWxlbWVudCBp biBhIGxvY2FsbHkgZWxhc3RpYyBwb29sIGlzIGluZGl2aWR1YWxseSANCj5hZGRyZXNzYWJsZSBh bmQgc2V0IGF0DQo+Y2xhc3NpZmljYXRpb24pIGlzIHJlYWxseSBhIGRlcml2YXRpdmUgb2YgdGhl IHNhbWUgY2FzZS4NCj4NCj5JZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIE5IIHNlZWRlZCBmb3Ig dGhlIFNJL1NQSSwgdGhlbiB0aGUgU0ZGIGVpdGhlciANCj53aWxsIHRyZWF0IHRoZSBmb3J3YXJk aW5nIGFzIEVDTVAgKGUuZy4gc3RhdGVsZXNzIHRvIGFuIGFueWNhc3QgcG9vbCAtIA0KPlNJL1NQ SSBJUyB0aGUgcmVuZGVyZWQgcGF0aCksIG9yIGhhdmUgYSBsb2NhbCBwb2xpY3kgdG8gcGVyZm9y bSBhbiANCj5leHBsaWNpdCBtYXBwaW5nLiAgVGhlIFNGRiBtYXkgYWxzbyBiZSBqdXN0IGhhbmRp bmcgdGhlIHBhY2tldCB3L05TSCANCj5oZWFkZXIgb2ZmIHRvIGEgbG9jYWwgaW50ZWdyYXRlZCBm dW5jdGlvbiAobGlrZSBhIGxvYWQgYmFsYW5jZXIpIG9yIGFuIA0KPmF0dGFjaGVkIGNvbXBvc2l0 ZSBmdW5jdGlvbiB0aGF0IGlzIGhhbmRsaW5nIGFuIGV4cGxpY2l0IG1hcHBpbmcgdG8gDQo+ZnVu Y3Rpb24gaW5zdGFuY2VzIGl0IGZyb250cyAoYW5kIG1hbmFnaW5nIHNhbWUgc29tZXdoYXQgb2Js aXF1ZWx5IHRvIA0KPnRoZSBTRkYgYW5kIHRoZSBwYXRoIGl0c2VsZikuDQo+DQo+VGhlc2UgbmV3 IGNvbnRleHRzIGRvbsK5dCBORUVEIGFuZCBzaG91bGRuwrl0IEdFVCBhIHNlcGFyYXRlIGZpZWxk IGluIHRoZSANCj5nZW5lcmFsIGhlYWRlci4gIElGLCBmb3IgZXhhbXBsZSwgdGhlIHJlc29sdXRp b24vbWFwcGluZyBvZiBlaXRoZXIgdGhlIA0KPmxvY2FsIFNGRiBwb2xpY3kgKG9yIHRoZSBvYmxp cXVlIGZ1bmN0aW9uKSBpcyBhIHBvbGljeSBrZXllZCB0byANCj5jbGFzc2lmaWNhdGlvbiBpbmZv IGxpa2UgZmxvd0lELCB0ZW5hbnRJRCwgc2Vzc2lvbklELCBzb21ldGhpbmcgDQo+cHJvcHJpZXRh cnkgLSB3ZWxsLCB5b3XCuXZlIGp1c3QgcmVkZWZpbmVkIHRoZSBuZWVkIGZvciBtZXRhZGF0YSAo b25lIG9mIA0KPm91ciBnb2FscyB3YXMgdG8gYmUgYWJsZSB0byBwcmVzZXJ2ZSBjbGFzc2lmaWVy IGluZm8gaW4gbWV0YWRhdGEgdG8gDQo+YXZvaWQgZXhjZXNzaXZlIGNsYXNzaWZpY2F0aW9uKSwg d2hpY2ggd2UgYWxsIGFncmVlZCB0byBhbHJlYWR5IC0gYW5kIA0KPndlIGtub3cgd2hlcmUgdG8g ZmluZCBzdWNoIGEga2V5IHNvIHRoZXJlwrlzIG5vIG5lZWQgdG8gbW92ZSBpdC4gIA0KPihFZGl0 b3JpYWwgLSBOb3RlIGFsc28gdGhlIHBvdGVudGlhbCBmb3IgdmFyaWFuY2Ugb2YgdGhlIGtleSAN Cj5zb3VyY2UvdmFsdWUgYWNyb3NzDQo+aW1wbGVtZW50YXRpb25zLikNCj4NCj5Zb3Ugc2hvdWxk bid0IE5FRUQgYW4gZXhwbGljaXQgUlNQIElEIGluIHRoZSBmaXhlZCBoZWFkZXIuICBUaGF0IHNl ZW1zIA0KPnRvIHdvcmsgYmFjayBhZ2FpbnN0IHRoZSBvcmlnaW5hbCBpbXBsaWNpdCBkZXNpZ24g Z29hbCBvZiB0aGUgaGVhZGVyLg0KPg0KPkkgZHVubm8sIGlmIGl0wrlzIGp1c3QgbWUsIEkgaGF2 ZW7CuXQgZG9uZSBwcm90b2NvbCBkZXNpZ24gc2luY2UgY29sbGVnZSANCj7FoCBtYXliZSBJwrlt IHJ1c3R5IG9yIEkgbmVlZCBzb21ldGhpbmcgc3Ryb25nZXIgdG8gZHJpbmsuDQo+ICANCj4NCj5D aGVlcnMuDQo+DQo+DQo+T24gMi81LzE1LCAxMTo1NyBBTSwgIlJvbiBQYXJrZXIiIDxSb25fUGFy a2VyQGFmZmlybWVkbmV0d29ya3MuY29tPiB3cm90ZToNCj4NCj4+Sm9lbCwNCj4+DQo+PkkgdGhp bmsgeW91IGFyZSByZWluZm9yY2luZyBhIGtleSBhc3N1bXB0aW9uIGhlcmUgLS0gaWYgdGhlIFNG RiBuZWVkcyANCj4+dGhlIGluZm9ybWF0aW9uIHRvIGRvIGl0cyBqb2IsIHRoZW4gdGhhdCBpbmZv cm1hdGlvbiBzaG91bGQgYmUgbmVpdGhlciBpbg0KPj5UeXBlIDEgbm9yIFR5cGUgMiBtZXRhZGF0 YS4gICAgQXMgYW4gZXhhbXBsZS4uLiAgZGVwZW5kaW5nIG9uIGhvdyBvdXINCj4+Y29udGludWlu ZyBkaXNjdXNzaW9uIG9uIFJTUCBJRCBnb2VzIChpLmUsIHRvIGVuYWJsZSBib3RoIGNlbnRyYWxp emVkIA0KPj5jb25jcmV0ZSBSU1AgZGV0ZXJtaW5hdGlvbiBhbmQgZGlzdHJpYnV0ZWQgaG9wLWJ5 LWhvcCAidHJhaWwtYmxhemVkIiANCj4+UlNQIGRldGVybWluYXRpb24pLCB3ZSBtYXkgd2FudCB0 byAicHJvbW90ZSIgUlNQIElEIGZyb20gbWV0YWRhdGEgdG8gDQo+PnRoZSBzdGFuZGFyZCBoZWFk ZXIuDQo+Pg0KPj4gICBSb24NCj4+DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj5Gcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpv ZWwgTS4gSGFscGVybg0KPj5TZW50OiBUaHVyc2RheSwgRmVicnVhcnkgNSwgMjAxNSAxMTozOSBB TQ0KPj5UbzogTmljb2xhcyBCT1VUSE9SUzsgJ3NmY0BpZXRmLm9yZycNCj4+U3ViamVjdDogUmU6 IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1uc2gtMDUsIG9wdGlvbmFsIGhlYWRlcnMNCj4+DQo+PlRo ZSBtZXRhZGF0YSBpcyAoZ2VuZXJhbGx5KSBmb3IgdGhlIGFTZXJ2aWNlIEZ1bmN0aW9ucywgbm90 IGZvciB0aGUgU0ZGLg0KPj4gIFNvIHRoZSBxdWVzaXRvbiBvZiBwcm9ncmFtbWluZyB0aGUgU0ZG IHRvIHByb2Nlc3MgdGhlIGluZm9ybWF0aW9uIA0KPj5zZWVtcyBub3QgZXNwZWNpYWxseSBtYWpv ci4NCj4+DQo+Pk1vcmUgc2lnbmlmaWNhbnRseSwgZ2l2ZW4gdGhhdCB0aGUgMTYgYnl0ZSB0eXBl IDEgZmllbGQgbWF5IGNhcnJ5IA0KPj5kaWZmZXJlbnQgdGhpbmdzIGluIGRpZmZlcmVudCBjYXNl cywgdGhlIFNGcyB3aWxsIGhhdmUgdG8gYmUgZmxleGlibGUgDQo+PmFib3V0IHByb2Nlc3Npbmcg dGhlIGluZm9ybWF0aW9uIGFueXdheS4gIFNvIGFueXRoaW5nIHdoaWNoIGNhbiBoYW5kbGUgDQo+ PnRoZSB0eXBlIDIgaW5mb3JtYXRpb24gY2FuIGJlIHJlYXNvYW5hYmx5IGV4cGVjdGVkIHRvIGhh bmRsZSB0aGUgc2FtZSANCj4+a2luZHMgb2YgaW5mb3JtYXRpb24gZnJvbSBUTFZzICh3aGV0aGVy IG9uZSBUTFYgb3IgbWFueSkuDQo+Pg0KPj5JdCB0aGVyZWZvcmUgc2VlbXMgY2xlYW5lciB0byBt ZSB0byByZWNvZ25pemUgdGhhdCB0eXBlIDEgYW5kIHR5cGUgMiANCj4+YXJlIGRpZmZlcmVudCB3 YXlzIG9mIGNhcnJ5aW5nIGluZm9ybWF0aW9uLCBhbmQganVzdCB1c2UgdGhlIG1lY2hhbmlzbSAN Cj4+ZWFjaCBzdXBwb3J0cy4NCj4+DQo+PllvdXJzLA0KPj5Kb2VsDQo+Pg0KPj5PbiAyLzQvMTUg MTI6MDYgUE0sIE5pY29sYXMgQk9VVEhPUlMgd3JvdGU6DQo+Pj4gSXQgaXMgZ3JlYXQgdG8gaGF2 ZSB0aGUgcG9zc2liaWxpdHkgdG8gYWRkIG9wdGlvbmFsIGhlYWRlcnMgaW4gTlNILg0KPj4+SG93 ZXZlciwgdGhlIG1lY2hhbmlzbSBwcm9wb3NlZCBzdXBwb3NlIHRoYXQgYSBzcGVjaWZpYyBoZWFk ZXIgdHlwZSANCj4+Pih0aGUgIE1EIFR5cGU9MHgyKWlzIHVzZWQgaW4gdGhlIGJhc2UgaGVhZGVy IHdoZW4gb3B0aW9uYWwgbWV0YWRhdGEgYXJlIHVzZWQuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gQXMg YSByZXN1bHQ6DQo+Pj4NCj4+PiAxLlRoZSBiYXNlIGhlYWRlciB0eXBlIDB4MSBjYW5ub3QgYmUg dXNlZCB3aXRoIG9wdGlvbmFsIGhlYWRlcnMuIA0KPj4+IFdoaWNoIG15IG1ha2Ugc2Vuc2UgZm9y IHBlcmZvcm1hbmNlIHBvaW50IG9mIHZpZXcNCj4+Pg0KPj4+IDIuTm9yIHdoZW4gdXNpbmcgaGVh ZGVyIE1EIHR5cGUgeDIgIGNhbiB0aGUgIm1hbmRhdG9yeSBjb250ZXh0IGhlYWRlcnMiDQo+Pj4g YmUgcHJlc2VudC4NCj4+Pg0KPj4+IENhc2UgMiBjYW4gYmUgd29ya2VkIGFyb3VuZCBieSBkZWZp bmluZyBhbiBvcHRpb25hbCBoZWFkZXIgdGhhdCANCj4+PiByZXByZXNlbnRzIHRoZSBtYW5kYXRv cnkgY29udGV4dCBoZWFkZXIuIFdoaWNoIGlzIGF3a3dhcmQgYXMgU0ZGcyANCj4+PiB3aWxsIGhh dmUgdG8gZGVjb2RlIHRoZSBzYW1lIGluZm9ybWF0aW9uIGluIHR3byBkaWZmZXJlbnQgd2F5cy4g Tm90IA0KPj4+IHBhcnRpY3VsYXJseSBiZWF1dGlmdWwgIQ0KPj4+DQo+Pj4gV2h5IG5vdCBoYXZl IGEgZmxhZyAoRjIpc3RhdGluZyB0aGF0IG5vIG9wdGlvbmFsIE1ldGFkYXRhIGFyZSANCj4+PiBw cmVzZW50IGFuZCBhbm90aGVyIG9uZSAoRjEpIHN0YXRpbmcgdGhhdCAod2hhdCBpcyBub3cgY2Fs bGVkKSB0aGUgDQo+Pj4gbWFuZGF0b3J5IGNvbnRleHQgaGVhZGVyIGlzIHByZXNlbnQgb3Igbm90 Lg0KPj4+DQo+Pj4gV2UgY2FuIHRoZW4gc3BlY2lmeSB0aGF0IHRoZSBjb21iaW5hdGlvbnMNCj4+ Pg0KPj4+IEYyPUZhbHNlIGltcGxpZXMgRjE9VHJ1ZQ0KPj4+DQo+Pj4gRjE9VHJ1ZSwgRjI9VHJ1 ZSBpcyBhbGxvd2VkDQo+Pj4NCj4+PiBGMT0gRmFsc2UsIEYyPVRydWUgaXMgYWxsb3dlZA0KPj4+ DQo+Pj4gSXQgc2VlbXMgY2xlYW5lci4gV2hlbiBwcmVzZW50LCB0aGUgIm1hbmRhdG9yeSBjb250 ZXh0IGhlYWRlcnMiIA0KPj4+IHdvdWxkIGFsd2F5cyBiZSBhdCB0aGUgc2FtZSBwbGFjZSBpbiB0 aGUgcGFja2V0Lg0KPj4+DQo+Pj4gTmljb2xhcw0KPj4+DQo+Pj4gVGhpcyBtZXNzYWdlIGFuZCBh bnkgYXR0YWNobWVudHMgKHRoZSAibWVzc2FnZSIpIGFyZSBjb25maWRlbnRpYWwsIA0KPj4+IGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZXMuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCANCj4+PiByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBieSBlLW1haWwgYW5kIGRlbGV0ZSANCj4+PiB0aGlzIG1lc3NhZ2UgZnJvbSB5b3VyIHN5c3Rl bS4gSW4gdGhpcyBjYXNlLCB5b3UgYXJlIG5vdCBhdXRob3JpemVkIA0KPj4+IHRvIHVzZSwgY29w eSB0aGlzIG1lc3NhZ2UgYW5kL29yIGRpc2Nsb3NlIHRoZSBjb250ZW50IHRvIGFueSBvdGhlciBw ZXJzb24uDQo+Pj4gRS1tYWlscyBhcmUgc3VzY2VwdGlibGUgdG8gYWx0ZXJhdGlvbi4gTmVpdGhl ciBRb3Ntb3Mgbm9yIGFueSBvZiBpdHMgDQo+Pj4gc3Vic2lkaWFyaWVzIG9yIGFmZmlsaWF0ZXMg c2hhbGwgYmUgbGlhYmxlIGZvciB0aGUgbWVzc2FnZSBpZiANCj4+PiBhbHRlcmVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4NCj4+Pg0KPj4+IENlIG1lc3NhZ2UgZXQgdG91dGVzIHNlcyBwacOoY2Vz IGpvaW50ZXMgKGNpLWFwcsOocyBsZSAibWVzc2FnZSIpc29udCAgDQo+Pj5jb25maWRlbnRpZWxz IGV0IMOpdGFibGlzIMOgIGwnaW50ZW50aW9uIGV4Y2x1c2l2ZSBkZSBzZXMgZGVzdGluYXRhaXJl cy4NCj4+PiBTaSB2b3VzIGF2ZXogcmXDp3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCBtZXJjaSBk J2VuIGluZm9ybWVyICANCj4+PmltbcOpZGlhdGVtZW50IHNvbiDDqW1ldHRldXIgcGFyIGNvdXJy aWVyIMOpbGVjdHJvbmlxdWUgZXQgZCdlZmZhY2VyIGNlICANCj4+Pm1lc3NhZ2UgZGUgdm90cmUg c3lzdMOobWUuIERhbnMgY2V0dGUgaHlwb3Row6hzZSwgdm91cyBuJ8OqdGVzIHBhcyAgDQo+Pj5h dXRvcmlzw6kgw6AgdXRpbGlzZXIsIGNvcGllciBjZSBtZXNzYWdlIGV0L291IGVuIGRpdnVsZ3Vl ciBsZSBjb250ZW51IA0KPj4+w6AgdW4gdGllcnMuDQo+Pj4gVG91dCBtZXNzYWdlIMOpbGVjdHJv bmlxdWUgZXN0IHN1c2NlcHRpYmxlIGQnYWx0w6lyYXRpb24uIFFvc21vcyBldCANCj4+PnNlcyAg ZmlsaWFsZXMgZMOpY2xpbmVudCB0b3V0ZSByZXNwb25zYWJpbGl0w6kgYXUgdGl0cmUgZGUgY2Ug bWVzc2FnZSANCj4+PnMnaWwgYSAgw6l0w6kgYWx0w6lyw6ksIGTDqWZvcm3DqSBvdSBmYWxzaWZp w6kuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4gc2ZjQGlldGYub3JnDQo+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pg0KPj4NCj4+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+c2ZjIG1h aWxpbmcgbGlzdA0KPj5zZmNAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PnNmYyBtYWlsaW5nIGxpc3QNCj4+c2ZjQGlldGYub3JnDQo+Pmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zZmMgbWFpbGluZyBsaXN0DQo+c2Zj QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCg0K From nobody Fri Feb 6 15:49:12 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 376231A8820 for ; Fri, 6 Feb 2015 15:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IC6o89qTnxgf for ; Fri, 6 Feb 2015 15:49:08 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042521A0673 for ; Fri, 6 Feb 2015 15:49:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,531,1418083200"; d="scan'208";a="148351724" X-IPAS-Result: Au4HAHtS1VTAqArr/2dsb2JhbABag1haBII2R79FJAqFcQIcgT0BAQEBAQF8hAwBAQEBAwEBAQkXERMNEQkXBAIBBgIRAQMBAQECAiMDAgICJQsUAQIGCAIEARIbiB+iI5xshRaRDgEBAQEBBQEBAQEBAQEBARUEgSGOJAgyAgICgmKBQQWNJxCGFoEuhGKDA4JGSYgFgz6CJByBUG+BRH4BAQE Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 06 Feb 2015 23:49:07 +0000 Received: from SEAEXCHMBX01.olympus.F5Net.com (192.168.15.223) by SEAEXCHMBX04.olympus.F5Net.com (192.168.15.226) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 6 Feb 2015 15:49:05 -0800 Received: from SEAEXCHMBX01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75]) by seaexchmbx01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75%13]) with mapi id 15.00.0995.028; Fri, 6 Feb 2015 15:49:06 -0800 From: Sumandra Majee To: Ron Parker , "Ken Gray (kegray)" , Wenzhe Zhou , "Joel M. Halpern" , Nicolas BOUTHORS , "'sfc@ietf.org'" Thread-Topic: [sfc] draft-quinn-sfc-nsh-05, optional headers Thread-Index: AdBAmYhGpM3EkfNlQ4eMZ3oRb+Ov2QBC7nyAABBDrQAAAATGgAAOiTxwABQciIAADeNUIP//fekA Date: Fri, 6 Feb 2015 23:49:05 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D7D2D2F@LILAS.jungle.qosmos.com> <54D39C93.8050704@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.3.9.131030 x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers 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, 06 Feb 2015 23:49:11 -0000 Um9uLA0KDQpJZiBJIHJlYWQgdGhlIFNDSCBkcmFmdCBhZ2FpbiwgSSBiZWxpZXZlIGl0IGlzIHBy b3Bvc2luZyBhIGZldyBkaWZmZXJlbnQNCnN0YW5kYXJkIG1ldGFkYXRhLCBhbSBJIGNvcnJlY3Q/ DQoNCkl0IGlzIHBvc3NpYmxlIHRvIG1ha2UgYSBSU1BJRCBsaWtlIG1ldGFkYXRhIHdpdGhpbiBO U0ggYW5kIGVmZmVjdGl2ZWx5DQpnZXQgc2ltaWxhciBmdW5jdGlvbmFsaXR5Lg0KDQo+PkFuZCwg YWx0aG91Z2ggaXQgaXMgbm90IGEgZnVuY3Rpb25hbCB1c2UgY2FzZSBpbiB0aGUgc2FtZSBtYW5u ZXIgYXMNCj4+YWJvdmUsIHdoYXQgaWYgc29tZSBuZXR3b3JrIGRlc2lnbmVycyBkZXRlcm1pbmUg aXQgaXMgY2hlYXBlciBhbmQNCj4+c2ltcGxlciB0byBkZXBsb3kgU0ZDIHVzaW5nIHNlcnZpY2Ug ZnVuY3Rpb24gPj5pbnN0YW5jZXMgdGhhdCBhcmUNCj4+c2ltcGxlciBhbmQgZG9uJ3QgaGF2ZSBp bmJ1aWx0IGhvcml6b250YWwgc2NhbGU/ICAgTW9yZSBhbG9uZyB0aGUgbGluZXMNCj4+b2YgdGhl ICJmaXQgVk5GIiBhcHByb2FjaCAoYXR0cmlidXRpb24gdG8gQ29udGV4dHJlYW0pLg0KDQoNClRo YXQgaXMgYSBmaW5lIGdvYWwgYW5kIEkgZG8gc3VwcG9ydCB0aGF0IHZpZXdwb2ludCwgPE9GRlRP UElDPmV4Y2VwdCBJDQp3aWxsIG5vdCBhdHRyaWJ1dGUgdGhhdCB0byBDb250ZXh0cmVhbSwgaXQg aXMgYSBmYWlybHkgb2xkIHByb2JsZW0uIFZORg0Kc2ltcGx5IGFkZGVkIG1vcmUgZGltZW5zaW9u cyBhbmQgdGhlcmUgYXJlIG11bHRpcGxlIHdheXMgdG8gc29sdmUgdGhhdA0KcHJvYmxlbS4gPFxP RkZUT1BJQz4uDQoNCkhvd2V2ZXIgZG9lcyBOU0ggYXMgYSBwcm90b2NvbCBoaW5kZXIgdGhhdCwg aXMgdGhlcmUgc29tZXRoaW5nDQpmdW5kYW1lbnRhbGx5IG1pc3NpbmcgdGhhdCByZXF1aXJlcyBh IGNvbXBsZXRlIGRpZmZlcmVudCBhcHByb2FjaD8gSSBkb27igJl0DQpzZWUgdGhhdC4gWWVzIHRo ZXJlIGNvdWxkIGJlIHJlcXVpcmVtZW50IHRvIGNhcnJ5IHByZXNlbGVjdGVkIGluc3RhbmNlIG9m DQphIGdpdmVuIFNGQyh4KSBhbmQgcHJvdG9jb2wgc2hvdWxkIGJlIGFibGUgdG8gY29udmV5IHRo YXQuIEkgY291bGQgYWxzbw0KY29uc2lkZXIgZmxhdHRlbmluZyB0aGUgZ3JhcGggYW5kIGNvbnNp ZGVyIHBhdGhJRCB0byBiZSBhYnNvbHV0ZS4NCg0KSGF2aW5nIElEIGRvZXNu4oCZdCBnZXQgcmlk IG9mIHN0YXRlcyBiZWNhdXNlIHVsdGltYXRlbHkgaXQgaXMgdGFyZ2V0ZWQgdG8NCmFuIElQLCBN QUMgZXRjLiBTbyBpdCBpcyBtb3JlIHRoYW4gbGlrZWx5IHRvIGhhdmUgYSBtYXBwaW5nIG9mIFJT UF9JRCB0bw0KUkVBTElUWS4gTm93IGlmIHRoZSByZWFsaXR5IGlzIGVsYXN0aWMgdGhlbiB0aGUg aGFzaGluZyBzY2hlbWUgaXMgbGlrZWx5DQp0byBiZSBzb21lIGtpbmQgb2YgY29uc2lzdGVudCBo YXNoaW5nIHNjaGVtZS4gSWYgSSBhZGQgZmFpbG92ZXIgdG8gdGhhdA0KZXF1YXRpb24gdGhlIGFj dHVhbCBpbXBsZW1lbnRhdGlvbiBtYXkgbm90IGJlIHRoYXQgc2ltcGxlLiBJIHdvdWxkIGJlIHZl cnkNCmludGVyZXN0ZWQgdG8gbGVhcm4gYWJvdXQgdGhlIHNjYWxpbmcgaXNzdWVzIGZyb20geW91 IGFuZCBhbGwuIEkgYW0gaW4gdGhlDQptaWRkbGUgb2Ygc29tZSBob3Jpem9udGFsIHNjYWxpbmcg aXNzdWUgbXlzZWxmIGFuZCBsb3ZlIHRvIGdldCB5b3VyDQpvcGluaW9uIG9uIHRoYXQuDQoNClJl Z2FyZHMuDQoNCk9uIDIvNi8xNSwgMTA6MzYgQU0sICJSb24gUGFya2VyIiA8Um9uX1BhcmtlckBh ZmZpcm1lZG5ldHdvcmtzLmNvbT4gd3JvdGU6DQoNCj5LZW4sDQo+DQo+Q2VydGFpbmx5LCB0aGVy ZSBpcyBhIGNvbmNlcHQgdGhhdCBhIG5pY2Ugc2ltcGxlIGRlcGxveW1lbnQgb2YgU0ZDIGlzIHRv DQo+aGF2ZSAxIGxvZ2ljYWwgaW5zdGFuY2Ugb2YgZWFjaCBzZXJ2aWNlIGZ1bmN0aW9uIHZpc2li bGUgYXQgdGhlIFNGQw0KPmxheWVyLiAgIEhvdyBlYWNoIG9mIHRob3NlIGluc3RhbmNlcyBzY2Fs ZXMgaXMgaXRzIG93biBidXNpbmVzcy4gICBBbmQsDQo+Y2VydGFpbmx5LCB0aGUgYXJjaGl0ZWN0 dXJlIHN1cHBvcnRzIHRoYXQuDQo+DQo+QnV0LCBkb2VzIHRoYXQgYWRlcXVhdGVseSBzYXRpc2Z5 IGFsbCBwb3NzaWJsZSB1c2VzIGNhc2VzIGFuZCBkZXBsb3ltZW50DQo+c2NlbmFyaW9zIHdlIGNh biBjb25zdHJ1Y3QgZm9yIFNGQz8gICAgSGVyZSBhcmUgc29tZSB1c2UgY2FzZXMgdGhhdA0KPnN1 Z2dlc3QgdGhlIGFib3ZlIGNvbmNlcHQgaXMgbmVjZXNzYXJ5IGJ1dCBub3Qgc3VmZmljaWVudDoN Cj4NCj5XaGF0IGlmIHRoZSByZWFsLXdvcmxkIHNjYWxlIG9mIG9uZSBvZiB0aGVzZSBpbnRlcm5h bGx5IHNjYWxhYmxlDQo+aW5zdGFuY2VzIGlzIHN0aWxsIGluc3VmZmljaWVudD8NCj4NCj5XaGF0 IGlmIGEgaGlnaGVyIGxldmVsIG9mIHJlZHVuZGFuY3kgaXMgZGVzaXJlZCBieSBkZXBsb3lpbmcg bW9yZSB0aGFuDQo+b25lIG9mIHRob3NlIGludGVybmFsbHkgc2NhbGFibGUgaW5zdGFuY2VzPyAg IE1vcmUgdGhhbiAyIG9mIHRoZW0/DQo+DQo+V2hhdCBpZiB0aGUgU0ZDIGlzIGV4dGVuZGVkIGFj cm9zcyB0aGUgTUFOIGFuZCBXQU4gKGFuZCB0byBhdm9pZA0KPmFyZ3VtZW50LCBsZXQncyBzYXkg d2UgYXJlIHN0aWxsIGluIHRoZSBzYW1lIGFkbWluaXN0cmF0aXZlIGRvbWFpbik/DQo+V2hhdCBp ZiB3ZSB3YW50IHRvIGFwcGx5IGxvY2F0aW9uIGF3YXJlbmVzcyB0byBpbnN0YW5jZSBzZWxlY3Rp b24gaW4NCj5vcmRlciB0byBvcHRpbWl6ZSB0aGUgb3ZlcmFsbCBiZWhhdmlvcj8NCj4NCj5XaGF0 IGlmIHdlIHdhbnQgdG8gc3VwcG9ydCBvdGhlciBpbnN0YW5jZSBzZWxlY3Rpb24gY3JpdGVyaWEs IGxpa2UgZ29sZA0KPmN1c3RvbWVycyBnZXQgb24gdGhlIGhpZ2hlciBwZXJmb3JtYW5jZSBSU1Ag Zm9yIGEgcGFydGljdWxhciBmdW5jdGlvbmFsDQo+Y2hhaW4gYnV0IGJyb256ZSBjdXN0b21lcnMg dGhlIGxvd2VyIHBlcmZvcm1hbmNlIFJTUCBmb3IgdGhhdCBzYW1lDQo+ZnVuY3Rpb25hbCBjaGFp bj8NCj4NCj5BbmQsIGFsdGhvdWdoIGl0IGlzIG5vdCBhIGZ1bmN0aW9uYWwgdXNlIGNhc2UgaW4g dGhlIHNhbWUgbWFubmVyIGFzDQo+YWJvdmUsIHdoYXQgaWYgc29tZSBuZXR3b3JrIGRlc2lnbmVy cyBkZXRlcm1pbmUgaXQgaXMgY2hlYXBlciBhbmQgc2ltcGxlcg0KPnRvIGRlcGxveSBTRkMgdXNp bmcgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZXMgdGhhdCBhcmUgc2ltcGxlciBhbmQgZG9uJ3QN Cj5oYXZlIGluYnVpbHQgaG9yaXpvbnRhbCBzY2FsZT8gICBNb3JlIGFsb25nIHRoZSBsaW5lcyBv ZiB0aGUgImZpdCBWTkYiDQo+YXBwcm9hY2ggKGF0dHJpYnV0aW9uIHRvIENvbnRleHRyZWFtKS4N Cj4NCj5UaGUgZ3JvdXAncyBwcm9wb3NlZCBzb2x1dGlvbiBzaG91bGQgYmUgbWVhc3VyZWQgYWdh aW5zdCB0aGUgdXNlIGNhc2VzDQo+YW5kIGFuZCBkZXBsb3ltZW50IHNjZW5hcmlvcyB3ZSBmZWVs IG5lZWQgdG8gYmUgYWRkcmVzc2VkLCBhbmQgdGhpcyBpcw0KPnByb2JhYmx5IHRoZSBtYWluIGRp ZmZlcmVuY2UgaW4gdmlld3BvaW50LCBoZXJlLiAgICBUbyBmb2xsb3cgb24gdG8gS2VuJ3MNCj5j b2xsb3F1aWFsaXNtLCBteSBvcGluaW9uIGlzIHRoYXQgdGhlIGhvcnNlIGlzIG5vdCBkZWFkIGFu ZCB0aGF0IHRoZQ0KPmRpZmZlcmVudCB2aWV3cG9pbnRzIGRvIG5vdCByZWZsZWN0IGEgZnVuZGFt ZW50YWwgaW5hYmlsaXR5IHRvIGdyYXNwIHRoZQ0KPmNvbmNlcHRzLg0KPg0KPlRoYW5rcy4NCj4N Cj4gICBSb24NCj4NCj4NCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206 IEtlbiBHcmF5IChrZWdyYXkpIFttYWlsdG86a2VncmF5QGNpc2NvLmNvbV0NCj5TZW50OiBGcmlk YXksIEZlYnJ1YXJ5IDYsIDIwMTUgMTE6NTcgQU0NCj5UbzogV2VuemhlIFpob3U7IFJvbiBQYXJr ZXI7IEpvZWwgTS4gSGFscGVybjsgTmljb2xhcyBCT1VUSE9SUzsNCj4nc2ZjQGlldGYub3JnJw0K PlN1YmplY3Q6IFJlOiBbc2ZjXSBkcmFmdC1xdWlubi1zZmMtbnNoLTA1LCBvcHRpb25hbCBoZWFk ZXJzDQo+DQo+SW4gbXkgd29yZHMsIEkgYW0gbm90IHN1Z2dlc3RpbmcgY2hhbmdpbmcgdGhlIGRy YWZ0IGF0IGFsbC4gIEkgdGhpbmsgaXTigJlzDQo+c3VmZmljaWVudC4gDQo+DQo+DQo+TXkgb3Bp bmlvbiwgaXMgdGhhdCB0aGUgc3VnZ2VzdGVkIGNoYW5nZXMgaW4gdGhpcyB0aHJlYWQgc2hvdyBh DQo+ZnVuZGFtZW50YWwgZmFpbHVyZSB0byBncmFzcCB0aGUgY29uY2VwdHMgd2UgaGFzaGVkIG91 dCBpbiB0aGUNCj5hcmNoaXRlY3R1cmUgKHdoaWNoIEkgYXR0ZW1wdGVkIHRvIGNsYXJpZnkpLiAg SW4gbXkgb3BpbmlvbiwgdG8gdXNlIGFuDQo+dW5mb3J0dW5hdGUgY29sbG9xdWlhbGlzbSAtIHRo aXMgaG9yc2UgaXMgZGVhZCwgd2Ugc2hvdWxkIHN0b3AgYmVhdGluZyBpdC4NCj4NCj5PbiAyLzYv MTUsIDEwOjI4IEFNLCAiV2VuemhlIFpob3UiIDxXZW56aGUuWmhvdUBodWF3ZWkuY29tPiB3cm90 ZToNCj4NCj4+S2VuLA0KPj4NCj4+SW4geW91ciB3b3JkcywgbWFuZGF0b3J5IGNvbnRleHQgaGVh ZGVycyBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIE5TSC4NCj4+DQo+PldlbnpoZQ0KPj4gDQo+Pg0K Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBzZmMgW21haWx0bzpzZmMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEtlbiBHcmF5IChrZWdyYXkpDQo+PlNlbnQ6IFRo dXJzZGF5LCBGZWJydWFyeSAwNSwgMjAxNSA0OjI1IFBNDQo+PlRvOiBSb24gUGFya2VyOyBKb2Vs IE0uIEhhbHBlcm47IE5pY29sYXMgQk9VVEhPUlM7ICdzZmNAaWV0Zi5vcmcnDQo+PlN1YmplY3Q6 IFJlOiBbc2ZjXSBkcmFmdC1xdWlubi1zZmMtbnNoLTA1LCBvcHRpb25hbCBoZWFkZXJzDQo+Pg0K Pj5JIHRoaW5rIHRoZXJlwrlzIGEgZGlzY29ubmVjdGlvbiBoZXJlIChjb3VsZCBiZSBtZSkgYmV0 d2VlbiB0aGUgaWRlYSBvZg0KPj5hbiBhYnN0cmFjdCBhbmQgc3BlY2lmaWMgcGF0aC4NCj4+DQo+ PkkgdGhvdWdodCBpdCB3YXMgcHJldHR5IGNsZWFyIChhbmQgdGhlcmUgd2FzIHNpZ25pZmljYW50 IHRhbGsgYWJvdXQgaXQNCj4+aGVyZSBvbiB0aGUgbGlzdCkgdGhhdCB5b3UgY2FuJ3QgbWFuZGF0 ZSBhIHNwZWNpZmljIG1vZGVsIG9mIGZ1bmN0aW9uDQo+PmVsYXN0aWNpdHkgLSB3ZSBjb3VsZG7C uXQgZGVjbGFyZSBsb2FkIGJhbGFuY2luZyBkZXZpY2VzIG9yIGZ1bmN0aW9ucw0KPj7Cs2RlYWTC siBidXQgaW5zdGVhZCBhc3N1bWVkIHRoYXQgZWxhc3RpY2l0eSBjb3VsZCBiZSBkb25lIGxvY2Fs bHkgYXMgYQ0KPj5TRiwgYXMgcGFydCBvZiBhIGNvbXBvc2l0ZSBmdW5jdGlvbiB3aGVyZSB0aGUg bG9hZCBiYWxhbmNlciBleGlzdHMgYXMNCj4+cGFydCBvZiB0aGUgbG9naWNhbCBmdW5jdGlvbiBi ZWluZyByZW5kZXJlZCBvciBjZW50cmFsbHkvc3RhdGljYWxseS4NCj4+V2UgaGFkIHNpbWlsYXIg ZGlhbG9ndWVzIGFib3V0IHRoZSBuZWVkIHRvIHJlbWFpbiBhYnN0cmFjdCBhcm91bmQgSEENCj4+ dGVjaG5pcXVlcyBhcyB3ZWxsLg0KPj4NCj4+VGhlc2UgdGhpbmdzIG1ha2UgQU4gaW5kaXZpZHVh bCBwYXRoLCB3aGljaCByZXByZXNlbnRzIGEgY2hhaW4gdGhhdA0KPj5maXRzIGEgc3BlY2lmaWMg cG9saWN5IHJ1bGVzZXQgxaAgdmFyaWFibGUgxaAgYW5kIHdlIGRpZG7CuXQgd2FudCB0bw0KPj51 bm5lY2Vzc2FyaWx5IGRlZmluZSBtdWx0aXBsZSBkaXNjcmV0ZSBjaGFpbnMgdG8gY292ZXIgdGhp cyBzb3J0IG9mDQo+PmZ1bmN0aW9uIHZhcmlhbmNlICh3aGljaCBjYW4gYmVjb21lIHF1aXRlIGxh cmdlLCBpZiBmb3IgZXhhbXBsZSB0aGUNCj4+ZnVuY3Rpb24gWCBhdCBzaXRlIFkgaXMgYWN0dWFs bHkgMTAwMCBwYXJhbGxlbCBpbnN0YW5jZXMgdG8gYWNjb21tb2RhdGUNCj4+bG9hZCwgd2l0aCBI QSBhZGQgYSBtdWx0aXBsaWVyLCBwZXIgZnVuY3Rpb24gbW9yZSBtdWx0aXBsaWVycyDFoGZvciBh DQo+PnNpbmdsZSBwYXRoIHRoYXQgYXQgdGhlIGFic3RyYWN0IGxldmVsLCB0cmF2ZXJzZWQgdGhl IHNhbWUgc2l0ZXMgxaBib29tKS4NCj4+DQo+PlRoZXNlIGRpYWxvZ3VlcyBhcmUgY2FwdHVyZWQg aW4gdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudC4NCj4+DQo+PlNvLCB3aGVuIEkgcmVhZCB0aGUg TlNIIGRyYWZ0LCBJIGludGVycHJldGVkIHRoZSB0cmVhdG1lbnQgb2YgdGhlIFNQSQ0KPj5hbmQg dGhlIFJlc29sdmVkIFBhdGggYXMgdmVyeSBjb21wYXRpYmxlIHdpdGggdGhhdCBhYnN0cmFjdGlv bi9jb25jZXB0Lg0KPj5JdCBtYWtlcyBtdWx0aXBsZSBkZXBsb3ltZW50IGNvbnRleHRzIHVuZGVy c3RhbmRhYmxlIGFuZCBwb3NzaWJsZQ0KPj53aXRob3V0IG92ZXJseSBkZWZpbmluZyB0aGUgaGVh ZGVyIHdpdGggcG90ZW50aWFsbHkgdXNlbGVzcyBmaWVsZHMgZm9yDQo+PmV2ZXJ5IGl0ZXJhYmxl IGNhc2UuIChFZGl0b3JpYWwgLSBLaW5kIG9mIGFuIGFydCBmb3JtIHRoYXQgd2Ugc2hvdWxkDQo+ PmNlbGVicmF0ZSwgSU1PLCBpZiBwZW9wbGUgYXJlIGdvaW5nIGFib3V0IGRlc2lnbmluZyBwcm90 b2NvbHMuKQ0KPj4NCj4+Rm9yIGV4YW1wbGUsIHRoZSBTRkYgY2FuIGJlIHNlZWRlZCB3aXRoIG9u ZSBhbmQgb25seSBvbmUgTkggZm9yIHRoZQ0KPj5TSS9TUEkgbWF0Y2ggLSB0aHVzIHRoZSBwYXRo IGlzIHJlc29sdmVkIGFuZCB0aGUgU0kvU1BJIHBhdGggSVMgdGhlDQo+PnJlbmRlcmVkIHBhdGgu ICBUaGUgwrNkaXJlY3RlZMKyIGdyYXBoIHRoYXQgc29tZSB3YW50ZWQgKHdoZXJlIGVhY2gNCj4+ aW5kaXZpZHVhbCBlbGVtZW50IGluIGEgbG9jYWxseSBlbGFzdGljIHBvb2wgaXMgaW5kaXZpZHVh bGx5DQo+PmFkZHJlc3NhYmxlIGFuZCBzZXQgYXQNCj4+Y2xhc3NpZmljYXRpb24pIGlzIHJlYWxs eSBhIGRlcml2YXRpdmUgb2YgdGhlIHNhbWUgY2FzZS4NCj4+DQo+PklmIHRoZXJlIGlzIG1vcmUg dGhhbiBvbmUgTkggc2VlZGVkIGZvciB0aGUgU0kvU1BJLCB0aGVuIHRoZSBTRkYgZWl0aGVyDQo+ PndpbGwgdHJlYXQgdGhlIGZvcndhcmRpbmcgYXMgRUNNUCAoZS5nLiBzdGF0ZWxlc3MgdG8gYW4g YW55Y2FzdCBwb29sIC0NCj4+U0kvU1BJIElTIHRoZSByZW5kZXJlZCBwYXRoKSwgb3IgaGF2ZSBh IGxvY2FsIHBvbGljeSB0byBwZXJmb3JtIGFuDQo+PmV4cGxpY2l0IG1hcHBpbmcuICBUaGUgU0ZG IG1heSBhbHNvIGJlIGp1c3QgaGFuZGluZyB0aGUgcGFja2V0IHcvTlNIDQo+PmhlYWRlciBvZmYg dG8gYSBsb2NhbCBpbnRlZ3JhdGVkIGZ1bmN0aW9uIChsaWtlIGEgbG9hZCBiYWxhbmNlcikgb3Ig YW4NCj4+YXR0YWNoZWQgY29tcG9zaXRlIGZ1bmN0aW9uIHRoYXQgaXMgaGFuZGxpbmcgYW4gZXhw bGljaXQgbWFwcGluZyB0bw0KPj5mdW5jdGlvbiBpbnN0YW5jZXMgaXQgZnJvbnRzIChhbmQgbWFu YWdpbmcgc2FtZSBzb21ld2hhdCBvYmxpcXVlbHkgdG8NCj4+dGhlIFNGRiBhbmQgdGhlIHBhdGgg aXRzZWxmKS4NCj4+DQo+PlRoZXNlIG5ldyBjb250ZXh0cyBkb27CuXQgTkVFRCBhbmQgc2hvdWxk bsK5dCBHRVQgYSBzZXBhcmF0ZSBmaWVsZCBpbiB0aGUNCj4+Z2VuZXJhbCBoZWFkZXIuICBJRiwg Zm9yIGV4YW1wbGUsIHRoZSByZXNvbHV0aW9uL21hcHBpbmcgb2YgZWl0aGVyIHRoZQ0KPj5sb2Nh bCBTRkYgcG9saWN5IChvciB0aGUgb2JsaXF1ZSBmdW5jdGlvbikgaXMgYSBwb2xpY3kga2V5ZWQg dG8NCj4+Y2xhc3NpZmljYXRpb24gaW5mbyBsaWtlIGZsb3dJRCwgdGVuYW50SUQsIHNlc3Npb25J RCwgc29tZXRoaW5nDQo+PnByb3ByaWV0YXJ5IC0gd2VsbCwgeW91wrl2ZSBqdXN0IHJlZGVmaW5l ZCB0aGUgbmVlZCBmb3IgbWV0YWRhdGEgKG9uZSBvZg0KPj5vdXIgZ29hbHMgd2FzIHRvIGJlIGFi bGUgdG8gcHJlc2VydmUgY2xhc3NpZmllciBpbmZvIGluIG1ldGFkYXRhIHRvDQo+PmF2b2lkIGV4 Y2Vzc2l2ZSBjbGFzc2lmaWNhdGlvbiksIHdoaWNoIHdlIGFsbCBhZ3JlZWQgdG8gYWxyZWFkeSAt IGFuZA0KPj53ZSBrbm93IHdoZXJlIHRvIGZpbmQgc3VjaCBhIGtleSBzbyB0aGVyZcK5cyBubyBu ZWVkIHRvIG1vdmUgaXQuDQo+PihFZGl0b3JpYWwgLSBOb3RlIGFsc28gdGhlIHBvdGVudGlhbCBm b3IgdmFyaWFuY2Ugb2YgdGhlIGtleQ0KPj5zb3VyY2UvdmFsdWUgYWNyb3NzDQo+PmltcGxlbWVu dGF0aW9ucy4pDQo+Pg0KPj5Zb3Ugc2hvdWxkbid0IE5FRUQgYW4gZXhwbGljaXQgUlNQIElEIGlu IHRoZSBmaXhlZCBoZWFkZXIuICBUaGF0IHNlZW1zDQo+PnRvIHdvcmsgYmFjayBhZ2FpbnN0IHRo ZSBvcmlnaW5hbCBpbXBsaWNpdCBkZXNpZ24gZ29hbCBvZiB0aGUgaGVhZGVyLg0KPj4NCj4+SSBk dW5ubywgaWYgaXTCuXMganVzdCBtZSwgSSBoYXZlbsK5dCBkb25lIHByb3RvY29sIGRlc2lnbiBz aW5jZSBjb2xsZWdlDQo+PsWgIG1heWJlIEnCuW0gcnVzdHkgb3IgSSBuZWVkIHNvbWV0aGluZyBz dHJvbmdlciB0byBkcmluay4NCj4+ICANCj4+DQo+PkNoZWVycy4NCj4+DQo+Pg0KPj5PbiAyLzUv MTUsIDExOjU3IEFNLCAiUm9uIFBhcmtlciIgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5j b20+DQo+Pndyb3RlOg0KPj4NCj4+PkpvZWwsDQo+Pj4NCj4+PkkgdGhpbmsgeW91IGFyZSByZWlu Zm9yY2luZyBhIGtleSBhc3N1bXB0aW9uIGhlcmUgLS0gaWYgdGhlIFNGRiBuZWVkcw0KPj4+dGhl IGluZm9ybWF0aW9uIHRvIGRvIGl0cyBqb2IsIHRoZW4gdGhhdCBpbmZvcm1hdGlvbiBzaG91bGQg YmUgbmVpdGhlcg0KPj4+aW4NCj4+PlR5cGUgMSBub3IgVHlwZSAyIG1ldGFkYXRhLiAgICBBcyBh biBleGFtcGxlLi4uICBkZXBlbmRpbmcgb24gaG93IG91cg0KPj4+Y29udGludWluZyBkaXNjdXNz aW9uIG9uIFJTUCBJRCBnb2VzIChpLmUsIHRvIGVuYWJsZSBib3RoIGNlbnRyYWxpemVkDQo+Pj5j b25jcmV0ZSBSU1AgZGV0ZXJtaW5hdGlvbiBhbmQgZGlzdHJpYnV0ZWQgaG9wLWJ5LWhvcCAidHJh aWwtYmxhemVkIg0KPj4+UlNQIGRldGVybWluYXRpb24pLCB3ZSBtYXkgd2FudCB0byAicHJvbW90 ZSIgUlNQIElEIGZyb20gbWV0YWRhdGEgdG8NCj4+PnRoZSBzdGFuZGFyZCBoZWFkZXIuDQo+Pj4N Cj4+PiAgIFJvbg0KPj4+DQo+Pj4NCj4+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5G cm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvZWwg TS4gSGFscGVybg0KPj4+U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDUsIDIwMTUgMTE6MzkgQU0N Cj4+PlRvOiBOaWNvbGFzIEJPVVRIT1JTOyAnc2ZjQGlldGYub3JnJw0KPj4+U3ViamVjdDogUmU6 IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1uc2gtMDUsIG9wdGlvbmFsIGhlYWRlcnMNCj4+Pg0KPj4+ VGhlIG1ldGFkYXRhIGlzIChnZW5lcmFsbHkpIGZvciB0aGUgYVNlcnZpY2UgRnVuY3Rpb25zLCBu b3QgZm9yIHRoZSBTRkYuDQo+Pj4gIFNvIHRoZSBxdWVzaXRvbiBvZiBwcm9ncmFtbWluZyB0aGUg U0ZGIHRvIHByb2Nlc3MgdGhlIGluZm9ybWF0aW9uDQo+Pj5zZWVtcyBub3QgZXNwZWNpYWxseSBt YWpvci4NCj4+Pg0KPj4+TW9yZSBzaWduaWZpY2FudGx5LCBnaXZlbiB0aGF0IHRoZSAxNiBieXRl IHR5cGUgMSBmaWVsZCBtYXkgY2FycnkNCj4+PmRpZmZlcmVudCB0aGluZ3MgaW4gZGlmZmVyZW50 IGNhc2VzLCB0aGUgU0ZzIHdpbGwgaGF2ZSB0byBiZSBmbGV4aWJsZQ0KPj4+YWJvdXQgcHJvY2Vz c2luZyB0aGUgaW5mb3JtYXRpb24gYW55d2F5LiAgU28gYW55dGhpbmcgd2hpY2ggY2FuIGhhbmRs ZQ0KPj4+dGhlIHR5cGUgMiBpbmZvcm1hdGlvbiBjYW4gYmUgcmVhc29hbmFibHkgZXhwZWN0ZWQg dG8gaGFuZGxlIHRoZSBzYW1lDQo+Pj5raW5kcyBvZiBpbmZvcm1hdGlvbiBmcm9tIFRMVnMgKHdo ZXRoZXIgb25lIFRMViBvciBtYW55KS4NCj4+Pg0KPj4+SXQgdGhlcmVmb3JlIHNlZW1zIGNsZWFu ZXIgdG8gbWUgdG8gcmVjb2duaXplIHRoYXQgdHlwZSAxIGFuZCB0eXBlIDINCj4+PmFyZSBkaWZm ZXJlbnQgd2F5cyBvZiBjYXJyeWluZyBpbmZvcm1hdGlvbiwgYW5kIGp1c3QgdXNlIHRoZSBtZWNo YW5pc20NCj4+PmVhY2ggc3VwcG9ydHMuDQo+Pj4NCj4+PllvdXJzLA0KPj4+Sm9lbA0KPj4+DQo+ Pj5PbiAyLzQvMTUgMTI6MDYgUE0sIE5pY29sYXMgQk9VVEhPUlMgd3JvdGU6DQo+Pj4+IEl0IGlz IGdyZWF0IHRvIGhhdmUgdGhlIHBvc3NpYmlsaXR5IHRvIGFkZCBvcHRpb25hbCBoZWFkZXJzIGlu IE5TSC4NCj4+Pj5Ib3dldmVyLCB0aGUgbWVjaGFuaXNtIHByb3Bvc2VkIHN1cHBvc2UgdGhhdCBh IHNwZWNpZmljIGhlYWRlciB0eXBlDQo+Pj4+KHRoZSAgTUQgVHlwZT0weDIpaXMgdXNlZCBpbiB0 aGUgYmFzZSBoZWFkZXIgd2hlbiBvcHRpb25hbCBtZXRhZGF0YQ0KPj4+PmFyZSB1c2VkLg0KPj4+ Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBBcyBhIHJlc3VsdDoNCj4+Pj4NCj4+Pj4gMS5UaGUgYmFzZSBo ZWFkZXIgdHlwZSAweDEgY2Fubm90IGJlIHVzZWQgd2l0aCBvcHRpb25hbCBoZWFkZXJzLg0KPj4+ PiBXaGljaCBteSBtYWtlIHNlbnNlIGZvciBwZXJmb3JtYW5jZSBwb2ludCBvZiB2aWV3DQo+Pj4+ DQo+Pj4+IDIuTm9yIHdoZW4gdXNpbmcgaGVhZGVyIE1EIHR5cGUgeDIgIGNhbiB0aGUgIm1hbmRh dG9yeSBjb250ZXh0DQo+Pj4+aGVhZGVycyINCj4+Pj4gYmUgcHJlc2VudC4NCj4+Pj4NCj4+Pj4g Q2FzZSAyIGNhbiBiZSB3b3JrZWQgYXJvdW5kIGJ5IGRlZmluaW5nIGFuIG9wdGlvbmFsIGhlYWRl ciB0aGF0DQo+Pj4+IHJlcHJlc2VudHMgdGhlIG1hbmRhdG9yeSBjb250ZXh0IGhlYWRlci4gV2hp Y2ggaXMgYXdrd2FyZCBhcyBTRkZzDQo+Pj4+IHdpbGwgaGF2ZSB0byBkZWNvZGUgdGhlIHNhbWUg aW5mb3JtYXRpb24gaW4gdHdvIGRpZmZlcmVudCB3YXlzLiBOb3QNCj4+Pj4gcGFydGljdWxhcmx5 IGJlYXV0aWZ1bCAhDQo+Pj4+DQo+Pj4+IFdoeSBub3QgaGF2ZSBhIGZsYWcgKEYyKXN0YXRpbmcg dGhhdCBubyBvcHRpb25hbCBNZXRhZGF0YSBhcmUNCj4+Pj4gcHJlc2VudCBhbmQgYW5vdGhlciBv bmUgKEYxKSBzdGF0aW5nIHRoYXQgKHdoYXQgaXMgbm93IGNhbGxlZCkgdGhlDQo+Pj4+IG1hbmRh dG9yeSBjb250ZXh0IGhlYWRlciBpcyBwcmVzZW50IG9yIG5vdC4NCj4+Pj4NCj4+Pj4gV2UgY2Fu IHRoZW4gc3BlY2lmeSB0aGF0IHRoZSBjb21iaW5hdGlvbnMNCj4+Pj4NCj4+Pj4gRjI9RmFsc2Ug aW1wbGllcyBGMT1UcnVlDQo+Pj4+DQo+Pj4+IEYxPVRydWUsIEYyPVRydWUgaXMgYWxsb3dlZA0K Pj4+Pg0KPj4+PiBGMT0gRmFsc2UsIEYyPVRydWUgaXMgYWxsb3dlZA0KPj4+Pg0KPj4+PiBJdCBz ZWVtcyBjbGVhbmVyLiBXaGVuIHByZXNlbnQsIHRoZSAibWFuZGF0b3J5IGNvbnRleHQgaGVhZGVy cyINCj4+Pj4gd291bGQgYWx3YXlzIGJlIGF0IHRoZSBzYW1lIHBsYWNlIGluIHRoZSBwYWNrZXQu DQo+Pj4+DQo+Pj4+IE5pY29sYXMNCj4+Pj4NCj4+Pj4gVGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0 YWNobWVudHMgKHRoZSAibWVzc2FnZSIpIGFyZSBjb25maWRlbnRpYWwsDQo+Pj4+IGludGVuZGVk IHNvbGVseSBmb3IgdGhlIGFkZHJlc3NlZXMuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZA0K Pj4+PiByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBl LW1haWwgYW5kIGRlbGV0ZQ0KPj4+PiB0aGlzIG1lc3NhZ2UgZnJvbSB5b3VyIHN5c3RlbS4gSW4g dGhpcyBjYXNlLCB5b3UgYXJlIG5vdCBhdXRob3JpemVkDQo+Pj4+IHRvIHVzZSwgY29weSB0aGlz IG1lc3NhZ2UgYW5kL29yIGRpc2Nsb3NlIHRoZSBjb250ZW50IHRvIGFueSBvdGhlcg0KPj4+PnBl cnNvbi4NCj4+Pj4gRS1tYWlscyBhcmUgc3VzY2VwdGlibGUgdG8gYWx0ZXJhdGlvbi4gTmVpdGhl ciBRb3Ntb3Mgbm9yIGFueSBvZiBpdHMNCj4+Pj4gc3Vic2lkaWFyaWVzIG9yIGFmZmlsaWF0ZXMg c2hhbGwgYmUgbGlhYmxlIGZvciB0aGUgbWVzc2FnZSBpZg0KPj4+PiBhbHRlcmVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4NCj4+Pj4NCj4+Pj4gQ2UgbWVzc2FnZSBldCB0b3V0ZXMgc2VzIHBpw6hj ZXMgam9pbnRlcyAoY2ktYXByw6hzIGxlICJtZXNzYWdlIilzb250DQo+Pj4+Y29uZmlkZW50aWVs cyBldCDDqXRhYmxpcyDDoCBsJ2ludGVudGlvbiBleGNsdXNpdmUgZGUgc2VzIGRlc3RpbmF0YWly ZXMuDQo+Pj4+IFNpIHZvdXMgYXZleiByZcOndSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIG1lcmNp IGQnZW4gaW5mb3JtZXINCj4+Pj5pbW3DqWRpYXRlbWVudCBzb24gw6ltZXR0ZXVyIHBhciBjb3Vy cmllciDDqWxlY3Ryb25pcXVlIGV0IGQnZWZmYWNlciBjZQ0KPj4+Pm1lc3NhZ2UgZGUgdm90cmUg c3lzdMOobWUuIERhbnMgY2V0dGUgaHlwb3Row6hzZSwgdm91cyBuJ8OqdGVzIHBhcw0KPj4+PmF1 dG9yaXPDqSDDoCB1dGlsaXNlciwgY29waWVyIGNlIG1lc3NhZ2UgZXQvb3UgZW4gZGl2dWxndWVy IGxlIGNvbnRlbnUNCj4+Pj7DoCB1biB0aWVycy4NCj4+Pj4gVG91dCBtZXNzYWdlIMOpbGVjdHJv bmlxdWUgZXN0IHN1c2NlcHRpYmxlIGQnYWx0w6lyYXRpb24uIFFvc21vcyBldA0KPj4+PnNlcyAg ZmlsaWFsZXMgZMOpY2xpbmVudCB0b3V0ZSByZXNwb25zYWJpbGl0w6kgYXUgdGl0cmUgZGUgY2Ug bWVzc2FnZQ0KPj4+PnMnaWwgYSAgw6l0w6kgYWx0w6lyw6ksIGTDqWZvcm3DqSBvdSBmYWxzaWZp w6kuDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4gc2ZjQGlldGYu b3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+ DQo+Pj4NCj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj5zZmMgbWFpbGluZyBsaXN0DQo+Pj5zZmNAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4NCj4+Pl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj5zZmMgbWFpbGluZyBsaXN0DQo+Pj5zZmNA aWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5z ZmMgbWFpbGluZyBsaXN0DQo+PnNmY0BpZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NmYw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+c2ZjIG1haWxpbmcgbGlzdA0KPnNmY0BpZXRmLm9yZw0KPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg== From nobody Fri Feb 6 16:21: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 644C61A001C for ; Fri, 6 Feb 2015 16:21:05 -0800 (PST) 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 dVvjITbrNUHK for ; Fri, 6 Feb 2015 16:21:01 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC6E11A07BE for ; Fri, 6 Feb 2015 16:21:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19288; q=dns/txt; s=iport; t=1423268461; x=1424478061; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BDTcbJo6i59wimeVL0jldZ9zdrNXZkWzRUV41DL9wGc=; b=L+Xmj5Z7QpjF/UtOfRZgaQ1WxPXTUDGxDkhbFa1c92Oo6pd+TiVq8AQO GSeKeExhsOFEEYUNFrWoXiz4xxpRxwJO4hYJ14INOnIEy9ECg5duqCazm w+XYabzsWr1wfC9ySiTi048lpMIPHO/jiMIOTXBlW2XYe4gQLu2I3Eosj o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIIAJ9Z1VStJV2d/2dsb2JhbABRCYJiIlJaBII2R79pCoVxAhx6QwEBAQEBfYQMAQEBBAEBAQkXERMNEQkXBAIBBgIRAQMBAQECAiMDAgICJQsUAQIGCAIEARIbiBIBDKIcnGyFFpEKAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIY18KAgyAgICgmKBQQEEjSeBc4QzgS6DS4EXgwOCRkmIBYM+IoICHIFQb4FEfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,531,1418083200"; d="scan'208";a="394167082" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 07 Feb 2015 00:21:00 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t170L0ab003643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Feb 2015 00:21:00 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Fri, 6 Feb 2015 18:20:58 -0600 From: "Ken Gray (kegray)" To: Ron Parker , Wenzhe Zhou , "Joel M. Halpern" , "Nicolas BOUTHORS" , "'sfc@ietf.org'" Thread-Topic: [sfc] draft-quinn-sfc-nsh-05, optional headers Thread-Index: AdBAmYhGpM3EkfNlQ4eMZ3oRb+Ov2QA+vZmAAACmJgAABSfyAAAqBvAA///E9gCAAG+2AIAADFSA Date: Sat, 7 Feb 2015 00:20:58 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D7D2D2F@LILAS.jungle.qosmos.com> <54D39C93.8050704@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.24.148.33] Content-Type: text/plain; charset="utf-8" Content-ID: <2B62EF07E26D384ABB06D50794B2EE4E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 00:21:05 -0000 SGFwcHkgRnJpZGF5LCBSb24uICBJbiBsaW5lIHJlc3BvbnNlcyAuLi4NCg0KT24gMi82LzE1LCAx OjM2IFBNLCAiUm9uIFBhcmtlciIgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+IHdy b3RlOg0KDQo+S2VuLA0KPg0KPkNlcnRhaW5seSwgdGhlcmUgaXMgYSBjb25jZXB0IHRoYXQgYSBu aWNlIHNpbXBsZSBkZXBsb3ltZW50IG9mIFNGQyBpcyB0bw0KPmhhdmUgMSBsb2dpY2FsIGluc3Rh bmNlIG9mIGVhY2ggc2VydmljZSBmdW5jdGlvbiB2aXNpYmxlIGF0IHRoZSBTRkMNCj5sYXllci4g ICBIb3cgZWFjaCBvZiB0aG9zZSBpbnN0YW5jZXMgc2NhbGVzIGlzIGl0cyBvd24gYnVzaW5lc3Mu ICAgQW5kLA0KPmNlcnRhaW5seSwgdGhlIGFyY2hpdGVjdHVyZSBzdXBwb3J0cyB0aGF0Lg0KPg0K PkJ1dCwgZG9lcyB0aGF0IGFkZXF1YXRlbHkgc2F0aXNmeSBhbGwgcG9zc2libGUgdXNlcyBjYXNl cyBhbmQgZGVwbG95bWVudA0KPnNjZW5hcmlvcyB3ZSBjYW4gY29uc3RydWN0IGZvciBTRkM/ICAg IEhlcmUgYXJlIHNvbWUgdXNlIGNhc2VzIHRoYXQNCj5zdWdnZXN0IHRoZSBhYm92ZSBjb25jZXB0 IGlzIG5lY2Vzc2FyeSBidXQgbm90IHN1ZmZpY2llbnQ6DQo+DQo+V2hhdCBpZiB0aGUgcmVhbC13 b3JsZCBzY2FsZSBvZiBvbmUgb2YgdGhlc2UgaW50ZXJuYWxseSBzY2FsYWJsZQ0KPmluc3RhbmNl cyBpcyBzdGlsbCBpbnN1ZmZpY2llbnQ/DQoNCjxrZWc+IFRoZSB0ZXJtcyDigJxyZWFsIHdvcmxk 4oCdIGFuZCDigJxpbnN1ZmZpY2llbnTigJ0gYXJlIHZhZ3VlLCBidXQgSSB0aGluaw0KYWN0dWFs bHkgYSBnb29kIGFyZ3VtZW50IHdoeSB0aGUgc2Vjb25kYXJ5IGtleSBmb3IgYSBsb29rdXAgYnkg dGhlDQpiYWxhbmNlci93aGF0ZXZlciBzaG91bGQgYmUga2VwdCBpbiBtZXRhZGF0YSAtIGFuZCwg YXMgSSBwb2ludCBvdXQgYmVmb3JlLA0KYSBSRUxFVkFOVCBrZXkgaXMgbW9zdCBsaWtlbHkgdGhl cmUuICBBdCB3b3JzdCwgaWYgaXTigJlzIGluIGEgZml4ZWQgY29udGV4dA0KKHR5cGUxKSBpdOKA mXMgYSAzMiBiaXQgbnVtYmVyIGFuZCBpZiB5b3UgbmVlZCBsYXJnZXIsIGl0IGNvdWxkIGJlIGlu IGENCnZhcmlhYmxlIGxlbmd0aCBUTFYgKHR5cGUgMikg4oCmYW5kIEnigJlkIHRoaW5rIOKAnGJp Z2dlciB0aGFuIDMyIGJpdHPigJ0gd291bGQgYmUNCnByZXR0eSBzcGVjaWFsLg0KDQo+IA0KPg0K PldoYXQgaWYgYSBoaWdoZXIgbGV2ZWwgb2YgcmVkdW5kYW5jeSBpcyBkZXNpcmVkIGJ5IGRlcGxv eWluZyBtb3JlIHRoYW4NCj5vbmUgb2YgdGhvc2UgaW50ZXJuYWxseSBzY2FsYWJsZSBpbnN0YW5j ZXM/ICAgTW9yZSB0aGFuIDIgb2YgdGhlbT8NCg0KPGtlZz4gSSB0aGluayB5b3XigJlyZSBtYWtp bmcgdGhlIHNhbWUgYXJndW1lbnQgSSB3YXMgbWFraW5nIGFib3ZlLiAgSQ0Kc2hvdWxkbuKAmXQg Y2FyZSBhbmQgaXQgc2VlbXMgbGlrZSB3ZeKAmXJlIGNhcmVlbmluZyBmdXJ0aGVyIGF3YXkgZnJv bSB1c2luZyBhDQpmaXhlZCBmaWVsZCB0byBzb2x2ZSB0aGF0IHByb2JsZW0uICBBZ2FpbiwgaWYg dGhlIFNQSS9TSSBnZXRzIG1lIHRvIG15DQpmaXJzdCDigJxkZWNpc2lvbiBwb2ludOKAnSDigKZh IGxvY2FsaXR5IHdoZXJlIGVsYXN0aWNpdHkvSEEgZXhwYW5zaW9uIGlzIHRha2luZw0KcGxhY2Ug YW5kIHlvdSB1c2UgbXkgZXhhbXBsZSBvZiB0aGUgY29udGV4dCBoZWFkZXIgYmVpbmcgYSBzZWNv bmRhcnkga2V5DQp0byBndWlkZSBhIGxvb2t1cCB0byB3aGF0ZXZlciB0aGF0IGRldmljZSBpcyDi gKYgYSB1bmlxdWUgMzJiaXQgdmFsdWUgZXZlbg0KZm9yIGEgZGlyZWN0IG1hcHBpbmcgaXMgYSBI VUdFIHNwYWNlIChDYXJsIFNhZ2FuZXNxdWUpLg0KDQo+ICANCj4NCj5XaGF0IGlmIHRoZSBTRkMg aXMgZXh0ZW5kZWQgYWNyb3NzIHRoZSBNQU4gYW5kIFdBTiAoYW5kIHRvIGF2b2lkDQo+YXJndW1l bnQsIGxldCdzIHNheSB3ZSBhcmUgc3RpbGwgaW4gdGhlIHNhbWUgYWRtaW5pc3RyYXRpdmUgZG9t YWluKT8NCj5XaGF0IGlmIHdlIHdhbnQgdG8gYXBwbHkgbG9jYXRpb24gYXdhcmVuZXNzIHRvIGlu c3RhbmNlIHNlbGVjdGlvbiBpbg0KPm9yZGVyIHRvIG9wdGltaXplIHRoZSBvdmVyYWxsIGJlaGF2 aW9yPw0KDQo8a2VnPiBJbnRlcmVzdGluZyBleGFtcGxlIGFuZCBJIGhlYXIgdGhpcyBhIGxvdCBh cyBmYXIgYXMgd2hhdCB5b3UgQ09VTEQNCmRvIHdpdGggU0ZDLCBidXQgaWYgZGVsYXkgaXMgYW55 IGZhY3RvciBpbiB0aGUgcG9saWN5IHRoYXQgY29udHJvbHMgdGhlDQpjcmVhdGlvbiBvZiBpbmRp dmlkdWFsIGNoYWlucy9TUElEcywgdGhlbiBJ4oCZZCBhcmd1ZSB0aGF0IHRoZXkgd291bGRu4oCZ dCBiZQ0KZXF1aXZhbGVudCBhYnN0cmFjdCBwYXRocyAtIHRoZXkgd291bGQgYmUgbW9yZSBvciBs ZXNzIHNlcGFyYXRlIGNoYWlucyBpbg0KbXkgdmlldy4NCg0KQnV0IG9rYXksIHRoZXnigJlyZSBj bG9zZSBlbm91Z2ggZm9yIHlvdSBub3QgdG8gY2FyZSDigKYgdGhlIHByb2JsZW0geW91IGhhdmUN CnRvIHNvbHZlIGlzIHRvIHNlbGVjdCBhIGNyaXRlcmlhIG9uIHdoaWNoIHRvIHBpY2sgdGhlIGRl c3RpbmF0aW9uIGZyb20gYQ0KZGVjaXNpb24gcG9pbnQgaW4gdGhlIHBhdGggZm9yIHlvdXIgZWxh c3RpYy9mbGV4aWJsZSBTSS9TUEkgbWF0Y2ggLi4uIG5vdA0KaG93IGZhciB0aGUgTkhzIHRoYXQg aXQgcmVzb2x2ZXMgdG8gYXJlIGZyb20gdGhhdCBwb2ludC4gIFNheSB5b3VyIE5IIGFyZQ0KaW4g Q2xldmVsYW5kIGFuZCBDaGljYWdvIOKApiB0aGVzZSBkb27igJl0IG1vdmUgcmVsYXRpdmUgdG8g dGhlIGRlY2lzaW9uIHBvaW50DQrigKYgc28gdGhlaXIgZGlzdGFuY2UgaXMgbm90IGEgY3JpdGVy aWEgaW4gYW5kIG9mIGl0c2VsZiAtIG90aGVyd2lzZSBJIHdvdWxkDQpqdXN0IHdlaWdodCB0aGUg TkggZnJvbSB0aGUgY29udHJvbCBwbGFuZSBkaXN0cmlidXRpbmcgdGhlbSB0byByZWZsZWN0DQp3 aGF0IG15IHZhbHVhdGlvbiBvZiBsb2FkIGFuZCBkaXN0YW5jZSBzaG91bGQgYmUgKHRvIHJlZmxl Y3QgbXkgcG9saWN5KS4NClRoYXTigJlzIGFsbCBzdGF0aWMgKHRoZSBOSCB3ZWlnaHQgY291bGQg YmUgdXBkYXRlZCBpZiBDbGV2ZWxhbmQgb3IgQ2hpY2Fnbw0KbW92ZSBvciBpZiBJIGNoYW5nZSBt eSBwb2xpY3kgO14pLg0KDQo+DQo+V2hhdCBpZiB3ZSB3YW50IHRvIHN1cHBvcnQgb3RoZXIgaW5z dGFuY2Ugc2VsZWN0aW9uIGNyaXRlcmlhLCBsaWtlIGdvbGQNCj5jdXN0b21lcnMgZ2V0IG9uIHRo ZSBoaWdoZXIgcGVyZm9ybWFuY2UgUlNQIGZvciBhIHBhcnRpY3VsYXIgZnVuY3Rpb25hbA0KPmNo YWluIGJ1dCBicm9uemUgY3VzdG9tZXJzIHRoZSBsb3dlciBwZXJmb3JtYW5jZSBSU1AgZm9yIHRo YXQgc2FtZQ0KPmZ1bmN0aW9uYWwgY2hhaW4/DQoNCjxrZWc+IElkZW50aXR5LCBzZXNzaW9uLCBt ZXRhZGF0YSDigKYgSSB0aGluayBJIGdhdmUgdGhpcyBleGFtcGxlLg0KDQo+DQo+QW5kLCBhbHRo b3VnaCBpdCBpcyBub3QgYSBmdW5jdGlvbmFsIHVzZSBjYXNlIGluIHRoZSBzYW1lIG1hbm5lciBh cw0KPmFib3ZlLCB3aGF0IGlmIHNvbWUgbmV0d29yayBkZXNpZ25lcnMgZGV0ZXJtaW5lIGl0IGlz IGNoZWFwZXIgYW5kIHNpbXBsZXINCj50byBkZXBsb3kgU0ZDIHVzaW5nIHNlcnZpY2UgZnVuY3Rp b24gaW5zdGFuY2VzIHRoYXQgYXJlIHNpbXBsZXIgYW5kIGRvbid0DQo+aGF2ZSBpbmJ1aWx0IGhv cml6b250YWwgc2NhbGU/ICAgTW9yZSBhbG9uZyB0aGUgbGluZXMgb2YgdGhlICJmaXQgVk5GIg0K PmFwcHJvYWNoIChhdHRyaWJ1dGlvbiB0byBDb250ZXh0cmVhbSkuDQoNCjxrZWc+IFRoZXkgaGF2 ZSB0aGUgb3B0aW9uIG9mIGJsb3dpbmcgb3V0IHRoZSBTUElEIHNwYWNlLCBhcyBJIHNhaWQsDQp0 aGF04oCZcyBhIGRlcml2YXRpdmUgZXhhbXBsZSBvZiB0aGUgU1BJL1NJIGhhdmluZyBhIHNpbmds ZSBOSCwgSU1PIOKApmVhY2gNCnBlcm11dGF0aW9uIGlzIGEgZGlyZWN0IG1hcHBpbmcgYW5kIGRp ZmZlcmVudCBTUElEIGFuZCB3aGF0L2hvdyB5b3UgYWZmaXgNCnRoZXNlIChwb2xpY3kpIGlzIHJl ZmxlY3RlZCBhdCBjbGFzc2lmaWNhdGlvbi4gIFRoZSBhYnN0cmFjdGlvbiBpbiB0aGUNCmxhbmd1 YWdlIHdhcyBvbmx5IHRoZXJlIHRvIGhlbHAgcGVvcGxlIGltYWdpbmUgdGhlIGZsZXhpYmlsaXR5 IGF2YWlsYWJsZQ0KdGhyb3VnaCB0aGUgdXNhZ2UgSSBkZXNjcmliZS4NCg0KPg0KPlRoZSBncm91 cCdzIHByb3Bvc2VkIHNvbHV0aW9uIHNob3VsZCBiZSBtZWFzdXJlZCBhZ2FpbnN0IHRoZSB1c2Ug Y2FzZXMNCj5hbmQgYW5kIGRlcGxveW1lbnQgc2NlbmFyaW9zIHdlIGZlZWwgbmVlZCB0byBiZSBh ZGRyZXNzZWQsIGFuZCB0aGlzIGlzDQo+cHJvYmFibHkgdGhlIG1haW4gZGlmZmVyZW5jZSBpbiB2 aWV3cG9pbnQsIGhlcmUuICAgIFRvIGZvbGxvdyBvbiB0byBLZW4ncw0KPmNvbGxvcXVpYWxpc20s IG15IG9waW5pb24gaXMgdGhhdCB0aGUgaG9yc2UgaXMgbm90IGRlYWQgYW5kIHRoYXQgdGhlDQo+ ZGlmZmVyZW50IHZpZXdwb2ludHMgZG8gbm90IHJlZmxlY3QgYSBmdW5kYW1lbnRhbCBpbmFiaWxp dHkgdG8gZ3Jhc3AgdGhlDQo+Y29uY2VwdHMuDQo+DQo+VGhhbmtzLg0KPg0KPiAgIFJvbg0KPg0K Pg0KPg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogS2VuIEdyYXkgKGtl Z3JheSkgW21haWx0bzprZWdyYXlAY2lzY28uY29tXQ0KPlNlbnQ6IEZyaWRheSwgRmVicnVhcnkg NiwgMjAxNSAxMTo1NyBBTQ0KPlRvOiBXZW56aGUgWmhvdTsgUm9uIFBhcmtlcjsgSm9lbCBNLiBI YWxwZXJuOyBOaWNvbGFzIEJPVVRIT1JTOw0KPidzZmNAaWV0Zi5vcmcnDQo+U3ViamVjdDogUmU6 IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1uc2gtMDUsIG9wdGlvbmFsIGhlYWRlcnMNCj4NCj5JbiBt eSB3b3JkcywgSSBhbSBub3Qgc3VnZ2VzdGluZyBjaGFuZ2luZyB0aGUgZHJhZnQgYXQgYWxsLiAg SSB0aGluayBpdOKAmXMNCj5zdWZmaWNpZW50LiANCj4NCj4NCj5NeSBvcGluaW9uLCBpcyB0aGF0 IHRoZSBzdWdnZXN0ZWQgY2hhbmdlcyBpbiB0aGlzIHRocmVhZCBzaG93IGENCj5mdW5kYW1lbnRh bCBmYWlsdXJlIHRvIGdyYXNwIHRoZSBjb25jZXB0cyB3ZSBoYXNoZWQgb3V0IGluIHRoZQ0KPmFy Y2hpdGVjdHVyZSAod2hpY2ggSSBhdHRlbXB0ZWQgdG8gY2xhcmlmeSkuICBJbiBteSBvcGluaW9u LCB0byB1c2UgYW4NCj51bmZvcnR1bmF0ZSBjb2xsb3F1aWFsaXNtIC0gdGhpcyBob3JzZSBpcyBk ZWFkLCB3ZSBzaG91bGQgc3RvcCBiZWF0aW5nIGl0Lg0KPg0KPk9uIDIvNi8xNSwgMTA6MjggQU0s ICJXZW56aGUgWmhvdSIgPFdlbnpoZS5aaG91QGh1YXdlaS5jb20+IHdyb3RlOg0KPg0KPj5LZW4s DQo+Pg0KPj5JbiB5b3VyIHdvcmRzLCBtYW5kYXRvcnkgY29udGV4dCBoZWFkZXJzIHNob3VsZCBi ZSByZW1vdmVkIGZyb20gTlNILg0KPj4NCj4+V2VuemhlDQo+PiANCj4+DQo+Pi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgS2VuIEdyYXkgKGtlZ3JheSkNCj4+U2VudDogVGh1cnNkYXksIEZlYnJ1 YXJ5IDA1LCAyMDE1IDQ6MjUgUE0NCj4+VG86IFJvbiBQYXJrZXI7IEpvZWwgTS4gSGFscGVybjsg Tmljb2xhcyBCT1VUSE9SUzsgJ3NmY0BpZXRmLm9yZycNCj4+U3ViamVjdDogUmU6IFtzZmNdIGRy YWZ0LXF1aW5uLXNmYy1uc2gtMDUsIG9wdGlvbmFsIGhlYWRlcnMNCj4+DQo+PkkgdGhpbmsgdGhl cmXCuXMgYSBkaXNjb25uZWN0aW9uIGhlcmUgKGNvdWxkIGJlIG1lKSBiZXR3ZWVuIHRoZSBpZGVh IG9mDQo+PmFuIGFic3RyYWN0IGFuZCBzcGVjaWZpYyBwYXRoLg0KPj4NCj4+SSB0aG91Z2h0IGl0 IHdhcyBwcmV0dHkgY2xlYXIgKGFuZCB0aGVyZSB3YXMgc2lnbmlmaWNhbnQgdGFsayBhYm91dCBp dA0KPj5oZXJlIG9uIHRoZSBsaXN0KSB0aGF0IHlvdSBjYW4ndCBtYW5kYXRlIGEgc3BlY2lmaWMg bW9kZWwgb2YgZnVuY3Rpb24NCj4+ZWxhc3RpY2l0eSAtIHdlIGNvdWxkbsK5dCBkZWNsYXJlIGxv YWQgYmFsYW5jaW5nIGRldmljZXMgb3IgZnVuY3Rpb25zDQo+PsKzZGVhZMKyIGJ1dCBpbnN0ZWFk IGFzc3VtZWQgdGhhdCBlbGFzdGljaXR5IGNvdWxkIGJlIGRvbmUgbG9jYWxseSBhcyBhDQo+PlNG LCBhcyBwYXJ0IG9mIGEgY29tcG9zaXRlIGZ1bmN0aW9uIHdoZXJlIHRoZSBsb2FkIGJhbGFuY2Vy IGV4aXN0cyBhcw0KPj5wYXJ0IG9mIHRoZSBsb2dpY2FsIGZ1bmN0aW9uIGJlaW5nIHJlbmRlcmVk IG9yIGNlbnRyYWxseS9zdGF0aWNhbGx5Lg0KPj5XZSBoYWQgc2ltaWxhciBkaWFsb2d1ZXMgYWJv dXQgdGhlIG5lZWQgdG8gcmVtYWluIGFic3RyYWN0IGFyb3VuZCBIQQ0KPj50ZWNobmlxdWVzIGFz IHdlbGwuDQo+Pg0KPj5UaGVzZSB0aGluZ3MgbWFrZSBBTiBpbmRpdmlkdWFsIHBhdGgsIHdoaWNo IHJlcHJlc2VudHMgYSBjaGFpbiB0aGF0DQo+PmZpdHMgYSBzcGVjaWZpYyBwb2xpY3kgcnVsZXNl dCDFoCB2YXJpYWJsZSDFoCBhbmQgd2UgZGlkbsK5dCB3YW50IHRvDQo+PnVubmVjZXNzYXJpbHkg ZGVmaW5lIG11bHRpcGxlIGRpc2NyZXRlIGNoYWlucyB0byBjb3ZlciB0aGlzIHNvcnQgb2YNCj4+ ZnVuY3Rpb24gdmFyaWFuY2UgKHdoaWNoIGNhbiBiZWNvbWUgcXVpdGUgbGFyZ2UsIGlmIGZvciBl eGFtcGxlIHRoZQ0KPj5mdW5jdGlvbiBYIGF0IHNpdGUgWSBpcyBhY3R1YWxseSAxMDAwIHBhcmFs bGVsIGluc3RhbmNlcyB0byBhY2NvbW1vZGF0ZQ0KPj5sb2FkLCB3aXRoIEhBIGFkZCBhIG11bHRp cGxpZXIsIHBlciBmdW5jdGlvbiBtb3JlIG11bHRpcGxpZXJzIMWgZm9yIGENCj4+c2luZ2xlIHBh dGggdGhhdCBhdCB0aGUgYWJzdHJhY3QgbGV2ZWwsIHRyYXZlcnNlZCB0aGUgc2FtZSBzaXRlcyDF oGJvb20pLg0KPj4NCj4+VGhlc2UgZGlhbG9ndWVzIGFyZSBjYXB0dXJlZCBpbiB0aGUgYXJjaGl0 ZWN0dXJlIGRvY3VtZW50Lg0KPj4NCj4+U28sIHdoZW4gSSByZWFkIHRoZSBOU0ggZHJhZnQsIEkg aW50ZXJwcmV0ZWQgdGhlIHRyZWF0bWVudCBvZiB0aGUgU1BJDQo+PmFuZCB0aGUgUmVzb2x2ZWQg UGF0aCBhcyB2ZXJ5IGNvbXBhdGlibGUgd2l0aCB0aGF0IGFic3RyYWN0aW9uL2NvbmNlcHQuDQo+ Pkl0IG1ha2VzIG11bHRpcGxlIGRlcGxveW1lbnQgY29udGV4dHMgdW5kZXJzdGFuZGFibGUgYW5k IHBvc3NpYmxlDQo+PndpdGhvdXQgb3Zlcmx5IGRlZmluaW5nIHRoZSBoZWFkZXIgd2l0aCBwb3Rl bnRpYWxseSB1c2VsZXNzIGZpZWxkcyBmb3INCj4+ZXZlcnkgaXRlcmFibGUgY2FzZS4gKEVkaXRv cmlhbCAtIEtpbmQgb2YgYW4gYXJ0IGZvcm0gdGhhdCB3ZSBzaG91bGQNCj4+Y2VsZWJyYXRlLCBJ TU8sIGlmIHBlb3BsZSBhcmUgZ29pbmcgYWJvdXQgZGVzaWduaW5nIHByb3RvY29scy4pDQo+Pg0K Pj5Gb3IgZXhhbXBsZSwgdGhlIFNGRiBjYW4gYmUgc2VlZGVkIHdpdGggb25lIGFuZCBvbmx5IG9u ZSBOSCBmb3IgdGhlDQo+PlNJL1NQSSBtYXRjaCAtIHRodXMgdGhlIHBhdGggaXMgcmVzb2x2ZWQg YW5kIHRoZSBTSS9TUEkgcGF0aCBJUyB0aGUNCj4+cmVuZGVyZWQgcGF0aC4gIFRoZSDCs2RpcmVj dGVkwrIgZ3JhcGggdGhhdCBzb21lIHdhbnRlZCAod2hlcmUgZWFjaA0KPj5pbmRpdmlkdWFsIGVs ZW1lbnQgaW4gYSBsb2NhbGx5IGVsYXN0aWMgcG9vbCBpcyBpbmRpdmlkdWFsbHkNCj4+YWRkcmVz c2FibGUgYW5kIHNldCBhdA0KPj5jbGFzc2lmaWNhdGlvbikgaXMgcmVhbGx5IGEgZGVyaXZhdGl2 ZSBvZiB0aGUgc2FtZSBjYXNlLg0KPj4NCj4+SWYgdGhlcmUgaXMgbW9yZSB0aGFuIG9uZSBOSCBz ZWVkZWQgZm9yIHRoZSBTSS9TUEksIHRoZW4gdGhlIFNGRiBlaXRoZXINCj4+d2lsbCB0cmVhdCB0 aGUgZm9yd2FyZGluZyBhcyBFQ01QIChlLmcuIHN0YXRlbGVzcyB0byBhbiBhbnljYXN0IHBvb2wg LQ0KPj5TSS9TUEkgSVMgdGhlIHJlbmRlcmVkIHBhdGgpLCBvciBoYXZlIGEgbG9jYWwgcG9saWN5 IHRvIHBlcmZvcm0gYW4NCj4+ZXhwbGljaXQgbWFwcGluZy4gIFRoZSBTRkYgbWF5IGFsc28gYmUg anVzdCBoYW5kaW5nIHRoZSBwYWNrZXQgdy9OU0gNCj4+aGVhZGVyIG9mZiB0byBhIGxvY2FsIGlu dGVncmF0ZWQgZnVuY3Rpb24gKGxpa2UgYSBsb2FkIGJhbGFuY2VyKSBvciBhbg0KPj5hdHRhY2hl ZCBjb21wb3NpdGUgZnVuY3Rpb24gdGhhdCBpcyBoYW5kbGluZyBhbiBleHBsaWNpdCBtYXBwaW5n IHRvDQo+PmZ1bmN0aW9uIGluc3RhbmNlcyBpdCBmcm9udHMgKGFuZCBtYW5hZ2luZyBzYW1lIHNv bWV3aGF0IG9ibGlxdWVseSB0bw0KPj50aGUgU0ZGIGFuZCB0aGUgcGF0aCBpdHNlbGYpLg0KPj4N Cj4+VGhlc2UgbmV3IGNvbnRleHRzIGRvbsK5dCBORUVEIGFuZCBzaG91bGRuwrl0IEdFVCBhIHNl cGFyYXRlIGZpZWxkIGluIHRoZQ0KPj5nZW5lcmFsIGhlYWRlci4gIElGLCBmb3IgZXhhbXBsZSwg dGhlIHJlc29sdXRpb24vbWFwcGluZyBvZiBlaXRoZXIgdGhlDQo+PmxvY2FsIFNGRiBwb2xpY3kg KG9yIHRoZSBvYmxpcXVlIGZ1bmN0aW9uKSBpcyBhIHBvbGljeSBrZXllZCB0bw0KPj5jbGFzc2lm aWNhdGlvbiBpbmZvIGxpa2UgZmxvd0lELCB0ZW5hbnRJRCwgc2Vzc2lvbklELCBzb21ldGhpbmcN Cj4+cHJvcHJpZXRhcnkgLSB3ZWxsLCB5b3XCuXZlIGp1c3QgcmVkZWZpbmVkIHRoZSBuZWVkIGZv ciBtZXRhZGF0YSAob25lIG9mDQo+Pm91ciBnb2FscyB3YXMgdG8gYmUgYWJsZSB0byBwcmVzZXJ2 ZSBjbGFzc2lmaWVyIGluZm8gaW4gbWV0YWRhdGEgdG8NCj4+YXZvaWQgZXhjZXNzaXZlIGNsYXNz aWZpY2F0aW9uKSwgd2hpY2ggd2UgYWxsIGFncmVlZCB0byBhbHJlYWR5IC0gYW5kDQo+PndlIGtu b3cgd2hlcmUgdG8gZmluZCBzdWNoIGEga2V5IHNvIHRoZXJlwrlzIG5vIG5lZWQgdG8gbW92ZSBp dC4NCj4+KEVkaXRvcmlhbCAtIE5vdGUgYWxzbyB0aGUgcG90ZW50aWFsIGZvciB2YXJpYW5jZSBv ZiB0aGUga2V5DQo+PnNvdXJjZS92YWx1ZSBhY3Jvc3MNCj4+aW1wbGVtZW50YXRpb25zLikNCj4+ DQo+PllvdSBzaG91bGRuJ3QgTkVFRCBhbiBleHBsaWNpdCBSU1AgSUQgaW4gdGhlIGZpeGVkIGhl YWRlci4gIFRoYXQgc2VlbXMNCj4+dG8gd29yayBiYWNrIGFnYWluc3QgdGhlIG9yaWdpbmFsIGlt cGxpY2l0IGRlc2lnbiBnb2FsIG9mIHRoZSBoZWFkZXIuDQo+Pg0KPj5JIGR1bm5vLCBpZiBpdMK5 cyBqdXN0IG1lLCBJIGhhdmVuwrl0IGRvbmUgcHJvdG9jb2wgZGVzaWduIHNpbmNlIGNvbGxlZ2UN Cj4+xaAgbWF5YmUgScK5bSBydXN0eSBvciBJIG5lZWQgc29tZXRoaW5nIHN0cm9uZ2VyIHRvIGRy aW5rLg0KPj4gIA0KPj4NCj4+Q2hlZXJzLg0KPj4NCj4+DQo+Pk9uIDIvNS8xNSwgMTE6NTcgQU0s ICJSb24gUGFya2VyIiA8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4NCj4+d3JvdGU6 DQo+Pg0KPj4+Sm9lbCwNCj4+Pg0KPj4+SSB0aGluayB5b3UgYXJlIHJlaW5mb3JjaW5nIGEga2V5 IGFzc3VtcHRpb24gaGVyZSAtLSBpZiB0aGUgU0ZGIG5lZWRzDQo+Pj50aGUgaW5mb3JtYXRpb24g dG8gZG8gaXRzIGpvYiwgdGhlbiB0aGF0IGluZm9ybWF0aW9uIHNob3VsZCBiZSBuZWl0aGVyDQo+ Pj5pbg0KPj4+VHlwZSAxIG5vciBUeXBlIDIgbWV0YWRhdGEuICAgIEFzIGFuIGV4YW1wbGUuLi4g IGRlcGVuZGluZyBvbiBob3cgb3VyDQo+Pj5jb250aW51aW5nIGRpc2N1c3Npb24gb24gUlNQIElE IGdvZXMgKGkuZSwgdG8gZW5hYmxlIGJvdGggY2VudHJhbGl6ZWQNCj4+PmNvbmNyZXRlIFJTUCBk ZXRlcm1pbmF0aW9uIGFuZCBkaXN0cmlidXRlZCBob3AtYnktaG9wICJ0cmFpbC1ibGF6ZWQiDQo+ Pj5SU1AgZGV0ZXJtaW5hdGlvbiksIHdlIG1heSB3YW50IHRvICJwcm9tb3RlIiBSU1AgSUQgZnJv bSBtZXRhZGF0YSB0bw0KPj4+dGhlIHN0YW5kYXJkIGhlYWRlci4NCj4+Pg0KPj4+ICAgUm9uDQo+ Pj4NCj4+Pg0KPj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PkZyb206IHNmYyBbbWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJuDQo+ Pj5TZW50OiBUaHVyc2RheSwgRmVicnVhcnkgNSwgMjAxNSAxMTozOSBBTQ0KPj4+VG86IE5pY29s YXMgQk9VVEhPUlM7ICdzZmNAaWV0Zi5vcmcnDQo+Pj5TdWJqZWN0OiBSZTogW3NmY10gZHJhZnQt cXVpbm4tc2ZjLW5zaC0wNSwgb3B0aW9uYWwgaGVhZGVycw0KPj4+DQo+Pj5UaGUgbWV0YWRhdGEg aXMgKGdlbmVyYWxseSkgZm9yIHRoZSBhU2VydmljZSBGdW5jdGlvbnMsIG5vdCBmb3IgdGhlIFNG Ri4NCj4+PiAgU28gdGhlIHF1ZXNpdG9uIG9mIHByb2dyYW1taW5nIHRoZSBTRkYgdG8gcHJvY2Vz cyB0aGUgaW5mb3JtYXRpb24NCj4+PnNlZW1zIG5vdCBlc3BlY2lhbGx5IG1ham9yLg0KPj4+DQo+ Pj5Nb3JlIHNpZ25pZmljYW50bHksIGdpdmVuIHRoYXQgdGhlIDE2IGJ5dGUgdHlwZSAxIGZpZWxk IG1heSBjYXJyeQ0KPj4+ZGlmZmVyZW50IHRoaW5ncyBpbiBkaWZmZXJlbnQgY2FzZXMsIHRoZSBT RnMgd2lsbCBoYXZlIHRvIGJlIGZsZXhpYmxlDQo+Pj5hYm91dCBwcm9jZXNzaW5nIHRoZSBpbmZv cm1hdGlvbiBhbnl3YXkuICBTbyBhbnl0aGluZyB3aGljaCBjYW4gaGFuZGxlDQo+Pj50aGUgdHlw ZSAyIGluZm9ybWF0aW9uIGNhbiBiZSByZWFzb2FuYWJseSBleHBlY3RlZCB0byBoYW5kbGUgdGhl IHNhbWUNCj4+PmtpbmRzIG9mIGluZm9ybWF0aW9uIGZyb20gVExWcyAod2hldGhlciBvbmUgVExW IG9yIG1hbnkpLg0KPj4+DQo+Pj5JdCB0aGVyZWZvcmUgc2VlbXMgY2xlYW5lciB0byBtZSB0byBy ZWNvZ25pemUgdGhhdCB0eXBlIDEgYW5kIHR5cGUgMg0KPj4+YXJlIGRpZmZlcmVudCB3YXlzIG9m IGNhcnJ5aW5nIGluZm9ybWF0aW9uLCBhbmQganVzdCB1c2UgdGhlIG1lY2hhbmlzbQ0KPj4+ZWFj aCBzdXBwb3J0cy4NCj4+Pg0KPj4+WW91cnMsDQo+Pj5Kb2VsDQo+Pj4NCj4+Pk9uIDIvNC8xNSAx MjowNiBQTSwgTmljb2xhcyBCT1VUSE9SUyB3cm90ZToNCj4+Pj4gSXQgaXMgZ3JlYXQgdG8gaGF2 ZSB0aGUgcG9zc2liaWxpdHkgdG8gYWRkIG9wdGlvbmFsIGhlYWRlcnMgaW4gTlNILg0KPj4+Pkhv d2V2ZXIsIHRoZSBtZWNoYW5pc20gcHJvcG9zZWQgc3VwcG9zZSB0aGF0IGEgc3BlY2lmaWMgaGVh ZGVyIHR5cGUNCj4+Pj4odGhlICBNRCBUeXBlPTB4MilpcyB1c2VkIGluIHRoZSBiYXNlIGhlYWRl ciB3aGVuIG9wdGlvbmFsIG1ldGFkYXRhDQo+Pj4+YXJlIHVzZWQuDQo+Pj4+DQo+Pj4+DQo+Pj4+ DQo+Pj4+IEFzIGEgcmVzdWx0Og0KPj4+Pg0KPj4+PiAxLlRoZSBiYXNlIGhlYWRlciB0eXBlIDB4 MSBjYW5ub3QgYmUgdXNlZCB3aXRoIG9wdGlvbmFsIGhlYWRlcnMuDQo+Pj4+IFdoaWNoIG15IG1h a2Ugc2Vuc2UgZm9yIHBlcmZvcm1hbmNlIHBvaW50IG9mIHZpZXcNCj4+Pj4NCj4+Pj4gMi5Ob3Ig d2hlbiB1c2luZyBoZWFkZXIgTUQgdHlwZSB4MiAgY2FuIHRoZSAibWFuZGF0b3J5IGNvbnRleHQN Cj4+Pj5oZWFkZXJzIg0KPj4+PiBiZSBwcmVzZW50Lg0KPj4+Pg0KPj4+PiBDYXNlIDIgY2FuIGJl IHdvcmtlZCBhcm91bmQgYnkgZGVmaW5pbmcgYW4gb3B0aW9uYWwgaGVhZGVyIHRoYXQNCj4+Pj4g cmVwcmVzZW50cyB0aGUgbWFuZGF0b3J5IGNvbnRleHQgaGVhZGVyLiBXaGljaCBpcyBhd2t3YXJk IGFzIFNGRnMNCj4+Pj4gd2lsbCBoYXZlIHRvIGRlY29kZSB0aGUgc2FtZSBpbmZvcm1hdGlvbiBp biB0d28gZGlmZmVyZW50IHdheXMuIE5vdA0KPj4+PiBwYXJ0aWN1bGFybHkgYmVhdXRpZnVsICEN Cj4+Pj4NCj4+Pj4gV2h5IG5vdCBoYXZlIGEgZmxhZyAoRjIpc3RhdGluZyB0aGF0IG5vIG9wdGlv bmFsIE1ldGFkYXRhIGFyZQ0KPj4+PiBwcmVzZW50IGFuZCBhbm90aGVyIG9uZSAoRjEpIHN0YXRp bmcgdGhhdCAod2hhdCBpcyBub3cgY2FsbGVkKSB0aGUNCj4+Pj4gbWFuZGF0b3J5IGNvbnRleHQg aGVhZGVyIGlzIHByZXNlbnQgb3Igbm90Lg0KPj4+Pg0KPj4+PiBXZSBjYW4gdGhlbiBzcGVjaWZ5 IHRoYXQgdGhlIGNvbWJpbmF0aW9ucw0KPj4+Pg0KPj4+PiBGMj1GYWxzZSBpbXBsaWVzIEYxPVRy dWUNCj4+Pj4NCj4+Pj4gRjE9VHJ1ZSwgRjI9VHJ1ZSBpcyBhbGxvd2VkDQo+Pj4+DQo+Pj4+IEYx PSBGYWxzZSwgRjI9VHJ1ZSBpcyBhbGxvd2VkDQo+Pj4+DQo+Pj4+IEl0IHNlZW1zIGNsZWFuZXIu IFdoZW4gcHJlc2VudCwgdGhlICJtYW5kYXRvcnkgY29udGV4dCBoZWFkZXJzIg0KPj4+PiB3b3Vs ZCBhbHdheXMgYmUgYXQgdGhlIHNhbWUgcGxhY2UgaW4gdGhlIHBhY2tldC4NCj4+Pj4NCj4+Pj4g Tmljb2xhcw0KPj4+Pg0KPj4+PiBUaGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyAodGhl ICJtZXNzYWdlIikgYXJlIGNvbmZpZGVudGlhbCwNCj4+Pj4gaW50ZW5kZWQgc29sZWx5IGZvciB0 aGUgYWRkcmVzc2Vlcy4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQo+Pj4+IHJlY2lwaWVu dCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCBhbmQgZGVs ZXRlDQo+Pj4+IHRoaXMgbWVzc2FnZSBmcm9tIHlvdXIgc3lzdGVtLiBJbiB0aGlzIGNhc2UsIHlv dSBhcmUgbm90IGF1dGhvcml6ZWQNCj4+Pj4gdG8gdXNlLCBjb3B5IHRoaXMgbWVzc2FnZSBhbmQv b3IgZGlzY2xvc2UgdGhlIGNvbnRlbnQgdG8gYW55IG90aGVyDQo+Pj4+cGVyc29uLg0KPj4+PiBF LW1haWxzIGFyZSBzdXNjZXB0aWJsZSB0byBhbHRlcmF0aW9uLiBOZWl0aGVyIFFvc21vcyBub3Ig YW55IG9mIGl0cw0KPj4+PiBzdWJzaWRpYXJpZXMgb3IgYWZmaWxpYXRlcyBzaGFsbCBiZSBsaWFi bGUgZm9yIHRoZSBtZXNzYWdlIGlmDQo+Pj4+IGFsdGVyZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KPj4+Pg0KPj4+PiBDZSBtZXNzYWdlIGV0IHRvdXRlcyBzZXMgcGnDqGNlcyBqb2ludGVzIChj aS1hcHLDqHMgbGUgIm1lc3NhZ2UiKXNvbnQNCj4+Pj5jb25maWRlbnRpZWxzIGV0IMOpdGFibGlz IMOgIGwnaW50ZW50aW9uIGV4Y2x1c2l2ZSBkZSBzZXMgZGVzdGluYXRhaXJlcy4NCj4+Pj4gU2kg dm91cyBhdmV6IHJlw6d1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgbWVyY2kgZCdlbiBpbmZvcm1l cg0KPj4+PmltbcOpZGlhdGVtZW50IHNvbiDDqW1ldHRldXIgcGFyIGNvdXJyaWVyIMOpbGVjdHJv bmlxdWUgZXQgZCdlZmZhY2VyIGNlDQo+Pj4+bWVzc2FnZSBkZSB2b3RyZSBzeXN0w6htZS4gRGFu cyBjZXR0ZSBoeXBvdGjDqHNlLCB2b3VzIG4nw6p0ZXMgcGFzDQo+Pj4+YXV0b3Jpc8OpIMOgIHV0 aWxpc2VyLCBjb3BpZXIgY2UgbWVzc2FnZSBldC9vdSBlbiBkaXZ1bGd1ZXIgbGUgY29udGVudQ0K Pj4+PsOgIHVuIHRpZXJzLg0KPj4+PiBUb3V0IG1lc3NhZ2Ugw6lsZWN0cm9uaXF1ZSBlc3Qgc3Vz Y2VwdGlibGUgZCdhbHTDqXJhdGlvbi4gUW9zbW9zIGV0DQo+Pj4+c2VzICBmaWxpYWxlcyBkw6lj bGluZW50IHRvdXRlIHJlc3BvbnNhYmlsaXTDqSBhdSB0aXRyZSBkZSBjZSBtZXNzYWdlDQo+Pj4+ cydpbCBhICDDqXTDqSBhbHTDqXLDqSwgZMOpZm9ybcOpIG91IGZhbHNpZmnDqS4NCj4+Pj4NCj4+ Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4NCj4+Pg0KPj4+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PnNmYyBtYWls aW5nIGxpc3QNCj4+PnNmY0BpZXRmLm9yZw0KPj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCj4+Pg0KPj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+PnNmYyBtYWlsaW5nIGxpc3QNCj4+PnNmY0BpZXRmLm9yZw0KPj4+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+DQo+Pl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PnNmYyBtYWlsaW5nIGxp c3QNCj4+c2ZjQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2ZjDQo+DQoNCg== From nobody Fri Feb 6 18:54:55 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F5C1A1A6B for ; Fri, 6 Feb 2015 18:54:54 -0800 (PST) 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 m0avMk5WatRU for ; Fri, 6 Feb 2015 18:54:50 -0800 (PST) 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 6CD801A1B05 for ; Fri, 6 Feb 2015 18:54:50 -0800 (PST) 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; Fri, 6 Feb 2015 18:54:49 -0800 From: Ron Parker To: "Ken Gray (kegray)" , Wenzhe Zhou , "Joel M. Halpern" , "Nicolas BOUTHORS" , "'sfc@ietf.org'" Thread-Topic: [sfc] draft-quinn-sfc-nsh-05, optional headers Thread-Index: AdBAmYhGpM3EkfNlQ4eMZ3oRb+Ov2QBC7nyAABBDrQAAAATGgAAOiTxwABQciIAADeNUIAABneUA//+buLI= Date: Sat, 7 Feb 2015 02:54:48 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D7D2D2F@LILAS.jungle.qosmos.com> <54D39C93.8050704@joelhalpern.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.229.164.153] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 02:54:54 -0000 Ken,=0A= =0A= Thanks for the thoughtful responses.=0A= =0A= Please see inline Ron>>> below.=0A= =0A= =0A= ________________________________________=0A= From: Ken Gray (kegray) [kegray@cisco.com]=0A= Sent: Friday, February 06, 2015 7:20 PM=0A= To: Ron Parker; Wenzhe Zhou; Joel M. Halpern; Nicolas BOUTHORS; 'sfc@ietf.o= rg'=0A= Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers=0A= =0A= Happy Friday, Ron. In line responses ...=0A= =0A= On 2/6/15, 1:36 PM, "Ron Parker" wrote:= =0A= =0A= >Ken,=0A= >=0A= >Certainly, there is a concept that a nice simple deployment of SFC is to= =0A= >have 1 logical instance of each service function visible at the SFC=0A= >layer. How each of those instances scales is its own business. And,=0A= >certainly, the architecture supports that.=0A= >=0A= >But, does that adequately satisfy all possible uses cases and deployment= =0A= >scenarios we can construct for SFC? Here are some use cases that=0A= >suggest the above concept is necessary but not sufficient:=0A= >=0A= >What if the real-world scale of one of these internally scalable=0A= >instances is still insufficient?=0A= =0A= The terms =93real world=94 and =93insufficient=94 are vague, but I th= ink=0A= actually a good argument why the secondary key for a lookup by the=0A= balancer/whatever should be kept in metadata - and, as I point out before,= =0A= a RELEVANT key is most likely there. At worst, if it=92s in a fixed contex= t=0A= (type1) it=92s a 32 bit number and if you need larger, it could be in a=0A= variable length TLV (type 2) =85and I=92d think =93bigger than 32 bits=94 w= ould be=0A= pretty special.=0A= =0A= Ron>>> I did originally think of this as metadata, too (regardless of which= type), but I'm now questioning my own conclusion. Wouldn't SFF need to m= ake decisions based on this? Say for RSP x, after sending to and receivin= g from a locally connected Service Function Instance, the next SFF is SFF = y. And SFF is not supposed to care about metadata, certainly not for basi= c forwarding behavior.=0A= =0A= >=0A= >=0A= >What if a higher level of redundancy is desired by deploying more than=0A= >one of those internally scalable instances? More than 2 of them?=0A= =0A= I think you=92re making the same argument I was making above. I=0A= shouldn=92t care and it seems like we=92re careening further away from usin= g a=0A= fixed field to solve that problem. Again, if the SPI/SI gets me to my=0A= first =93decision point=94 =85a locality where elasticity/HA expansion is t= aking=0A= place and you use my example of the context header being a secondary key=0A= to guide a lookup to whatever that device is =85 a unique 32bit value even= =0A= for a direct mapping is a HUGE space (Carl Saganesque).=0A= =0A= Ron>>> But per the architecture, SFP is not necessarily an exact sequence o= f concrete next hops. That thing is the RSP. Same argument about the SF= F usage of this for forwarding. But do note that as I pointed out previou= sly, for centrally orchestrated environments, only a single level of identi= fier is needed -- but that identifier is better named RSP ID than SFP ID to= match the architectural spec. And 32 bits is fine. Where a dual level = identifier is needed (I'm proposing 2 32 bit identifiers) is when hop-by-ho= p trail blazing is used (i.e., late binding) to forge the actual RSP. Now= the RSP ID becomes a hint that the classifier drops into the packet to ens= ure that all packets with the same hint traverse the same exact sequence. = The first packet seen by SFF with this hint results in a local load balanc= ing decision. Subsequent packets are forwarded per the very first decisio= n, barring local failures. What I'm proposing is that the architecture em= brace both centrally orchestrated RSP binding and distributed RSP binding.= =0A= =0A= >=0A= >=0A= >What if the SFC is extended across the MAN and WAN (and to avoid=0A= >argument, let's say we are still in the same administrative domain)?=0A= >What if we want to apply location awareness to instance selection in=0A= >order to optimize the overall behavior?=0A= =0A= Interesting example and I hear this a lot as far as what you COULD=0A= do with SFC, but if delay is any factor in the policy that controls the=0A= creation of individual chains/SPIDs, then I=92d argue that they wouldn=92t = be=0A= equivalent abstract paths - they would be more or less separate chains in= =0A= my view.=0A= =0A= Ron>>> I'm close to conceding this point, except for the following counter = use case -- if the "close" instance is not in overload, then use it, otherw= ise use the "far" instance.=0A= =0A= =0A= But okay, they=92re close enough for you not to care =85 the problem you ha= ve=0A= to solve is to select a criteria on which to pick the destination from a=0A= decision point in the path for your elastic/flexible SI/SPI match ... not= =0A= how far the NHs that it resolves to are from that point. Say your NH are= =0A= in Cleveland and Chicago =85 these don=92t move relative to the decision po= int=0A= =85 so their distance is not a criteria in and of itself - otherwise I woul= d=0A= just weight the NH from the control plane distributing them to reflect=0A= what my valuation of load and distance should be (to reflect my policy).=0A= That=92s all static (the NH weight could be updated if Cleveland or Chicago= =0A= move or if I change my policy ;^).=0A= =0A= Ron>>> Per above. But I could also be convinced that yet higher level po= licy says to use SFP A preferably, but SFP B otherwise, per your analysis.= =0A= =0A= =0A= >=0A= >What if we want to support other instance selection criteria, like gold=0A= >customers get on the higher performance RSP for a particular functional=0A= >chain but bronze customers the lower performance RSP for that same=0A= >functional chain?=0A= =0A= Identity, session, metadata =85 I think I gave this example.=0A= =0A= Ron>>> I agree. Use case is withdrawn. This lends itself to distinct SF= P's (i.e., different policy constraints on the SFC).=0A= =0A= =0A= >=0A= >And, although it is not a functional use case in the same manner as=0A= >above, what if some network designers determine it is cheaper and simpler= =0A= >to deploy SFC using service function instances that are simpler and don't= =0A= >have inbuilt horizontal scale? More along the lines of the "fit VNF"=0A= >approach (attribution to Contextream).=0A= =0A= They have the option of blowing out the SPID space, as I said,=0A= that=92s a derivative example of the SPI/SI having a single NH, IMO =85each= =0A= permutation is a direct mapping and different SPID and what/how you affix= =0A= these (policy) is reflected at classification. The abstraction in the=0A= language was only there to help people imagine the flexibility available=0A= through the usage I describe.=0A= =0A= Ron>>> The architecture states that RSP is the fully concrete sequence of h= ops. But mostly, for me, the argument is about the utility of late bindin= g (or not, if you are of that persuasion).=0A= =0A= =0A= >=0A= >The group's proposed solution should be measured against the use cases=0A= >and and deployment scenarios we feel need to be addressed, and this is=0A= >probably the main difference in viewpoint, here. To follow on to Ken's= =0A= >colloquialism, my opinion is that the horse is not dead and that the=0A= >different viewpoints do not reflect a fundamental inability to grasp the= =0A= >concepts.=0A= >=0A= >Thanks.=0A= >=0A= > Ron=0A= >=0A= >=0A= >=0A= >=0A= >-----Original Message-----=0A= >From: Ken Gray (kegray) [mailto:kegray@cisco.com]=0A= >Sent: Friday, February 6, 2015 11:57 AM=0A= >To: Wenzhe Zhou; Ron Parker; Joel M. Halpern; Nicolas BOUTHORS;=0A= >'sfc@ietf.org'=0A= >Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers=0A= >=0A= >In my words, I am not suggesting changing the draft at all. I think it=92= s=0A= >sufficient.=0A= >=0A= >=0A= >My opinion, is that the suggested changes in this thread show a=0A= >fundamental failure to grasp the concepts we hashed out in the=0A= >architecture (which I attempted to clarify). In my opinion, to use an=0A= >unfortunate colloquialism - this horse is dead, we should stop beating it.= =0A= >=0A= >On 2/6/15, 10:28 AM, "Wenzhe Zhou" wrote:=0A= >=0A= >>Ken,=0A= >>=0A= >>In your words, mandatory context headers should be removed from NSH.=0A= >>=0A= >>Wenzhe=0A= >>=0A= >>=0A= >>-----Original Message-----=0A= >>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ken Gray (kegray)=0A= >>Sent: Thursday, February 05, 2015 4:25 PM=0A= >>To: Ron Parker; Joel M. Halpern; Nicolas BOUTHORS; 'sfc@ietf.org'=0A= >>Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers=0A= >>=0A= >>I think there=B9s a disconnection here (could be me) between the idea of= =0A= >>an abstract and specific path.=0A= >>=0A= >>I thought it was pretty clear (and there was significant talk about it=0A= >>here on the list) that you can't mandate a specific model of function=0A= >>elasticity - we couldn=B9t declare load balancing devices or functions=0A= >>=B3dead=B2 but instead assumed that elasticity could be done locally as a= =0A= >>SF, as part of a composite function where the load balancer exists as=0A= >>part of the logical function being rendered or centrally/statically.=0A= >>We had similar dialogues about the need to remain abstract around HA=0A= >>techniques as well.=0A= >>=0A= >>These things make AN individual path, which represents a chain that=0A= >>fits a specific policy ruleset =8A variable =8A and we didn=B9t want to= =0A= >>unnecessarily define multiple discrete chains to cover this sort of=0A= >>function variance (which can become quite large, if for example the=0A= >>function X at site Y is actually 1000 parallel instances to accommodate= =0A= >>load, with HA add a multiplier, per function more multipliers =8Afor a=0A= >>single path that at the abstract level, traversed the same sites =8Aboom)= .=0A= >>=0A= >>These dialogues are captured in the architecture document.=0A= >>=0A= >>So, when I read the NSH draft, I interpreted the treatment of the SPI=0A= >>and the Resolved Path as very compatible with that abstraction/concept.= =0A= >>It makes multiple deployment contexts understandable and possible=0A= >>without overly defining the header with potentially useless fields for=0A= >>every iterable case. (Editorial - Kind of an art form that we should=0A= >>celebrate, IMO, if people are going about designing protocols.)=0A= >>=0A= >>For example, the SFF can be seeded with one and only one NH for the=0A= >>SI/SPI match - thus the path is resolved and the SI/SPI path IS the=0A= >>rendered path. The =B3directed=B2 graph that some wanted (where each=0A= >>individual element in a locally elastic pool is individually=0A= >>addressable and set at=0A= >>classification) is really a derivative of the same case.=0A= >>=0A= >>If there is more than one NH seeded for the SI/SPI, then the SFF either= =0A= >>will treat the forwarding as ECMP (e.g. stateless to an anycast pool -=0A= >>SI/SPI IS the rendered path), or have a local policy to perform an=0A= >>explicit mapping. The SFF may also be just handing the packet w/NSH=0A= >>header off to a local integrated function (like a load balancer) or an=0A= >>attached composite function that is handling an explicit mapping to=0A= >>function instances it fronts (and managing same somewhat obliquely to=0A= >>the SFF and the path itself).=0A= >>=0A= >>These new contexts don=B9t NEED and shouldn=B9t GET a separate field in t= he=0A= >>general header. IF, for example, the resolution/mapping of either the=0A= >>local SFF policy (or the oblique function) is a policy keyed to=0A= >>classification info like flowID, tenantID, sessionID, something=0A= >>proprietary - well, you=B9ve just redefined the need for metadata (one of= =0A= >>our goals was to be able to preserve classifier info in metadata to=0A= >>avoid excessive classification), which we all agreed to already - and=0A= >>we know where to find such a key so there=B9s no need to move it.=0A= >>(Editorial - Note also the potential for variance of the key=0A= >>source/value across=0A= >>implementations.)=0A= >>=0A= >>You shouldn't NEED an explicit RSP ID in the fixed header. That seems=0A= >>to work back against the original implicit design goal of the header.=0A= >>=0A= >>I dunno, if it=B9s just me, I haven=B9t done protocol design since colleg= e=0A= >>=8A maybe I=B9m rusty or I need something stronger to drink.=0A= >>=0A= >>=0A= >>Cheers.=0A= >>=0A= >>=0A= >>On 2/5/15, 11:57 AM, "Ron Parker" =0A= >>wrote:=0A= >>=0A= >>>Joel,=0A= >>>=0A= >>>I think you are reinforcing a key assumption here -- if the SFF needs=0A= >>>the information to do its job, then that information should be neither= =0A= >>>in=0A= >>>Type 1 nor Type 2 metadata. As an example... depending on how our=0A= >>>continuing discussion on RSP ID goes (i.e, to enable both centralized=0A= >>>concrete RSP determination and distributed hop-by-hop "trail-blazed"=0A= >>>RSP determination), we may want to "promote" RSP ID from metadata to=0A= >>>the standard header.=0A= >>>=0A= >>> Ron=0A= >>>=0A= >>>=0A= >>>-----Original Message-----=0A= >>>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern=0A= >>>Sent: Thursday, February 5, 2015 11:39 AM=0A= >>>To: Nicolas BOUTHORS; 'sfc@ietf.org'=0A= >>>Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers=0A= >>>=0A= >>>The metadata is (generally) for the aService Functions, not for the SFF.= =0A= >>> So the quesiton of programming the SFF to process the information=0A= >>>seems not especially major.=0A= >>>=0A= >>>More significantly, given that the 16 byte type 1 field may carry=0A= >>>different things in different cases, the SFs will have to be flexible=0A= >>>about processing the information anyway. So anything which can handle= =0A= >>>the type 2 information can be reasoanably expected to handle the same=0A= >>>kinds of information from TLVs (whether one TLV or many).=0A= >>>=0A= >>>It therefore seems cleaner to me to recognize that type 1 and type 2=0A= >>>are different ways of carrying information, and just use the mechanism= =0A= >>>each supports.=0A= >>>=0A= >>>Yours,=0A= >>>Joel=0A= >>>=0A= >>>On 2/4/15 12:06 PM, Nicolas BOUTHORS wrote:=0A= >>>> It is great to have the possibility to add optional headers in NSH.=0A= >>>>However, the mechanism proposed suppose that a specific header type=0A= >>>>(the MD Type=3D0x2)is used in the base header when optional metadata= =0A= >>>>are used.=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> As a result:=0A= >>>>=0A= >>>> 1.The base header type 0x1 cannot be used with optional headers.=0A= >>>> Which my make sense for performance point of view=0A= >>>>=0A= >>>> 2.Nor when using header MD type x2 can the "mandatory context=0A= >>>>headers"=0A= >>>> be present.=0A= >>>>=0A= >>>> Case 2 can be worked around by defining an optional header that=0A= >>>> represents the mandatory context header. Which is awkward as SFFs=0A= >>>> will have to decode the same information in two different ways. Not=0A= >>>> particularly beautiful !=0A= >>>>=0A= >>>> Why not have a flag (F2)stating that no optional Metadata are=0A= >>>> present and another one (F1) stating that (what is now called) the=0A= >>>> mandatory context header is present or not.=0A= >>>>=0A= >>>> We can then specify that the combinations=0A= >>>>=0A= >>>> F2=3DFalse implies F1=3DTrue=0A= >>>>=0A= >>>> F1=3DTrue, F2=3DTrue is allowed=0A= >>>>=0A= >>>> F1=3D False, F2=3DTrue is allowed=0A= >>>>=0A= >>>> It seems cleaner. When present, the "mandatory context headers"=0A= >>>> would always be at the same place in the packet.=0A= >>>>=0A= >>>> Nicolas=0A= >>>>=0A= >>>> This message and any attachments (the "message") are confidential,=0A= >>>> intended solely for the addressees. If you are not the intended=0A= >>>> recipient, please notify the sender immediately by e-mail and delete= =0A= >>>> this message from your system. In this case, you are not authorized=0A= >>>> to use, copy this message and/or disclose the content to any other=0A= >>>>person.=0A= >>>> E-mails are susceptible to alteration. Neither Qosmos nor any of its= =0A= >>>> subsidiaries or affiliates shall be liable for the message if=0A= >>>> altered, changed or falsified.=0A= >>>>=0A= >>>> Ce message et toutes ses pi=E8ces jointes (ci-apr=E8s le "message")son= t=0A= >>>>confidentiels et =E9tablis =E0 l'intention exclusive de ses destinatair= es.=0A= >>>> Si vous avez re=E7u ce message par erreur, merci d'en informer=0A= >>>>imm=E9diatement son =E9metteur par courrier =E9lectronique et d'effacer= ce=0A= >>>>message de votre syst=E8me. Dans cette hypoth=E8se, vous n'=EAtes pas= =0A= >>>>autoris=E9 =E0 utiliser, copier ce message et/ou en divulguer le conten= u=0A= >>>>=E0 un tiers.=0A= >>>> Tout message =E9lectronique est susceptible d'alt=E9ration. Qosmos et= =0A= >>>>ses filiales d=E9clinent toute responsabilit=E9 au titre de ce message= =0A= >>>>s'il a =E9t=E9 alt=E9r=E9, d=E9form=E9 ou falsifi=E9.=0A= >>>>=0A= >>>>=0A= >>>>=0A= >>>> _______________________________________________=0A= >>>> sfc mailing list=0A= >>>> sfc@ietf.org=0A= >>>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>>>=0A= >>>=0A= >>>_______________________________________________=0A= >>>sfc mailing list=0A= >>>sfc@ietf.org=0A= >>>https://www.ietf.org/mailman/listinfo/sfc=0A= >>>=0A= >>>_______________________________________________=0A= >>>sfc mailing list=0A= >>>sfc@ietf.org=0A= >>>https://www.ietf.org/mailman/listinfo/sfc=0A= >>=0A= >>_______________________________________________=0A= >>sfc mailing list=0A= >>sfc@ietf.org=0A= >>https://www.ietf.org/mailman/listinfo/sfc=0A= >=0A= =0A= From nobody Sat Feb 7 07:55:25 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 8F14F1A1A17 for ; Sat, 7 Feb 2015 07:55:23 -0800 (PST) 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 lNOOF8rmw4gy for ; Sat, 7 Feb 2015 07:55:19 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96A271A026C for ; Sat, 7 Feb 2015 07:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27366; q=dns/txt; s=iport; t=1423324519; x=1424534119; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=J6+fHfDkG3DTnHoqqrYTce5VMKYhUQcEeIOPhK6bb1s=; b=Iddi+Jxl3Xwd/t1Q0Wy09TFa12CenW4CyS7LJu5lB0DUmA8NsGiTX+iy B7KId4xkFCbXSISx6hxfdhPWWYu+0WurF45ciuyKtVc0gYS0PUEAMkwck Ct8RRHVb5nS1oHDKbY+ds2WWKh+GBL8n3h09kuaoUcXAWqU15KK4rP5rV Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgHAP4z1lStJA2G/2dsb2JhbABSCYJkIlJaBII3R790CoVxAhxzQwEBAQEBAXyEDAEBAQQBAQEJFxETDREJFwQCAQYCEQEDAQEBAgIjAwICAiULFAECBggCBAESG4gSAQycJZxshRaRAAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSGIbYUPKAgyAgICgmKBQgWNKIFzhDOBLoNLgRiDA4JGSYgIgz4iggIcgVBvgUR+AQEB X-IronPort-AV: E=Sophos;i="5.09,535,1418083200"; d="scan'208";a="394292957" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP; 07 Feb 2015 15:55:17 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t17FtG5D030618 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 7 Feb 2015 15:55:17 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Sat, 7 Feb 2015 09:55:16 -0600 From: "Ken Gray (kegray)" To: Ron Parker , Wenzhe Zhou , "Joel M. Halpern" , "Nicolas BOUTHORS" , "'sfc@ietf.org'" Thread-Topic: [sfc] draft-quinn-sfc-nsh-05, optional headers Thread-Index: AdBAmYhGpM3EkfNlQ4eMZ3oRb+Ov2QA+vZmAAACmJgAABSfyAAAqBvAA///E9gCAAG+2AIAADFSAgAB+zgCAAIY8gA== Date: Sat, 7 Feb 2015 15:55:16 +0000 Message-ID: References: <76B41B8FACE1514795D30EC137FF391D7D2D2F@LILAS.jungle.qosmos.com> <54D39C93.8050704@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.24.144.124] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] draft-quinn-sfc-nsh-05, optional headers X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Feb 2015 15:55:23 -0000 QSBmZXcgaW4gbGluZSAuLi4NCg0KT24gMi82LzE1LCA5OjU0IFBNLCAiUm9uIFBhcmtlciIgPFJv bl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+IHdyb3RlOg0KDQo+S2VuLA0KPg0KPlRoYW5r cyBmb3IgdGhlIHRob3VnaHRmdWwgcmVzcG9uc2VzLg0KPg0KPlBsZWFzZSBzZWUgaW5saW5lIFJv bj4+PiBiZWxvdy4NCj4NCj4gDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPkZyb206IEtlbiBHcmF5IChrZWdyYXkpIFtrZWdyYXlAY2lzY28uY29tXQ0KPlNlbnQ6 IEZyaWRheSwgRmVicnVhcnkgMDYsIDIwMTUgNzoyMCBQTQ0KPlRvOiBSb24gUGFya2VyOyBXZW56 aGUgWmhvdTsgSm9lbCBNLiBIYWxwZXJuOyBOaWNvbGFzIEJPVVRIT1JTOw0KPidzZmNAaWV0Zi5v cmcnDQo+U3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1uc2gtMDUsIG9wdGlvbmFs IGhlYWRlcnMNCj4NCj5IYXBweSBGcmlkYXksIFJvbi4gIEluIGxpbmUgcmVzcG9uc2VzIC4uLg0K Pg0KPk9uIDIvNi8xNSwgMTozNiBQTSwgIlJvbiBQYXJrZXIiIDxSb25fUGFya2VyQGFmZmlybWVk bmV0d29ya3MuY29tPiB3cm90ZToNCj4NCj4+S2VuLA0KPj4NCj4+Q2VydGFpbmx5LCB0aGVyZSBp cyBhIGNvbmNlcHQgdGhhdCBhIG5pY2Ugc2ltcGxlIGRlcGxveW1lbnQgb2YgU0ZDIGlzIHRvDQo+ PmhhdmUgMSBsb2dpY2FsIGluc3RhbmNlIG9mIGVhY2ggc2VydmljZSBmdW5jdGlvbiB2aXNpYmxl IGF0IHRoZSBTRkMNCj4+bGF5ZXIuICAgSG93IGVhY2ggb2YgdGhvc2UgaW5zdGFuY2VzIHNjYWxl cyBpcyBpdHMgb3duIGJ1c2luZXNzLiAgIEFuZCwNCj4+Y2VydGFpbmx5LCB0aGUgYXJjaGl0ZWN0 dXJlIHN1cHBvcnRzIHRoYXQuDQo+Pg0KPj5CdXQsIGRvZXMgdGhhdCBhZGVxdWF0ZWx5IHNhdGlz ZnkgYWxsIHBvc3NpYmxlIHVzZXMgY2FzZXMgYW5kIGRlcGxveW1lbnQNCj4+c2NlbmFyaW9zIHdl IGNhbiBjb25zdHJ1Y3QgZm9yIFNGQz8gICAgSGVyZSBhcmUgc29tZSB1c2UgY2FzZXMgdGhhdA0K Pj5zdWdnZXN0IHRoZSBhYm92ZSBjb25jZXB0IGlzIG5lY2Vzc2FyeSBidXQgbm90IHN1ZmZpY2ll bnQ6DQo+Pg0KPj5XaGF0IGlmIHRoZSByZWFsLXdvcmxkIHNjYWxlIG9mIG9uZSBvZiB0aGVzZSBp bnRlcm5hbGx5IHNjYWxhYmxlDQo+Pmluc3RhbmNlcyBpcyBzdGlsbCBpbnN1ZmZpY2llbnQ/DQo+ DQo+PGtlZz4gVGhlIHRlcm1zIOKAnHJlYWwgd29ybGTigJ0gYW5kIOKAnGluc3VmZmljaWVudOKA nSBhcmUgdmFndWUsIGJ1dCBJIHRoaW5rDQo+YWN0dWFsbHkgYSBnb29kIGFyZ3VtZW50IHdoeSB0 aGUgc2Vjb25kYXJ5IGtleSBmb3IgYSBsb29rdXAgYnkgdGhlDQo+YmFsYW5jZXIvd2hhdGV2ZXIg c2hvdWxkIGJlIGtlcHQgaW4gbWV0YWRhdGEgLSBhbmQsIGFzIEkgcG9pbnQgb3V0IGJlZm9yZSwN Cj5hIFJFTEVWQU5UIGtleSBpcyBtb3N0IGxpa2VseSB0aGVyZS4gIEF0IHdvcnN0LCBpZiBpdOKA mXMgaW4gYSBmaXhlZCBjb250ZXh0DQo+KHR5cGUxKSBpdOKAmXMgYSAzMiBiaXQgbnVtYmVyIGFu ZCBpZiB5b3UgbmVlZCBsYXJnZXIsIGl0IGNvdWxkIGJlIGluIGENCj52YXJpYWJsZSBsZW5ndGgg VExWICh0eXBlIDIpIOKApmFuZCBJ4oCZZCB0aGluayDigJxiaWdnZXIgdGhhbiAzMiBiaXRz4oCd IHdvdWxkIGJlDQo+cHJldHR5IHNwZWNpYWwuDQo+DQo+Um9uPj4+IEkgZGlkIG9yaWdpbmFsbHkg dGhpbmsgb2YgdGhpcyBhcyBtZXRhZGF0YSwgdG9vIChyZWdhcmRsZXNzIG9mDQo+d2hpY2ggdHlw ZSksIGJ1dCBJJ20gbm93IHF1ZXN0aW9uaW5nIG15IG93biBjb25jbHVzaW9uLiAgIFdvdWxkbid0 IFNGRg0KPm5lZWQgdG8gbWFrZSBkZWNpc2lvbnMgYmFzZWQgb24gdGhpcz8gICBTYXkgZm9yIFJT UCB4LCBhZnRlciBzZW5kaW5nIHRvDQo+YW5kIHJlY2VpdmluZyBmcm9tIGEgbG9jYWxseSBjb25u ZWN0ZWQgU2VydmljZSBGdW5jdGlvbiBJbnN0YW5jZSwgIHRoZQ0KPm5leHQgU0ZGIGlzIFNGRiB5 LiAgIEFuZCBTRkYgaXMgbm90IHN1cHBvc2VkIHRvIGNhcmUgYWJvdXQgbWV0YWRhdGEsDQo+Y2Vy dGFpbmx5IG5vdCBmb3IgYmFzaWMgZm9yd2FyZGluZyBiZWhhdmlvci4NCg0KPGtlZz4gSeKAmW0g ZW5jb3VyYWdpbmcgeW91IHRvIGdvIHdpdGggeW91ciBmaXJzdCBpbnN0aW5jdCA7XikuDQoNCj4N Cj4+DQo+Pg0KPj5XaGF0IGlmIGEgaGlnaGVyIGxldmVsIG9mIHJlZHVuZGFuY3kgaXMgZGVzaXJl ZCBieSBkZXBsb3lpbmcgbW9yZSB0aGFuDQo+Pm9uZSBvZiB0aG9zZSBpbnRlcm5hbGx5IHNjYWxh YmxlIGluc3RhbmNlcz8gICBNb3JlIHRoYW4gMiBvZiB0aGVtPw0KPg0KPjxrZWc+IEkgdGhpbmsg eW914oCZcmUgbWFraW5nIHRoZSBzYW1lIGFyZ3VtZW50IEkgd2FzIG1ha2luZyBhYm92ZS4gIEkN Cj5zaG91bGRu4oCZdCBjYXJlIGFuZCBpdCBzZWVtcyBsaWtlIHdl4oCZcmUgY2FyZWVuaW5nIGZ1 cnRoZXIgYXdheSBmcm9tIHVzaW5nIGENCj5maXhlZCBmaWVsZCB0byBzb2x2ZSB0aGF0IHByb2Js ZW0uICBBZ2FpbiwgaWYgdGhlIFNQSS9TSSBnZXRzIG1lIHRvIG15DQo+Zmlyc3Qg4oCcZGVjaXNp b24gcG9pbnTigJ0g4oCmYSBsb2NhbGl0eSB3aGVyZSBlbGFzdGljaXR5L0hBIGV4cGFuc2lvbiBp cyB0YWtpbmcNCj5wbGFjZSBhbmQgeW91IHVzZSBteSBleGFtcGxlIG9mIHRoZSBjb250ZXh0IGhl YWRlciBiZWluZyBhIHNlY29uZGFyeSBrZXkNCj50byBndWlkZSBhIGxvb2t1cCB0byB3aGF0ZXZl ciB0aGF0IGRldmljZSBpcyDigKYgYSB1bmlxdWUgMzJiaXQgdmFsdWUgZXZlbg0KPmZvciBhIGRp cmVjdCBtYXBwaW5nIGlzIGEgSFVHRSBzcGFjZSAoQ2FybCBTYWdhbmVzcXVlKS4NCj4NCj5Sb24+ Pj4gQnV0IHBlciB0aGUgYXJjaGl0ZWN0dXJlLCBTRlAgaXMgbm90IG5lY2Vzc2FyaWx5IGFuIGV4 YWN0IHNlcXVlbmNlDQo+b2YgY29uY3JldGUgbmV4dCBob3BzLiAgIFRoYXQgdGhpbmcgaXMgdGhl IFJTUC4gICBTYW1lIGFyZ3VtZW50IGFib3V0IHRoZQ0KPlNGRiB1c2FnZSBvZiB0aGlzIGZvciBm b3J3YXJkaW5nLiAgIEJ1dCBkbyBub3RlIHRoYXQgYXMgSSBwb2ludGVkIG91dA0KPnByZXZpb3Vz bHksIGZvciBjZW50cmFsbHkgb3JjaGVzdHJhdGVkIGVudmlyb25tZW50cywgb25seSBhIHNpbmds ZSBsZXZlbA0KPm9mIGlkZW50aWZpZXIgaXMgbmVlZGVkIC0tIGJ1dCB0aGF0IGlkZW50aWZpZXIg aXMgYmV0dGVyIG5hbWVkIFJTUCBJRA0KPnRoYW4gU0ZQIElEIHRvIG1hdGNoIHRoZSBhcmNoaXRl Y3R1cmFsIHNwZWMuICAgQW5kIDMyIGJpdHMgaXMgZmluZS4NCj5XaGVyZSBhIGR1YWwgbGV2ZWwg aWRlbnRpZmllciBpcyBuZWVkZWQgKEknbSBwcm9wb3NpbmcgMiAzMiBiaXQNCj5pZGVudGlmaWVy cykgaXMgd2hlbiBob3AtYnktaG9wIHRyYWlsIGJsYXppbmcgaXMgdXNlZCAoaS5lLiwgbGF0ZQ0K PmJpbmRpbmcpIHRvIGZvcmdlIHRoZSBhY3R1YWwgUlNQLiAgIE5vdyB0aGUgUlNQIElEIGJlY29t ZXMgYSBoaW50IHRoYXQNCj50aGUgY2xhc3NpZmllciBkcm9wcyBpbnRvIHRoZSBwYWNrZXQgdG8g ZW5zdXJlIHRoYXQgYWxsIHBhY2tldHMgd2l0aCB0aGUNCj5zYW1lIGhpbnQgdHJhdmVyc2UgdGhl IHNhbWUgZXhhY3Qgc2VxdWVuY2UuICAgVGhlIGZpcnN0IHBhY2tldCBzZWVuIGJ5DQo+U0ZGIHdp dGggdGhpcyBoaW50IHJlc3VsdHMgaW4gYSBsb2NhbCBsb2FkIGJhbGFuY2luZyBkZWNpc2lvbi4N Cj5TdWJzZXF1ZW50IHBhY2tldHMgYXJlIGZvcndhcmRlZCBwZXIgdGhlIHZlcnkgZmlyc3QgZGVj aXNpb24sIGJhcnJpbmcNCj5sb2NhbCBmYWlsdXJlcy4gICBXaGF0IEknbSBwcm9wb3NpbmcgaXMg dGhhdCB0aGUgYXJjaGl0ZWN0dXJlIGVtYnJhY2UNCj5ib3RoIGNlbnRyYWxseSBvcmNoZXN0cmF0 ZWQgUlNQIGJpbmRpbmcgYW5kIGRpc3RyaWJ1dGVkIFJTUCBiaW5kaW5nLg0KDQo8a2VnPiBXaGF0 IEnigJltIGFyZ3VpbmcgaXMgdGhhdCB5b3UgU0hPVUxETuKAmVQgY29kaWZ5IHRoaXMgaW4gdGhl IGZpeGVkDQpoZWFkZXIgdW5sZXNzIHlvdeKAmXJlIHN1cmUgaXTigJlzIHRoZSBydWxlIGluc3Rl YWQgb2YgdGhlIGV4Y2VwdGlvbi4gIEV2ZW4gaWYNCml0IHdlcmUgdGhlIHJ1bGUsIGhvdyBtYW55 IGxheWVycyBvZiBzZWNvbmRhcnkga2V5IHNob3VsZCB3ZSBhbGxvdyDigKYgd2h5DQpzdG9wIGF0 IHR3bz8gIFRoZSBNRCBUeXBlMSBjb250ZXh0cyBhbmQgcGVyaGFwcyBldmVuIHRoZSBUTFZzIChp ZiB5b3UNCnRydWx5IGhhdmUgYSBjYXNlIHdoZXJlIHlvdSB3YW50IG11bHRpLW11bHRpIGxldmVs cywg4oCccnVzc2lhbiBkb2xs4oCdIHN0eWxlDQrigKYgYW5kIGFnYWluIHRoaXMgaXMgd2hlcmUg 4oCmaWYgSSBleHRlbmQgeW91ciB1c2UgY2FzZSDigKZJIGdvKSBhcmUgYSBiZXR0ZXINCnBsYWNl IHRvIHB1dCB0aGVzZS4NCg0KPg0KPj4NCj4+DQo+PldoYXQgaWYgdGhlIFNGQyBpcyBleHRlbmRl ZCBhY3Jvc3MgdGhlIE1BTiBhbmQgV0FOIChhbmQgdG8gYXZvaWQNCj4+YXJndW1lbnQsIGxldCdz IHNheSB3ZSBhcmUgc3RpbGwgaW4gdGhlIHNhbWUgYWRtaW5pc3RyYXRpdmUgZG9tYWluKT8NCj4+ V2hhdCBpZiB3ZSB3YW50IHRvIGFwcGx5IGxvY2F0aW9uIGF3YXJlbmVzcyB0byBpbnN0YW5jZSBz ZWxlY3Rpb24gaW4NCj4+b3JkZXIgdG8gb3B0aW1pemUgdGhlIG92ZXJhbGwgYmVoYXZpb3I/DQo+ DQo+PGtlZz4gSW50ZXJlc3RpbmcgZXhhbXBsZSBhbmQgSSBoZWFyIHRoaXMgYSBsb3QgYXMgZmFy IGFzIHdoYXQgeW91IENPVUxEDQo+ZG8gd2l0aCBTRkMsIGJ1dCBpZiBkZWxheSBpcyBhbnkgZmFj dG9yIGluIHRoZSBwb2xpY3kgdGhhdCBjb250cm9scyB0aGUNCj5jcmVhdGlvbiBvZiBpbmRpdmlk dWFsIGNoYWlucy9TUElEcywgdGhlbiBJ4oCZZCBhcmd1ZSB0aGF0IHRoZXkgd291bGRu4oCZdCBi ZQ0KPmVxdWl2YWxlbnQgYWJzdHJhY3QgcGF0aHMgLSB0aGV5IHdvdWxkIGJlIG1vcmUgb3IgbGVz cyBzZXBhcmF0ZSBjaGFpbnMgaW4NCj5teSB2aWV3Lg0KPg0KPlJvbj4+PiBJJ20gY2xvc2UgdG8g Y29uY2VkaW5nIHRoaXMgcG9pbnQsIGV4Y2VwdCBmb3IgdGhlIGZvbGxvd2luZw0KPmNvdW50ZXIg dXNlIGNhc2UgLS0gaWYgdGhlICJjbG9zZSIgaW5zdGFuY2UgaXMgbm90IGluIG92ZXJsb2FkLCB0 aGVuIHVzZQ0KPml0LCBvdGhlcndpc2UgdXNlIHRoZSAiZmFyIiBpbnN0YW5jZS4NCg0KPGtlZz4g T3VyIGRpZmZlcmVuY2VzIGhlcmUgd291bGQgZ28gYmFjayB0byBteSB2aWV3cyBvbiB0aGUgcHJh Y3RpY2FsaXR5DQpvZiBhbiBvdmVybG9hZCBiaXQuDQoNCkZpcnN0LCBJIHRoaW5rIGFzc3VtaW5n IHRoYXQgdGhlIFNGIHdvdWxkIGJlIHVubWFuYWdlZCBzaG91bGRu4oCZdCBiZQ0KZW5jb3VyYWdl ZCAtIHRvIG1lIGl04oCZcyBvbmUgb2YgdGhlIHRlbmFudHMgb2YgZG9pbmcgdGhpcyBORlYtdGhp bmcgaW4gdGhlDQpmaXJzdCBwbGFjZS4gIElmIHlvdSBhcmUgaW1iZWRkaW5nIHlvdXIgZWxhc3Rp Y2l0eSBtYW5hZ2VtZW50IGludG8gdGhlDQpzZXJpZXMgb2YgTkgsIHRoZW4geW91IHVsdGltYXRl bHkgd2lsbCBoYXZlIGEgc2l0dWF0aW9uIHdoZXJlIHRoZSBTRkMgd2lsbA0KZmFpbCBiZWNhdXNl IHlvdSBkaWRu4oCZdCBzcGluIHVwIGVub3VnaCBpbnN0YW5jZXMgb3IgaXMgaW5lZmZpY2llbnQg YmVjYXVzZQ0KeW91IHNwdW4gdXAgdG9vIG1hbnkuICBFdmVuIGlmIHRoZSBhcmd1bWVudCBpcyDi gJxvbGQgcGh5c2ljYWwgdGhpbmcgdGhhdOKAmXMNCm5vdCBtYW5hZ2VhYmxlIHdpdGggbmV3IHRv b2xz4oCdIG15IHJlc3BvbnNlIHdvdWxkIGJlIOKAnHRoZW4ganVzdCBkb27igJl0IGRvDQppdOKA nS4NCg0KV2VyZSBzb21lb25lIHRvIHB1cnN1ZSB0aGUgYXJndW1lbnQgdGhhdCBWTkZzIGFyZSB1 bm1hbmFnZWQsIHRoZW4gSeKAmWQgYWxzbw0KZW5jb3VyYWdlIHRoZSBleGNlcHRpb24tdnMtcnVs ZSBsb2dpYyB3aGVuIGl0IGNvbWVzIHRvIHVzaW5nIGhlYWRlciBiaXRzDQp0byBzdXBwb3J0IHN1 Y2ggYSBkZXBsb3ltZW50IC0gYW5kIGFyZ3VlIGl04oCZcyBhbiBleGNlcHRpb24gYW5kIHRoZXkg c2hvdWxkDQptb3ZlIHRoZSBzaWduYWwgZWxzZXdoZXJlIHRoYW4gdGhlIGZpeGVkIGhlYWRlciAo dGhlcmUgaXMgc28gbXVjaA0K4oCcb3B0aW9uYWzigJ0gc3BhY2UgaGVyZSBpbiB0aGUgcHJvcG9z YWwpLg0KDQoNCklmIFZNRiBpcyBtYW5hZ2VkICh3aGljaCBpcyBteSBhc3N1bWVkIGRvbWluYW50 IGNhc2UpLCB0aGVuIGFsbG93aW5nIHRoZQ0KZGV2aWNlIGF1dG9ub215IHRvIG9mZi1saW5lIGl0 c2VsZiBjcmVhdGVzIHBvdGVudGlhbCBjb25mbGljdHMgKGUuZy4NClNlcnZpY2VBIHRlbGxzIHRo ZSBmb3J3YXJkaW5nIHBhdGggaXTigJlzIG92ZXJsb2FkZWQgd2hpbHN0IHRoZSBtYW5hZ2VtZW50 DQpzeXN0ZW0gZG9lc27igJl0IHRoaW5rIHNvKS4NCg0KQmV5b25kIHRoYXQsIEkgaGF2ZSBhIGZ1 bmRhbWVudGFsIGhlc2l0YXRpb24gaW4gdXNpbmcgYSBiaXQgYXMgYSBzaWduYWwNCnRoYXQgY2Fu IGFsdGVyIHRoZSBwYXRoIC0gaXQgaW52aXRlcyBjaGFvcywgSU1ITy4gIEkgdGhpbmsgYml0LWFz LXNpZ25hbA0KYmV0d2VlbiBuZWlnaGJvcnMgaGFzIHRvIGJlIHVzZWQgdmVyeSBjYXJlZnVsbHkg YmVjYXVzZSBvZiB0aGUgaGlzdG9yeSBpbg0KdGhpcyBpbmR1c3RyeSBvZiBib3RoIGhhcmR3YXJl IGFuZCBzb2Z0d2FyZQ0KY29ycnVwdGluZy9taXNpbnRlcnByZXRpbmcvYnVnZ2luZyBiaXRzIGlu IG5vdC1zby1mdW5ueSB3YXlzLiAgV2UgaGF2ZQ0KcmV2aWV3ZWQgZWFjaCBiaXQgYWxyZWFkeSBz dWdnZXN0ZWQgLSB0aGUgZnVuY3Rpb25hbGl0eSBvZiB0aGUgTyBhbmQgQw0KYml0cyBmb3IgZXhh bXBsZSBhcmUgYSkgdW5pdmVyc2FsIHRvIGFsbCBkZXBsb3ltZW50cyBhbmQgYikNCmltcGxlbWVu dGF0aW9ucyBjYW4gcHJvdmlkZSBkZWZlbnNlLWFnYWluc3QtZnJlYWtpbmcgdGhyb3VnaCBpbnRl bGxpZ2VudA0KcG9saWNpbmcuICBZZXMsIHdlIGRvIGhhdmUgZXhhbXBsZXMgb2YgdGhpcyB1dGls aXR5IGluIHRoZSBwYXN0LCBidXQgSQ0KdGhpbmsgaXTigJlzIGluYXBwcm9wcmlhdGUgZm9yIHRo aXMgcGFyYWRpZ20gKGUuZy4gSVNJUyB3ZSBhcmUgYnVpbGRpbmcgYQ0KY29vcGVyYXRpdmUgZGlz dHJpYnV0ZWQgdHJlZSB2aWV3IC0gaG93IG1hbnkgZGVwbG95bWVudHMgZW52aXNpb24gdGhhdCBh cw0KdGhlIHdheSB0aGV5IHdvdWxkIGJ1aWxkIFNGQ3MsIHBhcnRpY3VsYXJseSB3aGVuIGNlbnRy YWwgY29udHJvbCB3aXRoIGENCnRvcC1kb3duIHZpZXcgaXMgYXZhaWxhYmxlKS4gIEFuZCwg4oCc b3ZlcmxvYWTigJ0gaGlzdG9yaWNhbGx5IGRvZXNu4oCZdCBtZWFuIOKAnEkNCnRoaW5rIEnigJls bCBzdG9wIHRha2luZyB0cmFmZmljIGF0IDEwMEdicHMsIGJ1dCBrZWVwIGFsbCB5b3VyIHNlc3Np b25zIHVwDQp0byB0aGF0IHBvaW504oCdIGl0IG1lYW5zIOKAnEnigJltIG91dCBvZiByZXNvdXJj ZXMgc28gbXkgZGF0YWJhc2UgY291bGQgYmUNCmluY29uc2lzdGVudCAtIGhlbmNlIG9mZmxpbmUg Zm9yIEFMTCB0cmFmZmlj4oCdLg0KDQo+DQo+DQo+QnV0IG9rYXksIHRoZXnigJlyZSBjbG9zZSBl bm91Z2ggZm9yIHlvdSBub3QgdG8gY2FyZSDigKYgdGhlIHByb2JsZW0geW91IGhhdmUNCj50byBz b2x2ZSBpcyB0byBzZWxlY3QgYSBjcml0ZXJpYSBvbiB3aGljaCB0byBwaWNrIHRoZSBkZXN0aW5h dGlvbiBmcm9tIGENCj5kZWNpc2lvbiBwb2ludCBpbiB0aGUgcGF0aCBmb3IgeW91ciBlbGFzdGlj L2ZsZXhpYmxlIFNJL1NQSSBtYXRjaCAuLi4gbm90DQo+aG93IGZhciB0aGUgTkhzIHRoYXQgaXQg cmVzb2x2ZXMgdG8gYXJlIGZyb20gdGhhdCBwb2ludC4gIFNheSB5b3VyIE5IIGFyZQ0KPmluIENs ZXZlbGFuZCBhbmQgQ2hpY2FnbyDigKYgdGhlc2UgZG9u4oCZdCBtb3ZlIHJlbGF0aXZlIHRvIHRo ZSBkZWNpc2lvbiBwb2ludA0KPuKApiBzbyB0aGVpciBkaXN0YW5jZSBpcyBub3QgYSBjcml0ZXJp YSBpbiBhbmQgb2YgaXRzZWxmIC0gb3RoZXJ3aXNlIEkgd291bGQNCj5qdXN0IHdlaWdodCB0aGUg TkggZnJvbSB0aGUgY29udHJvbCBwbGFuZSBkaXN0cmlidXRpbmcgdGhlbSB0byByZWZsZWN0DQo+ d2hhdCBteSB2YWx1YXRpb24gb2YgbG9hZCBhbmQgZGlzdGFuY2Ugc2hvdWxkIGJlICh0byByZWZs ZWN0IG15IHBvbGljeSkuDQo+VGhhdOKAmXMgYWxsIHN0YXRpYyAodGhlIE5IIHdlaWdodCBjb3Vs ZCBiZSB1cGRhdGVkIGlmIENsZXZlbGFuZCBvciBDaGljYWdvDQo+bW92ZSBvciBpZiBJIGNoYW5n ZSBteSBwb2xpY3kgO14pLg0KPg0KPlJvbj4+PiBQZXIgYWJvdmUuICAgIEJ1dCBJIGNvdWxkIGFs c28gYmUgY29udmluY2VkIHRoYXQgeWV0IGhpZ2hlciBsZXZlbA0KPnBvbGljeSBzYXlzIHRvIHVz ZSBTRlAgQSBwcmVmZXJhYmx5LCBidXQgU0ZQIEIgb3RoZXJ3aXNlLCBwZXIgeW91cg0KPmFuYWx5 c2lzLg0KPg0KPg0KPj4NCj4+V2hhdCBpZiB3ZSB3YW50IHRvIHN1cHBvcnQgb3RoZXIgaW5zdGFu Y2Ugc2VsZWN0aW9uIGNyaXRlcmlhLCBsaWtlIGdvbGQNCj4+Y3VzdG9tZXJzIGdldCBvbiB0aGUg aGlnaGVyIHBlcmZvcm1hbmNlIFJTUCBmb3IgYSBwYXJ0aWN1bGFyIGZ1bmN0aW9uYWwNCj4+Y2hh aW4gYnV0IGJyb256ZSBjdXN0b21lcnMgdGhlIGxvd2VyIHBlcmZvcm1hbmNlIFJTUCBmb3IgdGhh dCBzYW1lDQo+PmZ1bmN0aW9uYWwgY2hhaW4/DQo+DQo+PGtlZz4gSWRlbnRpdHksIHNlc3Npb24s IG1ldGFkYXRhIOKApiBJIHRoaW5rIEkgZ2F2ZSB0aGlzIGV4YW1wbGUuDQo+DQo+Um9uPj4+IEkg YWdyZWUuICAgVXNlIGNhc2UgaXMgd2l0aGRyYXduLiAgIFRoaXMgbGVuZHMgaXRzZWxmIHRvIGRp c3RpbmN0DQo+U0ZQJ3MgKGkuZS4sIGRpZmZlcmVudCBwb2xpY3kgY29uc3RyYWludHMgb24gdGhl IFNGQykuDQo+DQo+DQo+Pg0KPj5BbmQsIGFsdGhvdWdoIGl0IGlzIG5vdCBhIGZ1bmN0aW9uYWwg dXNlIGNhc2UgaW4gdGhlIHNhbWUgbWFubmVyIGFzDQo+PmFib3ZlLCB3aGF0IGlmIHNvbWUgbmV0 d29yayBkZXNpZ25lcnMgZGV0ZXJtaW5lIGl0IGlzIGNoZWFwZXIgYW5kIHNpbXBsZXINCj4+dG8g ZGVwbG95IFNGQyB1c2luZyBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlcyB0aGF0IGFyZSBzaW1w bGVyIGFuZCBkb24ndA0KPj5oYXZlIGluYnVpbHQgaG9yaXpvbnRhbCBzY2FsZT8gICBNb3JlIGFs b25nIHRoZSBsaW5lcyBvZiB0aGUgImZpdCBWTkYiDQo+PmFwcHJvYWNoIChhdHRyaWJ1dGlvbiB0 byBDb250ZXh0cmVhbSkuDQo+DQo+PGtlZz4gVGhleSBoYXZlIHRoZSBvcHRpb24gb2YgYmxvd2lu ZyBvdXQgdGhlIFNQSUQgc3BhY2UsIGFzIEkgc2FpZCwNCj50aGF04oCZcyBhIGRlcml2YXRpdmUg ZXhhbXBsZSBvZiB0aGUgU1BJL1NJIGhhdmluZyBhIHNpbmdsZSBOSCwgSU1PIOKApmVhY2gNCj5w ZXJtdXRhdGlvbiBpcyBhIGRpcmVjdCBtYXBwaW5nIGFuZCBkaWZmZXJlbnQgU1BJRCBhbmQgd2hh dC9ob3cgeW91IGFmZml4DQo+dGhlc2UgKHBvbGljeSkgaXMgcmVmbGVjdGVkIGF0IGNsYXNzaWZp Y2F0aW9uLiAgVGhlIGFic3RyYWN0aW9uIGluIHRoZQ0KPmxhbmd1YWdlIHdhcyBvbmx5IHRoZXJl IHRvIGhlbHAgcGVvcGxlIGltYWdpbmUgdGhlIGZsZXhpYmlsaXR5IGF2YWlsYWJsZQ0KPnRocm91 Z2ggdGhlIHVzYWdlIEkgZGVzY3JpYmUuDQo+DQo+Um9uPj4+IFRoZSBhcmNoaXRlY3R1cmUgc3Rh dGVzIHRoYXQgUlNQIGlzIHRoZSBmdWxseSBjb25jcmV0ZSBzZXF1ZW5jZSBvZg0KPmhvcHMuICAg QnV0IG1vc3RseSwgZm9yIG1lLCB0aGUgYXJndW1lbnQgaXMgYWJvdXQgdGhlIHV0aWxpdHkgb2Yg bGF0ZQ0KPmJpbmRpbmcgKG9yIG5vdCwgaWYgeW91IGFyZSBvZiB0aGF0IHBlcnN1YXNpb24pLg0K Pg0KPg0KPj4NCj4+VGhlIGdyb3VwJ3MgcHJvcG9zZWQgc29sdXRpb24gc2hvdWxkIGJlIG1lYXN1 cmVkIGFnYWluc3QgdGhlIHVzZSBjYXNlcw0KPj5hbmQgYW5kIGRlcGxveW1lbnQgc2NlbmFyaW9z IHdlIGZlZWwgbmVlZCB0byBiZSBhZGRyZXNzZWQsIGFuZCB0aGlzIGlzDQo+PnByb2JhYmx5IHRo ZSBtYWluIGRpZmZlcmVuY2UgaW4gdmlld3BvaW50LCBoZXJlLiAgICBUbyBmb2xsb3cgb24gdG8g S2VuJ3MNCj4+Y29sbG9xdWlhbGlzbSwgbXkgb3BpbmlvbiBpcyB0aGF0IHRoZSBob3JzZSBpcyBu b3QgZGVhZCBhbmQgdGhhdCB0aGUNCj4+ZGlmZmVyZW50IHZpZXdwb2ludHMgZG8gbm90IHJlZmxl Y3QgYSBmdW5kYW1lbnRhbCBpbmFiaWxpdHkgdG8gZ3Jhc3AgdGhlDQo+PmNvbmNlcHRzLg0KPj4N Cj4+VGhhbmtzLg0KPj4NCj4+ICAgUm9uDQo+Pg0KPj4NCj4+DQo+Pg0KPj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBLZW4gR3JheSAoa2VncmF5KSBbbWFpbHRvOmtlZ3JheUBj aXNjby5jb21dDQo+PlNlbnQ6IEZyaWRheSwgRmVicnVhcnkgNiwgMjAxNSAxMTo1NyBBTQ0KPj5U bzogV2VuemhlIFpob3U7IFJvbiBQYXJrZXI7IEpvZWwgTS4gSGFscGVybjsgTmljb2xhcyBCT1VU SE9SUzsNCj4+J3NmY0BpZXRmLm9yZycNCj4+U3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LXF1aW5u LXNmYy1uc2gtMDUsIG9wdGlvbmFsIGhlYWRlcnMNCj4+DQo+PkluIG15IHdvcmRzLCBJIGFtIG5v dCBzdWdnZXN0aW5nIGNoYW5naW5nIHRoZSBkcmFmdCBhdCBhbGwuICBJIHRoaW5rIGl04oCZcw0K Pj5zdWZmaWNpZW50Lg0KPj4NCj4+DQo+Pk15IG9waW5pb24sIGlzIHRoYXQgdGhlIHN1Z2dlc3Rl ZCBjaGFuZ2VzIGluIHRoaXMgdGhyZWFkIHNob3cgYQ0KPj5mdW5kYW1lbnRhbCBmYWlsdXJlIHRv IGdyYXNwIHRoZSBjb25jZXB0cyB3ZSBoYXNoZWQgb3V0IGluIHRoZQ0KPj5hcmNoaXRlY3R1cmUg KHdoaWNoIEkgYXR0ZW1wdGVkIHRvIGNsYXJpZnkpLiAgSW4gbXkgb3BpbmlvbiwgdG8gdXNlIGFu DQo+PnVuZm9ydHVuYXRlIGNvbGxvcXVpYWxpc20gLSB0aGlzIGhvcnNlIGlzIGRlYWQsIHdlIHNo b3VsZCBzdG9wIGJlYXRpbmcNCj4+aXQuDQo+Pg0KPj5PbiAyLzYvMTUsIDEwOjI4IEFNLCAiV2Vu emhlIFpob3UiIDxXZW56aGUuWmhvdUBodWF3ZWkuY29tPiB3cm90ZToNCj4+DQo+Pj5LZW4sDQo+ Pj4NCj4+PkluIHlvdXIgd29yZHMsIG1hbmRhdG9yeSBjb250ZXh0IGhlYWRlcnMgc2hvdWxkIGJl IHJlbW92ZWQgZnJvbSBOU0guDQo+Pj4NCj4+PldlbnpoZQ0KPj4+DQo+Pj4NCj4+Pi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj5Gcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEtlbiBHcmF5IChrZWdyYXkpDQo+Pj5TZW50OiBUaHVyc2RheSwg RmVicnVhcnkgMDUsIDIwMTUgNDoyNSBQTQ0KPj4+VG86IFJvbiBQYXJrZXI7IEpvZWwgTS4gSGFs cGVybjsgTmljb2xhcyBCT1VUSE9SUzsgJ3NmY0BpZXRmLm9yZycNCj4+PlN1YmplY3Q6IFJlOiBb c2ZjXSBkcmFmdC1xdWlubi1zZmMtbnNoLTA1LCBvcHRpb25hbCBoZWFkZXJzDQo+Pj4NCj4+Pkkg dGhpbmsgdGhlcmXCuXMgYSBkaXNjb25uZWN0aW9uIGhlcmUgKGNvdWxkIGJlIG1lKSBiZXR3ZWVu IHRoZSBpZGVhIG9mDQo+Pj5hbiBhYnN0cmFjdCBhbmQgc3BlY2lmaWMgcGF0aC4NCj4+Pg0KPj4+ SSB0aG91Z2h0IGl0IHdhcyBwcmV0dHkgY2xlYXIgKGFuZCB0aGVyZSB3YXMgc2lnbmlmaWNhbnQg dGFsayBhYm91dCBpdA0KPj4+aGVyZSBvbiB0aGUgbGlzdCkgdGhhdCB5b3UgY2FuJ3QgbWFuZGF0 ZSBhIHNwZWNpZmljIG1vZGVsIG9mIGZ1bmN0aW9uDQo+Pj5lbGFzdGljaXR5IC0gd2UgY291bGRu wrl0IGRlY2xhcmUgbG9hZCBiYWxhbmNpbmcgZGV2aWNlcyBvciBmdW5jdGlvbnMNCj4+PsKzZGVh ZMKyIGJ1dCBpbnN0ZWFkIGFzc3VtZWQgdGhhdCBlbGFzdGljaXR5IGNvdWxkIGJlIGRvbmUgbG9j YWxseSBhcyBhDQo+Pj5TRiwgYXMgcGFydCBvZiBhIGNvbXBvc2l0ZSBmdW5jdGlvbiB3aGVyZSB0 aGUgbG9hZCBiYWxhbmNlciBleGlzdHMgYXMNCj4+PnBhcnQgb2YgdGhlIGxvZ2ljYWwgZnVuY3Rp b24gYmVpbmcgcmVuZGVyZWQgb3IgY2VudHJhbGx5L3N0YXRpY2FsbHkuDQo+Pj5XZSBoYWQgc2lt aWxhciBkaWFsb2d1ZXMgYWJvdXQgdGhlIG5lZWQgdG8gcmVtYWluIGFic3RyYWN0IGFyb3VuZCBI QQ0KPj4+dGVjaG5pcXVlcyBhcyB3ZWxsLg0KPj4+DQo+Pj5UaGVzZSB0aGluZ3MgbWFrZSBBTiBp bmRpdmlkdWFsIHBhdGgsIHdoaWNoIHJlcHJlc2VudHMgYSBjaGFpbiB0aGF0DQo+Pj5maXRzIGEg c3BlY2lmaWMgcG9saWN5IHJ1bGVzZXQgxaAgdmFyaWFibGUgxaAgYW5kIHdlIGRpZG7CuXQgd2Fu dCB0bw0KPj4+dW5uZWNlc3NhcmlseSBkZWZpbmUgbXVsdGlwbGUgZGlzY3JldGUgY2hhaW5zIHRv IGNvdmVyIHRoaXMgc29ydCBvZg0KPj4+ZnVuY3Rpb24gdmFyaWFuY2UgKHdoaWNoIGNhbiBiZWNv bWUgcXVpdGUgbGFyZ2UsIGlmIGZvciBleGFtcGxlIHRoZQ0KPj4+ZnVuY3Rpb24gWCBhdCBzaXRl IFkgaXMgYWN0dWFsbHkgMTAwMCBwYXJhbGxlbCBpbnN0YW5jZXMgdG8gYWNjb21tb2RhdGUNCj4+ PmxvYWQsIHdpdGggSEEgYWRkIGEgbXVsdGlwbGllciwgcGVyIGZ1bmN0aW9uIG1vcmUgbXVsdGlw bGllcnMgxaBmb3IgYQ0KPj4+c2luZ2xlIHBhdGggdGhhdCBhdCB0aGUgYWJzdHJhY3QgbGV2ZWws IHRyYXZlcnNlZCB0aGUgc2FtZSBzaXRlcyDFoGJvb20pLg0KPj4+DQo+Pj5UaGVzZSBkaWFsb2d1 ZXMgYXJlIGNhcHR1cmVkIGluIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQuDQo+Pj4NCj4+PlNv LCB3aGVuIEkgcmVhZCB0aGUgTlNIIGRyYWZ0LCBJIGludGVycHJldGVkIHRoZSB0cmVhdG1lbnQg b2YgdGhlIFNQSQ0KPj4+YW5kIHRoZSBSZXNvbHZlZCBQYXRoIGFzIHZlcnkgY29tcGF0aWJsZSB3 aXRoIHRoYXQgYWJzdHJhY3Rpb24vY29uY2VwdC4NCj4+Pkl0IG1ha2VzIG11bHRpcGxlIGRlcGxv eW1lbnQgY29udGV4dHMgdW5kZXJzdGFuZGFibGUgYW5kIHBvc3NpYmxlDQo+Pj53aXRob3V0IG92 ZXJseSBkZWZpbmluZyB0aGUgaGVhZGVyIHdpdGggcG90ZW50aWFsbHkgdXNlbGVzcyBmaWVsZHMg Zm9yDQo+Pj5ldmVyeSBpdGVyYWJsZSBjYXNlLiAoRWRpdG9yaWFsIC0gS2luZCBvZiBhbiBhcnQg Zm9ybSB0aGF0IHdlIHNob3VsZA0KPj4+Y2VsZWJyYXRlLCBJTU8sIGlmIHBlb3BsZSBhcmUgZ29p bmcgYWJvdXQgZGVzaWduaW5nIHByb3RvY29scy4pDQo+Pj4NCj4+PkZvciBleGFtcGxlLCB0aGUg U0ZGIGNhbiBiZSBzZWVkZWQgd2l0aCBvbmUgYW5kIG9ubHkgb25lIE5IIGZvciB0aGUNCj4+PlNJ L1NQSSBtYXRjaCAtIHRodXMgdGhlIHBhdGggaXMgcmVzb2x2ZWQgYW5kIHRoZSBTSS9TUEkgcGF0 aCBJUyB0aGUNCj4+PnJlbmRlcmVkIHBhdGguICBUaGUgwrNkaXJlY3RlZMKyIGdyYXBoIHRoYXQg c29tZSB3YW50ZWQgKHdoZXJlIGVhY2gNCj4+PmluZGl2aWR1YWwgZWxlbWVudCBpbiBhIGxvY2Fs bHkgZWxhc3RpYyBwb29sIGlzIGluZGl2aWR1YWxseQ0KPj4+YWRkcmVzc2FibGUgYW5kIHNldCBh dA0KPj4+Y2xhc3NpZmljYXRpb24pIGlzIHJlYWxseSBhIGRlcml2YXRpdmUgb2YgdGhlIHNhbWUg Y2FzZS4NCj4+Pg0KPj4+SWYgdGhlcmUgaXMgbW9yZSB0aGFuIG9uZSBOSCBzZWVkZWQgZm9yIHRo ZSBTSS9TUEksIHRoZW4gdGhlIFNGRiBlaXRoZXINCj4+PndpbGwgdHJlYXQgdGhlIGZvcndhcmRp bmcgYXMgRUNNUCAoZS5nLiBzdGF0ZWxlc3MgdG8gYW4gYW55Y2FzdCBwb29sIC0NCj4+PlNJL1NQ SSBJUyB0aGUgcmVuZGVyZWQgcGF0aCksIG9yIGhhdmUgYSBsb2NhbCBwb2xpY3kgdG8gcGVyZm9y bSBhbg0KPj4+ZXhwbGljaXQgbWFwcGluZy4gIFRoZSBTRkYgbWF5IGFsc28gYmUganVzdCBoYW5k aW5nIHRoZSBwYWNrZXQgdy9OU0gNCj4+PmhlYWRlciBvZmYgdG8gYSBsb2NhbCBpbnRlZ3JhdGVk IGZ1bmN0aW9uIChsaWtlIGEgbG9hZCBiYWxhbmNlcikgb3IgYW4NCj4+PmF0dGFjaGVkIGNvbXBv c2l0ZSBmdW5jdGlvbiB0aGF0IGlzIGhhbmRsaW5nIGFuIGV4cGxpY2l0IG1hcHBpbmcgdG8NCj4+ PmZ1bmN0aW9uIGluc3RhbmNlcyBpdCBmcm9udHMgKGFuZCBtYW5hZ2luZyBzYW1lIHNvbWV3aGF0 IG9ibGlxdWVseSB0bw0KPj4+dGhlIFNGRiBhbmQgdGhlIHBhdGggaXRzZWxmKS4NCj4+Pg0KPj4+ VGhlc2UgbmV3IGNvbnRleHRzIGRvbsK5dCBORUVEIGFuZCBzaG91bGRuwrl0IEdFVCBhIHNlcGFy YXRlIGZpZWxkIGluIHRoZQ0KPj4+Z2VuZXJhbCBoZWFkZXIuICBJRiwgZm9yIGV4YW1wbGUsIHRo ZSByZXNvbHV0aW9uL21hcHBpbmcgb2YgZWl0aGVyIHRoZQ0KPj4+bG9jYWwgU0ZGIHBvbGljeSAo b3IgdGhlIG9ibGlxdWUgZnVuY3Rpb24pIGlzIGEgcG9saWN5IGtleWVkIHRvDQo+Pj5jbGFzc2lm aWNhdGlvbiBpbmZvIGxpa2UgZmxvd0lELCB0ZW5hbnRJRCwgc2Vzc2lvbklELCBzb21ldGhpbmcN Cj4+PnByb3ByaWV0YXJ5IC0gd2VsbCwgeW91wrl2ZSBqdXN0IHJlZGVmaW5lZCB0aGUgbmVlZCBm b3IgbWV0YWRhdGEgKG9uZSBvZg0KPj4+b3VyIGdvYWxzIHdhcyB0byBiZSBhYmxlIHRvIHByZXNl cnZlIGNsYXNzaWZpZXIgaW5mbyBpbiBtZXRhZGF0YSB0bw0KPj4+YXZvaWQgZXhjZXNzaXZlIGNs YXNzaWZpY2F0aW9uKSwgd2hpY2ggd2UgYWxsIGFncmVlZCB0byBhbHJlYWR5IC0gYW5kDQo+Pj53 ZSBrbm93IHdoZXJlIHRvIGZpbmQgc3VjaCBhIGtleSBzbyB0aGVyZcK5cyBubyBuZWVkIHRvIG1v dmUgaXQuDQo+Pj4oRWRpdG9yaWFsIC0gTm90ZSBhbHNvIHRoZSBwb3RlbnRpYWwgZm9yIHZhcmlh bmNlIG9mIHRoZSBrZXkNCj4+PnNvdXJjZS92YWx1ZSBhY3Jvc3MNCj4+PmltcGxlbWVudGF0aW9u cy4pDQo+Pj4NCj4+PllvdSBzaG91bGRuJ3QgTkVFRCBhbiBleHBsaWNpdCBSU1AgSUQgaW4gdGhl IGZpeGVkIGhlYWRlci4gIFRoYXQgc2VlbXMNCj4+PnRvIHdvcmsgYmFjayBhZ2FpbnN0IHRoZSBv cmlnaW5hbCBpbXBsaWNpdCBkZXNpZ24gZ29hbCBvZiB0aGUgaGVhZGVyLg0KPj4+DQo+Pj5JIGR1 bm5vLCBpZiBpdMK5cyBqdXN0IG1lLCBJIGhhdmVuwrl0IGRvbmUgcHJvdG9jb2wgZGVzaWduIHNp bmNlIGNvbGxlZ2UNCj4+PsWgIG1heWJlIEnCuW0gcnVzdHkgb3IgSSBuZWVkIHNvbWV0aGluZyBz dHJvbmdlciB0byBkcmluay4NCj4+Pg0KPj4+DQo+Pj5DaGVlcnMuDQo+Pj4NCj4+Pg0KPj4+T24g Mi81LzE1LCAxMTo1NyBBTSwgIlJvbiBQYXJrZXIiIDxSb25fUGFya2VyQGFmZmlybWVkbmV0d29y a3MuY29tPg0KPj4+d3JvdGU6DQo+Pj4NCj4+Pj5Kb2VsLA0KPj4+Pg0KPj4+PkkgdGhpbmsgeW91 IGFyZSByZWluZm9yY2luZyBhIGtleSBhc3N1bXB0aW9uIGhlcmUgLS0gaWYgdGhlIFNGRiBuZWVk cw0KPj4+PnRoZSBpbmZvcm1hdGlvbiB0byBkbyBpdHMgam9iLCB0aGVuIHRoYXQgaW5mb3JtYXRp b24gc2hvdWxkIGJlIG5laXRoZXINCj4+Pj5pbg0KPj4+PlR5cGUgMSBub3IgVHlwZSAyIG1ldGFk YXRhLiAgICBBcyBhbiBleGFtcGxlLi4uICBkZXBlbmRpbmcgb24gaG93IG91cg0KPj4+PmNvbnRp bnVpbmcgZGlzY3Vzc2lvbiBvbiBSU1AgSUQgZ29lcyAoaS5lLCB0byBlbmFibGUgYm90aCBjZW50 cmFsaXplZA0KPj4+PmNvbmNyZXRlIFJTUCBkZXRlcm1pbmF0aW9uIGFuZCBkaXN0cmlidXRlZCBo b3AtYnktaG9wICJ0cmFpbC1ibGF6ZWQiDQo+Pj4+UlNQIGRldGVybWluYXRpb24pLCB3ZSBtYXkg d2FudCB0byAicHJvbW90ZSIgUlNQIElEIGZyb20gbWV0YWRhdGEgdG8NCj4+Pj50aGUgc3RhbmRh cmQgaGVhZGVyLg0KPj4+Pg0KPj4+PiAgIFJvbg0KPj4+Pg0KPj4+Pg0KPj4+Pi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+Pj4+RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBKb2VsIE0uIEhhbHBlcm4NCj4+Pj5TZW50OiBUaHVyc2RheSwgRmVi cnVhcnkgNSwgMjAxNSAxMTozOSBBTQ0KPj4+PlRvOiBOaWNvbGFzIEJPVVRIT1JTOyAnc2ZjQGll dGYub3JnJw0KPj4+PlN1YmplY3Q6IFJlOiBbc2ZjXSBkcmFmdC1xdWlubi1zZmMtbnNoLTA1LCBv cHRpb25hbCBoZWFkZXJzDQo+Pj4+DQo+Pj4+VGhlIG1ldGFkYXRhIGlzIChnZW5lcmFsbHkpIGZv ciB0aGUgYVNlcnZpY2UgRnVuY3Rpb25zLCBub3QgZm9yIHRoZQ0KPj4+PlNGRi4NCj4+Pj4gIFNv IHRoZSBxdWVzaXRvbiBvZiBwcm9ncmFtbWluZyB0aGUgU0ZGIHRvIHByb2Nlc3MgdGhlIGluZm9y bWF0aW9uDQo+Pj4+c2VlbXMgbm90IGVzcGVjaWFsbHkgbWFqb3IuDQo+Pj4+DQo+Pj4+TW9yZSBz aWduaWZpY2FudGx5LCBnaXZlbiB0aGF0IHRoZSAxNiBieXRlIHR5cGUgMSBmaWVsZCBtYXkgY2Fy cnkNCj4+Pj5kaWZmZXJlbnQgdGhpbmdzIGluIGRpZmZlcmVudCBjYXNlcywgdGhlIFNGcyB3aWxs IGhhdmUgdG8gYmUgZmxleGlibGUNCj4+Pj5hYm91dCBwcm9jZXNzaW5nIHRoZSBpbmZvcm1hdGlv biBhbnl3YXkuICBTbyBhbnl0aGluZyB3aGljaCBjYW4gaGFuZGxlDQo+Pj4+dGhlIHR5cGUgMiBp bmZvcm1hdGlvbiBjYW4gYmUgcmVhc29hbmFibHkgZXhwZWN0ZWQgdG8gaGFuZGxlIHRoZSBzYW1l DQo+Pj4+a2luZHMgb2YgaW5mb3JtYXRpb24gZnJvbSBUTFZzICh3aGV0aGVyIG9uZSBUTFYgb3Ig bWFueSkuDQo+Pj4+DQo+Pj4+SXQgdGhlcmVmb3JlIHNlZW1zIGNsZWFuZXIgdG8gbWUgdG8gcmVj b2duaXplIHRoYXQgdHlwZSAxIGFuZCB0eXBlIDINCj4+Pj5hcmUgZGlmZmVyZW50IHdheXMgb2Yg Y2FycnlpbmcgaW5mb3JtYXRpb24sIGFuZCBqdXN0IHVzZSB0aGUgbWVjaGFuaXNtDQo+Pj4+ZWFj aCBzdXBwb3J0cy4NCj4+Pj4NCj4+Pj5Zb3VycywNCj4+Pj5Kb2VsDQo+Pj4+DQo+Pj4+T24gMi80 LzE1IDEyOjA2IFBNLCBOaWNvbGFzIEJPVVRIT1JTIHdyb3RlOg0KPj4+Pj4gSXQgaXMgZ3JlYXQg dG8gaGF2ZSB0aGUgcG9zc2liaWxpdHkgdG8gYWRkIG9wdGlvbmFsIGhlYWRlcnMgaW4gTlNILg0K Pj4+Pj5Ib3dldmVyLCB0aGUgbWVjaGFuaXNtIHByb3Bvc2VkIHN1cHBvc2UgdGhhdCBhIHNwZWNp ZmljIGhlYWRlciB0eXBlDQo+Pj4+Pih0aGUgIE1EIFR5cGU9MHgyKWlzIHVzZWQgaW4gdGhlIGJh c2UgaGVhZGVyIHdoZW4gb3B0aW9uYWwgbWV0YWRhdGENCj4+Pj4+YXJlIHVzZWQuDQo+Pj4+Pg0K Pj4+Pj4NCj4+Pj4+DQo+Pj4+PiBBcyBhIHJlc3VsdDoNCj4+Pj4+DQo+Pj4+PiAxLlRoZSBiYXNl IGhlYWRlciB0eXBlIDB4MSBjYW5ub3QgYmUgdXNlZCB3aXRoIG9wdGlvbmFsIGhlYWRlcnMuDQo+ Pj4+PiBXaGljaCBteSBtYWtlIHNlbnNlIGZvciBwZXJmb3JtYW5jZSBwb2ludCBvZiB2aWV3DQo+ Pj4+Pg0KPj4+Pj4gMi5Ob3Igd2hlbiB1c2luZyBoZWFkZXIgTUQgdHlwZSB4MiAgY2FuIHRoZSAi bWFuZGF0b3J5IGNvbnRleHQNCj4+Pj4+aGVhZGVycyINCj4+Pj4+IGJlIHByZXNlbnQuDQo+Pj4+ Pg0KPj4+Pj4gQ2FzZSAyIGNhbiBiZSB3b3JrZWQgYXJvdW5kIGJ5IGRlZmluaW5nIGFuIG9wdGlv bmFsIGhlYWRlciB0aGF0DQo+Pj4+PiByZXByZXNlbnRzIHRoZSBtYW5kYXRvcnkgY29udGV4dCBo ZWFkZXIuIFdoaWNoIGlzIGF3a3dhcmQgYXMgU0ZGcw0KPj4+Pj4gd2lsbCBoYXZlIHRvIGRlY29k ZSB0aGUgc2FtZSBpbmZvcm1hdGlvbiBpbiB0d28gZGlmZmVyZW50IHdheXMuIE5vdA0KPj4+Pj4g cGFydGljdWxhcmx5IGJlYXV0aWZ1bCAhDQo+Pj4+Pg0KPj4+Pj4gV2h5IG5vdCBoYXZlIGEgZmxh ZyAoRjIpc3RhdGluZyB0aGF0IG5vIG9wdGlvbmFsIE1ldGFkYXRhIGFyZQ0KPj4+Pj4gcHJlc2Vu dCBhbmQgYW5vdGhlciBvbmUgKEYxKSBzdGF0aW5nIHRoYXQgKHdoYXQgaXMgbm93IGNhbGxlZCkg dGhlDQo+Pj4+PiBtYW5kYXRvcnkgY29udGV4dCBoZWFkZXIgaXMgcHJlc2VudCBvciBub3QuDQo+ Pj4+Pg0KPj4+Pj4gV2UgY2FuIHRoZW4gc3BlY2lmeSB0aGF0IHRoZSBjb21iaW5hdGlvbnMNCj4+ Pj4+DQo+Pj4+PiBGMj1GYWxzZSBpbXBsaWVzIEYxPVRydWUNCj4+Pj4+DQo+Pj4+PiBGMT1UcnVl LCBGMj1UcnVlIGlzIGFsbG93ZWQNCj4+Pj4+DQo+Pj4+PiBGMT0gRmFsc2UsIEYyPVRydWUgaXMg YWxsb3dlZA0KPj4+Pj4NCj4+Pj4+IEl0IHNlZW1zIGNsZWFuZXIuIFdoZW4gcHJlc2VudCwgdGhl ICJtYW5kYXRvcnkgY29udGV4dCBoZWFkZXJzIg0KPj4+Pj4gd291bGQgYWx3YXlzIGJlIGF0IHRo ZSBzYW1lIHBsYWNlIGluIHRoZSBwYWNrZXQuDQo+Pj4+Pg0KPj4+Pj4gTmljb2xhcw0KPj4+Pj4N Cj4+Pj4+IFRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzICh0aGUgIm1lc3NhZ2UiKSBh cmUgY29uZmlkZW50aWFsLA0KPj4+Pj4gaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2Vl cy4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkDQo+Pj4+PiByZWNpcGllbnQsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBieSBlLW1haWwgYW5kIGRlbGV0ZQ0KPj4+Pj4g dGhpcyBtZXNzYWdlIGZyb20geW91ciBzeXN0ZW0uIEluIHRoaXMgY2FzZSwgeW91IGFyZSBub3Qg YXV0aG9yaXplZA0KPj4+Pj4gdG8gdXNlLCBjb3B5IHRoaXMgbWVzc2FnZSBhbmQvb3IgZGlzY2xv c2UgdGhlIGNvbnRlbnQgdG8gYW55IG90aGVyDQo+Pj4+PnBlcnNvbi4NCj4+Pj4+IEUtbWFpbHMg YXJlIHN1c2NlcHRpYmxlIHRvIGFsdGVyYXRpb24uIE5laXRoZXIgUW9zbW9zIG5vciBhbnkgb2Yg aXRzDQo+Pj4+PiBzdWJzaWRpYXJpZXMgb3IgYWZmaWxpYXRlcyBzaGFsbCBiZSBsaWFibGUgZm9y IHRoZSBtZXNzYWdlIGlmDQo+Pj4+PiBhbHRlcmVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4+ Pj4+DQo+Pj4+PiBDZSBtZXNzYWdlIGV0IHRvdXRlcyBzZXMgcGnDqGNlcyBqb2ludGVzIChjaS1h cHLDqHMgbGUgIm1lc3NhZ2UiKXNvbnQNCj4+Pj4+Y29uZmlkZW50aWVscyBldCDDqXRhYmxpcyDD oCBsJ2ludGVudGlvbiBleGNsdXNpdmUgZGUgc2VzIGRlc3RpbmF0YWlyZXMuDQo+Pj4+PiBTaSB2 b3VzIGF2ZXogcmXDp3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCBtZXJjaSBkJ2VuIGluZm9ybWVy DQo+Pj4+PmltbcOpZGlhdGVtZW50IHNvbiDDqW1ldHRldXIgcGFyIGNvdXJyaWVyIMOpbGVjdHJv bmlxdWUgZXQgZCdlZmZhY2VyIGNlDQo+Pj4+Pm1lc3NhZ2UgZGUgdm90cmUgc3lzdMOobWUuIERh bnMgY2V0dGUgaHlwb3Row6hzZSwgdm91cyBuJ8OqdGVzIHBhcw0KPj4+Pj5hdXRvcmlzw6kgw6Ag dXRpbGlzZXIsIGNvcGllciBjZSBtZXNzYWdlIGV0L291IGVuIGRpdnVsZ3VlciBsZSBjb250ZW51 DQo+Pj4+PsOgIHVuIHRpZXJzLg0KPj4+Pj4gVG91dCBtZXNzYWdlIMOpbGVjdHJvbmlxdWUgZXN0 IHN1c2NlcHRpYmxlIGQnYWx0w6lyYXRpb24uIFFvc21vcyBldA0KPj4+Pj5zZXMgIGZpbGlhbGVz IGTDqWNsaW5lbnQgdG91dGUgcmVzcG9uc2FiaWxpdMOpIGF1IHRpdHJlIGRlIGNlIG1lc3NhZ2UN Cj4+Pj4+cydpbCBhICDDqXTDqSBhbHTDqXLDqSwgZMOpZm9ybcOpIG91IGZhbHNpZmnDqS4NCj4+ Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+PiBzZmMgbWFpbGluZyBsaXN0DQo+Pj4+PiBzZmNAaWV0Zi5v cmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+ Pg0KPj4+Pg0KPj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+c2ZjIG1haWxpbmcgbGlzdA0KPj4+PnNmY0BpZXRmLm9yZw0KPj4+Pmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+DQo+Pj4+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj5zZmMgbWFpbGluZyBsaXN0 DQo+Pj4+c2ZjQGlldGYub3JnDQo+Pj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zZmMNCj4+Pg0KPj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+PnNmYyBtYWlsaW5nIGxpc3QNCj4+PnNmY0BpZXRmLm9yZw0KPj4+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+DQo+DQoNCg== From nobody Mon Feb 9 11:04:43 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A881A1B84; Mon, 9 Feb 2015 10:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 yr6tHg715aGK; Mon, 9 Feb 2015 10:38:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0D81A1B6E; Mon, 9 Feb 2015 10:38:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209183804.24017.43858.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 10:38:04 -0800 From: IETF Secretariat Archived-At: Subject: [sfc] ID Tracker State Update Notice: X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 18:38:06 -0000 IESG state changed to Waiting for AD Go-Ahead from AD Evaluation::Revised I-D Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ From nobody Mon Feb 9 11:06: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 5292C1A1B84; Mon, 9 Feb 2015 10:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 5npwBpzLiakL; Mon, 9 Feb 2015 10:38:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A02171A1B6E; Mon, 9 Feb 2015 10:38:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209183840.24878.72520.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 10:38:40 -0800 From: IETF Secretariat Archived-At: Subject: [sfc] ID Tracker State Update Notice: X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 18:38:42 -0000 IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead Still needs to address Kathleen's discuss ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ From nobody Mon Feb 9 12:10:24 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4484B1A1BC9; Mon, 9 Feb 2015 11:36:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 tcNxjCiiz6MY; Mon, 9 Feb 2015 11:36:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFFC1A87D7; Mon, 9 Feb 2015 11:35:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209193545.19379.12476.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 11:35:45 -0800 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-11.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 19:36:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining Problem Statement Authors : Paul Quinn Thomas Nadeau Filename : draft-ietf-sfc-problem-statement-11.txt Pages : 19 Date : 2015-02-09 Abstract: This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term service function chaining is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions. The set of enabled service function chains reflect operator service offerings and is designed in conjunction with application delivery and service and network policy. This document also identifies several key areas that the SFC working group will investigate to guide its architectural and protocol work and associated drafts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 9 12:12: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 4C0DF1A87E8; Mon, 9 Feb 2015 11:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 nBme8T48uMmV; Mon, 9 Feb 2015 11:36:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A13351A87DB; Mon, 9 Feb 2015 11:35:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.10.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209193545.19379.36366.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 11:35:45 -0800 Archived-At: Subject: [sfc] New Version Notification - draft-ietf-sfc-problem-statement-11.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 19:36:19 -0000 A new version (-11) has been submitted for draft-ietf-sfc-problem-statement: http://www.ietf.org/internet-drafts/draft-ietf-sfc-problem-statement-11.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Mon Feb 9 12:19: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 D24DC1A87CA for ; Mon, 9 Feb 2015 11:39:32 -0800 (PST) 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 5sLCcxO-ryuw for ; Mon, 9 Feb 2015 11:39:31 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382641A1BD9 for ; Mon, 9 Feb 2015 11:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2368; q=dns/txt; s=iport; t=1423510761; x=1424720361; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=n6qG+wGqkQAjVNuc7VLWJFOZ1oUFyLy8/JrOsoeFVxA=; b=G4rNtRPTCO54N8ljzDPEPpbaRug1J2tXvnYMm3Y64/a+SpgIsDBXRmFR GZg8+ixTeT8Fa+Jt7Gt4VtUkBJaRiV9kdiy1l+JeAHjVD6HDvL7WSkXYQ ysRIYD4TcpQJR7XR7XW4Rw/bKne0q4IGBqYDMGIOPHCR8ic102fVX0Gr1 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BkBQA1DNlU/4ENJK1cgwZSVQUEwniFbwKBHkMBAQEBAQF8hAwBAQEDATorEgIFCwIBGQMBAh8QMhsCCAIEDgUJiBwICAXIcAEBAQEBAQEBAQEBAQEBAQEBAQEBARePeA2DEIEUBY8bg1CFXIEYNoJNjlUig25vAYFDfgEBAQ X-IronPort-AV: E=Sophos;i="5.09,545,1418083200"; d="scan'208";a="121982393" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP; 09 Feb 2015 19:39:20 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t19JdK5W021376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Feb 2015 19:39:20 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.59]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Mon, 9 Feb 2015 13:39:20 -0600 From: "Paul Quinn (paulq)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-ietf-sfc-problem-statement-11.txt Thread-Index: AQHQRJ+yCpjiEc6HSE6ljdrT8t3N6g== Date: Mon, 9 Feb 2015 19:39:19 +0000 Message-ID: <705F3693-C5B2-476A-BD67-AAB3C274783B@cisco.com> References: <20150209193545.19379.85240.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: text/plain; charset="us-ascii" Content-ID: <40BEF76C50D1734B9CACF67F6E300504@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Thomas Nadeau Subject: [sfc] Fwd: New Version Notification for draft-ietf-sfc-problem-statement-11.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, 09 Feb 2015 19:39:33 -0000 Hello, As you know both the IESG and secdir has some comments and suggestions abou= t this draft. Tom and I tried to incorporate most of it in this version, p= lease review it and let us know if you have comments, concerns or suggestio= ns.=20 Thank you, Paul > Begin forwarded message: >=20 > From: > To: Thomas Nadeau , Paul Quinn = , Thomas Nadeau , Paul Quinn > Subject: New Version Notification for draft-ietf-sfc-problem-statement-11= .txt > Date: February 9, 2015 at 2:35:45 PM EST >=20 >=20 > A new version of I-D, draft-ietf-sfc-problem-statement-11.txt > has been successfully submitted by Paul Quinn and posted to the > IETF repository. >=20 > Name: draft-ietf-sfc-problem-statement > Revision: 11 > Title: Service Function Chaining Problem Statement > Document date: 2015-02-09 > Group: sfc > Pages: 19 > URL: http://www.ietf.org/internet-drafts/draft-ietf-sfc-proble= m-statement-11.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-s= tatement/ > Htmlized: http://tools.ietf.org/html/draft-ietf-sfc-problem-stateme= nt-11 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem= -statement-11 >=20 > Abstract: > This document provides an overview of the issues associated with the > deployment of service functions (such as firewalls, load balancers, > etc.) in large-scale environments. The term service function > chaining is used to describe the definition and instantiation of an > ordered list of instances of such service functions, and the > subsequent "steering" of traffic flows through those service > functions. >=20 > The set of enabled service function chains reflect operator service > offerings and is designed in conjunction with application delivery > and service and network policy. >=20 > This document also identifies several key areas that the SFC working > group will investigate to guide its architectural and protocol work > and associated drafts. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 From nobody Mon Feb 9 12:23:26 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9762B1A1BE9 for ; Mon, 9 Feb 2015 11:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.61 X-Spam-Level: X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rydEnlQ_TKPO for ; Mon, 9 Feb 2015 11:43:40 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 9097F1A044F for ; Mon, 9 Feb 2015 11:43:40 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 79D042C407D for ; Mon, 9 Feb 2015 11:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tG8Bxc-HMW3o for ; Mon, 9 Feb 2015 11:43:39 -0800 (PST) Received: from mail-qg0-f53.google.com (mail-qg0-f53.google.com [209.85.192.53]) (Authenticated sender: narseo) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id DF8B42C407C for ; Mon, 9 Feb 2015 11:43:38 -0800 (PST) Received: by mail-qg0-f53.google.com with SMTP id f51so23282609qge.12 for ; Mon, 09 Feb 2015 11:43:38 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.86.75 with SMTP id o69mr42606913qgd.98.1423511018201; Mon, 09 Feb 2015 11:43:38 -0800 (PST) Received: by 10.96.136.39 with HTTP; Mon, 9 Feb 2015 11:43:38 -0800 (PST) Date: Mon, 9 Feb 2015 11:43:38 -0800 Message-ID: From: Narseo Vallina Rodriguez To: sfc@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [sfc] HTTP Header injection 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, 09 Feb 2015 19:43:41 -0000 Hi, I've been working for a while on analyzing headers added by middleboxes, in particular in the context on mobile networks. This draft is very interesting to read. It brings a number of questions to mind. The most basic is regarding user's privacy. I'd appreciate hearing perspectives on it. In particular, I'm wondering about the security and privacy implications for mobile user associated with adding unique identifiers (aka perma-cookies), and other values such as the IMEI, IMSI and MSISDN that can be maliciously used to identify, profile and track mobile users. Many thanks, Narseo Vallina-Rodriguez http://www.icsi.berkeley.edu/~narseo From nobody Mon Feb 9 13:47:11 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 A85C41A19F7 for ; Mon, 9 Feb 2015 13:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kVAcX_S5qSa for ; Mon, 9 Feb 2015 13:10:26 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id A9B571A1A06 for ; Mon, 9 Feb 2015 13:10:26 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 9D30D2C4091 for ; Mon, 9 Feb 2015 13:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23hlpG0j9cp1 for ; Mon, 9 Feb 2015 13:10:26 -0800 (PST) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (Authenticated sender: narseo) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 12E462C4089 for ; Mon, 9 Feb 2015 13:10:26 -0800 (PST) Received: by mail-qg0-f48.google.com with SMTP id a108so23686276qge.7 for ; Mon, 09 Feb 2015 13:10:25 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.107.75 with SMTP id g69mr39699150qgf.103.1423516225150; Mon, 09 Feb 2015 13:10:25 -0800 (PST) Received: by 10.96.136.39 with HTTP; Mon, 9 Feb 2015 13:10:25 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Feb 2015 13:10:25 -0800 Message-ID: From: Narseo Vallina Rodriguez To: sfc@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [sfc] HTTP Header injection 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, 09 Feb 2015 21:10:33 -0000 Just to clarify, I'm referring to this specific use-case for mobile networks: https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-00#section-3.3 On Mon, Feb 9, 2015 at 11:43 AM, Narseo Vallina Rodriguez wrote: > Hi, > > I've been working for a while on analyzing headers added by > middleboxes, in particular in the context on mobile networks. This > draft is very interesting to read. > > It brings a number of questions to mind. The most basic is regarding > user's privacy. I'd appreciate hearing perspectives on it. In > particular, I'm wondering about the security and privacy implications > for mobile user associated with adding unique identifiers (aka > perma-cookies), and other values such as the IMEI, IMSI and MSISDN > that can be maliciously used to identify, profile and track mobile > users. > > Many thanks, > > Narseo Vallina-Rodriguez > http://www.icsi.berkeley.edu/~narseo From nobody Mon Feb 9 14:45: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 0B0ED1A8A29 for ; Mon, 9 Feb 2015 14:28:04 -0800 (PST) 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 wLPvHHw2ew_j for ; Mon, 9 Feb 2015 14:28:00 -0800 (PST) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0AF41A8A44 for ; Mon, 9 Feb 2015 14:27:59 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0224.002; Mon, 9 Feb 2015 14:27:59 -0800 From: Ron Parker To: Narseo Vallina Rodriguez , "sfc@ietf.org" Thread-Topic: [GRAYMAIL] Re: [sfc] HTTP Header injection Thread-Index: AQHQRKzZ59iubDB4U0CjiJzedoUga5zo5TBg Date: Mon, 9 Feb 2015 22:27:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.229.164.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection 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, 09 Feb 2015 22:28:04 -0000 Narseo, There are a few techniques I know of that are sometimes utilized to address= this issue: 1. One-way anonymization of identifying fields 2. Reversable anonymization with dictionary maintained separately and/or s= ecurely 3. Encrypted values inserted as the values of the headers Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Narseo Vallina Rodrigu= ez Sent: Monday, February 9, 2015 4:10 PM To: sfc@ietf.org Subject: [GRAYMAIL] Re: [sfc] HTTP Header injection Just to clarify, I'm referring to this specific use-case for mobile network= s: https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-00#section-3.3 On Mon, Feb 9, 2015 at 11:43 AM, Narseo Vallina Rodriguez wrote: > Hi, > > I've been working for a while on analyzing headers added by=20 > middleboxes, in particular in the context on mobile networks. This=20 > draft is very interesting to read. > > It brings a number of questions to mind. The most basic is regarding=20 > user's privacy. I'd appreciate hearing perspectives on it. In=20 > particular, I'm wondering about the security and privacy implications=20 > for mobile user associated with adding unique identifiers (aka=20 > perma-cookies), and other values such as the IMEI, IMSI and MSISDN=20 > that can be maliciously used to identify, profile and track mobile=20 > users. > > Many thanks, > > Narseo Vallina-Rodriguez > http://www.icsi.berkeley.edu/~narseo _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Feb 9 15:12: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 7D8D91A8A57 for ; Mon, 9 Feb 2015 14:53:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gz-9gMXnrirJ for ; Mon, 9 Feb 2015 14:53:47 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id E4AEB1A8A13 for ; Mon, 9 Feb 2015 14:53:46 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id DBF5F2C409F for ; Mon, 9 Feb 2015 14:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id g+ZUhPB6RANx for ; Mon, 9 Feb 2015 14:53:46 -0800 (PST) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) (Authenticated sender: narseo) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 2DBA92C409E for ; Mon, 9 Feb 2015 14:53:46 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id s11so5759187qcv.11 for ; Mon, 09 Feb 2015 14:53:45 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.224.16.139 with SMTP id o11mr25712470qaa.55.1423522425153; Mon, 09 Feb 2015 14:53:45 -0800 (PST) Received: by 10.96.136.39 with HTTP; Mon, 9 Feb 2015 14:53:45 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Feb 2015 14:53:45 -0800 Message-ID: From: Narseo Vallina Rodriguez To: Ron Parker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection 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, 09 Feb 2015 22:53:48 -0000 Hi Ron Thanks a lot for your response! As I understand from your answer, that will prevent the leak of the real value itself but the problem is that it still allows any server (as the HTTP headers are injected to ANY HTTP request) to track any user uniquely. For instance, the hash of the IMSI will not leak the IMSI value itself but it will still be a unique value for a given GSM subscriber. As a result, any web-server could use this information for tracking purposes and profiling, which could be used maliciously. There is no way of controlling where this information actually ends up, and web tracking is becoming a serious privacy concern. As a result, this is still a quite sensitive privacy leak in my opinion. Moreover, we have seen that mobile proxies do not advertise their presence as it is supposed to be done with the VIA field according to the HTTP standards so the header injection happens behind the scenes without user awareness. I'm curious about the reason behind injecting this information as I can see the privacy implications but not the actual benefit for the user or even for the operator unless it's for advertisement purposes. It's a bit contradictory, as the draft mentions that one of the use-cases is protecting users' privacy. Any insight will be very appreciated Many thanks! Cheers ---------- Forwarded message ---------- From: Ron Parker Date: Mon, Feb 9, 2015 at 2:27 PM Subject: RE: [GRAYMAIL] Re: [sfc] HTTP Header injection To: Narseo Vallina Rodriguez , "sfc@ietf.org" Narseo, There are a few techniques I know of that are sometimes utilized to address this issue: 1. One-way anonymization of identifying fields 2. Reversable anonymization with dictionary maintained separately and/or securely 3. Encrypted values inserted as the values of the headers Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Narseo Vallina Rodriguez Sent: Monday, February 9, 2015 4:10 PM To: sfc@ietf.org Subject: [GRAYMAIL] Re: [sfc] HTTP Header injection Just to clarify, I'm referring to this specific use-case for mobile networks: https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility-00#section-3.3 On Mon, Feb 9, 2015 at 11:43 AM, Narseo Vallina Rodriguez wrote: > Hi, > > I've been working for a while on analyzing headers added by > middleboxes, in particular in the context on mobile networks. This > draft is very interesting to read. > > It brings a number of questions to mind. The most basic is regarding > user's privacy. I'd appreciate hearing perspectives on it. In > particular, I'm wondering about the security and privacy implications > for mobile user associated with adding unique identifiers (aka > perma-cookies), and other values such as the IMEI, IMSI and MSISDN > that can be maliciously used to identify, profile and track mobile > users. > > Many thanks, > > Narseo Vallina-Rodriguez > http://www.icsi.berkeley.edu/~narseo _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Feb 9 15:50: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 1FC2F1A8A7C; Mon, 9 Feb 2015 15:10:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 kwh287nMC14O; Mon, 9 Feb 2015 15:10:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC751A883B; Mon, 9 Feb 2015 15:10:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150209231014.30535.46548.idtracker@ietfa.amsl.com> Date: Mon, 09 Feb 2015 15:10:14 -0800 Archived-At: Cc: draft-ietf-sfc-problem-statement@ietf.org, jmh@joelhalpern.com, sfc-chairs@ietf.org, sfc@ietf.org Subject: [sfc] Stephen Farrell's No Objection on draft-ietf-sfc-problem-statement-11: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2015 23:10:16 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-sfc-problem-statement-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for handling my discuss via the additional security considerations text. I look forward to seeing the SFC architecture and subsequent documents and how they handle the security and privacy issues that will need to be tackled. From nobody Mon Feb 9 15:51: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 C50FC1A8940 for ; Mon, 9 Feb 2015 15:33:35 -0800 (PST) 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 cZFmOmsajPRK for ; Mon, 9 Feb 2015 15:33:33 -0800 (PST) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7619E1A6EE8 for ; Mon, 9 Feb 2015 15:33:33 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0224.002; Mon, 9 Feb 2015 15:33:32 -0800 From: Ron Parker To: Narseo Vallina Rodriguez Thread-Topic: [GRAYMAIL] Re: [sfc] HTTP Header injection Thread-Index: AQHQRKzZ59iubDB4U0CjiJzedoUga5zo5TBggACOFoD//4N48A== Date: Mon, 9 Feb 2015 23:33:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.229.164.153] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection 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, 09 Feb 2015 23:33:35 -0000 TmFyc2VvLA0KDQpUaGUgSFRUUCBYLWhlYWRlcnMgcmVsYXRlZCB0byBpZGVudGlmaWNhdGlvbiBh cmUgdHlwaWNhbGx5IGluc2VydGVkIGJ5IHRoZSBTdWJzY3JpYmVyIE1hbmFnZW1lbnQgU3lzdGVt IGZvciB0aGUgYmVuZWZpdCBvZiB0cmFuc3BhcmVudCBtaWRib3hlcyBzdWNoIGFzIHZpZGVvIG9w dGltaXplcnMsIElEUy9JUFMsIEZpcmV3YWxsLCBldGMuICAgVGhlIGZhY3QgdGhhdCBpdCBnb2Vz IGFsbCB0aGUgd2F5IHRvIHRoZSBvcmlnaW4gc2VydmVyIGlzIHNvbWV0aW1lcyBpbmNpZGVudGFs Lg0KDQpCdXQsIHRoaXMgdGVjaG5pcXVlIGlzIGxpbWl0ZWQgdG8gb25seSBjbGVhci10ZXh0IEhU VFAuICAgQXMgZW5kLXRvLWVuZCBIVFRQUyBpbmNyZWFzZXMsIHRoZSBwb3J0aW9uIG9mIGZsb3dz IHRoYXQgY2FuIGJlIGVucmljaGVkIGluIHRoaXMgbWFubmVyIGRlY3JlYXNlcy4NCg0KU0ZDIGhh cyB0aGUgcG90ZW50aWFsIHRvIHNvbHZlIHRoZSBwcm9ibGVtIG9mIHByb3ZpZGluZyBwb2xpY3kg aG9va3MgdG8gbWlkYm94ZXMgaW4gYSBtb3JlIHVuaXZlcnNhbCBhbmQgZWxlZ2FudCBmYXNoaW9u IHRocm91Z2ggdGhlIHVzZSBvZiB0aGUgbWV0YWRhdGEgY2FwYWJpbGl0aWVzIGluaGVyZW50IGlu IHRoZSBTRkMgZW5jYXBzdWxhdGlvbiBoZWFkZXIuDQoNCiAgIFJvbg0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBOYXJzZW8gVmFsbGluYSBSb2RyaWd1ZXogW21haWx0bzpu YXJzZW9AaWNzaS5iZXJrZWxleS5lZHVdIA0KU2VudDogTW9uZGF5LCBGZWJydWFyeSA5LCAyMDE1 IDU6NTQgUE0NClRvOiBSb24gUGFya2VyDQpDYzogc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTog W0dSQVlNQUlMXSBSZTogW3NmY10gSFRUUCBIZWFkZXIgaW5qZWN0aW9uDQoNCkhpIFJvbg0KDQpU aGFua3MgYSBsb3QgZm9yIHlvdXIgcmVzcG9uc2UhDQoNCkFzIEkgdW5kZXJzdGFuZCBmcm9tIHlv dXIgYW5zd2VyLCB0aGF0IHdpbGwgcHJldmVudCB0aGUgbGVhayBvZiB0aGUgcmVhbCB2YWx1ZSBp dHNlbGYgYnV0IHRoZSBwcm9ibGVtIGlzIHRoYXQgaXQgc3RpbGwgYWxsb3dzIGFueSBzZXJ2ZXIg KGFzIHRoZSBIVFRQIGhlYWRlcnMgYXJlIGluamVjdGVkIHRvIEFOWSBIVFRQIHJlcXVlc3QpIHRv IHRyYWNrIGFueSB1c2VyIHVuaXF1ZWx5Lg0KDQpGb3IgaW5zdGFuY2UsIHRoZSBoYXNoIG9mIHRo ZSBJTVNJIHdpbGwgbm90IGxlYWsgdGhlIElNU0kgdmFsdWUgaXRzZWxmIGJ1dCBpdCB3aWxsIHN0 aWxsIGJlIGEgdW5pcXVlIHZhbHVlIGZvciBhIGdpdmVuIEdTTSBzdWJzY3JpYmVyLiBBcyBhIHJl c3VsdCwgYW55IHdlYi1zZXJ2ZXIgY291bGQgdXNlIHRoaXMgaW5mb3JtYXRpb24gZm9yIHRyYWNr aW5nIHB1cnBvc2VzIGFuZCBwcm9maWxpbmcsIHdoaWNoIGNvdWxkIGJlIHVzZWQgbWFsaWNpb3Vz bHkuDQoNClRoZXJlIGlzIG5vIHdheSBvZiBjb250cm9sbGluZyB3aGVyZSB0aGlzIGluZm9ybWF0 aW9uIGFjdHVhbGx5IGVuZHMgdXAsIGFuZCB3ZWIgdHJhY2tpbmcgaXMgYmVjb21pbmcgYSBzZXJp b3VzIHByaXZhY3kgY29uY2Vybi4gQXMgYSByZXN1bHQsIHRoaXMgaXMgc3RpbGwgYSBxdWl0ZSBz ZW5zaXRpdmUgcHJpdmFjeSBsZWFrIGluIG15IG9waW5pb24uDQpNb3Jlb3Zlciwgd2UgaGF2ZSBz ZWVuIHRoYXQgbW9iaWxlIHByb3hpZXMgZG8gbm90IGFkdmVydGlzZSB0aGVpciBwcmVzZW5jZSBh cyBpdCBpcyBzdXBwb3NlZCB0byBiZSBkb25lIHdpdGggdGhlIFZJQSBmaWVsZCBhY2NvcmRpbmcg dG8gdGhlIEhUVFAgc3RhbmRhcmRzIHNvIHRoZSBoZWFkZXIgaW5qZWN0aW9uIGhhcHBlbnMgYmVo aW5kIHRoZSBzY2VuZXMgd2l0aG91dCB1c2VyIGF3YXJlbmVzcy4NCg0KSSdtIGN1cmlvdXMgYWJv dXQgdGhlIHJlYXNvbiBiZWhpbmQgaW5qZWN0aW5nIHRoaXMgaW5mb3JtYXRpb24gYXMgSSBjYW4g c2VlIHRoZSBwcml2YWN5IGltcGxpY2F0aW9ucyBidXQgbm90IHRoZSBhY3R1YWwgYmVuZWZpdCBm b3IgdGhlIHVzZXIgb3IgZXZlbiBmb3IgdGhlIG9wZXJhdG9yIHVubGVzcyBpdCdzIGZvciBhZHZl cnRpc2VtZW50IHB1cnBvc2VzLg0KSXQncyBhIGJpdCBjb250cmFkaWN0b3J5LCBhcyB0aGUgZHJh ZnQgbWVudGlvbnMgdGhhdCBvbmUgb2YgdGhlIHVzZS1jYXNlcyBpcyBwcm90ZWN0aW5nIHVzZXJz JyBwcml2YWN5Lg0KDQpBbnkgaW5zaWdodCB3aWxsIGJlIHZlcnkgYXBwcmVjaWF0ZWQNCg0KTWFu eSB0aGFua3MhDQoNCkNoZWVycw0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0t LS0tLS0NCkZyb206IFJvbiBQYXJrZXIgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+ DQpEYXRlOiBNb24sIEZlYiA5LCAyMDE1IGF0IDI6MjcgUE0NClN1YmplY3Q6IFJFOiBbR1JBWU1B SUxdIFJlOiBbc2ZjXSBIVFRQIEhlYWRlciBpbmplY3Rpb24NClRvOiBOYXJzZW8gVmFsbGluYSBS b2RyaWd1ZXogPG5hcnNlb0BpY3NpLmJlcmtlbGV5LmVkdT4sICJzZmNAaWV0Zi5vcmciIDxzZmNA aWV0Zi5vcmc+DQoNCg0KTmFyc2VvLA0KDQpUaGVyZSBhcmUgYSBmZXcgdGVjaG5pcXVlcyBJIGtu b3cgb2YgdGhhdCBhcmUgc29tZXRpbWVzIHV0aWxpemVkIHRvIGFkZHJlc3MgdGhpcyBpc3N1ZToN Cg0KMS4gIE9uZS13YXkgYW5vbnltaXphdGlvbiBvZiBpZGVudGlmeWluZyBmaWVsZHMgMi4gIFJl dmVyc2FibGUgYW5vbnltaXphdGlvbiB3aXRoIGRpY3Rpb25hcnkgbWFpbnRhaW5lZCBzZXBhcmF0 ZWx5IGFuZC9vciBzZWN1cmVseSAzLiAgRW5jcnlwdGVkIHZhbHVlcyBpbnNlcnRlZCBhcyB0aGUg dmFsdWVzIG9mIHRoZSBoZWFkZXJzDQoNCiAgIFJvbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIE5hcnNlbyBWYWxsaW5hIFJvZHJpZ3Vleg0KU2VudDogTW9uZGF5LCBGZWJydWFyeSA5LCAy MDE1IDQ6MTAgUE0NClRvOiBzZmNAaWV0Zi5vcmcNClN1YmplY3Q6IFtHUkFZTUFJTF0gUmU6IFtz ZmNdIEhUVFAgSGVhZGVyIGluamVjdGlvbg0KDQpKdXN0IHRvIGNsYXJpZnksIEknbSByZWZlcnJp bmcgdG8gdGhpcyBzcGVjaWZpYyB1c2UtY2FzZSBmb3IgbW9iaWxlIG5ldHdvcmtzOg0KDQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zZmMtdXNlLWNhc2UtbW9iaWxpdHkt MDAjc2VjdGlvbi0zLjMNCg0KT24gTW9uLCBGZWIgOSwgMjAxNSBhdCAxMTo0MyBBTSwgTmFyc2Vv IFZhbGxpbmEgUm9kcmlndWV6IDxuYXJzZW9AaWNzaS5iZXJrZWxleS5lZHU+IHdyb3RlOg0KPiBI aSwNCj4NCj4gSSd2ZSBiZWVuIHdvcmtpbmcgZm9yIGEgd2hpbGUgb24gYW5hbHl6aW5nIGhlYWRl cnMgYWRkZWQgYnkgDQo+IG1pZGRsZWJveGVzLCBpbiBwYXJ0aWN1bGFyIGluIHRoZSBjb250ZXh0 IG9uIG1vYmlsZSBuZXR3b3Jrcy4gVGhpcyANCj4gZHJhZnQgaXMgdmVyeSBpbnRlcmVzdGluZyB0 byByZWFkLg0KPg0KPiBJdCBicmluZ3MgYSBudW1iZXIgb2YgcXVlc3Rpb25zIHRvIG1pbmQuICBU aGUgbW9zdCBiYXNpYyBpcyByZWdhcmRpbmcgDQo+IHVzZXIncyBwcml2YWN5LiAgSSdkIGFwcHJl Y2lhdGUgaGVhcmluZyBwZXJzcGVjdGl2ZXMgb24gaXQuICBJbiANCj4gcGFydGljdWxhciwgSSdt IHdvbmRlcmluZyBhYm91dCB0aGUgc2VjdXJpdHkgYW5kIHByaXZhY3kgaW1wbGljYXRpb25zIA0K PiBmb3IgbW9iaWxlIHVzZXIgYXNzb2NpYXRlZCB3aXRoIGFkZGluZyB1bmlxdWUgaWRlbnRpZmll cnMgKGFrYSANCj4gcGVybWEtY29va2llcyksIGFuZCBvdGhlciB2YWx1ZXMgc3VjaCBhcyB0aGUg SU1FSSwgSU1TSSBhbmQgTVNJU0ROIA0KPiB0aGF0IGNhbiBiZSBtYWxpY2lvdXNseSB1c2VkIHRv IGlkZW50aWZ5LCBwcm9maWxlIGFuZCB0cmFjayBtb2JpbGUgDQo+IHVzZXJzLg0KPg0KPiBNYW55 IHRoYW5rcywNCj4NCj4gTmFyc2VvIFZhbGxpbmEtUm9kcmlndWV6DQo+IGh0dHA6Ly93d3cuaWNz aS5iZXJrZWxleS5lZHUvfm5hcnNlbw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K From nobody Mon Feb 9 16:27: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 C8A5C1A8AA0 for ; Mon, 9 Feb 2015 16:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.61 X-Spam-Level: X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7YQj74QMn0qP for ; Mon, 9 Feb 2015 16:26:49 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 02B0A1A0372 for ; Mon, 9 Feb 2015 16:26:49 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id EA4CD2C40A1 for ; Mon, 9 Feb 2015 16:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id xqILgxADup7Q for ; Mon, 9 Feb 2015 16:26:48 -0800 (PST) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (Authenticated sender: narseo) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 561B22C4007 for ; Mon, 9 Feb 2015 16:26:48 -0800 (PST) Received: by mail-qg0-f44.google.com with SMTP id j5so9065921qga.3 for ; Mon, 09 Feb 2015 16:26:47 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.107.75 with SMTP id g69mr41403823qgf.103.1423528007436; Mon, 09 Feb 2015 16:26:47 -0800 (PST) Received: by 10.96.136.39 with HTTP; Mon, 9 Feb 2015 16:26:47 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Feb 2015 16:26:47 -0800 Message-ID: From: Narseo Vallina Rodriguez To: Ron Parker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection 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, 10 Feb 2015 00:26:51 -0000 Hi Ron Thanks for the explanation. I still have some concerns about the header enrichment that may be worth discussing further. Let me respond inline. > The HTTP X-headers related to identification are typically inserted by th= e Subscriber Management System for the benefit of transparent midboxes such= as video optimizers, IDS/IPS, Firewall, etc. The fact that it goes all t= he way to the origin server is sometimes incidental. > That's exactly my main concern. The first example for SFC use cases in mobile networks is functions to protect the carrier network and the privacy of its users. This is contradictory with many other parts of the draft as in the case that we're discussing unless there are other reasons behind such as monetizing user's metadata. If not, why is this information leaving the network and reaching the origin server without any control given how sensitive it is? As you frame it, it sounds like End-to-End SFC is not the goal in this case. If so, aren't better ways of doing performance enhancement as in the video streaming case without leaking personal data as using "differential" values rather than unique absolute ones on a per-user basis? >From my perspective, adding these headers does not add much value to the whole chain, but still present a serious privacy concern for most users so that's why I would like to know about a real use case in which the uncontrolled leak beyond the scope of the operator (and the addition of the headers) is completely justify. Just for reference, we have identified the following headers added by mobile proxies. We have records going back to November 2013 The 3 headers listed below are perma-cookies (the EFF showed their concerns with such headers), which do not map to any unique identifier such as IMEI/IMSI but they still identify the user uniquely. We have observed them in a bunch of operators all over the world. x-acr X-UIDH X-VF-ACR The headers below leak directly raw values without any anonymization as you proposed, thus becoming serious privacy leaks. In fact, these are some of the values that are listed on the draft as possible values to be included, which is worrying and also contradicting the privacy preserving use case. LBS-EventTime: Header probably related to location-based services. LBS-ZoneID: Idem MSISDN: Subscriber phone number. x-up-3gpp-imeisv: Device IMEI. Identifies the device uniquely. x-up-nai: Email-like name that identifies the user and operator. x-up-calling-line-id: Subscriber phone number. x-up-vodacomgw-subid: Subscriber phone number. > But, this technique is limited to only clear-text HTTP. As end-to-end H= TTPS increases, the portion of flows that can be enriched in this manner de= creases. > Still, a large fraction of users' traffic is still HTTP, as in the case of ad-traffic that actually involve more than one party. Just check a normal online newspaper or magazine. As a result, this information is being collected by an uncontrolled number of online services. Some of them, may not be trustworthy. > SFC has the potential to solve the problem of providing policy hooks to m= idboxes in a more universal and elegant fashion through the use of the meta= data capabilities inherent in the SFC encapsulation header. > So is the point to enable E2E SFC? Once more, couldn't this be done without enabling users' tracking and leaking their personal data? How will middleboxes take advantage of them if the x-headers are not standardised and are highly customized by operators and proxy manufacturers? From nobody Mon Feb 9 16:55: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 67DBF1A0193 for ; Mon, 9 Feb 2015 16:54:40 -0800 (PST) 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 SFLohGsVHow1 for ; Mon, 9 Feb 2015 16:54:37 -0800 (PST) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43AB1A01F7 for ; Mon, 9 Feb 2015 16:54:37 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0224.002; Mon, 9 Feb 2015 16:54:37 -0800 From: Ron Parker To: Narseo Vallina Rodriguez Thread-Topic: [GRAYMAIL] Re: [sfc] HTTP Header injection Thread-Index: AQHQRKzZ59iubDB4U0CjiJzedoUga5zo5TBggACOFoD//4N48IAAloaA//+A+9Y= Date: Tue, 10 Feb 2015 00:54:36 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.229.164.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection 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, 10 Feb 2015 00:54:40 -0000 Narseo,=0A= =0A= The point I was trying to make is that the use of the SFC encapsulation met= adata within the carrier's administrative domain, instead of HTTP header en= richment, will address these security considerations. The current SFC arc= hitecture states that it is supported within a single administrative domain= with inter-domain SFC for further study. Stated another way, end-to-end = SFC is not supported.=0A= =0A= Ron=0A= =0A= =0A= ________________________________________=0A= From: Narseo Vallina Rodriguez [narseo@icsi.berkeley.edu]=0A= Sent: Monday, February 09, 2015 7:26 PM=0A= To: Ron Parker=0A= Cc: sfc@ietf.org=0A= Subject: Re: [GRAYMAIL] Re: [sfc] HTTP Header injection=0A= =0A= Hi Ron=0A= =0A= Thanks for the explanation. I still have some concerns about the=0A= header enrichment that may be worth discussing further. Let me respond=0A= inline.=0A= =0A= > The HTTP X-headers related to identification are typically inserted by th= e Subscriber Management System for the benefit of transparent midboxes such= as video optimizers, IDS/IPS, Firewall, etc. The fact that it goes all t= he way to the origin server is sometimes incidental.=0A= >=0A= =0A= That's exactly my main concern. The first example for SFC use cases in=0A= mobile networks is functions to protect the carrier network and the=0A= privacy of its users. This is contradictory with many other parts of=0A= the draft as in the case that we're discussing unless there are other=0A= reasons behind such as monetizing user's metadata.=0A= =0A= If not, why is this information leaving the network and reaching the=0A= origin server without any control given how sensitive it is?=0A= =0A= As you frame it, it sounds like End-to-End SFC is not the goal in this=0A= case. If so, aren't better ways of doing performance enhancement as in=0A= the video streaming case without leaking personal data as using=0A= "differential" values rather than unique absolute ones on a per-user=0A= basis?=0A= =0A= >From my perspective, adding these headers does not add much value to=0A= the whole chain, but still present a serious privacy concern for most=0A= users so that's why I would like to know about a real use case in=0A= which the uncontrolled leak beyond the scope of the operator (and the=0A= addition of the headers) is completely justify.=0A= =0A= Just for reference, we have identified the following headers added by=0A= mobile proxies. We have records going back to November 2013=0A= =0A= The 3 headers listed below are perma-cookies (the EFF showed their=0A= concerns with such headers), which do not map to any unique identifier=0A= such as IMEI/IMSI but they still identify the user uniquely. We have=0A= observed them in a bunch of operators all over the world.=0A= =0A= x-acr=0A= X-UIDH=0A= X-VF-ACR=0A= =0A= The headers below leak directly raw values without any anonymization=0A= as you proposed, thus becoming serious privacy leaks. In fact, these=0A= are some of the values that are listed on the draft as possible values=0A= to be included, which is worrying and also contradicting the privacy=0A= preserving use case.=0A= =0A= LBS-EventTime: Header probably related to location-based services.=0A= LBS-ZoneID: Idem=0A= MSISDN: Subscriber phone number.=0A= x-up-3gpp-imeisv: Device IMEI. Identifies the device uniquely.=0A= x-up-nai: Email-like name that identifies the user and operator.=0A= x-up-calling-line-id: Subscriber phone number.=0A= x-up-vodacomgw-subid: Subscriber phone number.=0A= =0A= > But, this technique is limited to only clear-text HTTP. As end-to-end H= TTPS increases, the portion of flows that can be enriched in this manner de= creases.=0A= >=0A= =0A= Still, a large fraction of users' traffic is still HTTP, as in the=0A= case of ad-traffic that actually involve more than one party. Just=0A= check a normal online newspaper or magazine. As a result, this=0A= information is being collected by an uncontrolled number of online=0A= services. Some of them, may not be trustworthy.=0A= =0A= > SFC has the potential to solve the problem of providing policy hooks to m= idboxes in a more universal and elegant fashion through the use of the meta= data capabilities inherent in the SFC encapsulation header.=0A= >=0A= =0A= So is the point to enable E2E SFC? Once more, couldn't this be done=0A= without enabling users' tracking and leaking their personal data?=0A= =0A= How will middleboxes take advantage of them if the x-headers are not=0A= standardised and are highly customized by operators and proxy=0A= manufacturers?=0A= From nobody Mon Feb 9 23:34: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 B28201A0066 for ; Mon, 9 Feb 2015 23:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GCUfh7psO7R for ; Mon, 9 Feb 2015 23:34:30 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 351BF1A0065 for ; Mon, 9 Feb 2015 23:34:30 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 27AF02C4034 for ; Mon, 9 Feb 2015 23:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id YUn69GiLaR+i for ; Mon, 9 Feb 2015 23:34:29 -0800 (PST) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (Authenticated sender: narseo) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 5B37E2C4007 for ; Mon, 9 Feb 2015 23:34:29 -0800 (PST) Received: by mail-qg0-f47.google.com with SMTP id q107so10193707qgd.6 for ; Mon, 09 Feb 2015 23:34:28 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.224.130.200 with SMTP id u8mr50843683qas.37.1423553668529; Mon, 09 Feb 2015 23:34:28 -0800 (PST) Received: by 10.96.136.39 with HTTP; Mon, 9 Feb 2015 23:34:28 -0800 (PST) In-Reply-To: References: Date: Mon, 9 Feb 2015 23:34:28 -0800 Message-ID: From: Narseo Vallina Rodriguez To: Ron Parker Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection 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, 10 Feb 2015 07:34:31 -0000 Hi Ron Thanks a lot for your explanation. I get better the point that you were trying to make so I understand your position and I'm starting to get a better picture of the whole draft. I would appreciate other's opinions about why such headers may be needed, in particular in the mobile scenario, and how the associated privacy issues that today exist will be addressed. Many thanks again On Mon, Feb 9, 2015 at 4:54 PM, Ron Parker wrote: > Narseo, > > The point I was trying to make is that the use of the SFC encapsulation m= etadata within the carrier's administrative domain, instead of HTTP header = enrichment, will address these security considerations. The current SFC a= rchitecture states that it is supported within a single administrative doma= in with inter-domain SFC for further study. Stated another way, end-to-en= d SFC is not supported. > > Ron > > > ________________________________________ > From: Narseo Vallina Rodriguez [narseo@icsi.berkeley.edu] > Sent: Monday, February 09, 2015 7:26 PM > To: Ron Parker > Cc: sfc@ietf.org > Subject: Re: [GRAYMAIL] Re: [sfc] HTTP Header injection > > Hi Ron > > Thanks for the explanation. I still have some concerns about the > header enrichment that may be worth discussing further. Let me respond > inline. > >> The HTTP X-headers related to identification are typically inserted by t= he Subscriber Management System for the benefit of transparent midboxes suc= h as video optimizers, IDS/IPS, Firewall, etc. The fact that it goes all = the way to the origin server is sometimes incidental. >> > > That's exactly my main concern. The first example for SFC use cases in > mobile networks is functions to protect the carrier network and the > privacy of its users. This is contradictory with many other parts of > the draft as in the case that we're discussing unless there are other > reasons behind such as monetizing user's metadata. > > If not, why is this information leaving the network and reaching the > origin server without any control given how sensitive it is? > > As you frame it, it sounds like End-to-End SFC is not the goal in this > case. If so, aren't better ways of doing performance enhancement as in > the video streaming case without leaking personal data as using > "differential" values rather than unique absolute ones on a per-user > basis? > > From my perspective, adding these headers does not add much value to > the whole chain, but still present a serious privacy concern for most > users so that's why I would like to know about a real use case in > which the uncontrolled leak beyond the scope of the operator (and the > addition of the headers) is completely justify. > > Just for reference, we have identified the following headers added by > mobile proxies. We have records going back to November 2013 > > The 3 headers listed below are perma-cookies (the EFF showed their > concerns with such headers), which do not map to any unique identifier > such as IMEI/IMSI but they still identify the user uniquely. We have > observed them in a bunch of operators all over the world. > > x-acr > X-UIDH > X-VF-ACR > > The headers below leak directly raw values without any anonymization > as you proposed, thus becoming serious privacy leaks. In fact, these > are some of the values that are listed on the draft as possible values > to be included, which is worrying and also contradicting the privacy > preserving use case. > > LBS-EventTime: Header probably related to location-based services. > LBS-ZoneID: Idem > MSISDN: Subscriber phone number. > x-up-3gpp-imeisv: Device IMEI. Identifies the device uniquely. > x-up-nai: Email-like name that identifies the user and operator. > x-up-calling-line-id: Subscriber phone number. > x-up-vodacomgw-subid: Subscriber phone number. > >> But, this technique is limited to only clear-text HTTP. As end-to-end = HTTPS increases, the portion of flows that can be enriched in this manner d= ecreases. >> > > Still, a large fraction of users' traffic is still HTTP, as in the > case of ad-traffic that actually involve more than one party. Just > check a normal online newspaper or magazine. As a result, this > information is being collected by an uncontrolled number of online > services. Some of them, may not be trustworthy. > >> SFC has the potential to solve the problem of providing policy hooks to = midboxes in a more universal and elegant fashion through the use of the met= adata capabilities inherent in the SFC encapsulation header. >> > > So is the point to enable E2E SFC? Once more, couldn't this be done > without enabling users' tracking and leaking their personal data? > > How will middleboxes take advantage of them if the x-headers are not > standardised and are highly customized by operators and proxy > manufacturers? > From nobody Tue Feb 10 04:06:42 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FCFD1A0199 for ; Tue, 10 Feb 2015 04:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iM0wGOVeZGGX for ; Tue, 10 Feb 2015 04:06:33 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.152]) by ietfa.amsl.com (Postfix) with ESMTP id 474E51A0163 for ; Tue, 10 Feb 2015 04:06:32 -0800 (PST) Received: from [85.158.136.83] by server-16.bemta-5.messagelabs.com id 06/B6-02804-744F9D45; Tue, 10 Feb 2015 12:06:31 +0000 X-Env-Sender: walter.haeffner@vodafone.com X-Msg-Ref: server-7.tower-36.messagelabs.com!1423569991!7867707!1 X-Originating-IP: [195.232.224.75] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7814 invoked from network); 10 Feb 2015 12:06:31 -0000 Received: from mailout06.vodafone.com (HELO mailout06.vodafone.com) (195.232.224.75) by server-7.tower-36.messagelabs.com with SMTP; 10 Feb 2015 12:06:31 -0000 Received: from mailint06.vodafone.com (localhost [127.0.0.1]) by mailout06.vodafone.com (Postfix) with ESMTP id 1D1B71400F0 for ; Tue, 10 Feb 2015 13:06:31 +0100 (CET) Received: from VOEXC01W.internal.vodafone.com (voexc01w.dc-ratingen.de [145.230.101.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint06.vodafone.com (Postfix) with ESMTPS id 0B4721400E4; Tue, 10 Feb 2015 13:06:31 +0100 (CET) Received: from VOEXM20W.internal.vodafone.com ([169.254.4.248]) by VOEXC01W.internal.vodafone.com ([145.230.101.21]) with mapi id 14.03.0181.006; Tue, 10 Feb 2015 13:06:29 +0100 From: "Haeffner, Walter, Vodafone DE" To: Narseo Vallina Rodriguez , Ron Parker Thread-Topic: [sfc] [GRAYMAIL] Re: HTTP Header injection Thread-Index: AQHQRLfEVkKhebR7/kuLMj3Rbya6DZzo3FCAgAALHYCAAA7igIAAB8UAgABvuQCAAD4FAA== Date: Tue, 10 Feb 2015 12:06:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Stiemerling, Martin, Prof. Dr. \(martin.stiemerling@h-da.de\)" , "sfc@ietf.org" Subject: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection 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, 10 Feb 2015 12:06:38 -0000 Dear Narseo, dear Ron, Narseo, thanks for reading and commenting the draft. And thanks to Ron for = the explanations.=20 Indeed, some days ago one of the co-authors (Martin Stiemerling) mentioned = that HTTP Header Enrichment may come under attack. I will include a stateme= nt w.r.t. your security concerns. But as pointed out by Ron, the security i= ssues are even more general. And we probably could have the same discussion= with SIP P-Headers; or with any subscriber-related data exchanged between = different carriers and ISPs. Our intension for the mobility use case draft was to list a short number of= representative SFC use cases which are widely in place but we didn't rate = them w.r.t. security. For sure, you are right, the listed use cases are not= very coherent w.r.t. security requirements. But that is what you currently= find out there in the networks.=20 I will check, if the SFC problem statement draft includes such security con= cerns. This is probably the best place for the privacy issues. At least, th= e SFC architecture draft includes a paragraph:=20 "An operator may consider the SFC Metadata as sensitive. Therefore, solutions should consider whether there is a risk of sensitive information slipping out of the operators control." Narseo, if you have a proposal to improve the text, please feel free to sen= d it over. Best regards, Walter -----Urspr=FCngliche Nachricht----- Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Narseo Vallina Rodrig= uez Gesendet: Dienstag, 10. Februar 2015 08:34 An: Ron Parker Cc: sfc@ietf.org Betreff: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection Hi Ron Thanks a lot for your explanation. I get better the point that you were try= ing to make so I understand your position and I'm starting to get a better = picture of the whole draft. I would appreciate other's opinions about why such headers may be needed, i= n particular in the mobile scenario, and how the associated privacy issues = that today exist will be addressed. Many thanks again On Mon, Feb 9, 2015 at 4:54 PM, Ron Parker wrote: > Narseo, > > The point I was trying to make is that the use of the SFC encapsulation m= etadata within the carrier's administrative domain, instead of HTTP header = enrichment, will address these security considerations. The current SFC a= rchitecture states that it is supported within a single administrative doma= in with inter-domain SFC for further study. Stated another way, end-to-en= d SFC is not supported. > > Ron > > > ________________________________________ > From: Narseo Vallina Rodriguez [narseo@icsi.berkeley.edu] > Sent: Monday, February 09, 2015 7:26 PM > To: Ron Parker > Cc: sfc@ietf.org > Subject: Re: [GRAYMAIL] Re: [sfc] HTTP Header injection > > Hi Ron > > Thanks for the explanation. I still have some concerns about the=20 > header enrichment that may be worth discussing further. Let me respond=20 > inline. > >> The HTTP X-headers related to identification are typically inserted by t= he Subscriber Management System for the benefit of transparent midboxes suc= h as video optimizers, IDS/IPS, Firewall, etc. The fact that it goes all = the way to the origin server is sometimes incidental. >> > > That's exactly my main concern. The first example for SFC use cases in=20 > mobile networks is functions to protect the carrier network and the=20 > privacy of its users. This is contradictory with many other parts of=20 > the draft as in the case that we're discussing unless there are other=20 > reasons behind such as monetizing user's metadata. > > If not, why is this information leaving the network and reaching the=20 > origin server without any control given how sensitive it is? > > As you frame it, it sounds like End-to-End SFC is not the goal in this=20 > case. If so, aren't better ways of doing performance enhancement as in=20 > the video streaming case without leaking personal data as using=20 > "differential" values rather than unique absolute ones on a per-user=20 > basis? > > From my perspective, adding these headers does not add much value to=20 > the whole chain, but still present a serious privacy concern for most=20 > users so that's why I would like to know about a real use case in=20 > which the uncontrolled leak beyond the scope of the operator (and the=20 > addition of the headers) is completely justify. > > Just for reference, we have identified the following headers added by=20 > mobile proxies. We have records going back to November 2013 > > The 3 headers listed below are perma-cookies (the EFF showed their=20 > concerns with such headers), which do not map to any unique identifier=20 > such as IMEI/IMSI but they still identify the user uniquely. We have=20 > observed them in a bunch of operators all over the world. > > x-acr > X-UIDH > X-VF-ACR > > The headers below leak directly raw values without any anonymization=20 > as you proposed, thus becoming serious privacy leaks. In fact, these=20 > are some of the values that are listed on the draft as possible values=20 > to be included, which is worrying and also contradicting the privacy=20 > preserving use case. > > LBS-EventTime: Header probably related to location-based services. > LBS-ZoneID: Idem > MSISDN: Subscriber phone number. > x-up-3gpp-imeisv: Device IMEI. Identifies the device uniquely. > x-up-nai: Email-like name that identifies the user and operator. > x-up-calling-line-id: Subscriber phone number. > x-up-vodacomgw-subid: Subscriber phone number. > >> But, this technique is limited to only clear-text HTTP. As end-to-end = HTTPS increases, the portion of flows that can be enriched in this manner d= ecreases. >> > > Still, a large fraction of users' traffic is still HTTP, as in the=20 > case of ad-traffic that actually involve more than one party. Just=20 > check a normal online newspaper or magazine. As a result, this=20 > information is being collected by an uncontrolled number of online=20 > services. Some of them, may not be trustworthy. > >> SFC has the potential to solve the problem of providing policy hooks to = midboxes in a more universal and elegant fashion through the use of the met= adata capabilities inherent in the SFC encapsulation header. >> > > So is the point to enable E2E SFC? Once more, couldn't this be done=20 > without enabling users' tracking and leaking their personal data? > > How will middleboxes take advantage of them if the x-headers are not=20 > standardised and are highly customized by operators and proxy=20 > manufacturers? > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Feb 10 17:06: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 A95CF1A1A17 for ; Tue, 10 Feb 2015 17:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZM6D4eJMC8Y2 for ; Tue, 10 Feb 2015 17:06:41 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id E9DC71A03A8 for ; Tue, 10 Feb 2015 17:06:40 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id A517E2C4030 for ; Tue, 10 Feb 2015 17:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id awGwGNHo8Ztr for ; Tue, 10 Feb 2015 17:06:38 -0800 (PST) Received: from mail-qc0-f175.google.com (mail-qc0-f175.google.com [209.85.216.175]) (Authenticated sender: narseo) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id EF75F2C4025 for ; Tue, 10 Feb 2015 17:06:37 -0800 (PST) Received: by mail-qc0-f175.google.com with SMTP id c9so461252qcz.6 for ; Tue, 10 Feb 2015 17:06:36 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.224.16.139 with SMTP id o11mr39277515qaa.55.1423616796680; Tue, 10 Feb 2015 17:06:36 -0800 (PST) Received: by 10.96.136.39 with HTTP; Tue, 10 Feb 2015 17:06:36 -0800 (PST) In-Reply-To: References: Date: Tue, 10 Feb 2015 17:06:36 -0800 Message-ID: From: Narseo Vallina Rodriguez To: "Haeffner, Walter, Vodafone DE" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Stiemerling, Martin, Prof. Dr. \(martin.stiemerling@h-da.de\)" , "sfc@ietf.org" , Ron Parker Subject: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection 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, 11 Feb 2015 01:06:44 -0000 Dear Walter Thanks a lot for your response. It's actually a pleasure to read the draft and I think it has some very interesting points. I'd also love to read Martin Stiemerling's thoughts if they are available somewhere. A few weeks ago, we wrote a short blog post about our view on HTTP header injection at a global scale. http://netalyzr.icsi.berkeley.edu/blog/ We're working to extend it as paper that will be submitted this month. Of course, any feedback and comments, specially different views that may not be under our radar, will be very welcome! In your response, you mention real use-cases. As you can see in the blog post, we have found a diverse array of headers that are used for a wide range of actions. Some of them could be used to illustrate the benefits of header enrichment or to describe some use cases rather than including use-cases involving very sensitive information such as the IMEI/IMSI or even Perma-cookies. For instance the headers reporting the transport-layer protocol may be a nice use case. I personally think that the draft should clearly say that this information MUST NOT leave the actual domain of the operator in order to prevent user tracking by 3rd party services. It could be written in the same way that the HTTP standard says that any proxy MUST advertise its presence using the VIA field (BTW, only a small fraction of the mobile proxies we've seen deployed in real networks does actually include the standard VIA field). One more thought is that given that the headers are in plain HTTP text, what does prevent a client from impersonating someone else, specially for charging purposes, by adding their own headers? So to sum up, a nice definition of what kind of information is privacy sensitive could be useful, specially in the mobile use case. That would be better than leaving the decision to the operator's or proxy vendor judgement. Could that be possible? Another point to make is that enriching such headers is OK as long as they do not leave the operator's domain as Ron suggested. The US senate as well as the FCC are also showed their concerns on the use of perma cookies and other header enrichment techniques: https://www.eff.org/deeplinks/2015/02/under-senate-pressure-verizon-improve= s-its-supercookie-opt-out On Tue, Feb 10, 2015 at 4:06 AM, Haeffner, Walter, Vodafone DE wrote: > Dear Narseo, dear Ron, > > Narseo, thanks for reading and commenting the draft. And thanks to Ron fo= r the explanations. > > Indeed, some days ago one of the co-authors (Martin Stiemerling) mentione= d that HTTP Header Enrichment may come under attack. I will include a state= ment w.r.t. your security concerns. But as pointed out by Ron, the security= issues are even more general. And we probably could have the same discussi= on with SIP P-Headers; or with any subscriber-related data exchanged betwee= n different carriers and ISPs. > > Our intension for the mobility use case draft was to list a short number = of representative SFC use cases which are widely in place but we didn't rat= e them w.r.t. security. For sure, you are right, the listed use cases are n= ot very coherent w.r.t. security requirements. But that is what you current= ly find out there in the networks. > > I will check, if the SFC problem statement draft includes such security c= oncerns. This is probably the best place for the privacy issues. At least, = the SFC architecture draft includes a paragraph: > > "An operator may consider the SFC Metadata as sensitive. Therefore, > solutions should consider whether there is a risk of sensitive > information slipping out of the operators control." > > Narseo, if you have a proposal to improve the text, please feel free to s= end it over. > > Best regards, > Walter > > -----Urspr=C3=BCngliche Nachricht----- > Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Narseo Vallina Rodr= iguez > Gesendet: Dienstag, 10. Februar 2015 08:34 > An: Ron Parker > Cc: sfc@ietf.org > Betreff: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection > > Hi Ron > > Thanks a lot for your explanation. I get better the point that you were t= rying to make so I understand your position and I'm starting to get a bette= r picture of the whole draft. > > I would appreciate other's opinions about why such headers may be needed,= in particular in the mobile scenario, and how the associated privacy issue= s that today exist will be addressed. > > Many thanks again > > > > On Mon, Feb 9, 2015 at 4:54 PM, Ron Parker wrote: >> Narseo, >> >> The point I was trying to make is that the use of the SFC encapsulation = metadata within the carrier's administrative domain, instead of HTTP header= enrichment, will address these security considerations. The current SFC = architecture states that it is supported within a single administrative dom= ain with inter-domain SFC for further study. Stated another way, end-to-e= nd SFC is not supported. >> >> Ron >> >> >> ________________________________________ >> From: Narseo Vallina Rodriguez [narseo@icsi.berkeley.edu] >> Sent: Monday, February 09, 2015 7:26 PM >> To: Ron Parker >> Cc: sfc@ietf.org >> Subject: Re: [GRAYMAIL] Re: [sfc] HTTP Header injection >> >> Hi Ron >> >> Thanks for the explanation. I still have some concerns about the >> header enrichment that may be worth discussing further. Let me respond >> inline. >> >>> The HTTP X-headers related to identification are typically inserted by = the Subscriber Management System for the benefit of transparent midboxes su= ch as video optimizers, IDS/IPS, Firewall, etc. The fact that it goes all= the way to the origin server is sometimes incidental. >>> >> >> That's exactly my main concern. The first example for SFC use cases in >> mobile networks is functions to protect the carrier network and the >> privacy of its users. This is contradictory with many other parts of >> the draft as in the case that we're discussing unless there are other >> reasons behind such as monetizing user's metadata. >> >> If not, why is this information leaving the network and reaching the >> origin server without any control given how sensitive it is? >> >> As you frame it, it sounds like End-to-End SFC is not the goal in this >> case. If so, aren't better ways of doing performance enhancement as in >> the video streaming case without leaking personal data as using >> "differential" values rather than unique absolute ones on a per-user >> basis? >> >> From my perspective, adding these headers does not add much value to >> the whole chain, but still present a serious privacy concern for most >> users so that's why I would like to know about a real use case in >> which the uncontrolled leak beyond the scope of the operator (and the >> addition of the headers) is completely justify. >> >> Just for reference, we have identified the following headers added by >> mobile proxies. We have records going back to November 2013 >> >> The 3 headers listed below are perma-cookies (the EFF showed their >> concerns with such headers), which do not map to any unique identifier >> such as IMEI/IMSI but they still identify the user uniquely. We have >> observed them in a bunch of operators all over the world. >> >> x-acr >> X-UIDH >> X-VF-ACR >> >> The headers below leak directly raw values without any anonymization >> as you proposed, thus becoming serious privacy leaks. In fact, these >> are some of the values that are listed on the draft as possible values >> to be included, which is worrying and also contradicting the privacy >> preserving use case. >> >> LBS-EventTime: Header probably related to location-based services. >> LBS-ZoneID: Idem >> MSISDN: Subscriber phone number. >> x-up-3gpp-imeisv: Device IMEI. Identifies the device uniquely. >> x-up-nai: Email-like name that identifies the user and operator. >> x-up-calling-line-id: Subscriber phone number. >> x-up-vodacomgw-subid: Subscriber phone number. >> >>> But, this technique is limited to only clear-text HTTP. As end-to-end= HTTPS increases, the portion of flows that can be enriched in this manner = decreases. >>> >> >> Still, a large fraction of users' traffic is still HTTP, as in the >> case of ad-traffic that actually involve more than one party. Just >> check a normal online newspaper or magazine. As a result, this >> information is being collected by an uncontrolled number of online >> services. Some of them, may not be trustworthy. >> >>> SFC has the potential to solve the problem of providing policy hooks to= midboxes in a more universal and elegant fashion through the use of the me= tadata capabilities inherent in the SFC encapsulation header. >>> >> >> So is the point to enable E2E SFC? Once more, couldn't this be done >> without enabling users' tracking and leaking their personal data? >> >> How will middleboxes take advantage of them if the x-headers are not >> standardised and are highly customized by operators and proxy >> manufacturers? >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Fri Feb 13 06:12:30 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 623581A8704 for ; Fri, 13 Feb 2015 06:12:29 -0800 (PST) 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 6WjDmCNNCNVa for ; Fri, 13 Feb 2015 06:12:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8B51A86FB for ; Fri, 13 Feb 2015 06:12:14 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 0E5072DC509; Fri, 13 Feb 2015 15:12:13 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id D73D84C0F3; Fri, 13 Feb 2015 15:12:12 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Fri, 13 Feb 2015 15:12:10 +0100 From: To: Narseo Vallina Rodriguez Thread-Topic: [sfc] [GRAYMAIL] Re: HTTP Header injection Thread-Index: AQHQRQQGYf3dPoiF4kyzwlTYmpG4dZzuoW8g Date: Fri, 13 Feb 2015 14:12:09 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490AE24@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: In-Reply-To: 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.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.13.120922 Archived-At: Cc: Ron Parker , "sfc@ietf.org" Subject: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection 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, 13 Feb 2015 14:12:29 -0000 Dear Narseo,=20 An example to illustrate the need to inject a header in a mobile network (o= ther than those similar to HTTP_MSISDN, HTTP_X_MSISDN, HTTP_X_UP_CALLING_LI= NE_ID, HTTP_X_NOKIA_MSISDN, HTTP_X_HTS_CLID, HTTP_X_MSP_CLID,HTTP_X_NX_CLID= , HTTP_RAPMIN, HTTP_X_WAP_MSISDN, HTTP_COOKIE, HTTP_X_UP_LSID, HTTP_X_H3G_M= SISDN, HTTP_X_JINNY_CID, HTTP_X_NETWORK_INFO, etc. ) is discussed in: https= ://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-09= #section-10.2.=20 Privacy related considerations of this typical example are elaborated here:= https://tools.ietf.org/html/rfc6967#section-3. Cheers, Med -----Message d'origine----- De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Narseo Vallina Rodri= guez Envoy=E9=A0: mardi 10 f=E9vrier 2015 08:34 =C0=A0: Ron Parker Cc=A0: sfc@ietf.org Objet=A0: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection Hi Ron Thanks a lot for your explanation. I get better the point that you were trying to make so I understand your position and I'm starting to get a better picture of the whole draft. I would appreciate other's opinions about why such headers may be needed, in particular in the mobile scenario, and how the associated privacy issues that today exist will be addressed. Many thanks again On Mon, Feb 9, 2015 at 4:54 PM, Ron Parker wrote: > Narseo, > > The point I was trying to make is that the use of the SFC encapsulation m= etadata within the carrier's administrative domain, instead of HTTP header = enrichment, will address these security considerations. The current SFC a= rchitecture states that it is supported within a single administrative doma= in with inter-domain SFC for further study. Stated another way, end-to-en= d SFC is not supported. > > Ron > > > ________________________________________ > From: Narseo Vallina Rodriguez [narseo@icsi.berkeley.edu] > Sent: Monday, February 09, 2015 7:26 PM > To: Ron Parker > Cc: sfc@ietf.org > Subject: Re: [GRAYMAIL] Re: [sfc] HTTP Header injection > > Hi Ron > > Thanks for the explanation. I still have some concerns about the > header enrichment that may be worth discussing further. Let me respond > inline. > >> The HTTP X-headers related to identification are typically inserted by t= he Subscriber Management System for the benefit of transparent midboxes suc= h as video optimizers, IDS/IPS, Firewall, etc. The fact that it goes all = the way to the origin server is sometimes incidental. >> > > That's exactly my main concern. The first example for SFC use cases in > mobile networks is functions to protect the carrier network and the > privacy of its users. This is contradictory with many other parts of > the draft as in the case that we're discussing unless there are other > reasons behind such as monetizing user's metadata. > > If not, why is this information leaving the network and reaching the > origin server without any control given how sensitive it is? > > As you frame it, it sounds like End-to-End SFC is not the goal in this > case. If so, aren't better ways of doing performance enhancement as in > the video streaming case without leaking personal data as using > "differential" values rather than unique absolute ones on a per-user > basis? > > From my perspective, adding these headers does not add much value to > the whole chain, but still present a serious privacy concern for most > users so that's why I would like to know about a real use case in > which the uncontrolled leak beyond the scope of the operator (and the > addition of the headers) is completely justify. > > Just for reference, we have identified the following headers added by > mobile proxies. We have records going back to November 2013 > > The 3 headers listed below are perma-cookies (the EFF showed their > concerns with such headers), which do not map to any unique identifier > such as IMEI/IMSI but they still identify the user uniquely. We have > observed them in a bunch of operators all over the world. > > x-acr > X-UIDH > X-VF-ACR > > The headers below leak directly raw values without any anonymization > as you proposed, thus becoming serious privacy leaks. In fact, these > are some of the values that are listed on the draft as possible values > to be included, which is worrying and also contradicting the privacy > preserving use case. > > LBS-EventTime: Header probably related to location-based services. > LBS-ZoneID: Idem > MSISDN: Subscriber phone number. > x-up-3gpp-imeisv: Device IMEI. Identifies the device uniquely. > x-up-nai: Email-like name that identifies the user and operator. > x-up-calling-line-id: Subscriber phone number. > x-up-vodacomgw-subid: Subscriber phone number. > >> But, this technique is limited to only clear-text HTTP. As end-to-end = HTTPS increases, the portion of flows that can be enriched in this manner d= ecreases. >> > > Still, a large fraction of users' traffic is still HTTP, as in the > case of ad-traffic that actually involve more than one party. Just > check a normal online newspaper or magazine. As a result, this > information is being collected by an uncontrolled number of online > services. Some of them, may not be trustworthy. > >> SFC has the potential to solve the problem of providing policy hooks to = midboxes in a more universal and elegant fashion through the use of the met= adata capabilities inherent in the SFC encapsulation header. >> > > So is the point to enable E2E SFC? Once more, couldn't this be done > without enabling users' tracking and leaking their personal data? > > How will middleboxes take advantage of them if the x-headers are not > standardised and are highly customized by operators and proxy > manufacturers? > _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Feb 13 13:45: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 8DB601A1AA9; Fri, 13 Feb 2015 13:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 UprfUQsUOXrj; Fri, 13 Feb 2015 13:44:46 -0800 (PST) Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) (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 8CE5C1A1AE2; Fri, 13 Feb 2015 13:44:38 -0800 (PST) Received: by labgq15 with SMTP id gq15so19047748lab.6; Fri, 13 Feb 2015 13:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KsIIiF7ttNPOyt3gnj3oZXVtc50los4pepZY16dQAao=; b=DMSy4wyAlRX9SRitCAo4RLbGtWulMVZrYOyiOJpMUkbKuLMeaJ2Ec4Guf7DUsBW2ps jicn5EAUZe5NtInAzViwHixA34YXUUsaAC4fW8w29YoVKs8+A4qP/0p8GD3QL34S3hMX nl4QNHf8G5v81FpOyfX7uzcmtSZ3rGckHiK/S4LKayT+SqH4FDiIyJupWrpToC//OMiB z4L64BqGC+S+4FR65L1C6IWOcC4bCsutqame/n/5ITLA/pDIc4akVG3a/q+ee5NlJSef oW/uUPP79Nf6cJUWF3hRZXX0uA0DJK1C/XGFbmKf76Hxsxif3HFyFKykYkuJKGjaCNmI TBZw== MIME-Version: 1.0 X-Received: by 10.112.97.106 with SMTP id dz10mr9859424lbb.4.1423863877066; Fri, 13 Feb 2015 13:44:37 -0800 (PST) Received: by 10.112.167.101 with HTTP; Fri, 13 Feb 2015 13:44:37 -0800 (PST) In-Reply-To: References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> Date: Fri, 13 Feb 2015 16:44:37 -0500 Message-ID: From: Kathleen Moriarty To: "Paul Quinn (paulq)" Content-Type: multipart/alternative; boundary=001a11345b1299e3a7050eff24b0 Archived-At: Cc: "jmh@joelhalpern.com" , "draft-ietf-sfc-problem-statement@tools.ietf.org" , The IESG , "sfc@ietf.org" , "sfc-chairs@tools.ietf.org" Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) 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, 13 Feb 2015 21:44:50 -0000 --001a11345b1299e3a7050eff24b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Paul, On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) wrote= : > Hi Kathleen, > > We are working my way through the IESG comments, thanks for sending yours= ! > Thank you and sorry for my delay in response. > > Please see inline. > > Paul > > > > On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I didn't see any mention of risks with multiple tenants and shared > > infrastructure for service functions, is that a concern? This > > consideration may fall into the same description as the second point fr= om > > Ben's SecDir review (linked in Stephen's review). Although the SecDir > > review point could be within a single tenant environment where there ma= y > > or may not be various levels of trust depending on access constraints (= to > > the same or different set of applications for a single tenant). I'd li= ke > > to make sure both points get addressed or if someone can tell me why it > > doesn't matter, that would be fine too. > Is this problem addressed by SFC encapsulation? Doe it somehow mark the sessions to ensure the streams as it goes through service chains is following the chain for that specific service and instance of that service that might be tenant specific? I'd like to see some language added on this topic. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > I agree with Barry, Alissa, and maybe others that a wiki may be a bette= r > > option, but I won't stand in the way of publication. I do think the > > problem SFC is working on is important and the work will be worthwhile, > > but this draft isn't ready ready or may not need to be published. > > Having worked on SFC since the first BoF I strongly feel that a formal > problem statement needs to be codified, particularly in a space that isn= =E2=80=99t > as familiar to many as other working groups. As I mentioned to Alia, the= re > is a clear need for the information, and to have it officially documented > as an RFC for the rest of the WG efforts. > > > > > > There are still numerous security considerations to be included as > > pointed out in the SecDir review and in Stephen's DISCUSS points that I > > support. > > > > We will augment the security considerations appropriately. > > > > The draft mentions ordering for service functions, and it would be good > > to see some concrete examples of how security may be an issue with > > different options for ordering. Since SFC's scope is a single > > administrative domain, the service chaining could result in session > > decryption at various points in the chain that could result in security > > and privacy exposures within that domain (typically considered a > > manageable risk). > > But this isn=E2=80=99t really the focus of SFC WG because that encrypt/de= crypt can > happen today using the exiting service insertion techniques. What we are > focused on here is how to improve service chaining technology, we don=E2= =80=99t get > involved in the actual services. > Could you add a statement to that effect, perhaps to the end of the last sentence in Section 2.4. Suggest change from: Furthermore, altering the order of a deployed chain is complex and cumbersome. To: Furthermore, altering the order of a deployed chain is complex and cumbersome, and is therefore out-of-scope for SFC. > > > > Functionality may be limited for some of the service > > functions if the decryption does not happen prior to that point and ris= k > > prioritization will be necessary (exposure of data, session interceptio= n, > > corruption of data, etc. could result from this exposure) since this is > > likely to be used in hosted environments with multiple tenants. The > > SecDir review did mention crossover between management/control and data > > planes, but tenant isolation may also need to be mentioned. > > > > Some nits (I don't think others mentioned these, but sorry if they were > > already addressed): > > Section 2.1: 3rd paragraph: > > Is this intended to mean after a new service function is added? I can'= t > > imagine that this our happen on the fly, so I think that's the case and > > adding a word or two may help: > > from: > > As more service functions are required - often with strict ordering - > > topology changes are needed before and after each service function is > > added > > resulting in complex network changes and device configuration. > > Thank you, we=E2=80=99ll make that paragraph more specific. > > > > > 4th paragraph: I'm have trouble reading this paragraph as I think it > > contradicts itself, but the example in the following paragraph is > > helpful. If topology dictates placement, how could using topology not = be > > viable? Maybe rewording it would help: > > The topological coupling limits placement and selection of service > > functions: service functions are "fixed" in place by topology and > > therefore placement and service function selection taking into > > account network topology information is not viable. Furthermore, > > altering the services traversed, or their order, based on flow > > direction is not possible. > > > > The intent here was to convey that placement isn=E2=80=99t dynamic, and o= ne > functions are =E2=80=9Cinserted=E2=80=9D an operator cannot easily take n= etwork information > into account if/when things need to change or be updated. In other words= , > the topology dictates placement, rather than the traffic. I agree the te= xt > does explain it well and will clean it up. > In the security considerations section, the second paragraph on Classification uses the term "pervasive encryption", where I think you just mean encryption. One might use encryption to protect against pervasive monitoring and we can hope that encryption becomes pervasive one day but the meaning wound't be what was intended below. From: The use of pervasive encryption varies based on type of traffic, environment and level of operator control. To: The use of encryption varies based on type of traffic, environment and level of operator control. > > > Thanks, > > Kathleen > > > > Thanks again! > Paul Thank you! --=20 Best regards, Kathleen --001a11345b1299e3a7050eff24b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) <paulq@cisco.com= > wrote:
Hi Kathleen,

We are working my way through the IESG comments, thanks for sending yours!<= br>

Thank you and sorry for my delay in res= ponse.=C2=A0

Please see inline.

Paul


> On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wr= ote:
>
>
> ----------------------------------------------------------------------=
> DISCUSS:
> ----------------------------------------------------------------------=
>
> I didn't see any mention of risks with multiple tenants and shared=
> infrastructure for service functions, is that a concern?=C2=A0 This > consideration may fall into the same description as the second point f= rom
> Ben's SecDir review (linked in Stephen's review). Although the= SecDir
> review point could be within a single tenant environment where there m= ay
> or may not be various levels of trust depending on access constraints = (to
> the same or different set of applications for a single tenant).=C2=A0 = I'd like
> to make sure both points get addressed or if someone can tell me why i= t
> doesn't matter, that would be fine too.

Is this problem addressed by SFC encapsulation?=C2=A0 Doe = it somehow mark the sessions to ensure the streams as it goes through servi= ce chains is following the chain for that specific service and instance of = that service that might be tenant specific?=C2=A0 I'd like to see some = language added on this topic.=C2=A0
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> I agree with Barry, Alissa, and maybe others that a wiki may be a bett= er
> option, but I won't stand in the way of publication.=C2=A0 I do th= ink the
> problem SFC is working on is important and the work will be worthwhile= ,
> but this draft isn't ready ready or may not need to be published.<= br>
Having worked on SFC since the first BoF I strongly feel that a form= al problem statement needs to be codified, particularly in a space that isn= =E2=80=99t as familiar to many as other working groups.=C2=A0 As I mentione= d to Alia, there is a clear need for the information, and to have it offici= ally documented as an RFC for the rest of the WG efforts.


>
> There are still numerous security considerations to be included as
> pointed out in the SecDir review and in Stephen's DISCUSS points t= hat I
> support.
>

We will augment the security considerations appropriately.


> The draft mentions ordering for service functions, and it would be goo= d
> to see some concrete examples of how security may be an issue with
> different options for ordering.=C2=A0 Since SFC's scope is a singl= e
> administrative domain, the service chaining could result in session > decryption at various points in the chain that could result in securit= y
> and privacy exposures within that domain (typically considered a
> manageable risk).

But this isn=E2=80=99t really the focus of SFC WG because that encry= pt/decrypt can happen today using the exiting service insertion techniques.= =C2=A0 What we are focused on here is how to improve service chaining techn= ology, we don=E2=80=99t get involved in the actual services.

Could you add a statement to that effect, perhaps to = the end of the last sentence in Section 2.4.

Sugge= st change from:
Furthermore, alte=
ring the order of a=C2=A0
=C2=A0 =C2=A0deployed chain is com= plex and cumbersome.
To:
Furthermore, altering the order of a=C2=A0
=C2=A0 =C2=A0de= ployed chain is complex and cumbersome, and is therefore out-of-scope for S= FC.=C2=A0


>=C2=A0 =C2=A0Functionality may be limited for some of the service
> functions if the decryption does not happen prior to that point and ri= sk
> prioritization will be necessary (exposure of data, session intercepti= on,
> corruption of data, etc. could result from this exposure) since this i= s
> likely to be used in hosted environments with multiple tenants.=C2=A0 = The
> SecDir review did mention crossover between management/control and dat= a
> planes, but tenant isolation may also need to be mentioned.
>
> Some nits (I don't think others mentioned these, but sorry if they= were
> already addressed):
> Section 2.1: 3rd paragraph:
> Is this intended to mean after a new service function is added?=C2=A0 = I can't
> imagine that this our happen on the fly, so I think that's the cas= e and
> adding a word or two may help:
> from:
>=C2=A0 =C2=A0As more service functions are required - often with strict= ordering -
>=C2=A0 =C2=A0topology changes are needed before and after each service = function is
> added
>=C2=A0 =C2=A0resulting in complex network changes and device configurat= ion.

Thank you, we=E2=80=99ll make that paragraph more specific.

>
> 4th paragraph:=C2=A0 I'm have trouble reading this paragraph as I = think it
> contradicts itself, but the example in the following paragraph is
> helpful.=C2=A0 If topology dictates placement, how could using topolog= y not be
> viable?=C2=A0 Maybe rewording it would help:
>=C2=A0 =C2=A0The topological coupling limits placement and selection of= service
>=C2=A0 =C2=A0functions: service functions are "fixed" in plac= e by topology and
>=C2=A0 =C2=A0therefore placement and service function selection taking = into
>=C2=A0 =C2=A0account network topology information is not viable.=C2=A0 = Furthermore,
>=C2=A0 =C2=A0altering the services traversed, or their order, based on = flow
>=C2=A0 =C2=A0direction is not possible.
>

The intent here was to convey that placement isn=E2=80=99t dynamic, = and one functions are =E2=80=9Cinserted=E2=80=9D an operator cannot easily = take network information into account if/when things need to change or be u= pdated.=C2=A0 In other words, the topology dictates placement, rather than = the traffic.=C2=A0 I agree the text does explain it well and will clean it = up.

In the security considerations sect= ion, the second paragraph on Classification uses the term "pervasive e= ncryption", where I think you just mean encryption.=C2=A0 One might us= e encryption to protect against pervasive monitoring and we can hope that e= ncryption becomes pervasive one day but the meaning wound't be what was= intended below.

From:
The use of pervasive encryption varies based on type of=
 traffic,
      environment and level of operator control.
To:
The use of encryption varies based on=
 type of traffic,=C2=A0
=C2=A0 =C2=A0 =C2=A0 environment and= level of operator control. =C2=A0=C2=A0

> Thanks,
> Kathleen
>

Thanks again!
Paul

Thank you!


--

Best regards,
Kathleen
--001a11345b1299e3a7050eff24b0-- From nobody Fri Feb 13 15:36: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 A8A3A1A0377; Fri, 13 Feb 2015 15:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 GIbv6eeIS20w; Fri, 13 Feb 2015 15:35:57 -0800 (PST) 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 365AF1A038C; Fri, 13 Feb 2015 15:35:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8CC6B1C00D7; Fri, 13 Feb 2015 15:35:52 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-240.clppva.east.verizon.net [70.106.135.240]) (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 6A37D1C00C6; Fri, 13 Feb 2015 15:35:51 -0800 (PST) Message-ID: <54DE8A41.3090606@joelhalpern.com> Date: Fri, 13 Feb 2015 18:35:29 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "sfc-chairs@tools.ietf.org" , "draft-ietf-sfc-problem-statement@tools.ietf.org" , "sfc@ietf.org" , The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) 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, 13 Feb 2015 23:36:01 -0000 I am not sure I understand what the question is about tenant isolation. Multi-tenant support can be provided in many ways. You can have a service chain per tenant. You can have tenant IDs in the metadata, use common chains, and separate things on the far end. And there are probably more ways. is there something in the problem statement that leads you to expect this problem to be addressed? Even the architecture does not address this. In fact, as far as I can tell the encapsulation is unlikely to deal directly with this, as it is a solution property, not an architectural or protocol property. Sorry if I am being obtuse. Yours, Joel On 2/13/15 4:44 PM, Kathleen Moriarty wrote: > Hi Paul, > > On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) > wrote: > > Hi Kathleen, > > We are working my way through the IESG comments, thanks for sending > yours! > > > Thank you and sorry for my delay in response. > > > Please see inline. > > Paul > > > > On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty > wrote: > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I didn't see any mention of risks with multiple tenants and shared > > infrastructure for service functions, is that a concern? This > > consideration may fall into the same description as the second point from > > Ben's SecDir review (linked in Stephen's review). Although the SecDir > > review point could be within a single tenant environment where there may > > or may not be various levels of trust depending on access constraints (to > > the same or different set of applications for a single tenant). I'd like > > to make sure both points get addressed or if someone can tell me why it > > doesn't matter, that would be fine too. > > > Is this problem addressed by SFC encapsulation? Doe it somehow mark the > sessions to ensure the streams as it goes through service chains is > following the chain for that specific service and instance of that > service that might be tenant specific? I'd like to see some language > added on this topic. From nobody Fri Feb 13 15:50: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 AE49E1A00A9; Fri, 13 Feb 2015 15:50:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.036 X-Spam-Level: X-Spam-Status: No, score=0.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, LONGWORDS=2.035, 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 txHyiySojwP5; Fri, 13 Feb 2015 15:50:08 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08731A008F; Fri, 13 Feb 2015 15:50:04 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id z12so18337944lbi.11; Fri, 13 Feb 2015 15:50:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uQB3uGjSfdNxybWqtvszF0vkfrR74CHYxe0d6rt3Gh0=; b=NROxJN/6b550vpDoZas2FUZ03A3ypbwFOLuP/3f0vWlIc1dVQEJV8y+VaJl3gn+a2R k+lvfxbP0vZHD9qrHr2IOM30OPnSh64qj1HXaBLyDAWE0c5HR7V+RSVmuuI5W70S+uvO Rx4dIsZomeqAJo+KNK7vXe1KQCsYlWacWbVaZ312ySsETjrMiaNoUn7SmNkmhjsu1hEk MDyx6Z/mrVkwHMW+nFsO168Tn6eR5IsRE/TLuZgkE+OCejHh3bQlq643OhkOXqzQCFJO LVFwBbwQ9fXRIMMsMc2YBXUrLcpueZJnOZnS176tueRKu0f/PVk1y9siGBLgh8EFr+fO SJxg== MIME-Version: 1.0 X-Received: by 10.152.207.100 with SMTP id lv4mr5528921lac.4.1423871403020; Fri, 13 Feb 2015 15:50:03 -0800 (PST) Received: by 10.112.167.101 with HTTP; Fri, 13 Feb 2015 15:50:02 -0800 (PST) In-Reply-To: <54DE8A41.3090606@joelhalpern.com> References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> <54DE8A41.3090606@joelhalpern.com> Date: Fri, 13 Feb 2015 18:50:02 -0500 Message-ID: From: Kathleen Moriarty To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=001a113470a82ed765050f00e506 Archived-At: Cc: "sfc-chairs@tools.ietf.org" , "draft-ietf-sfc-problem-statement@tools.ietf.org" , "sfc@ietf.org" , The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) 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, 13 Feb 2015 23:50:14 -0000 --001a113470a82ed765050f00e506 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 13, 2015 at 6:35 PM, Joel M. Halpern wrote: > I am not sure I understand what the question is about tenant isolation. > > Multi-tenant support can be provided in many ways. You can have a service > chain per tenant. You can have tenant IDs in the metadata, use common > chains, and separate things on the far end. And there are probably more > ways. > Sure, I'd just like to see a little more text on that. Tenants are mentioned in the introduction (1st paragraph), then the term doesn't appear again. The delivery of end-to-end services often require various service functions including traditional network service functions (for example firewalls and server load balancers), as well as application- specific features such as http header manipulation. Service functions may be delivered within the context of an isolated user (e.g. a tenant), or shared amongst many users/user groups. > is there something in the problem statement that leads you to expect this > problem to be addressed? Even the architecture does not address this. In > fact, as far as I can tell the encapsulation is unlikely to deal directly > with this, as it is a solution property, not an architectural or protocol > property. > > If it's inherently addressed, it would be good to have an idea of how it is addressed in this problem statement. I suspect that is the case and would like to know how you establish an isolated user and perhaps say that this is not part of the problem if it's been solved. Maybe it's through the encapsulation. Linda responded with some thoughts on markings for sessions, which makes sense. The solutions may not need to talk about it at all if laid out correctly in this draft, which I suspect is the case. Thank you, Kathleen > Sorry if I am being obtuse. > Yours, > Joel > > On 2/13/15 4:44 PM, Kathleen Moriarty wrote: > >> Hi Paul, >> >> On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) > > wrote: >> >> Hi Kathleen, >> >> We are working my way through the IESG comments, thanks for sending >> yours! >> >> >> Thank you and sorry for my delay in response. >> >> >> Please see inline. >> >> Paul >> >> >> > On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com >> > wrote: >> > >> > >> > ------------------------------------------------------------ >> ---------- >> > DISCUSS: >> > ------------------------------------------------------------ >> ---------- >> > >> > I didn't see any mention of risks with multiple tenants and shared >> > infrastructure for service functions, is that a concern? This >> > consideration may fall into the same description as the second >> point from >> > Ben's SecDir review (linked in Stephen's review). Although the >> SecDir >> > review point could be within a single tenant environment where >> there may >> > or may not be various levels of trust depending on access >> constraints (to >> > the same or different set of applications for a single tenant). >> I'd like >> > to make sure both points get addressed or if someone can tell me >> why it >> > doesn't matter, that would be fine too. >> >> >> Is this problem addressed by SFC encapsulation? Doe it somehow mark the >> sessions to ensure the streams as it goes through service chains is >> following the chain for that specific service and instance of that >> service that might be tenant specific? I'd like to see some language >> added on this topic. >> > -- Best regards, Kathleen --001a113470a82ed765050f00e506 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 13, 2015 at 6:35 PM, Joel M. Halpern <= jmh@joelhalpern.co= m> wrote:
I am not sure I understand what= the question is about tenant isolation.

Multi-tenant support can be provided in many ways.=C2=A0 You can have a ser= vice chain per tenant.=C2=A0 You can have tenant IDs in the metadata, use c= ommon chains, and separate things on the far end.=C2=A0 And there are proba= bly more ways.

Sure, I'd just like = to see a little more text on that.=C2=A0 Tenants are mentioned in the intro= duction (1st paragraph), then the term doesn't appear again.=C2=A0

   The delivery o=
f end-to-end services often require various service
   functions including traditional network service functions (for
   example firewalls and server load balancers), as well as application-
   specific features such as http header manipulation.  Service
   functions may be delivered within the context of an isolated user
   (e.g. a tenant), or shared amongst many users/user groups.

is there something in the problem statement that leads you to expect this p= roblem to be addressed?=C2=A0 Even the architecture does not address this.= =C2=A0 In fact, as far as I can tell the encapsulation is unlikely to deal = directly with this, as it is a solution property, not an architectural or p= rotocol property.

If it's inherently addressed, it would be good to= have an idea of how it is addressed in this problem statement.=C2=A0 I sus= pect that is the case and would like to know how you establish an isolated = user and perhaps say that this is not part of the problem if it's been = solved.=C2=A0 Maybe it's through the encapsulation.=C2=A0 Linda respond= ed with some thoughts on markings for sessions, which makes sense.=C2=A0 Th= e solutions may not need to talk about it at all if laid out correctly in t= his draft, which I suspect is the case.

Thank you,=
Kathleen
=C2=A0
Sorry if I am being obtuse.
Yours,
Joel

On 2/13/15 4:44 PM, Kathleen Moriarty wrote:
Hi Paul,

On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) <paulq@cisco.com
 <mailto:paulq@cisco= .com>> wrote:

=C2=A0 =C2=A0 Hi Kathleen,

=C2=A0 =C2=A0 We are working my way through the IESG comments, thanks for s= ending
=C2=A0 =C2=A0 yours!


Thank you and sorry for my delay in response.


=C2=A0 =C2=A0 Please see inline.

=C2=A0 =C2=A0 Paul


=C2=A0 =C2=A0 > On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty <kathleen.mo= riarty.ietf@gmail.com
 =C2=A0 =C2=A0 <mailto:kathleen.moriarty.ietf@gmail.com>> wro= te:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -------------------------------------------------= ---------------------
=C2=A0 =C2=A0 > DISCUSS:
=C2=A0 =C2=A0 > -------------------------------------------------= ---------------------
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I didn't see any mention of risks with multiple tena= nts and shared
=C2=A0 =C2=A0 > infrastructure for service functions, is that a concern?= =C2=A0 This
=C2=A0 =C2=A0 > consideration may fall into the same description as the = second point from
=C2=A0 =C2=A0 > Ben's SecDir review (linked in Stephen's review)= . Although the SecDir
=C2=A0 =C2=A0 > review point could be within a single tenant environment= where there may
=C2=A0 =C2=A0 > or may not be various levels of trust depending on acces= s constraints (to
=C2=A0 =C2=A0 > the same or different set of applications for a single t= enant).=C2=A0 I'd like
=C2=A0 =C2=A0 > to make sure both points get addressed or if someone can= tell me why it
=C2=A0 =C2=A0 > doesn't matter, that would be fine too.


Is this problem addressed by SFC encapsulation?=C2=A0 Doe it somehow mark t= he
sessions to ensure the streams as it goes through service chains is
following the chain for that specific service and instance of that
service that might be tenant specific?=C2=A0 I'd like to see some langu= age
added on this topic.



--

Best regards,
Kath= leen
--001a113470a82ed765050f00e506-- From nobody Fri Feb 13 16:44: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 0C50E1A0687; Fri, 13 Feb 2015 16:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 qud3eTlAOMFH; Fri, 13 Feb 2015 16:44:05 -0800 (PST) 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 F28431A044D; Fri, 13 Feb 2015 16:44:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C597B1C00D7; Fri, 13 Feb 2015 16:44:04 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-240.clppva.east.verizon.net [70.106.135.240]) (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 54B451C00C6; Fri, 13 Feb 2015 16:44:03 -0800 (PST) Message-ID: <54DE9A3D.1090801@joelhalpern.com> Date: Fri, 13 Feb 2015 19:43:41 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> <54DE8A41.3090606@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "sfc-chairs@tools.ietf.org" , "draft-ietf-sfc-problem-statement@tools.ietf.org" , "sfc@ietf.org" , The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 00:44:07 -0000 My first reaction is to suggest removing the last sentence you quote. I don't think it matters. The reason I say that is that from what I understand, tenant isolation is not an important part of the problem / driver for the SFC work. Rather, the SFC work can be used to provide tenant isolation if folks choose to do so. Having said that, I will leave it to the chairs and authors. Yours, Joel On 2/13/15 6:50 PM, Kathleen Moriarty wrote: > > > On Fri, Feb 13, 2015 at 6:35 PM, Joel M. Halpern > wrote: > > I am not sure I understand what the question is about tenant isolation. > > Multi-tenant support can be provided in many ways. You can have a > service chain per tenant. You can have tenant IDs in the metadata, > use common chains, and separate things on the far end. And there > are probably more ways. > > > Sure, I'd just like to see a little more text on that. Tenants are > mentioned in the introduction (1st paragraph), then the term doesn't > appear again. > > The delivery of end-to-end services often require various service > functions including traditional network service functions (for > example firewalls and server load balancers), as well as application- > specific features such as http header manipulation. Service > functions may be delivered within the context of an isolated user > (e.g. a tenant), or shared amongst many users/user groups. > > > is there something in the problem statement that leads you to expect > this problem to be addressed? Even the architecture does not > address this. In fact, as far as I can tell the encapsulation is > unlikely to deal directly with this, as it is a solution property, > not an architectural or protocol property. > > If it's inherently addressed, it would be good to have an idea of how it > is addressed in this problem statement. I suspect that is the case and > would like to know how you establish an isolated user and perhaps say > that this is not part of the problem if it's been solved. Maybe it's > through the encapsulation. Linda responded with some thoughts on > markings for sessions, which makes sense. The solutions may not need to > talk about it at all if laid out correctly in this draft, which I > suspect is the case. > > Thank you, > Kathleen > > Sorry if I am being obtuse. > Yours, > Joel > > On 2/13/15 4:44 PM, Kathleen Moriarty wrote: > > Hi Paul, > > On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) > > >> wrote: > > Hi Kathleen, > > We are working my way through the IESG comments, thanks for > sending > yours! > > > Thank you and sorry for my delay in response. > > > Please see inline. > > Paul > > > > On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty > > >> wrote: > > > > > > > ------------------------------__------------------------------__---------- > > DISCUSS: > > > ------------------------------__------------------------------__---------- > > > > I didn't see any mention of risks with multiple tenants > and shared > > infrastructure for service functions, is that a concern? > This > > consideration may fall into the same description as the > second point from > > Ben's SecDir review (linked in Stephen's review). > Although the SecDir > > review point could be within a single tenant environment > where there may > > or may not be various levels of trust depending on access > constraints (to > > the same or different set of applications for a single > tenant). I'd like > > to make sure both points get addressed or if someone can > tell me why it > > doesn't matter, that would be fine too. > > > Is this problem addressed by SFC encapsulation? Doe it somehow > mark the > sessions to ensure the streams as it goes through service chains is > following the chain for that specific service and instance of that > service that might be tenant specific? I'd like to see some > language > added on this topic. > > > > > -- > > Best regards, > Kathleen From nobody Fri Feb 13 18:32: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 C33DE1A0379; Fri, 13 Feb 2015 18:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 87GrA6q_fs4y; Fri, 13 Feb 2015 18:32:11 -0800 (PST) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18241A00F0; Fri, 13 Feb 2015 18:32:10 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id w8so14906426qac.1; Fri, 13 Feb 2015 18:32:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QQ3vnoVbc/BCI/wIITULaJv6qq9qVH3KL8GeVdtRRLk=; b=N8ucKGgoiEzb+FROGmAld4CDIn31kglV+9DVXPnBFvsT5CJC5nH16ftnvwol+x9kom wxJ3M73dbB8iq6EqGgy/QLJS4kpG91eOv07pj8IwX57IhqgxuwhHOW4elV2x0Ya94Xkr wICSY9OaE5AcoqhavHyEg3dnLugYkZ40Y8zVvDzkzclQ+wvibVcerA1Xv8tLZMq30Lid 2BBAe7Mzw2NkXwdWKfLkl74EtKKIE0kUTDBxdNJiM2jh0z/yaibHcuG9zITykAAq3iNX MduyHNGRVfOeNHz5n+QbbJFDbCo1rCgSWKf+Zmcvsc5DyD01xCOYXRMhbCJG4XkNSoxH eM9g== X-Received: by 10.140.102.205 with SMTP id w71mr29546263qge.104.1423881130050; Fri, 13 Feb 2015 18:32:10 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id 103sm8564712qgg.11.2015.02.13.18.32.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Feb 2015 18:32:08 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <54DE9A3D.1090801@joelhalpern.com> Date: Fri, 13 Feb 2015 21:32:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <48BB3B48-CDBA-425D-B4A2-17E53B875E88@gmail.com> References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> <54DE8A41.3090606@joelhalpern.com> <54DE9A3D.1090801@joelhalpern.com> To: "Joel M. Halpern" Archived-At: Cc: "sfc-chairs@tools.ietf.org" , "draft-ietf-sfc-problem-statement@tools.ietf.org" , "sfc@ietf.org" , The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 02:32:12 -0000 Hi Joel, Sent from my iPhone > On Feb 13, 2015, at 7:43 PM, "Joel M. Halpern" wrote= : >=20 > My first reaction is to suggest removing the last sentence you quote. I d= on't think it matters. The reason I say that is that from what I understand= , tenant isolation is not an important part of the problem / driver for the S= FC work. Rather, the SFC work can be used to provide tenant isolation if fo= lks choose to do so. That may be fine, but I'd like to understand why it's not a problem in this d= iscussion first. Thanks, Kathleen >=20 > Having said that, I will leave it to the chairs and authors. >=20 > Yours, > Joel >=20 >> On 2/13/15 6:50 PM, Kathleen Moriarty wrote: >>=20 >>=20 >> On Fri, Feb 13, 2015 at 6:35 PM, Joel M. Halpern > > wrote: >>=20 >> I am not sure I understand what the question is about tenant isolation= . >>=20 >> Multi-tenant support can be provided in many ways. You can have a >> service chain per tenant. You can have tenant IDs in the metadata, >> use common chains, and separate things on the far end. And there >> are probably more ways. >>=20 >>=20 >> Sure, I'd just like to see a little more text on that. Tenants are >> mentioned in the introduction (1st paragraph), then the term doesn't >> appear again. >>=20 >> The delivery of end-to-end services often require various service >> functions including traditional network service functions (for >> example firewalls and server load balancers), as well as application- >> specific features such as http header manipulation. Service >> functions may be delivered within the context of an isolated user >> (e.g. a tenant), or shared amongst many users/user groups. >>=20 >>=20 >> is there something in the problem statement that leads you to expect >> this problem to be addressed? Even the architecture does not >> address this. In fact, as far as I can tell the encapsulation is >> unlikely to deal directly with this, as it is a solution property, >> not an architectural or protocol property. >>=20 >> If it's inherently addressed, it would be good to have an idea of how it >> is addressed in this problem statement. I suspect that is the case and >> would like to know how you establish an isolated user and perhaps say >> that this is not part of the problem if it's been solved. Maybe it's >> through the encapsulation. Linda responded with some thoughts on >> markings for sessions, which makes sense. The solutions may not need to >> talk about it at all if laid out correctly in this draft, which I >> suspect is the case. >>=20 >> Thank you, >> Kathleen >>=20 >> Sorry if I am being obtuse. >> Yours, >> Joel >>=20 >> On 2/13/15 4:44 PM, Kathleen Moriarty wrote: >>=20 >> Hi Paul, >>=20 >> On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) >> >> >> wrote: >>=20 >> Hi Kathleen, >>=20 >> We are working my way through the IESG comments, thanks for >> sending >> yours! >>=20 >>=20 >> Thank you and sorry for my delay in response. >>=20 >>=20 >> Please see inline. >>=20 >> Paul >>=20 >>=20 >> > On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty >> > >> > >> wrote: >> > >> > >> > >> ------------------------------__------------------------------__--= -------- >> > DISCUSS: >> > >> ------------------------------__------------------------------__--= -------- >> > >> > I didn't see any mention of risks with multiple tenants >> and shared >> > infrastructure for service functions, is that a concern? >> This >> > consideration may fall into the same description as the >> second point from >> > Ben's SecDir review (linked in Stephen's review). >> Although the SecDir >> > review point could be within a single tenant environment >> where there may >> > or may not be various levels of trust depending on access >> constraints (to >> > the same or different set of applications for a single >> tenant). I'd like >> > to make sure both points get addressed or if someone can >> tell me why it >> > doesn't matter, that would be fine too. >>=20 >>=20 >> Is this problem addressed by SFC encapsulation? Doe it somehow >> mark the >> sessions to ensure the streams as it goes through service chains i= s >> following the chain for that specific service and instance of that= >> service that might be tenant specific? I'd like to see some >> language >> added on this topic. >>=20 >>=20 >>=20 >>=20 >> -- >>=20 >> Best regards, >> Kathleen From nobody Fri Feb 13 20:51: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 498F51A0252; Fri, 13 Feb 2015 20:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 6B11UIxnwKnq; Fri, 13 Feb 2015 20:51:10 -0800 (PST) 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 DCE831A0210; Fri, 13 Feb 2015 20:51:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id AEC3E1C01C3; Fri, 13 Feb 2015 20:51:10 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-240.clppva.east.verizon.net [70.106.135.240]) (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 54D581C0180; Fri, 13 Feb 2015 20:51:09 -0800 (PST) Message-ID: <54DED426.80608@joelhalpern.com> Date: Fri, 13 Feb 2015 23:50:46 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> <54DE8A41.3090606@joelhalpern.com> <54DE9A3D.1090801@joelhalpern.com> <48BB3B48-CDBA-425D-B4A2-17E53B875E88@gmail.com> In-Reply-To: <48BB3B48-CDBA-425D-B4A2-17E53B875E88@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-sfc-problem-statement@tools.ietf.org" , "sfc@ietf.org" , The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 04:51:13 -0000 For me, the question is which of the following two questions the document is trying to address: 1) What problems are driving and prompting the effort. This is generally about problems with current tools and techniques. 2) What problems are likely to come up during the effort, and need to be solved. This would include architectural issues, protocol design constraints, and deployment issues. I have generally understood working group problem statements to be addressing the first question. It seems that you are looking for a document that covers the second question. While the two are related, they seem to me to not be the same. Differing understandings of the charter goal will make for rather different expectations of the content of the document. Yours, Joel On 2/13/15 9:32 PM, Kathleen Moriarty wrote: > Hi Joel, > > Sent from my iPhone > >> On Feb 13, 2015, at 7:43 PM, "Joel M. Halpern" wrote: >> >> My first reaction is to suggest removing the last sentence you quote. I don't think it matters. The reason I say that is that from what I understand, tenant isolation is not an important part of the problem / driver for the SFC work. Rather, the SFC work can be used to provide tenant isolation if folks choose to do so. > > That may be fine, but I'd like to understand why it's not a problem in this discussion first. > > Thanks, > Kathleen > >> >> Having said that, I will leave it to the chairs and authors. >> >> Yours, >> Joel >> >>> On 2/13/15 6:50 PM, Kathleen Moriarty wrote: >>> >>> >>> On Fri, Feb 13, 2015 at 6:35 PM, Joel M. Halpern >> > wrote: >>> >>> I am not sure I understand what the question is about tenant isolation. >>> >>> Multi-tenant support can be provided in many ways. You can have a >>> service chain per tenant. You can have tenant IDs in the metadata, >>> use common chains, and separate things on the far end. And there >>> are probably more ways. >>> >>> >>> Sure, I'd just like to see a little more text on that. Tenants are >>> mentioned in the introduction (1st paragraph), then the term doesn't >>> appear again. >>> >>> The delivery of end-to-end services often require various service >>> functions including traditional network service functions (for >>> example firewalls and server load balancers), as well as application- >>> specific features such as http header manipulation. Service >>> functions may be delivered within the context of an isolated user >>> (e.g. a tenant), or shared amongst many users/user groups. >>> >>> >>> is there something in the problem statement that leads you to expect >>> this problem to be addressed? Even the architecture does not >>> address this. In fact, as far as I can tell the encapsulation is >>> unlikely to deal directly with this, as it is a solution property, >>> not an architectural or protocol property. >>> >>> If it's inherently addressed, it would be good to have an idea of how it >>> is addressed in this problem statement. I suspect that is the case and >>> would like to know how you establish an isolated user and perhaps say >>> that this is not part of the problem if it's been solved. Maybe it's >>> through the encapsulation. Linda responded with some thoughts on >>> markings for sessions, which makes sense. The solutions may not need to >>> talk about it at all if laid out correctly in this draft, which I >>> suspect is the case. >>> >>> Thank you, >>> Kathleen >>> >>> Sorry if I am being obtuse. >>> Yours, >>> Joel >>> >>> On 2/13/15 4:44 PM, Kathleen Moriarty wrote: >>> >>> Hi Paul, >>> >>> On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) >>> >>> >> wrote: >>> >>> Hi Kathleen, >>> >>> We are working my way through the IESG comments, thanks for >>> sending >>> yours! >>> >>> >>> Thank you and sorry for my delay in response. >>> >>> >>> Please see inline. >>> >>> Paul >>> >>> >>> > On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty >>> >> >>> >> >> wrote: >>> > >>> > >>> > >>> ------------------------------__------------------------------__---------- >>> > DISCUSS: >>> > >>> ------------------------------__------------------------------__---------- >>> > >>> > I didn't see any mention of risks with multiple tenants >>> and shared >>> > infrastructure for service functions, is that a concern? >>> This >>> > consideration may fall into the same description as the >>> second point from >>> > Ben's SecDir review (linked in Stephen's review). >>> Although the SecDir >>> > review point could be within a single tenant environment >>> where there may >>> > or may not be various levels of trust depending on access >>> constraints (to >>> > the same or different set of applications for a single >>> tenant). I'd like >>> > to make sure both points get addressed or if someone can >>> tell me why it >>> > doesn't matter, that would be fine too. >>> >>> >>> Is this problem addressed by SFC encapsulation? Doe it somehow >>> mark the >>> sessions to ensure the streams as it goes through service chains is >>> following the chain for that specific service and instance of that >>> service that might be tenant specific? I'd like to see some >>> language >>> added on this topic. >>> >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen > From nobody Sat Feb 14 07:26:47 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 370361A3BA5; Sat, 14 Feb 2015 07:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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 OPSQDiT3crO4; Sat, 14 Feb 2015 07:26:37 -0800 (PST) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (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 33F481A3BA2; Sat, 14 Feb 2015 07:26:37 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id r5so4743293qcx.13; Sat, 14 Feb 2015 07:26:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=p9riRr3O6xbKTdzCfOJZLD2q7ZKZ40uxT+eCUkpH9uE=; b=XGzH669hoYI9PmviHDaIlgBJYqYdpH9KVHCjmXJr6vBTWoPSV7ez6r3Q1Vi1BAxDFp 6e0UmS7snm/LOrb3QH+mACKsNsDk8IQ8c8HpEAVuWoCNEl6oXG4MxU7SUq14/Rmp37yF z3LRezUKnMeUMnFMprafzT6P/RBYv/c1WWio7nPHZni/7p5bjwaDx3FqJhvLJtbzl/0c BGZ5PJlQLT+XExpzWfuIOzDogN3fjVJjzp3xcTHKu5RUNOpohkBhuHXoAea8O82OxLgE GSbzhPrp/kXSLHlhVmCns475pCw7S9Bne9we/qYDxxnv76nQIHXuq8jV/AOVVhI3Hdr7 NpwQ== X-Received: by 10.140.232.149 with SMTP id d143mr7842885qhc.81.1423927596364; Sat, 14 Feb 2015 07:26:36 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id q5sm9660920qat.6.2015.02.14.07.26.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Feb 2015 07:26:34 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <54DED426.80608@joelhalpern.com> Date: Sat, 14 Feb 2015 10:26:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <83EF0DDF-77DE-47B7-91D3-AEF7A1D4865D@gmail.com> References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> <54DE8A41.3090606@joelhalpern.com> <54DE9A3D.1090801@joelhalpern.com> <48BB3B48-CDBA-425D-B4A2-17E53B875E88@gmail.com> <54DED426.80608@joelhalpern.com> To: "Joel M. Halpern" Archived-At: Cc: "draft-ietf-sfc-problem-statement@tools.ietf.org" , "sfc@ietf.org" , The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 15:26:39 -0000 Hi Joel, Sent from my iPhone > On Feb 13, 2015, at 11:50 PM, "Joel M. Halpern" wrot= e: >=20 > For me, the question is which of the following two questions the document i= s trying to address: >=20 > 1) What problems are driving and prompting the effort. This is generally a= bout problems with current tools and techniques. >=20 > 2) What problems are likely to come up during the effort, and need to be s= olved. This would include architectural issues, protocol design constraints= , and deployment issues. >=20 > I have generally understood working group problem statements to be address= ing the first question. It seems that you are looking for a document that c= overs the second question. =20 Nope, just looking for an answer to my question to understand scope. =20 > While the two are related, they seem to me to not be the same. Differing u= nderstandings of the charter goal will make for rather different expectation= s of the content of the document. Whether or not it goes in the draft, I'd like to understand what the problem= statement covers, what is in scope or out of scope and to understand why. I= t would help to just get an answer to my discuss question whether or not it g= oes in the draft. Talking around it doesn't help me understand why this doe= s or doesn't belong in the draft. The problem statement covers service chai= ning through shared infrastructure. If you are deciding how to direct traff= ic through service chains, I think my question is a fair one and I'd love to= get an answer. If it's not in scope, it should be clear why it's not in th= e draft. Thank you, Kathleen >=20 > Yours, > Joel >=20 >> On 2/13/15 9:32 PM, Kathleen Moriarty wrote: >> Hi Joel, >>=20 >> Sent from my iPhone >>=20 >>> On Feb 13, 2015, at 7:43 PM, "Joel M. Halpern" wro= te: >>>=20 >>> My first reaction is to suggest removing the last sentence you quote. I= don't think it matters. The reason I say that is that from what I understa= nd, tenant isolation is not an important part of the problem / driver for th= e SFC work. Rather, the SFC work can be used to provide tenant isolation if= folks choose to do so. >>=20 >> That may be fine, but I'd like to understand why it's not a problem in th= is discussion first. >>=20 >> Thanks, >> Kathleen >>=20 >>>=20 >>> Having said that, I will leave it to the chairs and authors. >>>=20 >>> Yours, >>> Joel >>>=20 >>>> On 2/13/15 6:50 PM, Kathleen Moriarty wrote: >>>>=20 >>>>=20 >>>> On Fri, Feb 13, 2015 at 6:35 PM, Joel M. Halpern >>> > wrote: >>>>=20 >>>> I am not sure I understand what the question is about tenant isolati= on. >>>>=20 >>>> Multi-tenant support can be provided in many ways. You can have a >>>> service chain per tenant. You can have tenant IDs in the metadata, >>>> use common chains, and separate things on the far end. And there >>>> are probably more ways. >>>>=20 >>>>=20 >>>> Sure, I'd just like to see a little more text on that. Tenants are >>>> mentioned in the introduction (1st paragraph), then the term doesn't >>>> appear again. >>>>=20 >>>> The delivery of end-to-end services often require various service >>>> functions including traditional network service functions (for >>>> example firewalls and server load balancers), as well as application= - >>>> specific features such as http header manipulation. Service >>>> functions may be delivered within the context of an isolated user >>>> (e.g. a tenant), or shared amongst many users/user groups. >>>>=20 >>>>=20 >>>> is there something in the problem statement that leads you to expect= >>>> this problem to be addressed? Even the architecture does not >>>> address this. In fact, as far as I can tell the encapsulation is >>>> unlikely to deal directly with this, as it is a solution property, >>>> not an architectural or protocol property. >>>>=20 >>>> If it's inherently addressed, it would be good to have an idea of how i= t >>>> is addressed in this problem statement. I suspect that is the case and= >>>> would like to know how you establish an isolated user and perhaps say >>>> that this is not part of the problem if it's been solved. Maybe it's >>>> through the encapsulation. Linda responded with some thoughts on >>>> markings for sessions, which makes sense. The solutions may not need t= o >>>> talk about it at all if laid out correctly in this draft, which I >>>> suspect is the case. >>>>=20 >>>> Thank you, >>>> Kathleen >>>>=20 >>>> Sorry if I am being obtuse. >>>> Yours, >>>> Joel >>>>=20 >>>> On 2/13/15 4:44 PM, Kathleen Moriarty wrote: >>>>=20 >>>> Hi Paul, >>>>=20 >>>> On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) >>>> >>>> >> wrote: >>>>=20 >>>> Hi Kathleen, >>>>=20 >>>> We are working my way through the IESG comments, thanks for= >>>> sending >>>> yours! >>>>=20 >>>>=20 >>>> Thank you and sorry for my delay in response. >>>>=20 >>>>=20 >>>> Please see inline. >>>>=20 >>>> Paul >>>>=20 >>>>=20 >>>> > On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty >>>> >>> >>>> >>> >> wrote: >>>> > >>>> > >>>> > >>>> ------------------------------__------------------------------__= ---------- >>>> > DISCUSS: >>>> > >>>> ------------------------------__------------------------------__= ---------- >>>> > >>>> > I didn't see any mention of risks with multiple tenants >>>> and shared >>>> > infrastructure for service functions, is that a concern? >>>> This >>>> > consideration may fall into the same description as the >>>> second point from >>>> > Ben's SecDir review (linked in Stephen's review). >>>> Although the SecDir >>>> > review point could be within a single tenant environment >>>> where there may >>>> > or may not be various levels of trust depending on access= >>>> constraints (to >>>> > the same or different set of applications for a single >>>> tenant). I'd like >>>> > to make sure both points get addressed or if someone can >>>> tell me why it >>>> > doesn't matter, that would be fine too. >>>>=20 >>>>=20 >>>> Is this problem addressed by SFC encapsulation? Doe it somehow >>>> mark the >>>> sessions to ensure the streams as it goes through service chains= is >>>> following the chain for that specific service and instance of th= at >>>> service that might be tenant specific? I'd like to see some >>>> language >>>> added on this topic. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>>=20 >>>> Best regards, >>>> Kathleen >>=20 From nobody Sat Feb 14 08:58:56 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 B95EC1A6F39; Sat, 14 Feb 2015 08:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 fX1H_CxzZpdG; Sat, 14 Feb 2015 08:58:48 -0800 (PST) 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 6836B1A6EED; Sat, 14 Feb 2015 08:58:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4D0C81C0370; Sat, 14 Feb 2015 08:58:48 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-240.clppva.east.verizon.net [70.106.135.240]) (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 BE3081C0207; Sat, 14 Feb 2015 08:58:46 -0800 (PST) Message-ID: <54DF7EAC.6060003@joelhalpern.com> Date: Sat, 14 Feb 2015 11:58:20 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Kathleen Moriarty References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> <54DE8A41.3090606@joelhalpern.com> <54DE9A3D.1090801@joelhalpern.com> <48BB3B48-CDBA-425D-B4A2-17E53B875E88@gmail.com> <54DED426.80608@joelhalpern.com> <83EF0DDF-77DE-47B7-91D3-AEF7A1D4865D@gmail.com> In-Reply-To: <83EF0DDF-77DE-47B7-91D3-AEF7A1D4865D@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "draft-ietf-sfc-problem-statement@tools.ietf.org" , "sfc@ietf.org" , The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 16:58:50 -0000 That is a very fair request. If one of the authors does not get to it soon, I will send my take on an answer later today. Thank you, Joel On 2/14/15 10:26 AM, Kathleen Moriarty wrote: > Hi Joel, > > Sent from my iPhone > >> On Feb 13, 2015, at 11:50 PM, "Joel M. Halpern" wrote: >> >> For me, the question is which of the following two questions the document is trying to address: >> >> 1) What problems are driving and prompting the effort. This is generally about problems with current tools and techniques. >> >> 2) What problems are likely to come up during the effort, and need to be solved. This would include architectural issues, protocol design constraints, and deployment issues. >> >> I have generally understood working group problem statements to be addressing the first question. It seems that you are looking for a document that covers the second question. > > Nope, just looking for an answer to my question to understand scope. > >> While the two are related, they seem to me to not be the same. Differing understandings of the charter goal will make for rather different expectations of the content of the document. > > Whether or not it goes in the draft, I'd like to understand what the problem statement covers, what is in scope or out of scope and to understand why. It would help to just get an answer to my discuss question whether or not it goes in the draft. Talking around it doesn't help me understand why this does or doesn't belong in the draft. The problem statement covers service chaining through shared infrastructure. If you are deciding how to direct traffic through service chains, I think my question is a fair one and I'd love to get an answer. If it's not in scope, it should be clear why it's not in the draft. > > Thank you, > Kathleen > >> >> Yours, >> Joel >> >>> On 2/13/15 9:32 PM, Kathleen Moriarty wrote: >>> Hi Joel, >>> >>> Sent from my iPhone >>> >>>> On Feb 13, 2015, at 7:43 PM, "Joel M. Halpern" wrote: >>>> >>>> My first reaction is to suggest removing the last sentence you quote. I don't think it matters. The reason I say that is that from what I understand, tenant isolation is not an important part of the problem / driver for the SFC work. Rather, the SFC work can be used to provide tenant isolation if folks choose to do so. >>> >>> That may be fine, but I'd like to understand why it's not a problem in this discussion first. >>> >>> Thanks, >>> Kathleen >>> >>>> >>>> Having said that, I will leave it to the chairs and authors. >>>> >>>> Yours, >>>> Joel >>>> >>>>> On 2/13/15 6:50 PM, Kathleen Moriarty wrote: >>>>> >>>>> >>>>> On Fri, Feb 13, 2015 at 6:35 PM, Joel M. Halpern >>>> > wrote: >>>>> >>>>> I am not sure I understand what the question is about tenant isolation. >>>>> >>>>> Multi-tenant support can be provided in many ways. You can have a >>>>> service chain per tenant. You can have tenant IDs in the metadata, >>>>> use common chains, and separate things on the far end. And there >>>>> are probably more ways. >>>>> >>>>> >>>>> Sure, I'd just like to see a little more text on that. Tenants are >>>>> mentioned in the introduction (1st paragraph), then the term doesn't >>>>> appear again. >>>>> >>>>> The delivery of end-to-end services often require various service >>>>> functions including traditional network service functions (for >>>>> example firewalls and server load balancers), as well as application- >>>>> specific features such as http header manipulation. Service >>>>> functions may be delivered within the context of an isolated user >>>>> (e.g. a tenant), or shared amongst many users/user groups. >>>>> >>>>> >>>>> is there something in the problem statement that leads you to expect >>>>> this problem to be addressed? Even the architecture does not >>>>> address this. In fact, as far as I can tell the encapsulation is >>>>> unlikely to deal directly with this, as it is a solution property, >>>>> not an architectural or protocol property. >>>>> >>>>> If it's inherently addressed, it would be good to have an idea of how it >>>>> is addressed in this problem statement. I suspect that is the case and >>>>> would like to know how you establish an isolated user and perhaps say >>>>> that this is not part of the problem if it's been solved. Maybe it's >>>>> through the encapsulation. Linda responded with some thoughts on >>>>> markings for sessions, which makes sense. The solutions may not need to >>>>> talk about it at all if laid out correctly in this draft, which I >>>>> suspect is the case. >>>>> >>>>> Thank you, >>>>> Kathleen >>>>> >>>>> Sorry if I am being obtuse. >>>>> Yours, >>>>> Joel >>>>> >>>>> On 2/13/15 4:44 PM, Kathleen Moriarty wrote: >>>>> >>>>> Hi Paul, >>>>> >>>>> On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) >>>>> >>>>> >> wrote: >>>>> >>>>> Hi Kathleen, >>>>> >>>>> We are working my way through the IESG comments, thanks for >>>>> sending >>>>> yours! >>>>> >>>>> >>>>> Thank you and sorry for my delay in response. >>>>> >>>>> >>>>> Please see inline. >>>>> >>>>> Paul >>>>> >>>>> >>>>> > On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty >>>>> >>>> >>>>> >>>> >> wrote: >>>>> > >>>>> > >>>>> > >>>>> ------------------------------__------------------------------__---------- >>>>> > DISCUSS: >>>>> > >>>>> ------------------------------__------------------------------__---------- >>>>> > >>>>> > I didn't see any mention of risks with multiple tenants >>>>> and shared >>>>> > infrastructure for service functions, is that a concern? >>>>> This >>>>> > consideration may fall into the same description as the >>>>> second point from >>>>> > Ben's SecDir review (linked in Stephen's review). >>>>> Although the SecDir >>>>> > review point could be within a single tenant environment >>>>> where there may >>>>> > or may not be various levels of trust depending on access >>>>> constraints (to >>>>> > the same or different set of applications for a single >>>>> tenant). I'd like >>>>> > to make sure both points get addressed or if someone can >>>>> tell me why it >>>>> > doesn't matter, that would be fine too. >>>>> >>>>> >>>>> Is this problem addressed by SFC encapsulation? Doe it somehow >>>>> mark the >>>>> sessions to ensure the streams as it goes through service chains is >>>>> following the chain for that specific service and instance of that >>>>> service that might be tenant specific? I'd like to see some >>>>> language >>>>> added on this topic. >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Best regards, >>>>> Kathleen >>> From nobody Sat Feb 14 09:32:20 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB7E1A6FCF; Sat, 14 Feb 2015 09:32:18 -0800 (PST) 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 BxQSeviSrKb9; Sat, 14 Feb 2015 09:32:15 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3131A6FF0; Sat, 14 Feb 2015 09:32:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8289; q=dns/txt; s=iport; t=1423935135; x=1425144735; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2RkLC/a3Cfl2AH+Dbn/MCHmetn05nKMZXl/4ZV0wO6A=; b=MSPO043Au3oH4aQd2rvHWFk65VKm3hUPTXgU0UBc/t/i5381U3rwOc/l njjwo2fNxZZzo9XadbIDgNIxGLNY6SSEyPGXex9KP5ObbqIot3HJSOUun YidHFRUEnXYc/o93DpyEnUh0a2O7zMWkqPF1WZkq7nUZWX8phxhUfrDPx 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AqBQDwhd9U/5BdJa1bgwZSwwcKhXECgQ1DAQEBAQEBfIQMAQEBAwEBAQE3KwkLBQsCAQgSBh4FBAchBgsUAw4CBA4FG4d+AwkIDc4RDYVQAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLDIJDgXczB4MWgRQFhVmJXodvgUaBGIMLiGSGBCKCAhwUgTxvAYEBB4E6AQEB X-IronPort-AV: E=Sophos;i="5.09,577,1418083200"; d="scan'208";a="123605827" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP; 14 Feb 2015 17:32:14 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t1EHWEiC021302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 14 Feb 2015 17:32:14 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Sat, 14 Feb 2015 11:32:14 -0600 From: "Paul Quinn (paulq)" To: "Joel M. Halpern" Thread-Topic: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) Thread-Index: AQHQKrzRZ/IN5VrM6Emtyk3yZjMjpJy+hNMAgDE2z4CAAB75gIAABBEAgAAO/YCAAB5OgIAAJrsAgACxo4CAABmlAP//pOMB Date: Sat, 14 Feb 2015 17:32:13 +0000 Message-ID: References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> <54DE8A41.3090606@joelhalpern.com> <54DE9A3D.1090801@joelhalpern.com> <48BB3B48-CDBA-425D-B4A2-17E53B875E88@gmail.com> <54DED426.80608@joelhalpern.com> <83EF0DDF-77DE-47B7-91D3-AEF7A1D4865D@gmail.com>, <54DF7EAC.6060003@joelhalpern.com> In-Reply-To: <54DF7EAC.6060003@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Kathleen Moriarty , "draft-ietf-sfc-problem-statement@tools.ietf.org" , "sfc@ietf.org" , The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Feb 2015 17:32:18 -0000 I'm on it :). Might be Monday though.=20 > On Feb 14, 2015, at 11:59 AM, Joel M. Halpern wrote= : >=20 > That is a very fair request. If one of the authors does not get to it so= on, I will send my take on an answer later today. > Thank you, > Joel >=20 >> On 2/14/15 10:26 AM, Kathleen Moriarty wrote: >> Hi Joel, >>=20 >> Sent from my iPhone >>=20 >>> On Feb 13, 2015, at 11:50 PM, "Joel M. Halpern" w= rote: >>>=20 >>> For me, the question is which of the following two questions the docume= nt is trying to address: >>>=20 >>> 1) What problems are driving and prompting the effort. This is general= ly about problems with current tools and techniques. >>>=20 >>> 2) What problems are likely to come up during the effort, and need to b= e solved. This would include architectural issues, protocol design constra= ints, and deployment issues. >>>=20 >>> I have generally understood working group problem statements to be addr= essing the first question. It seems that you are looking for a document th= at covers the second question. >>=20 >> Nope, just looking for an answer to my question to understand scope. >>=20 >>> While the two are related, they seem to me to not be the same. Differi= ng understandings of the charter goal will make for rather different expect= ations of the content of the document. >>=20 >> Whether or not it goes in the draft, I'd like to understand what the pro= blem statement covers, what is in scope or out of scope and to understand w= hy. It would help to just get an answer to my discuss question whether or = not it goes in the draft. Talking around it doesn't help me understand why= this does or doesn't belong in the draft. The problem statement covers se= rvice chaining through shared infrastructure. If you are deciding how to d= irect traffic through service chains, I think my question is a fair one and= I'd love to get an answer. If it's not in scope, it should be clear why i= t's not in the draft. >>=20 >> Thank you, >> Kathleen >>=20 >>>=20 >>> Yours, >>> Joel >>>=20 >>>> On 2/13/15 9:32 PM, Kathleen Moriarty wrote: >>>> Hi Joel, >>>>=20 >>>> Sent from my iPhone >>>>=20 >>>>> On Feb 13, 2015, at 7:43 PM, "Joel M. Halpern" = wrote: >>>>>=20 >>>>> My first reaction is to suggest removing the last sentence you quote.= I don't think it matters. The reason I say that is that from what I unde= rstand, tenant isolation is not an important part of the problem / driver f= or the SFC work. Rather, the SFC work can be used to provide tenant isolat= ion if folks choose to do so. >>>>=20 >>>> That may be fine, but I'd like to understand why it's not a problem in= this discussion first. >>>>=20 >>>> Thanks, >>>> Kathleen >>>>=20 >>>>>=20 >>>>> Having said that, I will leave it to the chairs and authors. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>>> On 2/13/15 6:50 PM, Kathleen Moriarty wrote: >>>>>>=20 >>>>>>=20 >>>>>> On Fri, Feb 13, 2015 at 6:35 PM, Joel M. Halpern >>>>> > wrote: >>>>>>=20 >>>>>> I am not sure I understand what the question is about tenant isol= ation. >>>>>>=20 >>>>>> Multi-tenant support can be provided in many ways. You can have = a >>>>>> service chain per tenant. You can have tenant IDs in the metadat= a, >>>>>> use common chains, and separate things on the far end. And there >>>>>> are probably more ways. >>>>>>=20 >>>>>>=20 >>>>>> Sure, I'd just like to see a little more text on that. Tenants are >>>>>> mentioned in the introduction (1st paragraph), then the term doesn't >>>>>> appear again. >>>>>>=20 >>>>>> The delivery of end-to-end services often require various service >>>>>> functions including traditional network service functions (for >>>>>> example firewalls and server load balancers), as well as applicat= ion- >>>>>> specific features such as http header manipulation. Service >>>>>> functions may be delivered within the context of an isolated user >>>>>> (e.g. a tenant), or shared amongst many users/user groups. >>>>>>=20 >>>>>>=20 >>>>>> is there something in the problem statement that leads you to exp= ect >>>>>> this problem to be addressed? Even the architecture does not >>>>>> address this. In fact, as far as I can tell the encapsulation is >>>>>> unlikely to deal directly with this, as it is a solution property= , >>>>>> not an architectural or protocol property. >>>>>>=20 >>>>>> If it's inherently addressed, it would be good to have an idea of ho= w it >>>>>> is addressed in this problem statement. I suspect that is the case = and >>>>>> would like to know how you establish an isolated user and perhaps sa= y >>>>>> that this is not part of the problem if it's been solved. Maybe it'= s >>>>>> through the encapsulation. Linda responded with some thoughts on >>>>>> markings for sessions, which makes sense. The solutions may not nee= d to >>>>>> talk about it at all if laid out correctly in this draft, which I >>>>>> suspect is the case. >>>>>>=20 >>>>>> Thank you, >>>>>> Kathleen >>>>>>=20 >>>>>> Sorry if I am being obtuse. >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>> On 2/13/15 4:44 PM, Kathleen Moriarty wrote: >>>>>>=20 >>>>>> Hi Paul, >>>>>>=20 >>>>>> On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) >>>>>> >>>>>> >> wrote: >>>>>>=20 >>>>>> Hi Kathleen, >>>>>>=20 >>>>>> We are working my way through the IESG comments, thanks = for >>>>>> sending >>>>>> yours! >>>>>>=20 >>>>>>=20 >>>>>> Thank you and sorry for my delay in response. >>>>>>=20 >>>>>>=20 >>>>>> Please see inline. >>>>>>=20 >>>>>> Paul >>>>>>=20 >>>>>>=20 >>>>>> > On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty >>>>>> >>>>> >>>>>> >>>>> >> wrote: >>>>>> > >>>>>> > >>>>>> > >>>>>> ------------------------------__-----------------------------= -__---------- >>>>>> > DISCUSS: >>>>>> > >>>>>> ------------------------------__-----------------------------= -__---------- >>>>>> > >>>>>> > I didn't see any mention of risks with multiple tenant= s >>>>>> and shared >>>>>> > infrastructure for service functions, is that a concer= n? >>>>>> This >>>>>> > consideration may fall into the same description as th= e >>>>>> second point from >>>>>> > Ben's SecDir review (linked in Stephen's review). >>>>>> Although the SecDir >>>>>> > review point could be within a single tenant environme= nt >>>>>> where there may >>>>>> > or may not be various levels of trust depending on acc= ess >>>>>> constraints (to >>>>>> > the same or different set of applications for a single >>>>>> tenant). I'd like >>>>>> > to make sure both points get addressed or if someone c= an >>>>>> tell me why it >>>>>> > doesn't matter, that would be fine too. >>>>>>=20 >>>>>>=20 >>>>>> Is this problem addressed by SFC encapsulation? Doe it someh= ow >>>>>> mark the >>>>>> sessions to ensure the streams as it goes through service cha= ins is >>>>>> following the chain for that specific service and instance of= that >>>>>> service that might be tenant specific? I'd like to see some >>>>>> language >>>>>> added on this topic. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>>=20 >>>>>> Best regards, >>>>>> Kathleen >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Sun Feb 15 02:14:00 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 8AC2D1A1AA7; Sun, 15 Feb 2015 02:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1jI-jHTQrLr; Sun, 15 Feb 2015 02:13:45 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C521A03AA; Sun, 15 Feb 2015 02:13:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPH44964; Sun, 15 Feb 2015 10:13:42 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sun, 15 Feb 2015 10:13:40 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Sun, 15 Feb 2015 18:13:33 +0800 From: Xuxiaohu To: "Joel M. Halpern" , Kathleen Moriarty Thread-Topic: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) Thread-Index: AQHQKrzRZ/IN5VrM6Emtyk3yZjMjpJy+hNMAgDBMHYCAAB76gIACxtWw Date: Sun, 15 Feb 2015 10:13:34 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08306CF4@NKGEML512-MBS.china.huawei.com> References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> <54DE8A41.3090606@joelhalpern.com> In-Reply-To: <54DE8A41.3090606@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: The IESG , "draft-ietf-sfc-problem-statement@tools.ietf.org" , "sfc@ietf.org" , "sfc-chairs@tools.ietf.org" Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) 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, 15 Feb 2015 10:13:47 -0000 Hi Joel, You have raised a very interesting point. In the MPLS/BGP IP VPN case, if w= e choose to contain tenant ID in the metadata and use common chains identif= ied by the NSH, where should the egress PE's address and the VPN label assi= gned by the PE address be located in the data packet if the NSH is imposed = on the original IP packet (i.e., customer packet)? Otherwise, if the NSH is= imposed on the encapsulated VPN packet (e.g., IP-in-MPLS-in-GRE-in-IP), sh= ould the intermediate SFFs or SFs be capable of decapsulating the encapsula= ted VPN packet? Best regards, Xiaohu > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Saturday, February 14, 2015 7:35 AM > To: Kathleen Moriarty > Cc: sfc-chairs@tools.ietf.org; draft-ietf-sfc-problem-statement@tools.iet= f.org; > sfc@ietf.org; The IESG > Subject: Re: [sfc] Kathleen Moriarty's Discuss on > draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) >=20 > I am not sure I understand what the question is about tenant isolation. >=20 > Multi-tenant support can be provided in many ways. You can have a servic= e > chain per tenant. You can have tenant IDs in the metadata, use common ch= ains, > and separate things on the far end. And there are probably more ways. >=20 > is there something in the problem statement that leads you to expect this > problem to be addressed? Even the architecture does not address this. I= n > fact, as far as I can tell the encapsulation is unlikely to deal directly= with this, as it > is a solution property, not an architectural or protocol property. >=20 > Sorry if I am being obtuse. > Yours, > Joel >=20 > On 2/13/15 4:44 PM, Kathleen Moriarty wrote: > > Hi Paul, > > > > On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) > > wrote: > > > > Hi Kathleen, > > > > We are working my way through the IESG comments, thanks for sending > > yours! > > > > > > Thank you and sorry for my delay in response. > > > > > > Please see inline. > > > > Paul > > > > > > > On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty > > > wrote: > > > > > > > > > -----------------------------------------------------------------= ----- > > > DISCUSS: > > > -----------------------------------------------------------------= ----- > > > > > > I didn't see any mention of risks with multiple tenants and share= d > > > infrastructure for service functions, is that a concern? This > > > consideration may fall into the same description as the second po= int > from > > > Ben's SecDir review (linked in Stephen's review). Although the Se= cDir > > > review point could be within a single tenant environment where th= ere > may > > > or may not be various levels of trust depending on access constra= ints > (to > > > the same or different set of applications for a single tenant). = I'd like > > > to make sure both points get addressed or if someone can tell me = why > it > > > doesn't matter, that would be fine too. > > > > > > Is this problem addressed by SFC encapsulation? Doe it somehow mark > > the sessions to ensure the streams as it goes through service chains > > is following the chain for that specific service and instance of that > > service that might be tenant specific? I'd like to see some language > > added on this topic. >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Feb 16 04:56: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 C180A1A1AF1; Mon, 16 Feb 2015 04:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-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 VQB7VIzaEOn6; Mon, 16 Feb 2015 04:56:11 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 08D701A1AD0; Mon, 16 Feb 2015 04:56:11 -0800 (PST) Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 6E33C2E9E4B6; Mon, 16 Feb 2015 07:56:10 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Thomas D. Nadeau" In-Reply-To: <54DE9A3D.1090801@joelhalpern.com> Date: Mon, 16 Feb 2015 07:56:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <54182DC7-F0F6-484F-9F25-CCAD3F15ADEC@lucidvision.com> References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> <54DE8A41.3090606@joelhalpern.com> <54DE9A3D.1090801@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Kathleen Moriarty , "sfc-chairs@tools.ietf.org" , "draft-ietf-sfc-problem-statement@tools.ietf.org" , "sfc@ietf.org" , The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) 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, 16 Feb 2015 12:56:12 -0000 I agree. Like any other networking technology, it can be = associated with a tenant but that is really unrelated to the tech.=20 --Tom > On Feb 13, 2015:7:43 PM, at 7:43 PM, Joel M. Halpern = wrote: >=20 > My first reaction is to suggest removing the last sentence you quote. = I don't think it matters. The reason I say that is that from what I = understand, tenant isolation is not an important part of the problem / = driver for the SFC work. Rather, the SFC work can be used to provide = tenant isolation if folks choose to do so. >=20 > Having said that, I will leave it to the chairs and authors. >=20 > Yours, > Joel >=20 > On 2/13/15 6:50 PM, Kathleen Moriarty wrote: >>=20 >>=20 >> On Fri, Feb 13, 2015 at 6:35 PM, Joel M. Halpern > > wrote: >>=20 >> I am not sure I understand what the question is about tenant = isolation. >>=20 >> Multi-tenant support can be provided in many ways. You can have a >> service chain per tenant. You can have tenant IDs in the = metadata, >> use common chains, and separate things on the far end. And there >> are probably more ways. >>=20 >>=20 >> Sure, I'd just like to see a little more text on that. Tenants are >> mentioned in the introduction (1st paragraph), then the term doesn't >> appear again. >>=20 >> The delivery of end-to-end services often require various service >> functions including traditional network service functions (for >> example firewalls and server load balancers), as well as = application- >> specific features such as http header manipulation. Service >> functions may be delivered within the context of an isolated user >> (e.g. a tenant), or shared amongst many users/user groups. >>=20 >>=20 >> is there something in the problem statement that leads you to = expect >> this problem to be addressed? Even the architecture does not >> address this. In fact, as far as I can tell the encapsulation is >> unlikely to deal directly with this, as it is a solution property, >> not an architectural or protocol property. >>=20 >> If it's inherently addressed, it would be good to have an idea of how = it >> is addressed in this problem statement. I suspect that is the case = and >> would like to know how you establish an isolated user and perhaps say >> that this is not part of the problem if it's been solved. Maybe it's >> through the encapsulation. Linda responded with some thoughts on >> markings for sessions, which makes sense. The solutions may not need = to >> talk about it at all if laid out correctly in this draft, which I >> suspect is the case. >>=20 >> Thank you, >> Kathleen >>=20 >> Sorry if I am being obtuse. >> Yours, >> Joel >>=20 >> On 2/13/15 4:44 PM, Kathleen Moriarty wrote: >>=20 >> Hi Paul, >>=20 >> On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) >> >> >> wrote: >>=20 >> Hi Kathleen, >>=20 >> We are working my way through the IESG comments, thanks = for >> sending >> yours! >>=20 >>=20 >> Thank you and sorry for my delay in response. >>=20 >>=20 >> Please see inline. >>=20 >> Paul >>=20 >>=20 >> > On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty >> > >> > >> wrote: >> > >> > >> > >> = ------------------------------__------------------------------__----------= >> > DISCUSS: >> > >> = ------------------------------__------------------------------__----------= >> > >> > I didn't see any mention of risks with multiple tenants >> and shared >> > infrastructure for service functions, is that a = concern? >> This >> > consideration may fall into the same description as the >> second point from >> > Ben's SecDir review (linked in Stephen's review). >> Although the SecDir >> > review point could be within a single tenant = environment >> where there may >> > or may not be various levels of trust depending on = access >> constraints (to >> > the same or different set of applications for a single >> tenant). I'd like >> > to make sure both points get addressed or if someone = can >> tell me why it >> > doesn't matter, that would be fine too. >>=20 >>=20 >> Is this problem addressed by SFC encapsulation? Doe it = somehow >> mark the >> sessions to ensure the streams as it goes through service = chains is >> following the chain for that specific service and instance of = that >> service that might be tenant specific? I'd like to see some >> language >> added on this topic. >>=20 >>=20 >>=20 >>=20 >> -- >>=20 >> Best regards, >> Kathleen >=20 From nobody Mon Feb 16 04:57: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 D1C991A1AF1; Mon, 16 Feb 2015 04:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.895 X-Spam-Level: X-Spam-Status: No, score=0.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-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 Guemi5OM9N-U; Mon, 16 Feb 2015 04:57:48 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD961A1ADC; Mon, 16 Feb 2015 04:57:47 -0800 (PST) Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 6DF312E9E523; Mon, 16 Feb 2015 07:57:47 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Thomas D. Nadeau" In-Reply-To: <48BB3B48-CDBA-425D-B4A2-17E53B875E88@gmail.com> Date: Mon, 16 Feb 2015 07:57:47 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1C109B46-BF14-43A3-89CC-4A582DF9599E@lucidvision.com> References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> <54DE8A41.3090606@joelhalpern.com> <54DE9A3D.1090801@joelhalpern.com> <48BB3B48-CDBA-425D-B4A2-17E53B875E88@gmail.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "Joel M. Halpern" , "sfc-chairs@tools.ietf.org" , "draft-ietf-sfc-problem-statement@tools.ietf.org" , "sfc@ietf.org" , The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) 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, 16 Feb 2015 12:57:50 -0000 The text says that it "can" be provided in many ways. It does = not say that it is intrinsic to the tech. All that its saying is that = you can do this if you want, and that is perhaps something people might = want to do. --Tom > On Feb 13, 2015:9:32 PM, at 9:32 PM, Kathleen Moriarty = wrote: >=20 > Hi Joel, >=20 > Sent from my iPhone >=20 >> On Feb 13, 2015, at 7:43 PM, "Joel M. Halpern" = wrote: >>=20 >> My first reaction is to suggest removing the last sentence you quote. = I don't think it matters. The reason I say that is that from what I = understand, tenant isolation is not an important part of the problem / = driver for the SFC work. Rather, the SFC work can be used to provide = tenant isolation if folks choose to do so. >=20 > That may be fine, but I'd like to understand why it's not a problem in = this discussion first. >=20 > Thanks, > Kathleen >=20 >>=20 >> Having said that, I will leave it to the chairs and authors. >>=20 >> Yours, >> Joel >>=20 >>> On 2/13/15 6:50 PM, Kathleen Moriarty wrote: >>>=20 >>>=20 >>> On Fri, Feb 13, 2015 at 6:35 PM, Joel M. Halpern = >> > wrote: >>>=20 >>> I am not sure I understand what the question is about tenant = isolation. >>>=20 >>> Multi-tenant support can be provided in many ways. You can have a >>> service chain per tenant. You can have tenant IDs in the = metadata, >>> use common chains, and separate things on the far end. And there >>> are probably more ways. >>>=20 >>>=20 >>> Sure, I'd just like to see a little more text on that. Tenants are >>> mentioned in the introduction (1st paragraph), then the term doesn't >>> appear again. >>>=20 >>> The delivery of end-to-end services often require various service >>> functions including traditional network service functions (for >>> example firewalls and server load balancers), as well as = application- >>> specific features such as http header manipulation. Service >>> functions may be delivered within the context of an isolated user >>> (e.g. a tenant), or shared amongst many users/user groups. >>>=20 >>>=20 >>> is there something in the problem statement that leads you to = expect >>> this problem to be addressed? Even the architecture does not >>> address this. In fact, as far as I can tell the encapsulation is >>> unlikely to deal directly with this, as it is a solution property, >>> not an architectural or protocol property. >>>=20 >>> If it's inherently addressed, it would be good to have an idea of = how it >>> is addressed in this problem statement. I suspect that is the case = and >>> would like to know how you establish an isolated user and perhaps = say >>> that this is not part of the problem if it's been solved. Maybe = it's >>> through the encapsulation. Linda responded with some thoughts on >>> markings for sessions, which makes sense. The solutions may not = need to >>> talk about it at all if laid out correctly in this draft, which I >>> suspect is the case. >>>=20 >>> Thank you, >>> Kathleen >>>=20 >>> Sorry if I am being obtuse. >>> Yours, >>> Joel >>>=20 >>> On 2/13/15 4:44 PM, Kathleen Moriarty wrote: >>>=20 >>> Hi Paul, >>>=20 >>> On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) >>> >>> >> wrote: >>>=20 >>> Hi Kathleen, >>>=20 >>> We are working my way through the IESG comments, thanks = for >>> sending >>> yours! >>>=20 >>>=20 >>> Thank you and sorry for my delay in response. >>>=20 >>>=20 >>> Please see inline. >>>=20 >>> Paul >>>=20 >>>=20 >>>> On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty >>> >> >>> >> >> wrote: >>>>=20 >>>>=20 >>>>=20 >>> = ------------------------------__------------------------------__----------= >>>> DISCUSS: >>>>=20 >>> = ------------------------------__------------------------------__----------= >>>>=20 >>>> I didn't see any mention of risks with multiple tenants >>> and shared >>>> infrastructure for service functions, is that a concern? >>> This >>>> consideration may fall into the same description as the >>> second point from >>>> Ben's SecDir review (linked in Stephen's review). >>> Although the SecDir >>>> review point could be within a single tenant environment >>> where there may >>>> or may not be various levels of trust depending on access >>> constraints (to >>>> the same or different set of applications for a single >>> tenant). I'd like >>>> to make sure both points get addressed or if someone can >>> tell me why it >>>> doesn't matter, that would be fine too. >>>=20 >>>=20 >>> Is this problem addressed by SFC encapsulation? Doe it = somehow >>> mark the >>> sessions to ensure the streams as it goes through service = chains is >>> following the chain for that specific service and instance of = that >>> service that might be tenant specific? I'd like to see some >>> language >>> added on this topic. >>>=20 >>>=20 >>>=20 >>>=20 >>> -- >>>=20 >>> Best regards, >>> Kathleen >=20 From nobody Mon Feb 16 06:52:24 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2671A1B0D; Mon, 16 Feb 2015 06:52:21 -0800 (PST) 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 lJX7_h2n_y-f; Mon, 16 Feb 2015 06:52:14 -0800 (PST) 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 641D61A1B88; Mon, 16 Feb 2015 06:52:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8310; q=dns/txt; s=iport; t=1424098334; x=1425307934; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aBLshVnsDDWtLmkr0kHMFaq6slKAAOzCidPyTPvalF0=; b=QfZXAy6CzjtvByKvWk/0fTES9GLbbP+GsSBQ0elYpdnQv6nOv4dsaHWe uk/NMt/cEsi74tDrsemu9y4YdAFFVmOH3OjbcWWQWFOSZnBksgthW4cAl kiS03hb422pIWEL/uEtJ9e4Ya9Y5d2FlVLO2/JelzTh+IaS0cXW5ADFYY M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmYFAOsC4lStJA2J/2dsb2JhbABcgwZSWgSCf8UrAhx4QwEBAQEBAXyEDAEBAQMBIxExFAULAgEIEgYCAh8EAwICAh8RFAECDgIEDgUbh34DCQi2IpEVDYVGAQEBAQEBAQEBAQEBAQEBAQEBARmBIYlrgkOBdzMHgmgugRQFhVqJXodxgUaBGIMNiGSGBCKCAhwUgTxvAYFDfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,588,1418083200"; d="scan'208";a="396584740" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP; 16 Feb 2015 14:52:13 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1GEqDT5014698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Feb 2015 14:52:13 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 08:52:13 -0600 From: "Paul Quinn (paulq)" To: "Joel M. Halpern" Thread-Topic: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) Thread-Index: AQHQKrzRZ/IN5VrM6Emtyk3yZjMjpJy+hNMAgDE2z4CAAB75gIAABBEAgAAO/YCABBG7gA== Date: Mon, 16 Feb 2015 14:52:12 +0000 Message-ID: <6DB46289-CDB0-46F9-AA34-348A9AB77C8E@cisco.com> References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> <54DE8A41.3090606@joelhalpern.com> <54DE9A3D.1090801@joelhalpern.com> In-Reply-To: <54DE9A3D.1090801@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Kathleen Moriarty , "sfc-chairs@tools.ietf.org" , "draft-ietf-sfc-problem-statement@tools.ietf.org" , "sfc@ietf.org" , The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) 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, 16 Feb 2015 14:52:21 -0000 SGksDQoNCkluIGdlbmVyYWwgU0ZDIGRvZXNu4oCZdCBjaGFuZ2UgdGhlIHNlY3VyaXR5IHBvc3R1 cmUgd3J0IHRlbmFuY3ksIHNvIEkgdGVuZCB0byBhZ3JlZSB3aXRoIEpvZWw6IGxldOKAmXMgcmVt b3ZlIHRoZSBzZW50ZW5jZSB0aGF0IGFkZCBjb25mdXNpb24uDQoNClRoZXJl4oCZcyBubyBpbXBs aWNhdGlvbiB0aGF0IHRoZSBTRkMgZW5jYXAgd2lsbCBwcm92aWRlIHRlbmFudCBpbmZvcm1hdGlv biBvciBpc29sYXRpb24gKGFsdGhvdWdoIGluIG1hbnkgY2FzZXMgSSBzdXNwZWN0IGl0IG1pZ2h0 IGNhcnJ5IHNvbWUgZm9ybSBvZiB0ZW5hbnQgSUQpLiAgSWYgdGhlcmXigJlzIGEgbmVlZCBmb3Ig dHJhbnNwb3J0IGlzb2xhdGlvbiwgdGhlbiB0aGUgbmV0d29yayB0cmFuc3BvcnQgbXVzdCBwcm92 aWRlIGl0LCBhcyBpdCBtdXN0IHRvZGF5LiAgDQoNCklmIHRoZSBXRyBhZ3JlZXMsIEnigJltIGZp bmUgd2l0aCBhIHNpbXBsZSBjbGFyaWZ5aW5nIHN0YXRlbWVudCwgc29tZXRoaW5nIGFsb25nIHRo ZSBsaW5lcyBvZg0KDQrigJxJZiB0ZW5hbnQgaXNvbGF0aW9uIGlzIHJlcXVpcmVkIGluIGFuIFNG QyBkZXBsb3ltZW50LCBhbiBhcHByb3ByaWF0ZSBuZXR3b3JrIHRyYW5zcG9ydCBvdmVybGF5IHRo YXQgcHJvdmlkZXMgYWRlcXVhdGUgaXNvbGF0aW9uIGFuZCBpZGVudGlmaWNhdGlvbiBjYW4gYmUg dXNlZC4gIEFkZGl0aW9uYWxseSwgdGVuYW5jeSBtaWdodCBiZSB1c2VkIGluIHRoZSBzZWxlY3Rp b24gb2YgdGhlIGFwcHJvcHJpYXRlIHNlcnZpY2UgY2hhaW4sIGhvd2V2ZXIsIGFzIHN0YXRlZCwg dGhlIG5ldHdvcmsgb3ZlcmxheSBpcyBzdGlsbCByZXF1aXJlZCB0byBwcm92aWRlIHRyYW5zcG9y dCBpc29sYXRpb24uICBTRiBkZXBsb3ltZW50IGFuZCBob3cgc3BlY2lmaWMgU0ZzIG1pZ2h0IG9y IG1pZ2h0IG5vdCBiZSBhbGxvY2F0ZWQgcGVyIHRlbmFudCBpcyBvdXRzaWRlIHRoZSBzY29wZSBv ZiB0aGlzIGRvY3VtZW50LiINCg0KDQo+IE9uIEZlYiAxMywgMjAxNSwgYXQgNzo0MyBQTSwgSm9l bCBNLiBIYWxwZXJuIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4gDQo+IE15IGZpcnN0 IHJlYWN0aW9uIGlzIHRvIHN1Z2dlc3QgcmVtb3ZpbmcgdGhlIGxhc3Qgc2VudGVuY2UgeW91IHF1 b3RlLiAgSSBkb24ndCB0aGluayBpdCBtYXR0ZXJzLiAgVGhlIHJlYXNvbiBJIHNheSB0aGF0IGlz IHRoYXQgZnJvbSB3aGF0IEkgdW5kZXJzdGFuZCwgdGVuYW50IGlzb2xhdGlvbiBpcyBub3QgYW4g aW1wb3J0YW50IHBhcnQgb2YgdGhlIHByb2JsZW0gLyBkcml2ZXIgZm9yIHRoZSBTRkMgd29yay4g IFJhdGhlciwgdGhlIFNGQyB3b3JrIGNhbiBiZSB1c2VkIHRvIHByb3ZpZGUgdGVuYW50IGlzb2xh dGlvbiBpZiBmb2xrcyBjaG9vc2UgdG8gZG8gc28uDQo+IA0KPiBIYXZpbmcgc2FpZCB0aGF0LCBJ IHdpbGwgbGVhdmUgaXQgdG8gdGhlIGNoYWlycyBhbmQgYXV0aG9ycy4NCj4gDQo+IFlvdXJzLA0K PiBKb2VsDQo+IA0KPiBPbiAyLzEzLzE1IDY6NTAgUE0sIEthdGhsZWVuIE1vcmlhcnR5IHdyb3Rl Og0KPj4gDQo+PiANCj4+IE9uIEZyaSwgRmViIDEzLCAyMDE1IGF0IDY6MzUgUE0sIEpvZWwgTS4g SGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbQ0KPj4gPG1haWx0bzpqbWhAam9lbGhhbHBlcm4u Y29tPj4gd3JvdGU6DQo+PiANCj4+ICAgIEkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHdoYXQg dGhlIHF1ZXN0aW9uIGlzIGFib3V0IHRlbmFudCBpc29sYXRpb24uDQo+PiANCj4+ICAgIE11bHRp LXRlbmFudCBzdXBwb3J0IGNhbiBiZSBwcm92aWRlZCBpbiBtYW55IHdheXMuICBZb3UgY2FuIGhh dmUgYQ0KPj4gICAgc2VydmljZSBjaGFpbiBwZXIgdGVuYW50LiAgWW91IGNhbiBoYXZlIHRlbmFu dCBJRHMgaW4gdGhlIG1ldGFkYXRhLA0KPj4gICAgdXNlIGNvbW1vbiBjaGFpbnMsIGFuZCBzZXBh cmF0ZSB0aGluZ3Mgb24gdGhlIGZhciBlbmQuICBBbmQgdGhlcmUNCj4+ICAgIGFyZSBwcm9iYWJs eSBtb3JlIHdheXMuDQo+PiANCj4+IA0KPj4gU3VyZSwgSSdkIGp1c3QgbGlrZSB0byBzZWUgYSBs aXR0bGUgbW9yZSB0ZXh0IG9uIHRoYXQuICBUZW5hbnRzIGFyZQ0KPj4gbWVudGlvbmVkIGluIHRo ZSBpbnRyb2R1Y3Rpb24gKDFzdCBwYXJhZ3JhcGgpLCB0aGVuIHRoZSB0ZXJtIGRvZXNuJ3QNCj4+ IGFwcGVhciBhZ2Fpbi4NCj4+IA0KPj4gICAgVGhlIGRlbGl2ZXJ5IG9mIGVuZC10by1lbmQgc2Vy dmljZXMgb2Z0ZW4gcmVxdWlyZSB2YXJpb3VzIHNlcnZpY2UNCj4+ICAgIGZ1bmN0aW9ucyBpbmNs dWRpbmcgdHJhZGl0aW9uYWwgbmV0d29yayBzZXJ2aWNlIGZ1bmN0aW9ucyAoZm9yDQo+PiAgICBl eGFtcGxlIGZpcmV3YWxscyBhbmQgc2VydmVyIGxvYWQgYmFsYW5jZXJzKSwgYXMgd2VsbCBhcyBh cHBsaWNhdGlvbi0NCj4+ICAgIHNwZWNpZmljIGZlYXR1cmVzIHN1Y2ggYXMgaHR0cCBoZWFkZXIg bWFuaXB1bGF0aW9uLiAgU2VydmljZQ0KPj4gICAgZnVuY3Rpb25zIG1heSBiZSBkZWxpdmVyZWQg d2l0aGluIHRoZSBjb250ZXh0IG9mIGFuIGlzb2xhdGVkIHVzZXINCj4+ICAgIChlLmcuIGEgdGVu YW50KSwgb3Igc2hhcmVkIGFtb25nc3QgbWFueSB1c2Vycy91c2VyIGdyb3Vwcy4NCj4+IA0KPj4g DQo+PiAgICBpcyB0aGVyZSBzb21ldGhpbmcgaW4gdGhlIHByb2JsZW0gc3RhdGVtZW50IHRoYXQg bGVhZHMgeW91IHRvIGV4cGVjdA0KPj4gICAgdGhpcyBwcm9ibGVtIHRvIGJlIGFkZHJlc3NlZD8g IEV2ZW4gdGhlIGFyY2hpdGVjdHVyZSBkb2VzIG5vdA0KPj4gICAgYWRkcmVzcyB0aGlzLiAgSW4g ZmFjdCwgYXMgZmFyIGFzIEkgY2FuIHRlbGwgdGhlIGVuY2Fwc3VsYXRpb24gaXMNCj4+ICAgIHVu bGlrZWx5IHRvIGRlYWwgZGlyZWN0bHkgd2l0aCB0aGlzLCBhcyBpdCBpcyBhIHNvbHV0aW9uIHBy b3BlcnR5LA0KPj4gICAgbm90IGFuIGFyY2hpdGVjdHVyYWwgb3IgcHJvdG9jb2wgcHJvcGVydHku DQo+PiANCj4+IElmIGl0J3MgaW5oZXJlbnRseSBhZGRyZXNzZWQsIGl0IHdvdWxkIGJlIGdvb2Qg dG8gaGF2ZSBhbiBpZGVhIG9mIGhvdyBpdA0KPj4gaXMgYWRkcmVzc2VkIGluIHRoaXMgcHJvYmxl bSBzdGF0ZW1lbnQuICBJIHN1c3BlY3QgdGhhdCBpcyB0aGUgY2FzZSBhbmQNCj4+IHdvdWxkIGxp a2UgdG8ga25vdyBob3cgeW91IGVzdGFibGlzaCBhbiBpc29sYXRlZCB1c2VyIGFuZCBwZXJoYXBz IHNheQ0KPj4gdGhhdCB0aGlzIGlzIG5vdCBwYXJ0IG9mIHRoZSBwcm9ibGVtIGlmIGl0J3MgYmVl biBzb2x2ZWQuICBNYXliZSBpdCdzDQo+PiB0aHJvdWdoIHRoZSBlbmNhcHN1bGF0aW9uLiAgTGlu ZGEgcmVzcG9uZGVkIHdpdGggc29tZSB0aG91Z2h0cyBvbg0KPj4gbWFya2luZ3MgZm9yIHNlc3Np b25zLCB3aGljaCBtYWtlcyBzZW5zZS4gIFRoZSBzb2x1dGlvbnMgbWF5IG5vdCBuZWVkIHRvDQo+ PiB0YWxrIGFib3V0IGl0IGF0IGFsbCBpZiBsYWlkIG91dCBjb3JyZWN0bHkgaW4gdGhpcyBkcmFm dCwgd2hpY2ggSQ0KPj4gc3VzcGVjdCBpcyB0aGUgY2FzZS4NCj4+IA0KPj4gVGhhbmsgeW91LA0K Pj4gS2F0aGxlZW4NCj4+IA0KPj4gICAgU29ycnkgaWYgSSBhbSBiZWluZyBvYnR1c2UuDQo+PiAg ICBZb3VycywNCj4+ICAgIEpvZWwNCj4+IA0KPj4gICAgT24gMi8xMy8xNSA0OjQ0IFBNLCBLYXRo bGVlbiBNb3JpYXJ0eSB3cm90ZToNCj4+IA0KPj4gICAgICAgIEhpIFBhdWwsDQo+PiANCj4+ICAg ICAgICBPbiBUdWUsIEphbiAxMywgMjAxNSBhdCA5OjExIEFNLCBQYXVsIFF1aW5uIChwYXVscSkN Cj4+ICAgICAgICA8cGF1bHFAY2lzY28uY29tIDxtYWlsdG86cGF1bHFAY2lzY28uY29tPg0KPj4g ICAgICAgIDxtYWlsdG86cGF1bHFAY2lzY28uY29tIDxtYWlsdG86cGF1bHFAY2lzY28uY29tPj4+ IHdyb3RlOg0KPj4gDQo+PiAgICAgICAgICAgICBIaSBLYXRobGVlbiwNCj4+IA0KPj4gICAgICAg ICAgICAgV2UgYXJlIHdvcmtpbmcgbXkgd2F5IHRocm91Z2ggdGhlIElFU0cgY29tbWVudHMsIHRo YW5rcyBmb3INCj4+ICAgICAgICBzZW5kaW5nDQo+PiAgICAgICAgICAgICB5b3VycyENCj4+IA0K Pj4gDQo+PiAgICAgICAgVGhhbmsgeW91IGFuZCBzb3JyeSBmb3IgbXkgZGVsYXkgaW4gcmVzcG9u c2UuDQo+PiANCj4+IA0KPj4gICAgICAgICAgICAgUGxlYXNlIHNlZSBpbmxpbmUuDQo+PiANCj4+ ICAgICAgICAgICAgIFBhdWwNCj4+IA0KPj4gDQo+PiAgICAgICAgICAgICA+IE9uIEphbiA3LCAy MDE1LCBhdCAzOjU4IFBNLCBLYXRobGVlbiBNb3JpYXJ0eQ0KPj4gICAgICAgIDxrYXRobGVlbi5t b3JpYXJ0eS5pZXRmQGdtYWlsLl9fY29tDQo+PiAgICAgICAgPG1haWx0bzprYXRobGVlbi5tb3Jp YXJ0eS5pZXRmQGdtYWlsLmNvbT4NCj4+ICAgICAgICAgICAgIDxtYWlsdG86a2F0aGxlZW4ubW9y aWFydHkuX19pZXRmQGdtYWlsLmNvbQ0KPj4gICAgICAgIDxtYWlsdG86a2F0aGxlZW4ubW9yaWFy dHkuaWV0ZkBnbWFpbC5jb20+Pj4gd3JvdGU6DQo+PiAgICAgICAgICAgICA+DQo+PiAgICAgICAg ICAgICA+DQo+PiAgICAgICAgICAgICA+DQo+PiAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tX18tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1fXy0tLS0tLS0tLS0NCj4+ ICAgICAgICAgICAgID4gRElTQ1VTUzoNCj4+ICAgICAgICAgICAgID4NCj4+ICAgICAgICAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1fXy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LV9fLS0tLS0tLS0tLQ0KPj4gICAgICAgICAgICAgPg0KPj4gICAgICAgICAgICAgPiBJIGRpZG4n dCBzZWUgYW55IG1lbnRpb24gb2Ygcmlza3Mgd2l0aCBtdWx0aXBsZSB0ZW5hbnRzDQo+PiAgICAg ICAgYW5kIHNoYXJlZA0KPj4gICAgICAgICAgICAgPiBpbmZyYXN0cnVjdHVyZSBmb3Igc2Vydmlj ZSBmdW5jdGlvbnMsIGlzIHRoYXQgYSBjb25jZXJuPw0KPj4gICAgICAgIFRoaXMNCj4+ICAgICAg ICAgICAgID4gY29uc2lkZXJhdGlvbiBtYXkgZmFsbCBpbnRvIHRoZSBzYW1lIGRlc2NyaXB0aW9u IGFzIHRoZQ0KPj4gICAgICAgIHNlY29uZCBwb2ludCBmcm9tDQo+PiAgICAgICAgICAgICA+IEJl bidzIFNlY0RpciByZXZpZXcgKGxpbmtlZCBpbiBTdGVwaGVuJ3MgcmV2aWV3KS4NCj4+ICAgICAg ICBBbHRob3VnaCB0aGUgU2VjRGlyDQo+PiAgICAgICAgICAgICA+IHJldmlldyBwb2ludCBjb3Vs ZCBiZSB3aXRoaW4gYSBzaW5nbGUgdGVuYW50IGVudmlyb25tZW50DQo+PiAgICAgICAgd2hlcmUg dGhlcmUgbWF5DQo+PiAgICAgICAgICAgICA+IG9yIG1heSBub3QgYmUgdmFyaW91cyBsZXZlbHMg b2YgdHJ1c3QgZGVwZW5kaW5nIG9uIGFjY2Vzcw0KPj4gICAgICAgIGNvbnN0cmFpbnRzICh0bw0K Pj4gICAgICAgICAgICAgPiB0aGUgc2FtZSBvciBkaWZmZXJlbnQgc2V0IG9mIGFwcGxpY2F0aW9u cyBmb3IgYSBzaW5nbGUNCj4+ICAgICAgICB0ZW5hbnQpLiAgSSdkIGxpa2UNCj4+ICAgICAgICAg ICAgID4gdG8gbWFrZSBzdXJlIGJvdGggcG9pbnRzIGdldCBhZGRyZXNzZWQgb3IgaWYgc29tZW9u ZSBjYW4NCj4+ICAgICAgICB0ZWxsIG1lIHdoeSBpdA0KPj4gICAgICAgICAgICAgPiBkb2Vzbid0 IG1hdHRlciwgdGhhdCB3b3VsZCBiZSBmaW5lIHRvby4NCj4+IA0KPj4gDQo+PiAgICAgICAgSXMg dGhpcyBwcm9ibGVtIGFkZHJlc3NlZCBieSBTRkMgZW5jYXBzdWxhdGlvbj8gIERvZSBpdCBzb21l aG93DQo+PiAgICAgICAgbWFyayB0aGUNCj4+ICAgICAgICBzZXNzaW9ucyB0byBlbnN1cmUgdGhl IHN0cmVhbXMgYXMgaXQgZ29lcyB0aHJvdWdoIHNlcnZpY2UgY2hhaW5zIGlzDQo+PiAgICAgICAg Zm9sbG93aW5nIHRoZSBjaGFpbiBmb3IgdGhhdCBzcGVjaWZpYyBzZXJ2aWNlIGFuZCBpbnN0YW5j ZSBvZiB0aGF0DQo+PiAgICAgICAgc2VydmljZSB0aGF0IG1pZ2h0IGJlIHRlbmFudCBzcGVjaWZp Yz8gIEknZCBsaWtlIHRvIHNlZSBzb21lDQo+PiAgICAgICAgbGFuZ3VhZ2UNCj4+ICAgICAgICBh ZGRlZCBvbiB0aGlzIHRvcGljLg0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiAtLQ0KPj4gDQo+PiBC ZXN0IHJlZ2FyZHMsDQo+PiBLYXRobGVlbg0KDQo= From nobody Mon Feb 16 07:02:25 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 86FC11A1BC9; Mon, 16 Feb 2015 07:02:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAcafU8vaxKL; Mon, 16 Feb 2015 07:02:13 -0800 (PST) Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) (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 F20FE1A1B88; Mon, 16 Feb 2015 07:02:12 -0800 (PST) Received: by labgq15 with SMTP id gq15so29512841lab.6; Mon, 16 Feb 2015 07:02:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OZF9PjNpkOkybbPpvorMcWpt23qGsiA/lApPEeMTSJw=; b=NqQC4eRBoktkPtiUEDKhY72iABbVF6h3iPexts0Es10f51OAFEvNtOBu+AMN1zynVn CE9OUROpf7aDFMoJr1+OR/qu8vvYSY+DyVbqIX3vbvmftudtD7O6V/RCMPw0oFIVvWrJ erVhWFcNuMTn5E7GX9C5LqOuIzygBgr27KDYW8vkr0ll75Enwa6fhzwHUGCwuYIDNRJM QebHF70goz9R3c0k/eP8VzyTBVfCkUPrIpAEbz2wojLw7ueyd6rDaUR2Ka1Hi3rsZpP2 WzfxfOW8QCyOJYftf1CM2+DkKCCQ+jnm7gPvnl0j+57E00YL/D6dFykMjtCdL8KSw4pi BLQw== MIME-Version: 1.0 X-Received: by 10.152.207.100 with SMTP id lv4mr17880023lac.4.1424098931451; Mon, 16 Feb 2015 07:02:11 -0800 (PST) Received: by 10.112.167.101 with HTTP; Mon, 16 Feb 2015 07:02:11 -0800 (PST) In-Reply-To: <6DB46289-CDB0-46F9-AA34-348A9AB77C8E@cisco.com> References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> <54DE8A41.3090606@joelhalpern.com> <54DE9A3D.1090801@joelhalpern.com> <6DB46289-CDB0-46F9-AA34-348A9AB77C8E@cisco.com> Date: Mon, 16 Feb 2015 10:02:11 -0500 Message-ID: From: Kathleen Moriarty To: "Paul Quinn (paulq)" Content-Type: multipart/alternative; boundary=001a113470a8ef2d43050f35de65 Archived-At: Cc: "Joel M. Halpern" , "sfc-chairs@tools.ietf.org" , "draft-ietf-sfc-problem-statement@tools.ietf.org" , "sfc@ietf.org" , The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) 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, 16 Feb 2015 15:02:17 -0000 --001a113470a8ef2d43050f35de65 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paul, On Mon, Feb 16, 2015 at 9:52 AM, Paul Quinn (paulq) wrote= : > Hi, > > In general SFC doesn=E2=80=99t change the security posture wrt tenancy, s= o I tend > to agree with Joel: let=E2=80=99s remove the sentence that add confusion. > > There=E2=80=99s no implication that the SFC encap will provide tenant inf= ormation > or isolation (although in many cases I suspect it might carry some form o= f > tenant ID). If there=E2=80=99s a need for transport isolation, then the = network > transport must provide it, as it must today. > > If the WG agrees, I=E2=80=99m fine with a simple clarifying statement, so= mething > along the lines of > > =E2=80=9CIf tenant isolation is required in an SFC deployment, an appropr= iate > network transport overlay that provides adequate isolation and > identification can be used. Additionally, tenancy might be used in the > selection of the appropriate service chain, however, as stated, the netwo= rk > overlay is still required to provide transport isolation. SF deployment > and how specific SFs might or might not be allocated per tenant is outsid= e > the scope of this document." > Thank you. I think this text is very helpful to understand the scope of the problem and what SFC will and will not address. It's a good clarifying statement. Thanks, Kathleen > > > > On Feb 13, 2015, at 7:43 PM, Joel M. Halpern > wrote: > > > > My first reaction is to suggest removing the last sentence you quote. = I > don't think it matters. The reason I say that is that from what I > understand, tenant isolation is not an important part of the problem / > driver for the SFC work. Rather, the SFC work can be used to provide > tenant isolation if folks choose to do so. > > > > Having said that, I will leave it to the chairs and authors. > > > > Yours, > > Joel > > > > On 2/13/15 6:50 PM, Kathleen Moriarty wrote: > >> > >> > >> On Fri, Feb 13, 2015 at 6:35 PM, Joel M. Halpern >> > wrote: > >> > >> I am not sure I understand what the question is about tenant > isolation. > >> > >> Multi-tenant support can be provided in many ways. You can have a > >> service chain per tenant. You can have tenant IDs in the metadata, > >> use common chains, and separate things on the far end. And there > >> are probably more ways. > >> > >> > >> Sure, I'd just like to see a little more text on that. Tenants are > >> mentioned in the introduction (1st paragraph), then the term doesn't > >> appear again. > >> > >> The delivery of end-to-end services often require various service > >> functions including traditional network service functions (for > >> example firewalls and server load balancers), as well as applicatio= n- > >> specific features such as http header manipulation. Service > >> functions may be delivered within the context of an isolated user > >> (e.g. a tenant), or shared amongst many users/user groups. > >> > >> > >> is there something in the problem statement that leads you to expec= t > >> this problem to be addressed? Even the architecture does not > >> address this. In fact, as far as I can tell the encapsulation is > >> unlikely to deal directly with this, as it is a solution property, > >> not an architectural or protocol property. > >> > >> If it's inherently addressed, it would be good to have an idea of how = it > >> is addressed in this problem statement. I suspect that is the case an= d > >> would like to know how you establish an isolated user and perhaps say > >> that this is not part of the problem if it's been solved. Maybe it's > >> through the encapsulation. Linda responded with some thoughts on > >> markings for sessions, which makes sense. The solutions may not need = to > >> talk about it at all if laid out correctly in this draft, which I > >> suspect is the case. > >> > >> Thank you, > >> Kathleen > >> > >> Sorry if I am being obtuse. > >> Yours, > >> Joel > >> > >> On 2/13/15 4:44 PM, Kathleen Moriarty wrote: > >> > >> Hi Paul, > >> > >> On Tue, Jan 13, 2015 at 9:11 AM, Paul Quinn (paulq) > >> > >> >> wrote: > >> > >> Hi Kathleen, > >> > >> We are working my way through the IESG comments, thanks fo= r > >> sending > >> yours! > >> > >> > >> Thank you and sorry for my delay in response. > >> > >> > >> Please see inline. > >> > >> Paul > >> > >> > >> > On Jan 7, 2015, at 3:58 PM, Kathleen Moriarty > >> >> > >> >> >> wrote: > >> > > >> > > >> > > >> > ------------------------------__------------------------------__---------= - > >> > DISCUSS: > >> > > >> > ------------------------------__------------------------------__---------= - > >> > > >> > I didn't see any mention of risks with multiple tenants > >> and shared > >> > infrastructure for service functions, is that a concern? > >> This > >> > consideration may fall into the same description as the > >> second point from > >> > Ben's SecDir review (linked in Stephen's review). > >> Although the SecDir > >> > review point could be within a single tenant environment > >> where there may > >> > or may not be various levels of trust depending on acces= s > >> constraints (to > >> > the same or different set of applications for a single > >> tenant). I'd like > >> > to make sure both points get addressed or if someone can > >> tell me why it > >> > doesn't matter, that would be fine too. > >> > >> > >> Is this problem addressed by SFC encapsulation? Doe it somehow > >> mark the > >> sessions to ensure the streams as it goes through service chain= s > is > >> following the chain for that specific service and instance of > that > >> service that might be tenant specific? I'd like to see some > >> language > >> added on this topic. > >> > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > > --=20 Best regards, Kathleen --001a113470a8ef2d43050f35de65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Paul,

On Mon, Feb 16, 2015 at 9:52 AM, Paul Quinn (paulq) = <paulq@cisco.com> wrote:
Hi,

In general SFC doesn=E2=80=99t change the security posture wrt tenancy, so = I tend to agree with Joel: let=E2=80=99s remove the sentence that add confu= sion.

There=E2=80=99s no implication that the SFC encap will provide tenant infor= mation or isolation (although in many cases I suspect it might carry some f= orm of tenant ID).=C2=A0 If there=E2=80=99s a need for transport isolation,= then the network transport must provide it, as it must today.

If the WG agrees, I=E2=80=99m fine with a simple clarifying statement, some= thing along the lines of

=E2=80=9CIf tenant isolation is required in an SFC deployment, an appropria= te network transport overlay that provides adequate isolation and identific= ation can be used.=C2=A0 Additionally, tenancy might be used in the selecti= on of the appropriate service chain, however, as stated, the network overla= y is still required to provide transport isolation.=C2=A0 SF deployment and= how specific SFs might or might not be allocated per tenant is outside the= scope of this document."

Thank yo= u.=C2=A0 I think this text is very helpful to understand the scope of the p= roblem and what SFC will and will not address.=C2=A0 It's a good clarif= ying statement.

Thanks,
Kathleen=C2=A0


> On Feb 13, 2015, at 7:43 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>
> My first reaction is to suggest removing the last sentence you quote.= =C2=A0 I don't think it matters.=C2=A0 The reason I say that is that fr= om what I understand, tenant isolation is not an important part of the prob= lem / driver for the SFC work.=C2=A0 Rather, the SFC work can be used to pr= ovide tenant isolation if folks choose to do so.
>
> Having said that, I will leave it to the chairs and authors.
>
> Yours,
> Joel
>
> On 2/13/15 6:50 PM, Kathleen Moriarty wrote:
>>
>>
>> On Fri, Feb 13, 2015 at 6:35 PM, Joel M. Halpern <jmh@joelhalpern.com
>> <mailto:jmh@joelhalpern.= com>> wrote:
>>
>>=C2=A0 =C2=A0 I am not sure I understand what the question is about= tenant isolation.
>>
>>=C2=A0 =C2=A0 Multi-tenant support can be provided in many ways.=C2= =A0 You can have a
>>=C2=A0 =C2=A0 service chain per tenant.=C2=A0 You can have tenant I= Ds in the metadata,
>>=C2=A0 =C2=A0 use common chains, and separate things on the far end= .=C2=A0 And there
>>=C2=A0 =C2=A0 are probably more ways.
>>
>>
>> Sure, I'd just like to see a little more text on that.=C2=A0 T= enants are
>> mentioned in the introduction (1st paragraph), then the term doesn= 't
>> appear again.
>>
>>=C2=A0 =C2=A0 The delivery of end-to-end services often require var= ious service
>>=C2=A0 =C2=A0 functions including traditional network service funct= ions (for
>>=C2=A0 =C2=A0 example firewalls and server load balancers), as well= as application-
>>=C2=A0 =C2=A0 specific features such as http header manipulation.= =C2=A0 Service
>>=C2=A0 =C2=A0 functions may be delivered within the context of an i= solated user
>>=C2=A0 =C2=A0 (e.g. a tenant), or shared amongst many users/user gr= oups.
>>
>>
>>=C2=A0 =C2=A0 is there something in the problem statement that lead= s you to expect
>>=C2=A0 =C2=A0 this problem to be addressed?=C2=A0 Even the architec= ture does not
>>=C2=A0 =C2=A0 address this.=C2=A0 In fact, as far as I can tell the= encapsulation is
>>=C2=A0 =C2=A0 unlikely to deal directly with this, as it is a solut= ion property,
>>=C2=A0 =C2=A0 not an architectural or protocol property.
>>
>> If it's inherently addressed, it would be good to have an idea= of how it
>> is addressed in this problem statement.=C2=A0 I suspect that is th= e case and
>> would like to know how you establish an isolated user and perhaps = say
>> that this is not part of the problem if it's been solved.=C2= =A0 Maybe it's
>> through the encapsulation.=C2=A0 Linda responded with some thought= s on
>> markings for sessions, which makes sense.=C2=A0 The solutions may = not need to
>> talk about it at all if laid out correctly in this draft, which I<= br> >> suspect is the case.
>>
>> Thank you,
>> Kathleen
>>
>>=C2=A0 =C2=A0 Sorry if I am being obtuse.
>>=C2=A0 =C2=A0 Yours,
>>=C2=A0 =C2=A0 Joel
>>
>>=C2=A0 =C2=A0 On 2/13/15 4:44 PM, Kathleen Moriarty wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi Paul,
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Tue, Jan 13, 2015 at 9:11 AM, Paul Q= uinn (paulq)
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <= paulq@cisco.com <mailto:paulq@cis= co.com>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:paulq@cisco.com <mailto:pa= ulq@cisco.com>>> wrote:
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Kathleen,
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We are working my w= ay through the IESG comments, thanks for
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 sending
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yours!
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thank you and sorry for my delay in res= ponse.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Please see inline.<= br> >>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Paul
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> On Jan 7, 2015= , at 3:58 PM, Kathleen Moriarty
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <kathleen.moriarty.ietf@gmail.__com<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:kathleen.moriarty.ietf@gmail.com>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<mailto:kathleen.moriarty.__ietf@gma= il.com
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:kathleen.moriarty.ietf@gmail.com>>> wr= ote:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ------------------------------__-------= -----------------------__----------
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> DISCUSS:
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ------------------------------__-------= -----------------------__----------
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I didn't s= ee any mention of risks with multiple tenants
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 and shared
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> infrastructure= for service functions, is that a concern?
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 This
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> consideration = may fall into the same description as the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 second point from
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Ben's SecD= ir review (linked in Stephen's review).
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Although the SecDir
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> review point c= ould be within a single tenant environment
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 where there may
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> or may not be = various levels of trust depending on access
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 constraints (to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> the same or di= fferent set of applications for a single
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 tenant).=C2=A0 I'd like
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> to make sure b= oth points get addressed or if someone can
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 tell me why it
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> doesn't ma= tter, that would be fine too.
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Is this problem addressed by SFC encaps= ulation?=C2=A0 Doe it somehow
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 mark the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 sessions to ensure the streams as it go= es through service chains is
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 following the chain for that specific s= ervice and instance of that
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 service that might be tenant specific?= =C2=A0 I'd like to see some
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 language
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 added on this topic.
>>
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen




--
=

Best regards,
Kathleen
--001a113470a8ef2d43050f35de65-- From nobody Mon Feb 16 07:17:22 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 916101A1BBB; Mon, 16 Feb 2015 07:17:04 -0800 (PST) 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 CmAAXvDAFVqD; Mon, 16 Feb 2015 07:16:49 -0800 (PST) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2AEE1A1EB7; Mon, 16 Feb 2015 07:16:49 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0224.002; Mon, 16 Feb 2015 07:16:49 -0800 From: Ron Parker To: "Paul Quinn (paulq)" , "Joel M. Halpern" Thread-Topic: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) Thread-Index: AQHQR+9aKsau+DB+vUK93sW5AIlLT5zz5ogA//+AQwA= Date: Mon, 16 Feb 2015 15:16:48 +0000 Message-ID: References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> <54DE8A41.3090606@joelhalpern.com> <54DE9A3D.1090801@joelhalpern.com> <6DB46289-CDB0-46F9-AA34-348A9AB77C8E@cisco.com> In-Reply-To: <6DB46289-CDB0-46F9-AA34-348A9AB77C8E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: The IESG , Kathleen Moriarty , "draft-ietf-sfc-problem-statement@tools.ietf.org" , "sfc@ietf.org" , "sfc-chairs@tools.ietf.org" Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) 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, 16 Feb 2015 15:17:07 -0000 SGksIFBhdWwuDQoNCllvdXIgcHJvcG9zZWQgdGV4dCBsb29rcyBnb29kIHRvIG1lLiAgIEl0IGlz IHZlcnkgY2xlYXIgYWJvdXQgaG93IFNGQyBkZWFscyB3aXRoIHRlbmFuY3kgYW5kIGlzb2xhdGlv biBpc3N1ZXMuDQoNCkthdGhsZWVuLCB0aGlzIHdhcyBhIHZlcnkgdXNlZnVsIGRpc2N1c3Npb24u ICAgVGhhbmtzIGZvciBicmluZ2luZyBpdCB1cC4NCg0KICAgUm9uDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgUGF1bCBRdWlubiAocGF1bHEpDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDE2 LCAyMDE1IDk6NTIgQU0NClRvOiBKb2VsIE0uIEhhbHBlcm4NCkNjOiBLYXRobGVlbiBNb3JpYXJ0 eTsgc2ZjLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0 ZW1lbnRAdG9vbHMuaWV0Zi5vcmc7IHNmY0BpZXRmLm9yZzsgVGhlIElFU0cNClN1YmplY3Q6IFJl OiBbc2ZjXSBLYXRobGVlbiBNb3JpYXJ0eSdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1zZmMtcHJv YmxlbS1zdGF0ZW1lbnQtMTA6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1FTlQpDQoNCkhpLA0KDQpJ biBnZW5lcmFsIFNGQyBkb2VzbuKAmXQgY2hhbmdlIHRoZSBzZWN1cml0eSBwb3N0dXJlIHdydCB0 ZW5hbmN5LCBzbyBJIHRlbmQgdG8gYWdyZWUgd2l0aCBKb2VsOiBsZXTigJlzIHJlbW92ZSB0aGUg c2VudGVuY2UgdGhhdCBhZGQgY29uZnVzaW9uLg0KDQpUaGVyZeKAmXMgbm8gaW1wbGljYXRpb24g dGhhdCB0aGUgU0ZDIGVuY2FwIHdpbGwgcHJvdmlkZSB0ZW5hbnQgaW5mb3JtYXRpb24gb3IgaXNv bGF0aW9uIChhbHRob3VnaCBpbiBtYW55IGNhc2VzIEkgc3VzcGVjdCBpdCBtaWdodCBjYXJyeSBz b21lIGZvcm0gb2YgdGVuYW50IElEKS4gIElmIHRoZXJl4oCZcyBhIG5lZWQgZm9yIHRyYW5zcG9y dCBpc29sYXRpb24sIHRoZW4gdGhlIG5ldHdvcmsgdHJhbnNwb3J0IG11c3QgcHJvdmlkZSBpdCwg YXMgaXQgbXVzdCB0b2RheS4gIA0KDQpJZiB0aGUgV0cgYWdyZWVzLCBJ4oCZbSBmaW5lIHdpdGgg YSBzaW1wbGUgY2xhcmlmeWluZyBzdGF0ZW1lbnQsIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMg b2YNCg0K4oCcSWYgdGVuYW50IGlzb2xhdGlvbiBpcyByZXF1aXJlZCBpbiBhbiBTRkMgZGVwbG95 bWVudCwgYW4gYXBwcm9wcmlhdGUgbmV0d29yayB0cmFuc3BvcnQgb3ZlcmxheSB0aGF0IHByb3Zp ZGVzIGFkZXF1YXRlIGlzb2xhdGlvbiBhbmQgaWRlbnRpZmljYXRpb24gY2FuIGJlIHVzZWQuICBB ZGRpdGlvbmFsbHksIHRlbmFuY3kgbWlnaHQgYmUgdXNlZCBpbiB0aGUgc2VsZWN0aW9uIG9mIHRo ZSBhcHByb3ByaWF0ZSBzZXJ2aWNlIGNoYWluLCBob3dldmVyLCBhcyBzdGF0ZWQsIHRoZSBuZXR3 b3JrIG92ZXJsYXkgaXMgc3RpbGwgcmVxdWlyZWQgdG8gcHJvdmlkZSB0cmFuc3BvcnQgaXNvbGF0 aW9uLiAgU0YgZGVwbG95bWVudCBhbmQgaG93IHNwZWNpZmljIFNGcyBtaWdodCBvciBtaWdodCBu b3QgYmUgYWxsb2NhdGVkIHBlciB0ZW5hbnQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBk b2N1bWVudC4iDQoNCg0KPiBPbiBGZWIgMTMsIDIwMTUsIGF0IDc6NDMgUE0sIEpvZWwgTS4gSGFs cGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+IA0KPiBNeSBmaXJzdCByZWFjdGlv biBpcyB0byBzdWdnZXN0IHJlbW92aW5nIHRoZSBsYXN0IHNlbnRlbmNlIHlvdSBxdW90ZS4gIEkg ZG9uJ3QgdGhpbmsgaXQgbWF0dGVycy4gIFRoZSByZWFzb24gSSBzYXkgdGhhdCBpcyB0aGF0IGZy b20gd2hhdCBJIHVuZGVyc3RhbmQsIHRlbmFudCBpc29sYXRpb24gaXMgbm90IGFuIGltcG9ydGFu dCBwYXJ0IG9mIHRoZSBwcm9ibGVtIC8gZHJpdmVyIGZvciB0aGUgU0ZDIHdvcmsuICBSYXRoZXIs IHRoZSBTRkMgd29yayBjYW4gYmUgdXNlZCB0byBwcm92aWRlIHRlbmFudCBpc29sYXRpb24gaWYg Zm9sa3MgY2hvb3NlIHRvIGRvIHNvLg0KPiANCj4gSGF2aW5nIHNhaWQgdGhhdCwgSSB3aWxsIGxl YXZlIGl0IHRvIHRoZSBjaGFpcnMgYW5kIGF1dGhvcnMuDQo+IA0KPiBZb3VycywNCj4gSm9lbA0K PiANCj4gT24gMi8xMy8xNSA2OjUwIFBNLCBLYXRobGVlbiBNb3JpYXJ0eSB3cm90ZToNCj4+IA0K Pj4gDQo+PiBPbiBGcmksIEZlYiAxMywgMjAxNSBhdCA2OjM1IFBNLCBKb2VsIE0uIEhhbHBlcm4g PGptaEBqb2VsaGFscGVybi5jb20gDQo+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20+PiB3 cm90ZToNCj4+IA0KPj4gICAgSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2hhdCB0aGUgcXVl c3Rpb24gaXMgYWJvdXQgdGVuYW50IGlzb2xhdGlvbi4NCj4+IA0KPj4gICAgTXVsdGktdGVuYW50 IHN1cHBvcnQgY2FuIGJlIHByb3ZpZGVkIGluIG1hbnkgd2F5cy4gIFlvdSBjYW4gaGF2ZSBhDQo+ PiAgICBzZXJ2aWNlIGNoYWluIHBlciB0ZW5hbnQuICBZb3UgY2FuIGhhdmUgdGVuYW50IElEcyBp biB0aGUgbWV0YWRhdGEsDQo+PiAgICB1c2UgY29tbW9uIGNoYWlucywgYW5kIHNlcGFyYXRlIHRo aW5ncyBvbiB0aGUgZmFyIGVuZC4gIEFuZCB0aGVyZQ0KPj4gICAgYXJlIHByb2JhYmx5IG1vcmUg d2F5cy4NCj4+IA0KPj4gDQo+PiBTdXJlLCBJJ2QganVzdCBsaWtlIHRvIHNlZSBhIGxpdHRsZSBt b3JlIHRleHQgb24gdGhhdC4gIFRlbmFudHMgYXJlIA0KPj4gbWVudGlvbmVkIGluIHRoZSBpbnRy b2R1Y3Rpb24gKDFzdCBwYXJhZ3JhcGgpLCB0aGVuIHRoZSB0ZXJtIGRvZXNuJ3QgDQo+PiBhcHBl YXIgYWdhaW4uDQo+PiANCj4+ICAgIFRoZSBkZWxpdmVyeSBvZiBlbmQtdG8tZW5kIHNlcnZpY2Vz IG9mdGVuIHJlcXVpcmUgdmFyaW91cyBzZXJ2aWNlDQo+PiAgICBmdW5jdGlvbnMgaW5jbHVkaW5n IHRyYWRpdGlvbmFsIG5ldHdvcmsgc2VydmljZSBmdW5jdGlvbnMgKGZvcg0KPj4gICAgZXhhbXBs ZSBmaXJld2FsbHMgYW5kIHNlcnZlciBsb2FkIGJhbGFuY2VycyksIGFzIHdlbGwgYXMgYXBwbGlj YXRpb24tDQo+PiAgICBzcGVjaWZpYyBmZWF0dXJlcyBzdWNoIGFzIGh0dHAgaGVhZGVyIG1hbmlw dWxhdGlvbi4gIFNlcnZpY2UNCj4+ICAgIGZ1bmN0aW9ucyBtYXkgYmUgZGVsaXZlcmVkIHdpdGhp biB0aGUgY29udGV4dCBvZiBhbiBpc29sYXRlZCB1c2VyDQo+PiAgICAoZS5nLiBhIHRlbmFudCks IG9yIHNoYXJlZCBhbW9uZ3N0IG1hbnkgdXNlcnMvdXNlciBncm91cHMuDQo+PiANCj4+IA0KPj4g ICAgaXMgdGhlcmUgc29tZXRoaW5nIGluIHRoZSBwcm9ibGVtIHN0YXRlbWVudCB0aGF0IGxlYWRz IHlvdSB0byBleHBlY3QNCj4+ICAgIHRoaXMgcHJvYmxlbSB0byBiZSBhZGRyZXNzZWQ/ICBFdmVu IHRoZSBhcmNoaXRlY3R1cmUgZG9lcyBub3QNCj4+ICAgIGFkZHJlc3MgdGhpcy4gIEluIGZhY3Qs IGFzIGZhciBhcyBJIGNhbiB0ZWxsIHRoZSBlbmNhcHN1bGF0aW9uIGlzDQo+PiAgICB1bmxpa2Vs eSB0byBkZWFsIGRpcmVjdGx5IHdpdGggdGhpcywgYXMgaXQgaXMgYSBzb2x1dGlvbiBwcm9wZXJ0 eSwNCj4+ICAgIG5vdCBhbiBhcmNoaXRlY3R1cmFsIG9yIHByb3RvY29sIHByb3BlcnR5Lg0KPj4g DQo+PiBJZiBpdCdzIGluaGVyZW50bHkgYWRkcmVzc2VkLCBpdCB3b3VsZCBiZSBnb29kIHRvIGhh dmUgYW4gaWRlYSBvZiBob3cgDQo+PiBpdCBpcyBhZGRyZXNzZWQgaW4gdGhpcyBwcm9ibGVtIHN0 YXRlbWVudC4gIEkgc3VzcGVjdCB0aGF0IGlzIHRoZSANCj4+IGNhc2UgYW5kIHdvdWxkIGxpa2Ug dG8ga25vdyBob3cgeW91IGVzdGFibGlzaCBhbiBpc29sYXRlZCB1c2VyIGFuZCANCj4+IHBlcmhh cHMgc2F5IHRoYXQgdGhpcyBpcyBub3QgcGFydCBvZiB0aGUgcHJvYmxlbSBpZiBpdCdzIGJlZW4g c29sdmVkLiAgDQo+PiBNYXliZSBpdCdzIHRocm91Z2ggdGhlIGVuY2Fwc3VsYXRpb24uICBMaW5k YSByZXNwb25kZWQgd2l0aCBzb21lIA0KPj4gdGhvdWdodHMgb24gbWFya2luZ3MgZm9yIHNlc3Np b25zLCB3aGljaCBtYWtlcyBzZW5zZS4gIFRoZSBzb2x1dGlvbnMgDQo+PiBtYXkgbm90IG5lZWQg dG8gdGFsayBhYm91dCBpdCBhdCBhbGwgaWYgbGFpZCBvdXQgY29ycmVjdGx5IGluIHRoaXMgDQo+ PiBkcmFmdCwgd2hpY2ggSSBzdXNwZWN0IGlzIHRoZSBjYXNlLg0KPj4gDQo+PiBUaGFuayB5b3Us DQo+PiBLYXRobGVlbg0KPj4gDQo+PiAgICBTb3JyeSBpZiBJIGFtIGJlaW5nIG9idHVzZS4NCj4+ ICAgIFlvdXJzLA0KPj4gICAgSm9lbA0KPj4gDQo+PiAgICBPbiAyLzEzLzE1IDQ6NDQgUE0sIEth dGhsZWVuIE1vcmlhcnR5IHdyb3RlOg0KPj4gDQo+PiAgICAgICAgSGkgUGF1bCwNCj4+IA0KPj4g ICAgICAgIE9uIFR1ZSwgSmFuIDEzLCAyMDE1IGF0IDk6MTEgQU0sIFBhdWwgUXVpbm4gKHBhdWxx KQ0KPj4gICAgICAgIDxwYXVscUBjaXNjby5jb20gPG1haWx0bzpwYXVscUBjaXNjby5jb20+DQo+ PiAgICAgICAgPG1haWx0bzpwYXVscUBjaXNjby5jb20gPG1haWx0bzpwYXVscUBjaXNjby5jb20+ Pj4gd3JvdGU6DQo+PiANCj4+ICAgICAgICAgICAgIEhpIEthdGhsZWVuLA0KPj4gDQo+PiAgICAg ICAgICAgICBXZSBhcmUgd29ya2luZyBteSB3YXkgdGhyb3VnaCB0aGUgSUVTRyBjb21tZW50cywg dGhhbmtzIGZvcg0KPj4gICAgICAgIHNlbmRpbmcNCj4+ICAgICAgICAgICAgIHlvdXJzIQ0KPj4g DQo+PiANCj4+ICAgICAgICBUaGFuayB5b3UgYW5kIHNvcnJ5IGZvciBteSBkZWxheSBpbiByZXNw b25zZS4NCj4+IA0KPj4gDQo+PiAgICAgICAgICAgICBQbGVhc2Ugc2VlIGlubGluZS4NCj4+IA0K Pj4gICAgICAgICAgICAgUGF1bA0KPj4gDQo+PiANCj4+ICAgICAgICAgICAgID4gT24gSmFuIDcs IDIwMTUsIGF0IDM6NTggUE0sIEthdGhsZWVuIE1vcmlhcnR5DQo+PiAgICAgICAgPGthdGhsZWVu Lm1vcmlhcnR5LmlldGZAZ21haWwuX19jb20NCj4+ICAgICAgICA8bWFpbHRvOmthdGhsZWVuLm1v cmlhcnR5LmlldGZAZ21haWwuY29tPg0KPj4gICAgICAgICAgICAgPG1haWx0bzprYXRobGVlbi5t b3JpYXJ0eS5fX2lldGZAZ21haWwuY29tDQo+PiAgICAgICAgPG1haWx0bzprYXRobGVlbi5tb3Jp YXJ0eS5pZXRmQGdtYWlsLmNvbT4+PiB3cm90ZToNCj4+ICAgICAgICAgICAgID4NCj4+ICAgICAg ICAgICAgID4NCj4+ICAgICAgICAgICAgID4NCj4+ICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS1fXy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLV9fLS0tLS0tLS0tLQ0K Pj4gICAgICAgICAgICAgPiBESVNDVVNTOg0KPj4gICAgICAgICAgICAgPg0KPj4gICAgICAgIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLV9fLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tX18tLS0tLS0tLS0tDQo+PiAgICAgICAgICAgICA+DQo+PiAgICAgICAgICAgICA+IEkgZGlk bid0IHNlZSBhbnkgbWVudGlvbiBvZiByaXNrcyB3aXRoIG11bHRpcGxlIHRlbmFudHMNCj4+ICAg ICAgICBhbmQgc2hhcmVkDQo+PiAgICAgICAgICAgICA+IGluZnJhc3RydWN0dXJlIGZvciBzZXJ2 aWNlIGZ1bmN0aW9ucywgaXMgdGhhdCBhIGNvbmNlcm4/DQo+PiAgICAgICAgVGhpcw0KPj4gICAg ICAgICAgICAgPiBjb25zaWRlcmF0aW9uIG1heSBmYWxsIGludG8gdGhlIHNhbWUgZGVzY3JpcHRp b24gYXMgdGhlDQo+PiAgICAgICAgc2Vjb25kIHBvaW50IGZyb20NCj4+ICAgICAgICAgICAgID4g QmVuJ3MgU2VjRGlyIHJldmlldyAobGlua2VkIGluIFN0ZXBoZW4ncyByZXZpZXcpLg0KPj4gICAg ICAgIEFsdGhvdWdoIHRoZSBTZWNEaXINCj4+ICAgICAgICAgICAgID4gcmV2aWV3IHBvaW50IGNv dWxkIGJlIHdpdGhpbiBhIHNpbmdsZSB0ZW5hbnQgZW52aXJvbm1lbnQNCj4+ICAgICAgICB3aGVy ZSB0aGVyZSBtYXkNCj4+ICAgICAgICAgICAgID4gb3IgbWF5IG5vdCBiZSB2YXJpb3VzIGxldmVs cyBvZiB0cnVzdCBkZXBlbmRpbmcgb24gYWNjZXNzDQo+PiAgICAgICAgY29uc3RyYWludHMgKHRv DQo+PiAgICAgICAgICAgICA+IHRoZSBzYW1lIG9yIGRpZmZlcmVudCBzZXQgb2YgYXBwbGljYXRp b25zIGZvciBhIHNpbmdsZQ0KPj4gICAgICAgIHRlbmFudCkuICBJJ2QgbGlrZQ0KPj4gICAgICAg ICAgICAgPiB0byBtYWtlIHN1cmUgYm90aCBwb2ludHMgZ2V0IGFkZHJlc3NlZCBvciBpZiBzb21l b25lIGNhbg0KPj4gICAgICAgIHRlbGwgbWUgd2h5IGl0DQo+PiAgICAgICAgICAgICA+IGRvZXNu J3QgbWF0dGVyLCB0aGF0IHdvdWxkIGJlIGZpbmUgdG9vLg0KPj4gDQo+PiANCj4+ICAgICAgICBJ cyB0aGlzIHByb2JsZW0gYWRkcmVzc2VkIGJ5IFNGQyBlbmNhcHN1bGF0aW9uPyAgRG9lIGl0IHNv bWVob3cNCj4+ICAgICAgICBtYXJrIHRoZQ0KPj4gICAgICAgIHNlc3Npb25zIHRvIGVuc3VyZSB0 aGUgc3RyZWFtcyBhcyBpdCBnb2VzIHRocm91Z2ggc2VydmljZSBjaGFpbnMgaXMNCj4+ICAgICAg ICBmb2xsb3dpbmcgdGhlIGNoYWluIGZvciB0aGF0IHNwZWNpZmljIHNlcnZpY2UgYW5kIGluc3Rh bmNlIG9mIHRoYXQNCj4+ICAgICAgICBzZXJ2aWNlIHRoYXQgbWlnaHQgYmUgdGVuYW50IHNwZWNp ZmljPyAgSSdkIGxpa2UgdG8gc2VlIHNvbWUNCj4+ICAgICAgICBsYW5ndWFnZQ0KPj4gICAgICAg IGFkZGVkIG9uIHRoaXMgdG9waWMuDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IC0tDQo+PiANCj4+ IEJlc3QgcmVnYXJkcywNCj4+IEthdGhsZWVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpzZmMgbWFpbGluZyBsaXN0DQpzZmNAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo= From nobody Mon Feb 16 07:41: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 4E3991A1B6B; Mon, 16 Feb 2015 07:41:24 -0800 (PST) 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 qORIwJrr8dTj; Mon, 16 Feb 2015 07:41:17 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD091A1DE1; Mon, 16 Feb 2015 07:40:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9566; q=dns/txt; s=iport; t=1424101237; x=1425310837; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9ivIjNJKNfaJbSSb+gXmXQSb5oVE1CPDdbqI+KNdVaI=; b=SeF9Zc5sjDhGAJKb42lPkw4GcQJRSfiw/4wLEpR2kBBUBlv/nV8NUm5E gH1bB89+zwvuXykHlrGgusq4zyw+UKcUJBeYXSS46/d7eV7mX77Hp0jrE ZCY26/1Y9Y2ljmlBY1KQz0wLXK3HRBlnPvljT74259jvSVsb2WMvRf1Sv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAG8O4lStJV2d/2dsb2JhbABcgwZSWgSCf78wCoVxAhx4QwEBAQEBAXyEDAEBAQMBAQEBIBExCQsFBwQCAQgRAQMBAQECAh8EAwICAh8GCxQBAgYIAgQOBRuHfgMJCA22SpEYDYVGAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIYlrgkOBdwgrBwICAoJiLoEUBYVah3KBbIdxgUaBGIMNiGSCRoM+IoICHBSBPG8BgUN/AQEB X-IronPort-AV: E=Sophos;i="5.09,588,1418083200"; d="scan'208";a="396484302" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 16 Feb 2015 15:40:36 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t1GFealp006880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 16 Feb 2015 15:40:36 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 09:40:36 -0600 From: "Paul Quinn (paulq)" To: Ron Parker Thread-Topic: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) Thread-Index: AQHQKrzRZ/IN5VrM6Emtyk3yZjMjpJy+hNMAgDE2z4CAAB75gIAABBEAgAAO/YCABBG7gIAABuEAgAAGpAA= Date: Mon, 16 Feb 2015 15:40:35 +0000 Message-ID: <654A69C3-335E-4B51-9C8E-E6E3A3BE508E@cisco.com> References: <20150107205841.26716.9180.idtracker@ietfa.amsl.com> <54DE8A41.3090606@joelhalpern.com> <54DE9A3D.1090801@joelhalpern.com> <6DB46289-CDB0-46F9-AA34-348A9AB77C8E@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: text/plain; charset="utf-8" Content-ID: <0B676EC70186EB4C843F5FCF4A99AF2F@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sfc-problem-statement@tools.ietf.org" , "sfc@ietf.org" , Kathleen Moriarty , The IESG , "sfc-chairs@tools.ietf.org" , "Joel M. Halpern" Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-problem-statement-10: (with DISCUSS and COMMENT) 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, 16 Feb 2015 15:41:24 -0000 DQo+IE9uIEZlYiAxNiwgMjAxNSwgYXQgMTA6MTYgQU0sIFJvbiBQYXJrZXIgPFJvbl9QYXJrZXJA YWZmaXJtZWRuZXR3b3Jrcy5jb20+IHdyb3RlOg0KPiANCj4gSGksIFBhdWwuDQo+IA0KPiBZb3Vy IHByb3Bvc2VkIHRleHQgbG9va3MgZ29vZCB0byBtZS4gICBJdCBpcyB2ZXJ5IGNsZWFyIGFib3V0 IGhvdyBTRkMgZGVhbHMgd2l0aCB0ZW5hbmN5IGFuZCBpc29sYXRpb24gaXNzdWVzLg0KDQpUaGFu a3MgZm9yIHRoZSBxdWljayByZXZpZXchDQoNCg0KPiANCj4gS2F0aGxlZW4sIHRoaXMgd2FzIGEg dmVyeSB1c2VmdWwgZGlzY3Vzc2lvbi4gICBUaGFua3MgZm9yIGJyaW5naW5nIGl0IHVwLg0KDQpB Z3JlZWQsIHRoYW5rIHlvdS4gIEnigJlsbCBnaXZlIHRoZSBsaXN0IGEgbGl0dGxlIHdoaWxlIHRv IHdlaWdoIGluLCB0aGVuIHB1c2ggYSBuZXcgdmVyc2lvbi4NCg0KVGhhbmtzDQpQYXVsDQoNCg0K PiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2ZjIFttYWlsdG86c2Zj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQYXVsIFF1aW5uIChwYXVscSkNCj4gU2Vu dDogTW9uZGF5LCBGZWJydWFyeSAxNiwgMjAxNSA5OjUyIEFNDQo+IFRvOiBKb2VsIE0uIEhhbHBl cm4NCj4gQ2M6IEthdGhsZWVuIE1vcmlhcnR5OyBzZmMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBk cmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudEB0b29scy5pZXRmLm9yZzsgc2ZjQGlldGYu b3JnOyBUaGUgSUVTRw0KPiBTdWJqZWN0OiBSZTogW3NmY10gS2F0aGxlZW4gTW9yaWFydHkncyBE aXNjdXNzIG9uIGRyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50LTEwOiAod2l0aCBESVND VVNTIGFuZCBDT01NRU5UKQ0KPiANCj4gSGksDQo+IA0KPiBJbiBnZW5lcmFsIFNGQyBkb2VzbuKA mXQgY2hhbmdlIHRoZSBzZWN1cml0eSBwb3N0dXJlIHdydCB0ZW5hbmN5LCBzbyBJIHRlbmQgdG8g YWdyZWUgd2l0aCBKb2VsOiBsZXTigJlzIHJlbW92ZSB0aGUgc2VudGVuY2UgdGhhdCBhZGQgY29u ZnVzaW9uLg0KPiANCj4gVGhlcmXigJlzIG5vIGltcGxpY2F0aW9uIHRoYXQgdGhlIFNGQyBlbmNh cCB3aWxsIHByb3ZpZGUgdGVuYW50IGluZm9ybWF0aW9uIG9yIGlzb2xhdGlvbiAoYWx0aG91Z2gg aW4gbWFueSBjYXNlcyBJIHN1c3BlY3QgaXQgbWlnaHQgY2Fycnkgc29tZSBmb3JtIG9mIHRlbmFu dCBJRCkuICBJZiB0aGVyZeKAmXMgYSBuZWVkIGZvciB0cmFuc3BvcnQgaXNvbGF0aW9uLCB0aGVu IHRoZSBuZXR3b3JrIHRyYW5zcG9ydCBtdXN0IHByb3ZpZGUgaXQsIGFzIGl0IG11c3QgdG9kYXku ICANCj4gDQo+IElmIHRoZSBXRyBhZ3JlZXMsIEnigJltIGZpbmUgd2l0aCBhIHNpbXBsZSBjbGFy aWZ5aW5nIHN0YXRlbWVudCwgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZg0KPiANCj4g4oCc SWYgdGVuYW50IGlzb2xhdGlvbiBpcyByZXF1aXJlZCBpbiBhbiBTRkMgZGVwbG95bWVudCwgYW4g YXBwcm9wcmlhdGUgbmV0d29yayB0cmFuc3BvcnQgb3ZlcmxheSB0aGF0IHByb3ZpZGVzIGFkZXF1 YXRlIGlzb2xhdGlvbiBhbmQgaWRlbnRpZmljYXRpb24gY2FuIGJlIHVzZWQuICBBZGRpdGlvbmFs bHksIHRlbmFuY3kgbWlnaHQgYmUgdXNlZCBpbiB0aGUgc2VsZWN0aW9uIG9mIHRoZSBhcHByb3By aWF0ZSBzZXJ2aWNlIGNoYWluLCBob3dldmVyLCBhcyBzdGF0ZWQsIHRoZSBuZXR3b3JrIG92ZXJs YXkgaXMgc3RpbGwgcmVxdWlyZWQgdG8gcHJvdmlkZSB0cmFuc3BvcnQgaXNvbGF0aW9uLiAgU0Yg ZGVwbG95bWVudCBhbmQgaG93IHNwZWNpZmljIFNGcyBtaWdodCBvciBtaWdodCBub3QgYmUgYWxs b2NhdGVkIHBlciB0ZW5hbnQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4i DQo+IA0KPiANCj4+IE9uIEZlYiAxMywgMjAxNSwgYXQgNzo0MyBQTSwgSm9lbCBNLiBIYWxwZXJu IDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4+IA0KPj4gTXkgZmlyc3QgcmVhY3Rpb24g aXMgdG8gc3VnZ2VzdCByZW1vdmluZyB0aGUgbGFzdCBzZW50ZW5jZSB5b3UgcXVvdGUuICBJIGRv bid0IHRoaW5rIGl0IG1hdHRlcnMuICBUaGUgcmVhc29uIEkgc2F5IHRoYXQgaXMgdGhhdCBmcm9t IHdoYXQgSSB1bmRlcnN0YW5kLCB0ZW5hbnQgaXNvbGF0aW9uIGlzIG5vdCBhbiBpbXBvcnRhbnQg cGFydCBvZiB0aGUgcHJvYmxlbSAvIGRyaXZlciBmb3IgdGhlIFNGQyB3b3JrLiAgUmF0aGVyLCB0 aGUgU0ZDIHdvcmsgY2FuIGJlIHVzZWQgdG8gcHJvdmlkZSB0ZW5hbnQgaXNvbGF0aW9uIGlmIGZv bGtzIGNob29zZSB0byBkbyBzby4NCj4+IA0KPj4gSGF2aW5nIHNhaWQgdGhhdCwgSSB3aWxsIGxl YXZlIGl0IHRvIHRoZSBjaGFpcnMgYW5kIGF1dGhvcnMuDQo+PiANCj4+IFlvdXJzLA0KPj4gSm9l bA0KPj4gDQo+PiBPbiAyLzEzLzE1IDY6NTAgUE0sIEthdGhsZWVuIE1vcmlhcnR5IHdyb3RlOg0K Pj4+IA0KPj4+IA0KPj4+IE9uIEZyaSwgRmViIDEzLCAyMDE1IGF0IDY6MzUgUE0sIEpvZWwgTS4g SGFscGVybiA8am1oQGpvZWxoYWxwZXJuLmNvbSANCj4+PiA8bWFpbHRvOmptaEBqb2VsaGFscGVy bi5jb20+PiB3cm90ZToNCj4+PiANCj4+PiAgIEkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHdo YXQgdGhlIHF1ZXN0aW9uIGlzIGFib3V0IHRlbmFudCBpc29sYXRpb24uDQo+Pj4gDQo+Pj4gICBN dWx0aS10ZW5hbnQgc3VwcG9ydCBjYW4gYmUgcHJvdmlkZWQgaW4gbWFueSB3YXlzLiAgWW91IGNh biBoYXZlIGENCj4+PiAgIHNlcnZpY2UgY2hhaW4gcGVyIHRlbmFudC4gIFlvdSBjYW4gaGF2ZSB0 ZW5hbnQgSURzIGluIHRoZSBtZXRhZGF0YSwNCj4+PiAgIHVzZSBjb21tb24gY2hhaW5zLCBhbmQg c2VwYXJhdGUgdGhpbmdzIG9uIHRoZSBmYXIgZW5kLiAgQW5kIHRoZXJlDQo+Pj4gICBhcmUgcHJv YmFibHkgbW9yZSB3YXlzLg0KPj4+IA0KPj4+IA0KPj4+IFN1cmUsIEknZCBqdXN0IGxpa2UgdG8g c2VlIGEgbGl0dGxlIG1vcmUgdGV4dCBvbiB0aGF0LiAgVGVuYW50cyBhcmUgDQo+Pj4gbWVudGlv bmVkIGluIHRoZSBpbnRyb2R1Y3Rpb24gKDFzdCBwYXJhZ3JhcGgpLCB0aGVuIHRoZSB0ZXJtIGRv ZXNuJ3QgDQo+Pj4gYXBwZWFyIGFnYWluLg0KPj4+IA0KPj4+ICAgVGhlIGRlbGl2ZXJ5IG9mIGVu ZC10by1lbmQgc2VydmljZXMgb2Z0ZW4gcmVxdWlyZSB2YXJpb3VzIHNlcnZpY2UNCj4+PiAgIGZ1 bmN0aW9ucyBpbmNsdWRpbmcgdHJhZGl0aW9uYWwgbmV0d29yayBzZXJ2aWNlIGZ1bmN0aW9ucyAo Zm9yDQo+Pj4gICBleGFtcGxlIGZpcmV3YWxscyBhbmQgc2VydmVyIGxvYWQgYmFsYW5jZXJzKSwg YXMgd2VsbCBhcyBhcHBsaWNhdGlvbi0NCj4+PiAgIHNwZWNpZmljIGZlYXR1cmVzIHN1Y2ggYXMg aHR0cCBoZWFkZXIgbWFuaXB1bGF0aW9uLiAgU2VydmljZQ0KPj4+ICAgZnVuY3Rpb25zIG1heSBi ZSBkZWxpdmVyZWQgd2l0aGluIHRoZSBjb250ZXh0IG9mIGFuIGlzb2xhdGVkIHVzZXINCj4+PiAg IChlLmcuIGEgdGVuYW50KSwgb3Igc2hhcmVkIGFtb25nc3QgbWFueSB1c2Vycy91c2VyIGdyb3Vw cy4NCj4+PiANCj4+PiANCj4+PiAgIGlzIHRoZXJlIHNvbWV0aGluZyBpbiB0aGUgcHJvYmxlbSBz dGF0ZW1lbnQgdGhhdCBsZWFkcyB5b3UgdG8gZXhwZWN0DQo+Pj4gICB0aGlzIHByb2JsZW0gdG8g YmUgYWRkcmVzc2VkPyAgRXZlbiB0aGUgYXJjaGl0ZWN0dXJlIGRvZXMgbm90DQo+Pj4gICBhZGRy ZXNzIHRoaXMuICBJbiBmYWN0LCBhcyBmYXIgYXMgSSBjYW4gdGVsbCB0aGUgZW5jYXBzdWxhdGlv biBpcw0KPj4+ICAgdW5saWtlbHkgdG8gZGVhbCBkaXJlY3RseSB3aXRoIHRoaXMsIGFzIGl0IGlz IGEgc29sdXRpb24gcHJvcGVydHksDQo+Pj4gICBub3QgYW4gYXJjaGl0ZWN0dXJhbCBvciBwcm90 b2NvbCBwcm9wZXJ0eS4NCj4+PiANCj4+PiBJZiBpdCdzIGluaGVyZW50bHkgYWRkcmVzc2VkLCBp dCB3b3VsZCBiZSBnb29kIHRvIGhhdmUgYW4gaWRlYSBvZiBob3cgDQo+Pj4gaXQgaXMgYWRkcmVz c2VkIGluIHRoaXMgcHJvYmxlbSBzdGF0ZW1lbnQuICBJIHN1c3BlY3QgdGhhdCBpcyB0aGUgDQo+ Pj4gY2FzZSBhbmQgd291bGQgbGlrZSB0byBrbm93IGhvdyB5b3UgZXN0YWJsaXNoIGFuIGlzb2xh dGVkIHVzZXIgYW5kIA0KPj4+IHBlcmhhcHMgc2F5IHRoYXQgdGhpcyBpcyBub3QgcGFydCBvZiB0 aGUgcHJvYmxlbSBpZiBpdCdzIGJlZW4gc29sdmVkLiAgDQo+Pj4gTWF5YmUgaXQncyB0aHJvdWdo IHRoZSBlbmNhcHN1bGF0aW9uLiAgTGluZGEgcmVzcG9uZGVkIHdpdGggc29tZSANCj4+PiB0aG91 Z2h0cyBvbiBtYXJraW5ncyBmb3Igc2Vzc2lvbnMsIHdoaWNoIG1ha2VzIHNlbnNlLiAgVGhlIHNv bHV0aW9ucyANCj4+PiBtYXkgbm90IG5lZWQgdG8gdGFsayBhYm91dCBpdCBhdCBhbGwgaWYgbGFp ZCBvdXQgY29ycmVjdGx5IGluIHRoaXMgDQo+Pj4gZHJhZnQsIHdoaWNoIEkgc3VzcGVjdCBpcyB0 aGUgY2FzZS4NCj4+PiANCj4+PiBUaGFuayB5b3UsDQo+Pj4gS2F0aGxlZW4NCj4+PiANCj4+PiAg IFNvcnJ5IGlmIEkgYW0gYmVpbmcgb2J0dXNlLg0KPj4+ICAgWW91cnMsDQo+Pj4gICBKb2VsDQo+ Pj4gDQo+Pj4gICBPbiAyLzEzLzE1IDQ6NDQgUE0sIEthdGhsZWVuIE1vcmlhcnR5IHdyb3RlOg0K Pj4+IA0KPj4+ICAgICAgIEhpIFBhdWwsDQo+Pj4gDQo+Pj4gICAgICAgT24gVHVlLCBKYW4gMTMs IDIwMTUgYXQgOToxMSBBTSwgUGF1bCBRdWlubiAocGF1bHEpDQo+Pj4gICAgICAgPHBhdWxxQGNp c2NvLmNvbSA8bWFpbHRvOnBhdWxxQGNpc2NvLmNvbT4NCj4+PiAgICAgICA8bWFpbHRvOnBhdWxx QGNpc2NvLmNvbSA8bWFpbHRvOnBhdWxxQGNpc2NvLmNvbT4+PiB3cm90ZToNCj4+PiANCj4+PiAg ICAgICAgICAgIEhpIEthdGhsZWVuLA0KPj4+IA0KPj4+ICAgICAgICAgICAgV2UgYXJlIHdvcmtp bmcgbXkgd2F5IHRocm91Z2ggdGhlIElFU0cgY29tbWVudHMsIHRoYW5rcyBmb3INCj4+PiAgICAg ICBzZW5kaW5nDQo+Pj4gICAgICAgICAgICB5b3VycyENCj4+PiANCj4+PiANCj4+PiAgICAgICBU aGFuayB5b3UgYW5kIHNvcnJ5IGZvciBteSBkZWxheSBpbiByZXNwb25zZS4NCj4+PiANCj4+PiAN Cj4+PiAgICAgICAgICAgIFBsZWFzZSBzZWUgaW5saW5lLg0KPj4+IA0KPj4+ICAgICAgICAgICAg UGF1bA0KPj4+IA0KPj4+IA0KPj4+PiBPbiBKYW4gNywgMjAxNSwgYXQgMzo1OCBQTSwgS2F0aGxl ZW4gTW9yaWFydHkNCj4+PiAgICAgICA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5fX2Nv bQ0KPj4+ICAgICAgIDxtYWlsdG86a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+DQo+ Pj4gICAgICAgICAgICA8bWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5Ll9faWV0ZkBnbWFpbC5jb20N Cj4+PiAgICAgICA8bWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPj4+IHdy b3RlOg0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+ICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLV9fLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tX18tLS0tLS0tLS0tDQo+ Pj4+IERJU0NVU1M6DQo+Pj4+IA0KPj4+ICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLV9fLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tX18tLS0tLS0tLS0tDQo+Pj4+IA0K Pj4+PiBJIGRpZG4ndCBzZWUgYW55IG1lbnRpb24gb2Ygcmlza3Mgd2l0aCBtdWx0aXBsZSB0ZW5h bnRzDQo+Pj4gICAgICAgYW5kIHNoYXJlZA0KPj4+PiBpbmZyYXN0cnVjdHVyZSBmb3Igc2Vydmlj ZSBmdW5jdGlvbnMsIGlzIHRoYXQgYSBjb25jZXJuPw0KPj4+ICAgICAgIFRoaXMNCj4+Pj4gY29u c2lkZXJhdGlvbiBtYXkgZmFsbCBpbnRvIHRoZSBzYW1lIGRlc2NyaXB0aW9uIGFzIHRoZQ0KPj4+ ICAgICAgIHNlY29uZCBwb2ludCBmcm9tDQo+Pj4+IEJlbidzIFNlY0RpciByZXZpZXcgKGxpbmtl ZCBpbiBTdGVwaGVuJ3MgcmV2aWV3KS4NCj4+PiAgICAgICBBbHRob3VnaCB0aGUgU2VjRGlyDQo+ Pj4+IHJldmlldyBwb2ludCBjb3VsZCBiZSB3aXRoaW4gYSBzaW5nbGUgdGVuYW50IGVudmlyb25t ZW50DQo+Pj4gICAgICAgd2hlcmUgdGhlcmUgbWF5DQo+Pj4+IG9yIG1heSBub3QgYmUgdmFyaW91 cyBsZXZlbHMgb2YgdHJ1c3QgZGVwZW5kaW5nIG9uIGFjY2Vzcw0KPj4+ICAgICAgIGNvbnN0cmFp bnRzICh0bw0KPj4+PiB0aGUgc2FtZSBvciBkaWZmZXJlbnQgc2V0IG9mIGFwcGxpY2F0aW9ucyBm b3IgYSBzaW5nbGUNCj4+PiAgICAgICB0ZW5hbnQpLiAgSSdkIGxpa2UNCj4+Pj4gdG8gbWFrZSBz dXJlIGJvdGggcG9pbnRzIGdldCBhZGRyZXNzZWQgb3IgaWYgc29tZW9uZSBjYW4NCj4+PiAgICAg ICB0ZWxsIG1lIHdoeSBpdA0KPj4+PiBkb2Vzbid0IG1hdHRlciwgdGhhdCB3b3VsZCBiZSBmaW5l IHRvby4NCj4+PiANCj4+PiANCj4+PiAgICAgICBJcyB0aGlzIHByb2JsZW0gYWRkcmVzc2VkIGJ5 IFNGQyBlbmNhcHN1bGF0aW9uPyAgRG9lIGl0IHNvbWVob3cNCj4+PiAgICAgICBtYXJrIHRoZQ0K Pj4+ICAgICAgIHNlc3Npb25zIHRvIGVuc3VyZSB0aGUgc3RyZWFtcyBhcyBpdCBnb2VzIHRocm91 Z2ggc2VydmljZSBjaGFpbnMgaXMNCj4+PiAgICAgICBmb2xsb3dpbmcgdGhlIGNoYWluIGZvciB0 aGF0IHNwZWNpZmljIHNlcnZpY2UgYW5kIGluc3RhbmNlIG9mIHRoYXQNCj4+PiAgICAgICBzZXJ2 aWNlIHRoYXQgbWlnaHQgYmUgdGVuYW50IHNwZWNpZmljPyAgSSdkIGxpa2UgdG8gc2VlIHNvbWUN Cj4+PiAgICAgICBsYW5ndWFnZQ0KPj4+ICAgICAgIGFkZGVkIG9uIHRoaXMgdG9waWMuDQo+Pj4g DQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gLS0NCj4+PiANCj4+PiBCZXN0IHJlZ2FyZHMsDQo+Pj4g S2F0aGxlZW4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2ZjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQoNCg== From nobody Mon Feb 16 13:32:58 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 3A9941A88C6 for ; Mon, 16 Feb 2015 13:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 0E_HSwGutmp1 for ; Mon, 16 Feb 2015 13:32:55 -0800 (PST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA5B1A88B9 for ; Mon, 16 Feb 2015 13:32:51 -0800 (PST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 16 Feb 2015 13:32:49 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,590,1418112000"; d="scan'208,217";a="455422738" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by FMSMGA003.fm.intel.com with ESMTP; 16 Feb 2015 13:17:52 -0800 Received: from orsmsx111.amr.corp.intel.com (10.22.240.12) by ORSMSX102.amr.corp.intel.com (10.22.225.129) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 16 Feb 2015 13:32:49 -0800 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.194]) by ORSMSX111.amr.corp.intel.com ([169.254.11.231]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 13:32:49 -0800 From: "Elzur, Uri" To: "sfc@ietf.org" Thread-Topic: [sfc] clarification on SFC and Overlay interaction Thread-Index: AdBKIpMhsqiyxxIdQCe0R10IHuyROw== Date: Mon, 16 Feb 2015 21:32:45 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B89958581B7E39A@ORSMSX114.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: multipart/alternative; boundary="_000_7E05C330D7FD6D4FAD0728C46B89958581B7E39AORSMSX114amrcor_" MIME-Version: 1.0 Archived-At: Subject: [sfc] clarification on SFC and Overlay interaction X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 21:32:57 -0000 --_000_7E05C330D7FD6D4FAD0728C46B89958581B7E39AORSMSX114amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While section 4.5 of draft-ietf-sfc-architecture-04, states "underneath the= SFF there are components responsible for performing the transport (overlay= ) forwarding. They do not consults the SFC encapsulation or inner payload f= or performing these forwarding.", there is no reason to exclude the followi= ng private case, I'd assume. This is the case where the SFF is effectively = integrated with the Overlay manager, or instantiated in other overlay netwo= rk elements (e.g. vSwitch), enabling in essence SFC within an Overlay netw= ork, with no need for a separate SFC domain. To be clear (or clearer), this is not to suggest that transport or topologi= cal independence can be or should be bend, but simply to suggest a deployme= nt scenario that may be popular for limited scale SFC Thx Uri ("Oo-Ree") C: 949-378-7568 --_000_7E05C330D7FD6D4FAD0728C46B89958581B7E39AORSMSX114amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

While section 4.5 of draft-ietf-sfc-architecture-04,= states “underneath the SFF there are components responsible for perf= orming the transport (overlay) forwarding. They do not consults the SFC enc= apsulation or inner payload for performing these forwarding.”, there is no reason to exclude the following priv= ate case, I’d assume. This is the case where the SFF is effectively i= ntegrated with the Overlay manager, or instantiated in other overlay networ= k elements (e.g. vSwitch),  enabling in essence SFC within an Overlay network, with no need for a separate SFC domain.

 

To be clear (or clearer), this is not to suggest tha= t transport or topological independence can be or should be bend, but simpl= y to suggest a deployment scenario that may be popular for limited scale SF= C

 

Thx

 

Uri (“Oo-Ree”)

C: 949-378-7568

 

--_000_7E05C330D7FD6D4FAD0728C46B89958581B7E39AORSMSX114amrcor_-- From nobody Mon Feb 16 13:36: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 3A1751A88D8 for ; Mon, 16 Feb 2015 13:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 j4XFzGtH6uYz for ; Mon, 16 Feb 2015 13:36:34 -0800 (PST) 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 135A41A88D6 for ; Mon, 16 Feb 2015 13:36:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id EAD1B1C04B8; Mon, 16 Feb 2015 13:36:33 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-240.clppva.east.verizon.net [70.106.135.240]) (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 36FDC1C043A; Mon, 16 Feb 2015 13:36:33 -0800 (PST) Message-ID: <54E262B8.2010605@joelhalpern.com> Date: Mon, 16 Feb 2015 16:35:52 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Elzur, Uri" , "sfc@ietf.org" References: <7E05C330D7FD6D4FAD0728C46B89958581B7E39A@ORSMSX114.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B89958581B7E39A@ORSMSX114.amr.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] clarification on SFC and Overlay interaction X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 21:36:39 -0000 One of the key reasons for identifying the logical components is that there are a broad range of ways that they can be composed. That does sound like one possible composition. Yours, Joel On 2/16/15 4:32 PM, Elzur, Uri wrote: > While section 4.5 of draft-ietf-sfc-architecture-04, states “underneath > the SFF there are components responsible for performing the transport > (overlay) forwarding. They do not consults the SFC encapsulation or > inner payload for performing these forwarding.”, there is no reason to > exclude the following private case, I’d assume. This is the case where > the SFF is effectively integrated with the Overlay manager, or > instantiated in other overlay network elements (e.g. vSwitch), enabling > in essence SFC within an Overlay network, with no need for a separate > SFC domain. > > To be clear (or clearer), this is not to suggest that transport or > topological independence can be or should be bend, but simply to suggest > a deployment scenario that may be popular for limited scale SFC > > Thx > > Uri (“Oo-Ree”) > > C: 949-378-7568 > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Feb 16 14:36:34 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314F91A88B2 for ; Mon, 16 Feb 2015 14:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SrSObKzhXc0F for ; Mon, 16 Feb 2015 14:36:31 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ietfa.amsl.com (Postfix) with ESMTP id 91FE61A6ED9 for ; Mon, 16 Feb 2015 14:36:31 -0800 (PST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP; 16 Feb 2015 14:32:28 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,590,1418112000"; d="scan'208";a="667224149" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by fmsmga001.fm.intel.com with ESMTP; 16 Feb 2015 14:36:13 -0800 Received: from orsmsx152.amr.corp.intel.com (10.22.226.39) by ORSMSX104.amr.corp.intel.com (10.22.225.131) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 16 Feb 2015 14:36:12 -0800 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.194]) by ORSMSX152.amr.corp.intel.com ([169.254.8.23]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 14:36:12 -0800 From: "Elzur, Uri" To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] clarification on SFC and Overlay interaction Thread-Index: AQHQSjCk/CO92w19PkOCqp0Z1D8ImZzz3I0w Date: Mon, 16 Feb 2015 22:36:11 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B89958581B7E414@ORSMSX114.amr.corp.intel.com> References: <7E05C330D7FD6D4FAD0728C46B89958581B7E39A@ORSMSX114.amr.corp.intel.com> <54E262B8.2010605@joelhalpern.com> In-Reply-To: <54E262B8.2010605@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] clarification on SFC and Overlay interaction X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 22:36:33 -0000 Joel Sounds good to me. However a clarification, maybe in the format of a commen= t or example (as I suspect this may be a very common case, for some) in the= draft will be of value Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Monday, February 16, 2015 1:36 PM To: Elzur, Uri; sfc@ietf.org Subject: Re: [sfc] clarification on SFC and Overlay interaction One of the key reasons for identifying the logical components is that there= are a broad range of ways that they can be composed. That does sound like= one possible composition. Yours, Joel On 2/16/15 4:32 PM, Elzur, Uri wrote: > While section 4.5 of draft-ietf-sfc-architecture-04, states=20 > "underneath the SFF there are components responsible for performing=20 > the transport > (overlay) forwarding. They do not consults the SFC encapsulation or=20 > inner payload for performing these forwarding.", there is no reason to=20 > exclude the following private case, I'd assume. This is the case where=20 > the SFF is effectively integrated with the Overlay manager, or=20 > instantiated in other overlay network elements (e.g. vSwitch), =20 > enabling in essence SFC within an Overlay network, with no need for a=20 > separate SFC domain. > > To be clear (or clearer), this is not to suggest that transport or=20 > topological independence can be or should be bend, but simply to=20 > suggest a deployment scenario that may be popular for limited scale=20 > SFC > > Thx > > Uri ("Oo-Ree") > > C: 949-378-7568 > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Feb 16 15:24:22 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 C6FC01A88EB for ; Mon, 16 Feb 2015 15:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 pGZMoXdSZVEO for ; Mon, 16 Feb 2015 15:24:20 -0800 (PST) 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 5DD601A88E8 for ; Mon, 16 Feb 2015 15:24:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 3F41A1C04FA; Mon, 16 Feb 2015 15:24:20 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-240.clppva.east.verizon.net [70.106.135.240]) (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 764C71C0331; Mon, 16 Feb 2015 15:24:19 -0800 (PST) Message-ID: <54E27BFA.2010608@joelhalpern.com> Date: Mon, 16 Feb 2015 18:23:38 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Elzur, Uri" , "sfc@ietf.org" References: <7E05C330D7FD6D4FAD0728C46B89958581B7E39A@ORSMSX114.amr.corp.intel.com> <54E262B8.2010605@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E414@ORSMSX114.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B89958581B7E414@ORSMSX114.amr.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] clarification on SFC and Overlay interaction X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 23:24:21 -0000 If we do not have text in there that says that these logical components may be combined in real world implementations or deployments with each other or with components from outside the architecture, I could see adding that. I thought we already said it. I would prefer not to add comments on any specific deployments, because there are so many ways to do so, and as far as I can tell, most of us think the one in our head is the most likely / common / useful. Yours, Joel On 2/16/15 5:36 PM, Elzur, Uri wrote: > Joel > > Sounds good to me. However a clarification, maybe in the format of a comment or example (as I suspect this may be a very common case, for some) in the draft will be of value > > Thx > > Uri ("Oo-Ree") > C: 949-378-7568 > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, February 16, 2015 1:36 PM > To: Elzur, Uri; sfc@ietf.org > Subject: Re: [sfc] clarification on SFC and Overlay interaction > > One of the key reasons for identifying the logical components is that there are a broad range of ways that they can be composed. That does sound like one possible composition. > > Yours, > Joel > > On 2/16/15 4:32 PM, Elzur, Uri wrote: >> While section 4.5 of draft-ietf-sfc-architecture-04, states >> "underneath the SFF there are components responsible for performing >> the transport >> (overlay) forwarding. They do not consults the SFC encapsulation or >> inner payload for performing these forwarding.", there is no reason to >> exclude the following private case, I'd assume. This is the case where >> the SFF is effectively integrated with the Overlay manager, or >> instantiated in other overlay network elements (e.g. vSwitch), >> enabling in essence SFC within an Overlay network, with no need for a >> separate SFC domain. >> >> To be clear (or clearer), this is not to suggest that transport or >> topological independence can be or should be bend, but simply to >> suggest a deployment scenario that may be popular for limited scale >> SFC >> >> Thx >> >> Uri ("Oo-Ree") >> >> C: 949-378-7568 >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > From nobody Mon Feb 16 15:37: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 B389C1A88EB for ; Mon, 16 Feb 2015 15:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 op3F-HeM7Bm5 for ; Mon, 16 Feb 2015 15:37:20 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0A61A88EA for ; Mon, 16 Feb 2015 15:37:20 -0800 (PST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 16 Feb 2015 15:29:37 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,591,1418112000"; d="scan'208";a="455452270" Received: from orsmsx104.amr.corp.intel.com ([10.22.225.131]) by FMSMGA003.fm.intel.com with ESMTP; 16 Feb 2015 15:22:05 -0800 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.194]) by ORSMSX104.amr.corp.intel.com ([169.254.3.113]) with mapi id 14.03.0195.001; Mon, 16 Feb 2015 15:37:03 -0800 From: "Elzur, Uri" To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] clarification on SFC and Overlay interaction Thread-Index: AQHQSjCk/CO92w19PkOCqp0Z1D8ImZzz3I0wgACUXQD//3x9gA== Date: Mon, 16 Feb 2015 23:36:57 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B89958581B7E4A5@ORSMSX114.amr.corp.intel.com> References: <7E05C330D7FD6D4FAD0728C46B89958581B7E39A@ORSMSX114.amr.corp.intel.com> <54E262B8.2010605@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E414@ORSMSX114.amr.corp.intel.com> <54E27BFA.2010608@joelhalpern.com> In-Reply-To: <54E27BFA.2010608@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] clarification on SFC and Overlay interaction X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 23:37:21 -0000 Agree. I do not recall however any such statement. I do recall many stateme= nt like section 4.5, indicating the separation and referring to topologica= l and transport independence. Pls point me to the paragraph or we may want = to add such clarification in the next rev Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Monday, February 16, 2015 3:24 PM To: Elzur, Uri; sfc@ietf.org Subject: Re: [sfc] clarification on SFC and Overlay interaction If we do not have text in there that says that these logical components may= be combined in real world implementations or deployments with each other o= r with components from outside the architecture, I could see adding that. = I thought we already said it. I would prefer not to add comments on any specific deployments, because the= re are so many ways to do so, and as far as I can tell, most of us think th= e one in our head is the most likely / common / useful. Yours, Joel On 2/16/15 5:36 PM, Elzur, Uri wrote: > Joel > > Sounds good to me. However a clarification, maybe in the format of a=20 > comment or example (as I suspect this may be a very common case, for=20 > some) in the draft will be of value > > Thx > > Uri ("Oo-Ree") > C: 949-378-7568 > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, February 16, 2015 1:36 PM > To: Elzur, Uri; sfc@ietf.org > Subject: Re: [sfc] clarification on SFC and Overlay interaction > > One of the key reasons for identifying the logical components is that the= re are a broad range of ways that they can be composed. That does sound li= ke one possible composition. > > Yours, > Joel > > On 2/16/15 4:32 PM, Elzur, Uri wrote: >> While section 4.5 of draft-ietf-sfc-architecture-04, states=20 >> "underneath the SFF there are components responsible for performing=20 >> the transport >> (overlay) forwarding. They do not consults the SFC encapsulation or=20 >> inner payload for performing these forwarding.", there is no reason=20 >> to exclude the following private case, I'd assume. This is the case=20 >> where the SFF is effectively integrated with the Overlay manager, or=20 >> instantiated in other overlay network elements (e.g. vSwitch),=20 >> enabling in essence SFC within an Overlay network, with no need for a=20 >> separate SFC domain. >> >> To be clear (or clearer), this is not to suggest that transport or=20 >> topological independence can be or should be bend, but simply to=20 >> suggest a deployment scenario that may be popular for limited scale=20 >> SFC >> >> Thx >> >> Uri ("Oo-Ree") >> >> C: 949-378-7568 >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > From nobody Mon Feb 16 15:43:50 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD3311A88EA for ; Mon, 16 Feb 2015 15:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 BjaRAC3Q5gwE for ; Mon, 16 Feb 2015 15:43:47 -0800 (PST) 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 CFBC31A8902 for ; Mon, 16 Feb 2015 15:43:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B5BFC1C06F0; Mon, 16 Feb 2015 15:43:43 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-240.clppva.east.verizon.net [70.106.135.240]) (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 D74B81C043A; Mon, 16 Feb 2015 15:43:42 -0800 (PST) Message-ID: <54E28085.8070803@joelhalpern.com> Date: Mon, 16 Feb 2015 18:43:01 -0500 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Elzur, Uri" , "sfc@ietf.org" References: <7E05C330D7FD6D4FAD0728C46B89958581B7E39A@ORSMSX114.amr.corp.intel.com> <54E262B8.2010605@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E414@ORSMSX114.amr.corp.intel.com> <54E27BFA.2010608@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E4A5@ORSMSX114.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B89958581B7E4A5@ORSMSX114.amr.corp.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] clarification on SFC and Overlay interaction X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 23:43:49 -0000 It seems like we can (and unless I am very confused, should) add such a statement in the base portion of section 4. Carlos and I will work on this. Thank you for calling our attention to the omission. Yours, Joel On 2/16/15 6:36 PM, Elzur, Uri wrote: > Agree. I do not recall however any such statement. I do recall many statement like section 4.5, indicating the separation and referring to topological and transport independence. Pls point me to the paragraph or we may want to add such clarification in the next rev > > Thx > > Uri ("Oo-Ree") > C: 949-378-7568 > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, February 16, 2015 3:24 PM > To: Elzur, Uri; sfc@ietf.org > Subject: Re: [sfc] clarification on SFC and Overlay interaction > > If we do not have text in there that says that these logical components may be combined in real world implementations or deployments with each other or with components from outside the architecture, I could see adding that. I thought we already said it. > > I would prefer not to add comments on any specific deployments, because there are so many ways to do so, and as far as I can tell, most of us think the one in our head is the most likely / common / useful. > > Yours, > Joel > > On 2/16/15 5:36 PM, Elzur, Uri wrote: >> Joel >> >> Sounds good to me. However a clarification, maybe in the format of a >> comment or example (as I suspect this may be a very common case, for >> some) in the draft will be of value >> >> Thx >> >> Uri ("Oo-Ree") >> C: 949-378-7568 >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Monday, February 16, 2015 1:36 PM >> To: Elzur, Uri; sfc@ietf.org >> Subject: Re: [sfc] clarification on SFC and Overlay interaction >> >> One of the key reasons for identifying the logical components is that there are a broad range of ways that they can be composed. That does sound like one possible composition. >> >> Yours, >> Joel >> >> On 2/16/15 4:32 PM, Elzur, Uri wrote: >>> While section 4.5 of draft-ietf-sfc-architecture-04, states >>> "underneath the SFF there are components responsible for performing >>> the transport >>> (overlay) forwarding. They do not consults the SFC encapsulation or >>> inner payload for performing these forwarding.", there is no reason >>> to exclude the following private case, I'd assume. This is the case >>> where the SFF is effectively integrated with the Overlay manager, or >>> instantiated in other overlay network elements (e.g. vSwitch), >>> enabling in essence SFC within an Overlay network, with no need for a >>> separate SFC domain. >>> >>> To be clear (or clearer), this is not to suggest that transport or >>> topological independence can be or should be bend, but simply to >>> suggest a deployment scenario that may be popular for limited scale >>> SFC >>> >>> Thx >>> >>> Uri ("Oo-Ree") >>> >>> C: 949-378-7568 >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> From nobody Tue Feb 17 10:40: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 C55431A9061; Tue, 17 Feb 2015 10:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 07Tv4mHSE9oR; Tue, 17 Feb 2015 10:40:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 501D81A903D; Tue, 17 Feb 2015 10:40:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217184047.2213.84722.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 10:40:47 -0800 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-12.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 18:40:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining Problem Statement Authors : Paul Quinn Thomas Nadeau Filename : draft-ietf-sfc-problem-statement-12.txt Pages : 19 Date : 2015-02-17 Abstract: This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term service function chaining is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions. The set of enabled service function chains reflect operator service offerings and is designed in conjunction with application delivery and service and network policy. This document also identifies several key areas that the SFC working group will investigate to guide its architectural and protocol work and associated drafts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-12 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 17 10:40:58 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 CBC1E1A9069; Tue, 17 Feb 2015 10:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 rnvy9axp8yS5; Tue, 17 Feb 2015 10:40:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 827BF1A904E; Tue, 17 Feb 2015 10:40:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217184047.2213.50385.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 10:40:47 -0800 Archived-At: Subject: [sfc] New Version Notification - draft-ietf-sfc-problem-statement-12.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 18:40:52 -0000 A new version (-12) has been submitted for draft-ietf-sfc-problem-statement: http://www.ietf.org/internet-drafts/draft-ietf-sfc-problem-statement-12.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-12 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. IETF Secretariat. From nobody Tue Feb 17 11:25:42 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FB81A9095 for ; Tue, 17 Feb 2015 11:25:41 -0800 (PST) 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 gWqFpwPo_8tD for ; Tue, 17 Feb 2015 11:25:39 -0800 (PST) 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 9A14D1A90B3 for ; Tue, 17 Feb 2015 11:25:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2501; q=dns/txt; s=iport; t=1424201126; x=1425410726; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=beYYX547mLeb7c6reAb80Edi2VXiOHzyV0gYMOiw7gs=; b=IzE/1QJH2WgqQfxSBd+UVaLWO09yzNNuIEnH4q2xYI578bSSjJRv2kI5 tYGtzRwijIyUmwwIDaryrh7IpKtj/3Nv5BuxpQXfLHjqmhtKAXGqDCZ2A W5Hz6m0jjnVZ4Qu7bUQ0TDxu9jdRWyynZdjebQQY9UspDORWGkbXWhDvA k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BUBQDnlONU/5tdJa1bgwZSVQUEwkYKhXECgRlDAQEBAQEBfIQMAQEBAwEBAQE3KwkQCwIBGQMBAh8QJwsbAggCBBMJiB4ICAXRGQEBAQEBAQQBAQEBAQEBARqLD4QdAQFRC4MQgRQFjziDV4VggRg4glWOaCKDbm8BgQo5fwEBAQ X-IronPort-AV: E=Sophos;i="5.09,595,1418083200"; d="scan'208";a="124386454" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 17 Feb 2015 19:25:25 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1HJPOQ3014095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 17 Feb 2015 19:25:24 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Tue, 17 Feb 2015 13:25:24 -0600 From: "Paul Quinn (paulq)" To: "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-problem-statement-12.txt Thread-Index: AQHQSuFTp3ESDZM1xEmRGlewkzVrTw== Date: Tue, 17 Feb 2015 19:25:24 +0000 Message-ID: References: <20150217184047.2213.84722.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.217.166] Content-Type: text/plain; charset="us-ascii" Content-ID: <2B1548117B2B9C42B5A3B0257FF0ED41@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [sfc] Fwd: I-D Action: draft-ietf-sfc-problem-statement-12.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, 17 Feb 2015 19:25:41 -0000 Hello, This version incorporates some text re: multi-tenancy as per the recent thr= ead (http://www.ietf.org/mail-archive/web/sfc/current/msg03111.html). Paul > Begin forwarded message: >=20 > From: > To: > Date: February 17, 2015 at 1:40:47 PM EST > Cc: > Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-12.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Service Function Chaining Working Group = of the IETF. >=20 > Title : Service Function Chaining Problem Statement > Authors : Paul Quinn > Thomas Nadeau > Filename : draft-ietf-sfc-problem-statement-12.txt > Pages : 19 > Date : 2015-02-17 >=20 > Abstract: > This document provides an overview of the issues associated with the > deployment of service functions (such as firewalls, load balancers, > etc.) in large-scale environments. The term service function > chaining is used to describe the definition and instantiation of an > ordered list of instances of such service functions, and the > subsequent "steering" of traffic flows through those service > functions. >=20 > The set of enabled service function chains reflect operator service > offerings and is designed in conjunction with application delivery > and service and network policy. >=20 > This document also identifies several key areas that the SFC working > group will investigate to guide its architectural and protocol work > and associated drafts. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-12 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-12 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Feb 17 15:37: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 813D91A88CF; Tue, 17 Feb 2015 15:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 BhK7lOwdsY5a; Tue, 17 Feb 2015 15:37:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B5C1A8889; Tue, 17 Feb 2015 15:37:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150217233754.22143.41495.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 15:37:54 -0800 Archived-At: Cc: draft-ietf-sfc-problem-statement@ietf.org, jmh@joelhalpern.com, sfc-chairs@ietf.org, sfc@ietf.org Subject: [sfc] Kathleen Moriarty's No Objection on draft-ietf-sfc-problem-statement-12: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2015 23:37:56 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-sfc-problem-statement-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my question on multi-tenancy and adding in text to describe how that could be handled. I agree with Barry, Alissa, and maybe others that a wiki may be a better option, but I won't stand in the way of publication. I do think the problem SFC is working on is important and the work will be worthwhile, but this draft isn't ready ready or may not need to be published. There are still numerous security considerations to be included as pointed out in the SecDir review and in Stephen's DISCUSS points that I support. The draft mentions ordering for service functions, and it would be good to see some concrete examples of how security may be an issue with different options for ordering. Since SFC's scope is a single administrative domain, the service chaining could result in session decryption at various points in the chain that could result in security and privacy exposures within that domain (typically considered a manageable risk). Functionality may be limited for some of the service functions if the decryption does not happen prior to that point and risk prioritization will be necessary (exposure of data, session interception, corruption of data, etc. could result from this exposure) since this is likely to be used in hosted environments with multiple tenants. The SecDir review did mention crossover between management/control and data planes, but tenant isolation may also need to be mentioned. Some nits (I don't think others mentioned these, but sorry if they were already addressed): Section 2.1: 3rd paragraph: Is this intended to mean after a new service function is added? I can't imagine that this our happen on the fly, so I think that's the case and adding a word or two may help: from: As more service functions are required - often with strict ordering - topology changes are needed before and after each service function is added resulting in complex network changes and device configuration. 4th paragraph: I'm have trouble reading this paragraph as I think it contradicts itself, but the example in the following paragraph is helpful. If topology dictates placement, how could using topology not be viable? Maybe rewording it would help: The topological coupling limits placement and selection of service functions: service functions are "fixed" in place by topology and therefore placement and service function selection taking into account network topology information is not viable. Furthermore, altering the services traversed, or their order, based on flow direction is not possible. Thanks, Kathleen From nobody Tue Feb 17 17:12: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 C9CA11A891D; Tue, 17 Feb 2015 17:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 a9QDOK7r1wLl; Tue, 17 Feb 2015 17:12:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B93F1A87A4; Tue, 17 Feb 2015 17:12:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218011246.30823.26976.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 17:12:46 -0800 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-architecture-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 01:12:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining (SFC) Architecture Authors : Joel Halpern Carlos Pignataro Filename : draft-ietf-sfc-architecture-05.txt Pages : 27 Date : 2015-02-17 Abstract: This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-architecture-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 17 17:47:49 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 D53B51A88F5 for ; Tue, 17 Feb 2015 17:47:47 -0800 (PST) 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 9SB3GDseJnKD for ; Tue, 17 Feb 2015 17:47:46 -0800 (PST) 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 368681A90FE for ; Tue, 17 Feb 2015 17:47:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2678; q=dns/txt; s=iport; t=1424224066; x=1425433666; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dxKfAytM3PI8fbr8WwwykDug5QLDP0j8U7ijMwM6p4w=; b=gm0UpNXonIqXJ46F0+em4962Gu7IIokP2uEq9gRnE7HDT+wnrUMRa1id ekGRQ/UVy0HzqzBzMZlHKtRpFlPvnaA4hV1BQW2LtMTyHeRAGDefp/OQt OUVJKjzdoy0bBuuJwMM03URAVCSACN3ew5bO/1Z2oY2ThK9WH742+jdiX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DQBQDU7eNU/5tdJa1bgwZSVQUEgn+9JoIgCoVxAhyBAEMBAQEBAQF8hAwBAQEDAQEBASAROhALAgEIEgYCAiYCAgIlCxUCDgIEEwkSiAwICAW5D5dvAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiW6EdYJoLoEUBY84g1eFYIEYOIJViCGGRyKDbm+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,595,1418083200"; d="scan'208";a="124488894" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 18 Feb 2015 01:47:45 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1I1lhJ5005697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 18 Feb 2015 01:47:43 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.138]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Tue, 17 Feb 2015 19:47:43 -0600 From: "Carlos Pignataro (cpignata)" To: "sfc@ietf.org" Thread-Topic: [sfc] I-D Action: draft-ietf-sfc-architecture-05.txt Thread-Index: AQHQSxgIuzqJnHIGgEeU6GgIEUryR5z2CCiA Date: Wed, 18 Feb 2015 01:47:42 +0000 Message-ID: References: <20150218011246.30823.26976.idtracker@ietfa.amsl.com> In-Reply-To: <20150218011246.30823.26976.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.236.189] Content-Type: text/plain; charset="utf-8" Content-ID: <8ED2C1CF78F5CC4B8A709012D2DA8F4C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] I-D Action: draft-ietf-sfc-architecture-05.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, 18 Feb 2015 01:47:48 -0000 SGksIFNGQ2VycywNCg0KVGhpcyB1cGRhdGUgc3RyZW5ndGhlbnMgdGhlIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zLCBhbmQgaGFybW9uaXplcyBpdCB3aXRoIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBvZiB0aGUgUHJvYmxlbSBTdGF0ZW1lbnQgZG9jdW1lbnQuDQoNCkJlc3QsDQoNCuKAlCBD YXJsb3MgJiBKb2VsLg0KDQo+IE9uIEZlYiAxNywgMjAxNSwgYXQgODoxMiBQTSwgaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPiANCj4gDQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlz IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4N Cj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU2VydmljZSBGdW5jdGlvbiBDaGFp bmluZyBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPiANCj4gICAgICAgIFRpdGxlICAgICAg ICAgICA6IFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgQXJjaGl0ZWN0dXJlDQo+ICAg ICAgICBBdXRob3JzICAgICAgICAgOiBKb2VsIEhhbHBlcm4NCj4gICAgICAgICAgICAgICAgICAg ICAgICAgIENhcmxvcyBQaWduYXRhcm8NCj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYt c2ZjLWFyY2hpdGVjdHVyZS0wNS50eHQNCj4gCVBhZ2VzICAgICAgICAgICA6IDI3DQo+IAlEYXRl ICAgICAgICAgICAgOiAyMDE1LTAyLTE3DQo+IA0KPiBBYnN0cmFjdDoNCj4gICBUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBhbiBhcmNoaXRlY3R1cmUgZm9yIHRoZSBzcGVjaWZpY2F0aW9uLA0KPiAg IGNyZWF0aW9uLCBhbmQgb25nb2luZyBtYWludGVuYW5jZSBvZiBTZXJ2aWNlIEZ1bmN0aW9uIENo YWlucyAoU0ZDKSBpbg0KPiAgIGEgbmV0d29yay4gIEl0IGluY2x1ZGVzIGFyY2hpdGVjdHVyYWwg Y29uY2VwdHMsIHByaW5jaXBsZXMsIGFuZA0KPiAgIGNvbXBvbmVudHMgdXNlZCBpbiB0aGUgY29u c3RydWN0aW9uIG9mIGNvbXBvc2l0ZSBzZXJ2aWNlcyB0aHJvdWdoDQo+ICAgZGVwbG95bWVudCBv ZiBTRkNzLCB3aXRoIGEgZm9jdXMgb24gdGhvc2UgdG8gYmUgc3RhbmRhcmRpemVkIGluIHRoZQ0K PiAgIElFVEYuICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IHByb3Bvc2Ugc29sdXRpb25zLCBwcm90 b2NvbHMsIG9yDQo+ICAgZXh0ZW5zaW9ucyB0byBleGlzdGluZyBwcm90b2NvbHMuDQo+IA0KPiAN Cj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLWFyY2hpdGVj dHVyZS8NCj4gDQo+IFRoZXJlJ3MgYWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0 Og0KPiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNmYy1hcmNoaXRlY3R1 cmUtMDUNCj4gDQo+IEEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJs ZSBhdDoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zZmMt YXJjaGl0ZWN0dXJlLTA1DQo+IA0KPiANCj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1v dXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2ZjIG1h aWxpbmcgbGlzdA0KPiBzZmNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zZmMNCg0K From nobody Tue Feb 17 18:18:04 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 37DEE1A9176 for ; Tue, 17 Feb 2015 18:18:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFqTzJ7RkC2z for ; Tue, 17 Feb 2015 18:18:00 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 496EB1A9168 for ; Tue, 17 Feb 2015 18:18:00 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 302AE2C402C for ; Tue, 17 Feb 2015 18:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id KzWhWo2hL-5p for ; Tue, 17 Feb 2015 18:17:58 -0800 (PST) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (Authenticated sender: narseo) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id DCD532C4029 for ; Tue, 17 Feb 2015 18:17:57 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id z60so30975579qgd.10 for ; Tue, 17 Feb 2015 18:17:56 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.192.15 with SMTP id n15mr2067439qha.28.1424225876989; Tue, 17 Feb 2015 18:17:56 -0800 (PST) Received: by 10.96.136.39 with HTTP; Tue, 17 Feb 2015 18:17:56 -0800 (PST) In-Reply-To: <787AE7BB302AE849A7480A190F8B93300490AE24@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300490AE24@OPEXCLILM23.corporate.adroot.infra.ftgroup> Date: Tue, 17 Feb 2015 18:17:56 -0800 Message-ID: From: Narseo Vallina Rodriguez To: mohamed.boucadair@orange.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ron Parker , "sfc@ietf.org" Subject: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection 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, 18 Feb 2015 02:18:03 -0000 Hi Mohamed Thanks a lot for the pointer. That explains the reason why certain headers may be useful but still does not answer why some privacy sensitive headers are explicitly listed on the mobile use case. Are there any examples about the privacy sensitive headers? On Fri, Feb 13, 2015 at 6:12 AM, wrote: > Dear Narseo, > > An example to illustrate the need to inject a header in a mobile network = (other than those similar to HTTP_MSISDN, HTTP_X_MSISDN, HTTP_X_UP_CALLING_= LINE_ID, HTTP_X_NOKIA_MSISDN, HTTP_X_HTS_CLID, HTTP_X_MSP_CLID,HTTP_X_NX_CL= ID, HTTP_RAPMIN, HTTP_X_WAP_MSISDN, HTTP_COOKIE, HTTP_X_UP_LSID, HTTP_X_H3G= _MSISDN, HTTP_X_JINNY_CID, HTTP_X_NETWORK_INFO, etc. ) is discussed in: htt= ps://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-= 09#section-10.2. > > Privacy related considerations of this typical example are elaborated her= e: https://tools.ietf.org/html/rfc6967#section-3. > > Cheers, > Med > > -----Message d'origine----- > De : sfc [mailto:sfc-bounces@ietf.org] De la part de Narseo Vallina Rodri= guez > Envoy=C3=A9 : mardi 10 f=C3=A9vrier 2015 08:34 > =C3=80 : Ron Parker > Cc : sfc@ietf.org > Objet : Re: [sfc] [GRAYMAIL] Re: HTTP Header injection > > Hi Ron > > Thanks a lot for your explanation. I get better the point that you > were trying to make so I understand your position and I'm starting to > get a better picture of the whole draft. > > I would appreciate other's opinions about why such headers may be > needed, in particular in the mobile scenario, and how the associated > privacy issues that today exist will be addressed. > > Many thanks again > > > > On Mon, Feb 9, 2015 at 4:54 PM, Ron Parker > wrote: >> Narseo, >> >> The point I was trying to make is that the use of the SFC encapsulation = metadata within the carrier's administrative domain, instead of HTTP header= enrichment, will address these security considerations. The current SFC = architecture states that it is supported within a single administrative dom= ain with inter-domain SFC for further study. Stated another way, end-to-e= nd SFC is not supported. >> >> Ron >> >> >> ________________________________________ >> From: Narseo Vallina Rodriguez [narseo@icsi.berkeley.edu] >> Sent: Monday, February 09, 2015 7:26 PM >> To: Ron Parker >> Cc: sfc@ietf.org >> Subject: Re: [GRAYMAIL] Re: [sfc] HTTP Header injection >> >> Hi Ron >> >> Thanks for the explanation. I still have some concerns about the >> header enrichment that may be worth discussing further. Let me respond >> inline. >> >>> The HTTP X-headers related to identification are typically inserted by = the Subscriber Management System for the benefit of transparent midboxes su= ch as video optimizers, IDS/IPS, Firewall, etc. The fact that it goes all= the way to the origin server is sometimes incidental. >>> >> >> That's exactly my main concern. The first example for SFC use cases in >> mobile networks is functions to protect the carrier network and the >> privacy of its users. This is contradictory with many other parts of >> the draft as in the case that we're discussing unless there are other >> reasons behind such as monetizing user's metadata. >> >> If not, why is this information leaving the network and reaching the >> origin server without any control given how sensitive it is? >> >> As you frame it, it sounds like End-to-End SFC is not the goal in this >> case. If so, aren't better ways of doing performance enhancement as in >> the video streaming case without leaking personal data as using >> "differential" values rather than unique absolute ones on a per-user >> basis? >> >> From my perspective, adding these headers does not add much value to >> the whole chain, but still present a serious privacy concern for most >> users so that's why I would like to know about a real use case in >> which the uncontrolled leak beyond the scope of the operator (and the >> addition of the headers) is completely justify. >> >> Just for reference, we have identified the following headers added by >> mobile proxies. We have records going back to November 2013 >> >> The 3 headers listed below are perma-cookies (the EFF showed their >> concerns with such headers), which do not map to any unique identifier >> such as IMEI/IMSI but they still identify the user uniquely. We have >> observed them in a bunch of operators all over the world. >> >> x-acr >> X-UIDH >> X-VF-ACR >> >> The headers below leak directly raw values without any anonymization >> as you proposed, thus becoming serious privacy leaks. In fact, these >> are some of the values that are listed on the draft as possible values >> to be included, which is worrying and also contradicting the privacy >> preserving use case. >> >> LBS-EventTime: Header probably related to location-based services. >> LBS-ZoneID: Idem >> MSISDN: Subscriber phone number. >> x-up-3gpp-imeisv: Device IMEI. Identifies the device uniquely. >> x-up-nai: Email-like name that identifies the user and operator. >> x-up-calling-line-id: Subscriber phone number. >> x-up-vodacomgw-subid: Subscriber phone number. >> >>> But, this technique is limited to only clear-text HTTP. As end-to-end= HTTPS increases, the portion of flows that can be enriched in this manner = decreases. >>> >> >> Still, a large fraction of users' traffic is still HTTP, as in the >> case of ad-traffic that actually involve more than one party. Just >> check a normal online newspaper or magazine. As a result, this >> information is being collected by an uncontrolled number of online >> services. Some of them, may not be trustworthy. >> >>> SFC has the potential to solve the problem of providing policy hooks to= midboxes in a more universal and elegant fashion through the use of the me= tadata capabilities inherent in the SFC encapsulation header. >>> >> >> So is the point to enable E2E SFC? Once more, couldn't this be done >> without enabling users' tracking and leaking their personal data? >> >> How will middleboxes take advantage of them if the x-headers are not >> standardised and are highly customized by operators and proxy >> manufacturers? >> > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Tue Feb 17 20:01:11 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 4088D1A8987; Tue, 17 Feb 2015 20:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppFk83o5DCoD; Tue, 17 Feb 2015 20:01:04 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 60B3E1A8981; Tue, 17 Feb 2015 20:00:58 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id uz6so61065760obc.9; Tue, 17 Feb 2015 20:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UGo4HUSeVrK+VEae7D6yJDFaAQgVL8/My8Wgt5ujww4=; b=JMH/KzVkNd4aHY5dFdW4nahZWedNNaBUSVjRuzMJ06/1NUVUABmiXk0vqFOKOZOkpH v3kCNfz3SWyBty6j+QZsFoT/7w6Za8v+PhuOSWdZorRXiX9qz4Ug8jR6aehVU+1j9MUO Ag15bcyxdzPWhn6cBEfvmqiiPGXhXM+DEoLqeirJzxNyAIPVb5t2oT7Z9sbZtgJIE4XJ t9fqV9Zta3H5HFGFIRmH6gcQQhwPO7pVV7IW99vCYXqSDU3M7MDkaG04QiAgoi2DM/g7 1Q8P0H/JFuc8wpXK+v4s1BsJGma8imBMPOTlupet6hAJWdyTMqxxG9B2d5whV7xTsvoq GDKw== MIME-Version: 1.0 X-Received: by 10.60.57.9 with SMTP id e9mr20949325oeq.24.1424232057658; Tue, 17 Feb 2015 20:00:57 -0800 (PST) Received: by 10.60.94.20 with HTTP; Tue, 17 Feb 2015 20:00:57 -0800 (PST) In-Reply-To: <20150217233754.22143.41495.idtracker@ietfa.amsl.com> References: <20150217233754.22143.41495.idtracker@ietfa.amsl.com> Date: Tue, 17 Feb 2015 23:00:57 -0500 Message-ID: From: Alia Atlas To: Kathleen Moriarty Content-Type: multipart/alternative; boundary=089e0149c4a8dfe50b050f54dd5c Archived-At: Cc: draft-ietf-sfc-problem-statement@ietf.org, "Joel M. Halpern" , sfc-chairs@ietf.org, The IESG , "sfc@ietf.org" Subject: Re: [sfc] Kathleen Moriarty's No Objection on draft-ietf-sfc-problem-statement-12: (with COMMENT) 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, 18 Feb 2015 04:01:07 -0000 --089e0149c4a8dfe50b050f54dd5c Content-Type: text/plain; charset=UTF-8 Paul, Have you looked at and considered Kathleen's comments? Thanks for the hard work so far, Alia On Tue, Feb 17, 2015 at 6:37 PM, Kathleen Moriarty < Kathleen.Moriarty.ietf@gmail.com> wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-sfc-problem-statement-12: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for addressing my question on multi-tenancy and adding in text to > describe how that could be handled. > > I agree with Barry, Alissa, and maybe others that a wiki may be a better > option, but I won't stand in the way of publication. I do think the > problem SFC is working on is important and the work will be worthwhile, > but this draft isn't ready ready or may not need to be published. > > There are still numerous security considerations to be included as > pointed out in the SecDir review and in Stephen's DISCUSS points that I > support. > > The draft mentions ordering for service functions, and it would be good > to see some concrete examples of how security may be an issue with > different options for ordering. Since SFC's scope is a single > administrative domain, the service chaining could result in session > decryption at various points in the chain that could result in security > and privacy exposures within that domain (typically considered a > manageable risk). Functionality may be limited for some of the service > functions if the decryption does not happen prior to that point and risk > prioritization will be necessary (exposure of data, session interception, > corruption of data, etc. could result from this exposure) since this is > likely to be used in hosted environments with multiple tenants. The > SecDir review did mention crossover between management/control and data > planes, but tenant isolation may also need to be mentioned. > > Some nits (I don't think others mentioned these, but sorry if they were > already addressed): > Section 2.1: 3rd paragraph: > Is this intended to mean after a new service function is added? I can't > imagine that this our happen on the fly, so I think that's the case and > adding a word or two may help: > from: > As more service functions are required - often with strict ordering - > topology changes are needed before and after each service function is > added > resulting in complex network changes and device configuration. > > 4th paragraph: I'm have trouble reading this paragraph as I think it > contradicts itself, but the example in the following paragraph is > helpful. If topology dictates placement, how could using topology not be > viable? Maybe rewording it would help: > The topological coupling limits placement and selection of service > functions: service functions are "fixed" in place by topology and > therefore placement and service function selection taking into > account network topology information is not viable. Furthermore, > altering the services traversed, or their order, based on flow > direction is not possible. > > Thanks, > Kathleen > > > --089e0149c4a8dfe50b050f54dd5c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Paul,

Have you looked at and considered= Kathleen's comments?

Thanks for the hard work= so far,
Alia

On Tue, Feb 17, 2015 at 6:37 PM, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com> wrote:
Kathleen Moriarty has entered the following ballo= t position for
draft-ietf-sfc-problem-statement-12: No Objection

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


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-sfc-problem= -statement/



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

Thanks for addressing my question on multi-tenancy and adding in text to describe how that could be handled.

I agree with Barry, Alissa, and maybe others that a wiki may be a better option, but I won't stand in the way of publication.=C2=A0 I do think t= he
problem SFC is working on is important and the work will be worthwhile,
but this draft isn't ready ready or may not need to be published.

There are still numerous security considerations to be included as
pointed out in the SecDir review and in Stephen's DISCUSS points that I=
support.

The draft mentions ordering for service functions, and it would be good
to see some concrete examples of how security may be an issue with
different options for ordering.=C2=A0 Since SFC's scope is a single
administrative domain, the service chaining could result in session
decryption at various points in the chain that could result in security
and privacy exposures within that domain (typically considered a
manageable risk).=C2=A0 =C2=A0Functionality may be limited for some of the = service
functions if the decryption does not happen prior to that point and risk prioritization will be necessary (exposure of data, session interception, corruption of data, etc. could result from this exposure) since this is
likely to be used in hosted environments with multiple tenants.=C2=A0 The SecDir review did mention crossover between management/control and data
planes, but tenant isolation may also need to be mentioned.

Some nits (I don't think others mentioned these, but sorry if they were=
already addressed):
Section 2.1: 3rd paragraph:
Is this intended to mean after a new service function is added?=C2=A0 I can= 't
imagine that this our happen on the fly, so I think that's the case and=
adding a word or two may help:
from:
=C2=A0 =C2=A0As more service functions are required - often with strict ord= ering -
=C2=A0 =C2=A0topology changes are needed before and after each service func= tion is
added
=C2=A0 =C2=A0resulting in complex network changes and device configuration.=

4th paragraph:=C2=A0 I'm have trouble reading this paragraph as I think= it
contradicts itself, but the example in the following paragraph is
helpful.=C2=A0 If topology dictates placement, how could using topology not= be
viable?=C2=A0 Maybe rewording it would help:
=C2=A0 =C2=A0The topological coupling limits placement and selection of ser= vice
=C2=A0 =C2=A0functions: service functions are "fixed" in place by= topology and
=C2=A0 =C2=A0therefore placement and service function selection taking into=
=C2=A0 =C2=A0account network topology information is not viable.=C2=A0 Furt= hermore,
=C2=A0 =C2=A0altering the services traversed, or their order, based on flow=
=C2=A0 =C2=A0direction is not possible.

Thanks,
Kathleen



--089e0149c4a8dfe50b050f54dd5c-- From nobody Tue Feb 17 22:25:44 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 7751C1A870F for ; Tue, 17 Feb 2015 22:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, 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 In9loVLv_9oh for ; Tue, 17 Feb 2015 22:25:41 -0800 (PST) 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 CC6C41A6FF3 for ; Tue, 17 Feb 2015 22:25:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11036; q=dns/txt; s=iport; t=1424240740; x=1425450340; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=U/ifcjzehMxnX5EZefwj/7MhphpXwy48A7Q9HQpbSd4=; b=iwh8M3Y8xGNDjGng1cd6ha3jSOT0gsi8ZhBm++pOe/oljLfjU5ywZ2ou H/Bc9t8EfiwMICKRyAESheSEOnDEEM2EUjGA1tCcfZFnh5KbLp9Ujn9JY XAx3lFhpJXNIg35yhODU2MK4xc22gt/DuY3f4d1xN1+DYkaG4NFdZwkFB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B9BQCbL+RU/5pdJa1RCg6CeFJagwO/SQyFbwKBHkMBAQEBAQF8hAwBAQEDAQEBASBEBwsQCxEBAwEBAQICIwMCAicfAwYIBg8EG4gMCA24bpdvAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiHB+hAwGBAcBHTMHgmgugRQFijqIVYITg02BGDiCVYIqIYhfgz4igzFeHTEBgQEJF4EhAQEB X-IronPort-AV: E=Sophos;i="5.09,595,1418083200"; d="scan'208";a="124591260" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP; 18 Feb 2015 06:25:39 +0000 Received: from [10.24.217.190] ([10.24.217.190]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t1I6PcIg028188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2015 06:25:38 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= In-Reply-To: Date: Tue, 17 Feb 2015 22:25:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <621061CE-2C4A-460A-8A42-8E4C5B39E461@cisco.com> References: To: Narseo Vallina Rodriguez X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "Stiemerling, Martin, Prof. Dr. \(martin.stiemerling@h-da.de\)" , "Haeffner, Walter, Vodafone DE" , Ron Parker , "sfc@ietf.org" Subject: Re: [sfc] HTTP Header injection 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, 18 Feb 2015 06:25:43 -0000 On 10-Feb-2015 05:06 PM, Narseo Vallina Rodriguez = wrote: >=20 > Dear Walter >=20 > Thanks a lot for your response. It's actually a pleasure to read the > draft and I think it has some very interesting points. I'd also love > to read Martin Stiemerling's thoughts if they are available somewhere. >=20 > A few weeks ago, we wrote a short blog post about our view on HTTP > header injection at a global scale. >=20 > http://netalyzr.icsi.berkeley.edu/blog/ >=20 > We're working to extend it as paper that will be submitted this month. > Of course, any feedback and comments, specially different views that > may not be under our radar, will be very welcome! >=20 > In your response, you mention real use-cases. As you can see in the > blog post, we have found a diverse array of headers that are used for > a wide range of actions. Some of them could be used to illustrate the > benefits of header enrichment or to describe some use cases rather > than including use-cases involving very sensitive information such as > the IMEI/IMSI or even Perma-cookies. For instance the headers > reporting the transport-layer protocol may be a nice use case. >=20 > I personally think that the draft should clearly say that this > information MUST NOT leave the actual domain of the operator in order > to prevent user tracking by 3rd party services. It could be written in > the same way that the HTTP standard says that any proxy MUST advertise > its presence using the VIA field (BTW, only a small fraction of the > mobile proxies we've seen deployed in real networks does actually > include the standard VIA field). One more thought is that given that > the headers are in plain HTTP text, what does prevent a client from > impersonating someone else, specially for charging purposes, by adding > their own headers? >=20 > So to sum up, a nice definition of what kind of information is privacy > sensitive could be useful, specially in the mobile use case. That > would be better than leaving the decision to the operator's or proxy > vendor judgement. Could that be possible? Another point to make is > that enriching such headers is OK as long as they do not leave the > operator's domain as Ron suggested. >=20 > The US senate as well as the FCC are also showed their concerns on the > use of perma cookies and other header enrichment techniques: >=20 > = https://www.eff.org/deeplinks/2015/02/under-senate-pressure-verizon-improv= es-its-supercookie-opt-out The problem is not permacookies or header 'enrichment', which is merely = today's technology. Rather, the problem is identifying that a flow = belongs to a user. That identification could be done with other = technological means (including something akin to a modern IDENT, see the = historic IDENT at RFC1413). It could be done with IPv6 addresses (if the = IPv6 prefix is assigned to a user, as is typical). It could be done = with IPv4 addresses (if IPv4 address is assigned to a user's home, as is = typical with wired residential addresses). It could be done with TCP or = IP options (draft-wing-nat-reveal-option, = draft-williams-exp-tcp-host-id-opt). Stepping back to analyze how and why such flow identification are = desired by network operators, and how to approach a solution in our = standards, would be useful to avoid the privacy concerns. Including the = privacy harm caused by IPv6 (and helped by IPv4 address sharing such as = CGNs), which many IETFers are reluctant to acknowledge. -d >=20 >=20 > On Tue, Feb 10, 2015 at 4:06 AM, Haeffner, Walter, Vodafone DE > wrote: >> Dear Narseo, dear Ron, >>=20 >> Narseo, thanks for reading and commenting the draft. And thanks to = Ron for the explanations. >>=20 >> Indeed, some days ago one of the co-authors (Martin Stiemerling) = mentioned that HTTP Header Enrichment may come under attack. I will = include a statement w.r.t. your security concerns. But as pointed out by = Ron, the security issues are even more general. And we probably could = have the same discussion with SIP P-Headers; or with any = subscriber-related data exchanged between different carriers and ISPs. >>=20 >> Our intension for the mobility use case draft was to list a short = number of representative SFC use cases which are widely in place but we = didn't rate them w.r.t. security. For sure, you are right, the listed = use cases are not very coherent w.r.t. security requirements. But that = is what you currently find out there in the networks. >>=20 >> I will check, if the SFC problem statement draft includes such = security concerns. This is probably the best place for the privacy = issues. At least, the SFC architecture draft includes a paragraph: >>=20 >> "An operator may consider the SFC Metadata as sensitive. Therefore, >> solutions should consider whether there is a risk of sensitive >> information slipping out of the operators control." >>=20 >> Narseo, if you have a proposal to improve the text, please feel free = to send it over. >>=20 >> Best regards, >> Walter >>=20 >> -----Urspr=C3=BCngliche Nachricht----- >> Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Narseo Vallina = Rodriguez >> Gesendet: Dienstag, 10. Februar 2015 08:34 >> An: Ron Parker >> Cc: sfc@ietf.org >> Betreff: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection >>=20 >> Hi Ron >>=20 >> Thanks a lot for your explanation. I get better the point that you = were trying to make so I understand your position and I'm starting to = get a better picture of the whole draft. >>=20 >> I would appreciate other's opinions about why such headers may be = needed, in particular in the mobile scenario, and how the associated = privacy issues that today exist will be addressed. >>=20 >> Many thanks again >>=20 >>=20 >>=20 >> On Mon, Feb 9, 2015 at 4:54 PM, Ron Parker = wrote: >>> Narseo, >>>=20 >>> The point I was trying to make is that the use of the SFC = encapsulation metadata within the carrier's administrative domain, = instead of HTTP header enrichment, will address these security = considerations. The current SFC architecture states that it is = supported within a single administrative domain with inter-domain SFC = for further study. Stated another way, end-to-end SFC is not = supported. >>>=20 >>> Ron >>>=20 >>>=20 >>> ________________________________________ >>> From: Narseo Vallina Rodriguez [narseo@icsi.berkeley.edu] >>> Sent: Monday, February 09, 2015 7:26 PM >>> To: Ron Parker >>> Cc: sfc@ietf.org >>> Subject: Re: [GRAYMAIL] Re: [sfc] HTTP Header injection >>>=20 >>> Hi Ron >>>=20 >>> Thanks for the explanation. I still have some concerns about the >>> header enrichment that may be worth discussing further. Let me = respond >>> inline. >>>=20 >>>> The HTTP X-headers related to identification are typically inserted = by the Subscriber Management System for the benefit of transparent = midboxes such as video optimizers, IDS/IPS, Firewall, etc. The fact = that it goes all the way to the origin server is sometimes incidental. >>>>=20 >>>=20 >>> That's exactly my main concern. The first example for SFC use cases = in >>> mobile networks is functions to protect the carrier network and the >>> privacy of its users. This is contradictory with many other parts of >>> the draft as in the case that we're discussing unless there are = other >>> reasons behind such as monetizing user's metadata. >>>=20 >>> If not, why is this information leaving the network and reaching the >>> origin server without any control given how sensitive it is? >>>=20 >>> As you frame it, it sounds like End-to-End SFC is not the goal in = this >>> case. If so, aren't better ways of doing performance enhancement as = in >>> the video streaming case without leaking personal data as using >>> "differential" values rather than unique absolute ones on a per-user >>> basis? >>>=20 >>> =46rom my perspective, adding these headers does not add much value = to >>> the whole chain, but still present a serious privacy concern for = most >>> users so that's why I would like to know about a real use case in >>> which the uncontrolled leak beyond the scope of the operator (and = the >>> addition of the headers) is completely justify. >>>=20 >>> Just for reference, we have identified the following headers added = by >>> mobile proxies. We have records going back to November 2013 >>>=20 >>> The 3 headers listed below are perma-cookies (the EFF showed their >>> concerns with such headers), which do not map to any unique = identifier >>> such as IMEI/IMSI but they still identify the user uniquely. We have >>> observed them in a bunch of operators all over the world. >>>=20 >>> x-acr >>> X-UIDH >>> X-VF-ACR >>>=20 >>> The headers below leak directly raw values without any anonymization >>> as you proposed, thus becoming serious privacy leaks. In fact, these >>> are some of the values that are listed on the draft as possible = values >>> to be included, which is worrying and also contradicting the privacy >>> preserving use case. >>>=20 >>> LBS-EventTime: Header probably related to location-based services. >>> LBS-ZoneID: Idem >>> MSISDN: Subscriber phone number. >>> x-up-3gpp-imeisv: Device IMEI. Identifies the device uniquely. >>> x-up-nai: Email-like name that identifies the user and operator. >>> x-up-calling-line-id: Subscriber phone number. >>> x-up-vodacomgw-subid: Subscriber phone number. >>>=20 >>>> But, this technique is limited to only clear-text HTTP. As = end-to-end HTTPS increases, the portion of flows that can be enriched in = this manner decreases. >>>>=20 >>>=20 >>> Still, a large fraction of users' traffic is still HTTP, as in the >>> case of ad-traffic that actually involve more than one party. Just >>> check a normal online newspaper or magazine. As a result, this >>> information is being collected by an uncontrolled number of online >>> services. Some of them, may not be trustworthy. >>>=20 >>>> SFC has the potential to solve the problem of providing policy = hooks to midboxes in a more universal and elegant fashion through the = use of the metadata capabilities inherent in the SFC encapsulation = header. >>>>=20 >>>=20 >>> So is the point to enable E2E SFC? Once more, couldn't this be done >>> without enabling users' tracking and leaking their personal data? >>>=20 >>> How will middleboxes take advantage of them if the x-headers are not >>> standardised and are highly customized by operators and proxy >>> manufacturers? >>>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Feb 17 23:37: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 689E31A9110 for ; Tue, 17 Feb 2015 23:37:32 -0800 (PST) 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 Q6a1s0Vcg6Ky for ; Tue, 17 Feb 2015 23:37:29 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039421A911A for ; Tue, 17 Feb 2015 23:37:29 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 39381324305; Wed, 18 Feb 2015 08:37:27 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 193A94C056; Wed, 18 Feb 2015 08:37:27 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Wed, 18 Feb 2015 08:37:27 +0100 From: To: Narseo Vallina Rodriguez Thread-Topic: [sfc] [GRAYMAIL] Re: HTTP Header injection Thread-Index: AQHQSyEfgfqCyWvkCkuMIcXaVZd/wZz2AmhQ Date: Wed, 18 Feb 2015 07:37:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300490D51F@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B93300490AE24@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.18.30917 Archived-At: Cc: Ron Parker , "sfc@ietf.org" Subject: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection 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, 18 Feb 2015 07:37:32 -0000 SGkgTmFyc2VvLA0KDQoiU2Vuc2l0aXZlIiBoZWFkZXJzIG5lZWQgdG8gYmUgc3RyaXBwZWQgYmVm b3JlIGV4aXN0aW5nIHRoZSBQTE1OLiBJIHRoaW5rIG1vc3Qgb2YgdGhlIGNhc2VzIGNhbiAiZGlz YXBwZWFyIiBmcm9tIHRoZSBwdWJsaWMgSW50ZXJuZXQgYnkgYWxlcnRpbmcgdGhvc2Ugb3BlcmF0 b3JzLiBIZWFkZXJzIEknbSBhd2FyZSBvZiBhcmUgaW5qZWN0ZWQgZm9yIGEgc2VydmljZSB1c2Fn ZSB0aGF0IGlzIGxvY2FsIHRvIGEgUExNTi4gSXQgbWF5IGhhcHBlbiB0aGF0IGFuIGluZm9ybWF0 aW9uIGlzIGxlYWtlZCBvdXRzaWRlIHRoZSBkb21haW4gZHVlIHRvIHZhcmlvdXMgcmVhc29ucy4g DQoNClVuZGVyc3RhbmRpbmcgdGhlIHByaXZhY3kgaW1wbGljYXRpb25zIG9mIGEgaGVhZGVyIHJl cXVpcmVzIHVuZGVyc3RhbmRpbmcgdGhlIHNlcnZpY2UgbW90aXZhdGlvbiBhdCBmaXJzdCBwbGFj ZS4gVW5mb3J0dW5hdGVseSwgdGhlIElFVEYgaXMgc3RpbGwgcmVzaXN0aW5nIHRvIHdvcmsgb24g c3VjaCB0b3BpY3MgZXZlbiBpZiAiRm9yd2FyZCIgd2FzIHB1Ymxpc2hlZCByZWNlbnRseTogaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzIzOSBvciB0aGUgYW5hbHlzaXMgaW4gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY5NjcuIA0KDQpDaGVlcnMsDQpNZWQNCg0KLS0tLS1N ZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQpEZcKgOiBOYXJzZW8gVmFsbGluYSBSb2RyaWd1ZXogW21h aWx0bzpuYXJzZW9AaWNzaS5iZXJrZWxleS5lZHVdIA0KRW52b3nDqcKgOiBtZXJjcmVkaSAxOCBm w6l2cmllciAyMDE1IDAzOjE4DQrDgMKgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xODQpDY8Kg OiBzZmNAaWV0Zi5vcmc7IFJvbiBQYXJrZXINCk9iamV0wqA6IFJlOiBbc2ZjXSBbR1JBWU1BSUxd IFJlOiBIVFRQIEhlYWRlciBpbmplY3Rpb24NCg0KSGkgTW9oYW1lZA0KDQpUaGFua3MgYSBsb3Qg Zm9yIHRoZSBwb2ludGVyLiBUaGF0IGV4cGxhaW5zIHRoZSByZWFzb24gd2h5IGNlcnRhaW4NCmhl YWRlcnMgbWF5IGJlIHVzZWZ1bCBidXQgc3RpbGwgZG9lcyBub3QgYW5zd2VyIHdoeSBzb21lIHBy aXZhY3kNCnNlbnNpdGl2ZSBoZWFkZXJzIGFyZSBleHBsaWNpdGx5IGxpc3RlZCBvbiB0aGUgbW9i aWxlIHVzZSBjYXNlLg0KDQpBcmUgdGhlcmUgYW55IGV4YW1wbGVzIGFib3V0IHRoZSBwcml2YWN5 IHNlbnNpdGl2ZSBoZWFkZXJzPw0KDQoNCg0KDQpPbiBGcmksIEZlYiAxMywgMjAxNSBhdCA2OjEy IEFNLCAgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+IHdyb3RlOg0KPiBEZWFyIE5hcnNl bywNCj4NCj4gQW4gZXhhbXBsZSB0byBpbGx1c3RyYXRlIHRoZSBuZWVkIHRvIGluamVjdCBhIGhl YWRlciBpbiBhIG1vYmlsZSBuZXR3b3JrIChvdGhlciB0aGFuIHRob3NlIHNpbWlsYXIgdG8gSFRU UF9NU0lTRE4sIEhUVFBfWF9NU0lTRE4sIEhUVFBfWF9VUF9DQUxMSU5HX0xJTkVfSUQsIEhUVFBf WF9OT0tJQV9NU0lTRE4sIEhUVFBfWF9IVFNfQ0xJRCwgSFRUUF9YX01TUF9DTElELEhUVFBfWF9O WF9DTElELCBIVFRQX1JBUE1JTiwgSFRUUF9YX1dBUF9NU0lTRE4sIEhUVFBfQ09PS0lFLCBIVFRQ X1hfVVBfTFNJRCwgSFRUUF9YX0gzR19NU0lTRE4sIEhUVFBfWF9KSU5OWV9DSUQsIEhUVFBfWF9O RVRXT1JLX0lORk8sIGV0Yy4gKSBpcyBkaXNjdXNzZWQgaW46IGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItaW50YXJlYS1ob3N0LWlkZW50aWZpZXItc2NlbmFyaW9z LTA5I3NlY3Rpb24tMTAuMi4NCj4NCj4gUHJpdmFjeSByZWxhdGVkIGNvbnNpZGVyYXRpb25zIG9m IHRoaXMgdHlwaWNhbCBleGFtcGxlIGFyZSBlbGFib3JhdGVkIGhlcmU6IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM2OTY3I3NlY3Rpb24tMy4NCj4NCj4gQ2hlZXJzLA0KPiBNZWQNCj4N Cj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlIDogc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgTmFyc2VvIFZhbGxpbmEgUm9kcmlndWV6DQo+ IEVudm95w6kgOiBtYXJkaSAxMCBmw6l2cmllciAyMDE1IDA4OjM0DQo+IMOAIDogUm9uIFBhcmtl cg0KPiBDYyA6IHNmY0BpZXRmLm9yZw0KPiBPYmpldCA6IFJlOiBbc2ZjXSBbR1JBWU1BSUxdIFJl OiBIVFRQIEhlYWRlciBpbmplY3Rpb24NCj4NCj4gSGkgUm9uDQo+DQo+IFRoYW5rcyBhIGxvdCBm b3IgeW91ciBleHBsYW5hdGlvbi4gSSBnZXQgYmV0dGVyIHRoZSBwb2ludCB0aGF0IHlvdQ0KPiB3 ZXJlIHRyeWluZyB0byBtYWtlIHNvIEkgdW5kZXJzdGFuZCB5b3VyIHBvc2l0aW9uIGFuZCBJJ20g c3RhcnRpbmcgdG8NCj4gZ2V0IGEgYmV0dGVyIHBpY3R1cmUgb2YgdGhlIHdob2xlIGRyYWZ0Lg0K Pg0KPiBJIHdvdWxkIGFwcHJlY2lhdGUgb3RoZXIncyBvcGluaW9ucyBhYm91dCB3aHkgc3VjaCBo ZWFkZXJzIG1heSBiZQ0KPiBuZWVkZWQsIGluIHBhcnRpY3VsYXIgaW4gdGhlIG1vYmlsZSBzY2Vu YXJpbywgYW5kIGhvdyB0aGUgYXNzb2NpYXRlZA0KPiBwcml2YWN5IGlzc3VlcyB0aGF0IHRvZGF5 IGV4aXN0IHdpbGwgYmUgYWRkcmVzc2VkLg0KPg0KPiBNYW55IHRoYW5rcyBhZ2Fpbg0KPg0KPg0K Pg0KPiBPbiBNb24sIEZlYiA5LCAyMDE1IGF0IDQ6NTQgUE0sIFJvbiBQYXJrZXINCj4gPFJvbl9Q YXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+IHdyb3RlOg0KPj4gTmFyc2VvLA0KPj4NCj4+IFRo ZSBwb2ludCBJIHdhcyB0cnlpbmcgdG8gbWFrZSBpcyB0aGF0IHRoZSB1c2Ugb2YgdGhlIFNGQyBl bmNhcHN1bGF0aW9uIG1ldGFkYXRhIHdpdGhpbiB0aGUgY2FycmllcidzIGFkbWluaXN0cmF0aXZl IGRvbWFpbiwgaW5zdGVhZCBvZiBIVFRQIGhlYWRlciBlbnJpY2htZW50LCB3aWxsIGFkZHJlc3Mg dGhlc2Ugc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuICAgVGhlIGN1cnJlbnQgU0ZDIGFyY2hpdGVj dHVyZSBzdGF0ZXMgdGhhdCBpdCBpcyBzdXBwb3J0ZWQgd2l0aGluIGEgc2luZ2xlIGFkbWluaXN0 cmF0aXZlIGRvbWFpbiB3aXRoIGludGVyLWRvbWFpbiBTRkMgZm9yIGZ1cnRoZXIgc3R1ZHkuICAg U3RhdGVkIGFub3RoZXIgd2F5LCBlbmQtdG8tZW5kIFNGQyBpcyBub3Qgc3VwcG9ydGVkLg0KPj4N Cj4+ICAgICBSb24NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gRnJvbTogTmFyc2VvIFZhbGxpbmEgUm9kcmlndWV6IFtuYXJzZW9AaWNzaS5i ZXJrZWxleS5lZHVdDQo+PiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDA5LCAyMDE1IDc6MjYgUE0N Cj4+IFRvOiBSb24gUGFya2VyDQo+PiBDYzogc2ZjQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTog W0dSQVlNQUlMXSBSZTogW3NmY10gSFRUUCBIZWFkZXIgaW5qZWN0aW9uDQo+Pg0KPj4gSGkgUm9u DQo+Pg0KPj4gVGhhbmtzIGZvciB0aGUgZXhwbGFuYXRpb24uIEkgc3RpbGwgaGF2ZSBzb21lIGNv bmNlcm5zIGFib3V0IHRoZQ0KPj4gaGVhZGVyIGVucmljaG1lbnQgdGhhdCBtYXkgYmUgd29ydGgg ZGlzY3Vzc2luZyBmdXJ0aGVyLiBMZXQgbWUgcmVzcG9uZA0KPj4gaW5saW5lLg0KPj4NCj4+PiBU aGUgSFRUUCBYLWhlYWRlcnMgcmVsYXRlZCB0byBpZGVudGlmaWNhdGlvbiBhcmUgdHlwaWNhbGx5 IGluc2VydGVkIGJ5IHRoZSBTdWJzY3JpYmVyIE1hbmFnZW1lbnQgU3lzdGVtIGZvciB0aGUgYmVu ZWZpdCBvZiB0cmFuc3BhcmVudCBtaWRib3hlcyBzdWNoIGFzIHZpZGVvIG9wdGltaXplcnMsIElE Uy9JUFMsIEZpcmV3YWxsLCBldGMuICAgVGhlIGZhY3QgdGhhdCBpdCBnb2VzIGFsbCB0aGUgd2F5 IHRvIHRoZSBvcmlnaW4gc2VydmVyIGlzIHNvbWV0aW1lcyBpbmNpZGVudGFsLg0KPj4+DQo+Pg0K Pj4gVGhhdCdzIGV4YWN0bHkgbXkgbWFpbiBjb25jZXJuLiBUaGUgZmlyc3QgZXhhbXBsZSBmb3Ig U0ZDIHVzZSBjYXNlcyBpbg0KPj4gbW9iaWxlIG5ldHdvcmtzIGlzIGZ1bmN0aW9ucyB0byBwcm90 ZWN0IHRoZSBjYXJyaWVyIG5ldHdvcmsgYW5kIHRoZQ0KPj4gcHJpdmFjeSBvZiBpdHMgdXNlcnMu IFRoaXMgaXMgY29udHJhZGljdG9yeSB3aXRoIG1hbnkgb3RoZXIgcGFydHMgb2YNCj4+IHRoZSBk cmFmdCBhcyBpbiB0aGUgY2FzZSB0aGF0IHdlJ3JlIGRpc2N1c3NpbmcgdW5sZXNzIHRoZXJlIGFy ZSBvdGhlcg0KPj4gcmVhc29ucyBiZWhpbmQgc3VjaCBhcyBtb25ldGl6aW5nIHVzZXIncyBtZXRh ZGF0YS4NCj4+DQo+PiBJZiBub3QsIHdoeSBpcyB0aGlzIGluZm9ybWF0aW9uIGxlYXZpbmcgdGhl IG5ldHdvcmsgYW5kIHJlYWNoaW5nIHRoZQ0KPj4gb3JpZ2luIHNlcnZlciB3aXRob3V0IGFueSBj b250cm9sIGdpdmVuIGhvdyBzZW5zaXRpdmUgaXQgaXM/DQo+Pg0KPj4gQXMgeW91IGZyYW1lIGl0 LCBpdCBzb3VuZHMgbGlrZSBFbmQtdG8tRW5kIFNGQyBpcyBub3QgdGhlIGdvYWwgaW4gdGhpcw0K Pj4gY2FzZS4gSWYgc28sIGFyZW4ndCBiZXR0ZXIgd2F5cyBvZiBkb2luZyBwZXJmb3JtYW5jZSBl bmhhbmNlbWVudCBhcyBpbg0KPj4gdGhlIHZpZGVvIHN0cmVhbWluZyBjYXNlIHdpdGhvdXQgbGVh a2luZyBwZXJzb25hbCBkYXRhIGFzIHVzaW5nDQo+PiAiZGlmZmVyZW50aWFsIiB2YWx1ZXMgcmF0 aGVyIHRoYW4gdW5pcXVlIGFic29sdXRlIG9uZXMgb24gYSBwZXItdXNlcg0KPj4gYmFzaXM/DQo+ Pg0KPj4gRnJvbSBteSBwZXJzcGVjdGl2ZSwgIGFkZGluZyB0aGVzZSBoZWFkZXJzIGRvZXMgbm90 IGFkZCBtdWNoIHZhbHVlIHRvDQo+PiB0aGUgd2hvbGUgY2hhaW4sIGJ1dCBzdGlsbCBwcmVzZW50 IGEgc2VyaW91cyBwcml2YWN5IGNvbmNlcm4gZm9yIG1vc3QNCj4+IHVzZXJzIHNvIHRoYXQncyB3 aHkgSSB3b3VsZCBsaWtlIHRvIGtub3cgYWJvdXQgYSByZWFsIHVzZSBjYXNlIGluDQo+PiB3aGlj aCB0aGUgdW5jb250cm9sbGVkIGxlYWsgYmV5b25kIHRoZSBzY29wZSBvZiB0aGUgb3BlcmF0b3Ig KGFuZCB0aGUNCj4+IGFkZGl0aW9uIG9mIHRoZSBoZWFkZXJzKSBpcyBjb21wbGV0ZWx5IGp1c3Rp ZnkuDQo+Pg0KPj4gSnVzdCBmb3IgcmVmZXJlbmNlLCB3ZSBoYXZlIGlkZW50aWZpZWQgdGhlIGZv bGxvd2luZyBoZWFkZXJzIGFkZGVkIGJ5DQo+PiBtb2JpbGUgcHJveGllcy4gV2UgaGF2ZSByZWNv cmRzIGdvaW5nIGJhY2sgdG8gTm92ZW1iZXIgMjAxMw0KPj4NCj4+IFRoZSAzIGhlYWRlcnMgbGlz dGVkIGJlbG93IGFyZSBwZXJtYS1jb29raWVzICh0aGUgRUZGIHNob3dlZCB0aGVpcg0KPj4gY29u Y2VybnMgd2l0aCBzdWNoIGhlYWRlcnMpLCB3aGljaCBkbyBub3QgbWFwIHRvIGFueSB1bmlxdWUg aWRlbnRpZmllcg0KPj4gc3VjaCBhcyBJTUVJL0lNU0kgYnV0IHRoZXkgc3RpbGwgaWRlbnRpZnkg dGhlIHVzZXIgdW5pcXVlbHkuIFdlIGhhdmUNCj4+IG9ic2VydmVkIHRoZW0gaW4gYSBidW5jaCBv ZiBvcGVyYXRvcnMgYWxsIG92ZXIgdGhlIHdvcmxkLg0KPj4NCj4+IHgtYWNyDQo+PiBYLVVJREgN Cj4+IFgtVkYtQUNSDQo+Pg0KPj4gVGhlIGhlYWRlcnMgYmVsb3cgbGVhayBkaXJlY3RseSByYXcg dmFsdWVzIHdpdGhvdXQgYW55IGFub255bWl6YXRpb24NCj4+IGFzIHlvdSBwcm9wb3NlZCwgdGh1 cyBiZWNvbWluZyBzZXJpb3VzIHByaXZhY3kgbGVha3MuIEluIGZhY3QsIHRoZXNlDQo+PiBhcmUg c29tZSBvZiB0aGUgdmFsdWVzIHRoYXQgYXJlIGxpc3RlZCBvbiB0aGUgZHJhZnQgYXMgcG9zc2li bGUgdmFsdWVzDQo+PiB0byBiZSBpbmNsdWRlZCwgd2hpY2ggaXMgd29ycnlpbmcgYW5kIGFsc28g Y29udHJhZGljdGluZyB0aGUgcHJpdmFjeQ0KPj4gcHJlc2VydmluZyB1c2UgY2FzZS4NCj4+DQo+ PiBMQlMtRXZlbnRUaW1lOiBIZWFkZXIgcHJvYmFibHkgcmVsYXRlZCB0byBsb2NhdGlvbi1iYXNl ZCBzZXJ2aWNlcy4NCj4+IExCUy1ab25lSUQ6IElkZW0NCj4+IE1TSVNETjogU3Vic2NyaWJlciBw aG9uZSBudW1iZXIuDQo+PiB4LXVwLTNncHAtaW1laXN2OiBEZXZpY2UgSU1FSS4gSWRlbnRpZmll cyB0aGUgZGV2aWNlIHVuaXF1ZWx5Lg0KPj4geC11cC1uYWk6IEVtYWlsLWxpa2UgbmFtZSB0aGF0 IGlkZW50aWZpZXMgdGhlIHVzZXIgYW5kIG9wZXJhdG9yLg0KPj4geC11cC1jYWxsaW5nLWxpbmUt aWQ6IFN1YnNjcmliZXIgcGhvbmUgbnVtYmVyLg0KPj4geC11cC12b2RhY29tZ3ctc3ViaWQ6IFN1 YnNjcmliZXIgcGhvbmUgbnVtYmVyLg0KPj4NCj4+PiBCdXQsIHRoaXMgdGVjaG5pcXVlIGlzIGxp bWl0ZWQgdG8gb25seSBjbGVhci10ZXh0IEhUVFAuICAgQXMgZW5kLXRvLWVuZCBIVFRQUyBpbmNy ZWFzZXMsIHRoZSBwb3J0aW9uIG9mIGZsb3dzIHRoYXQgY2FuIGJlIGVucmljaGVkIGluIHRoaXMg bWFubmVyIGRlY3JlYXNlcy4NCj4+Pg0KPj4NCj4+IFN0aWxsLCBhIGxhcmdlIGZyYWN0aW9uIG9m IHVzZXJzJyB0cmFmZmljIGlzIHN0aWxsIEhUVFAsIGFzIGluIHRoZQ0KPj4gY2FzZSBvZiBhZC10 cmFmZmljIHRoYXQgYWN0dWFsbHkgaW52b2x2ZSBtb3JlIHRoYW4gb25lIHBhcnR5LiBKdXN0DQo+ PiBjaGVjayBhIG5vcm1hbCBvbmxpbmUgbmV3c3BhcGVyIG9yIG1hZ2F6aW5lLiBBcyBhIHJlc3Vs dCwgdGhpcw0KPj4gaW5mb3JtYXRpb24gaXMgYmVpbmcgY29sbGVjdGVkIGJ5IGFuIHVuY29udHJv bGxlZCBudW1iZXIgb2Ygb25saW5lDQo+PiBzZXJ2aWNlcy4gU29tZSBvZiB0aGVtLCBtYXkgbm90 IGJlIHRydXN0d29ydGh5Lg0KPj4NCj4+PiBTRkMgaGFzIHRoZSBwb3RlbnRpYWwgdG8gc29sdmUg dGhlIHByb2JsZW0gb2YgcHJvdmlkaW5nIHBvbGljeSBob29rcyB0byBtaWRib3hlcyBpbiBhIG1v cmUgdW5pdmVyc2FsIGFuZCBlbGVnYW50IGZhc2hpb24gdGhyb3VnaCB0aGUgdXNlIG9mIHRoZSBt ZXRhZGF0YSBjYXBhYmlsaXRpZXMgaW5oZXJlbnQgaW4gdGhlIFNGQyBlbmNhcHN1bGF0aW9uIGhl YWRlci4NCj4+Pg0KPj4NCj4+IFNvIGlzIHRoZSBwb2ludCB0byBlbmFibGUgRTJFIFNGQz8gT25j ZSBtb3JlLCBjb3VsZG4ndCB0aGlzIGJlIGRvbmUNCj4+IHdpdGhvdXQgZW5hYmxpbmcgdXNlcnMn IHRyYWNraW5nIGFuZCBsZWFraW5nIHRoZWlyIHBlcnNvbmFsIGRhdGE/DQo+Pg0KPj4gSG93IHdp bGwgbWlkZGxlYm94ZXMgdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlbSBpZiB0aGUgeC1oZWFkZXJzIGFy ZSBub3QNCj4+IHN0YW5kYXJkaXNlZCBhbmQgYXJlIGhpZ2hseSBjdXN0b21pemVkIGJ5IG9wZXJh dG9ycyBhbmQgcHJveHkNCj4+IG1hbnVmYWN0dXJlcnM/DQo+Pg0KPg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+ IHNmY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm Yw0KPg0K From nobody Wed Feb 18 04:33:42 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3B21A882F; Wed, 18 Feb 2015 04:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 NFY810TZ42bV; Wed, 18 Feb 2015 04:33:33 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4BA1A1A9A; Wed, 18 Feb 2015 04:32:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218123251.13051.28502.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 04:32:51 -0800 Archived-At: Cc: draft-ietf-sfc-problem-statement@ietf.org, jmh@joelhalpern.com, sfc-chairs@ietf.org, sfc@ietf.org Subject: [sfc] Benoit Claise's No Objection on draft-ietf-sfc-problem-statement-12: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2015 12:33:35 -0000 Benoit Claise has entered the following ballot position for draft-ietf-sfc-problem-statement-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - A little bit disappointed that there are no much operational aspects in this problem statement. I guess this is fine as the charter contains: 5. Manageability: Work on the management and configuration of SFC components related to the support of Service Function Chaining will certainly be needed, but first needs to be better understood and scoped. However, the goal for SFC is to reduce the OPEX. For this to happen, the operational aspects (Troubleshooting and OAM come to mind) can not be an afterthought. - I can't parse supports the movement of service functions and application workloads in the existing network, all the while retaining the network and service policies and the ability to easily bind service policy to granular information such as per-subscriber state. - OLD: Service Function Chain (SFC): A service function chain defines an ordered or partially ordered set of abstract service functions (SFs) NEW: Service Function Chain (SFC): A service function chain defines an ordered or partially ordered set of abstract service functions OLD: Service Function: A function that is responsible for specific NEW: Service Function (SF): A function that is responsible for specific - In the Service Function Chain definition, I'm not sure how the sentence "An example of an abstract service function is "a firewall" helps the SFC definition. Anyway, this is covered in the Service Function definition. From nobody Wed Feb 18 06:55: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 B88FC1A8952 for ; Wed, 18 Feb 2015 06:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.597 X-Spam-Level: ** X-Spam-Status: No, score=2.597 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kss4yGuzjrOW for ; Wed, 18 Feb 2015 06:55:46 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 058D81A8932 for ; Wed, 18 Feb 2015 06:55:45 -0800 (PST) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t1IEtjQC023980 for ; Wed, 18 Feb 2015 23:55:45 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 618095F593 for ; Wed, 18 Feb 2015 23:55:45 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 4A5765F591 for ; Wed, 18 Feb 2015 23:55:45 +0900 (JST) Received: from [IPv6:::1] ([129.60.13.28]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t1IEtZWc004033 for ; Wed, 18 Feb 2015 23:55:45 +0900 Message-ID: <54E4A82E.1060801@lab.ntt.co.jp> Date: Wed, 18 Feb 2015 23:56:46 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit To: "sfc@ietf.org" X-TM-AS-MML: disable Archived-At: Subject: [sfc] Introduction of SFC interconnectability testing 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, 18 Feb 2015 14:55:47 -0000 Hi all, I would like to introduce our attempt for SFC. We had succeeded SFC interconnectability testing by six companies, and will exhibit the demo in NTT R&D forum which will be held from 19th to 20th February in Japan. In the demo, we will exhibit three use cases which show advantages of SFC. The detail of the interconnectability testing is described in the following web page: http://www.ntt.co.jp/news2015/1502e/150212a.html Also, we submitted the demo to NFV as PoC and it was accepted. It is published as PoC#33 last week. The PoC document describes the use cases of the demo. Cheers, Shunsuke -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service System Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Wed Feb 18 12:36:16 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 935A41A1A4B; Wed, 18 Feb 2015 12:36:12 -0800 (PST) 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 mAT7cOe2235k; Wed, 18 Feb 2015 12:36:10 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D710F1A1A59; Wed, 18 Feb 2015 12:35:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11054; q=dns/txt; s=iport; t=1424291750; x=1425501350; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=53tYE+MED1a16Ci85BidC0GH+U44DKSraomJZ0L+iPA=; b=CFP9cDsP7sEXOu7J1+VjtS+b70rT6G8JXI09Av6ajAuY61Pp8akEM6l5 koyM4enDB2CvG6//Aasu2GAt3ziNVvpEajdTfsDyUYNQdvOf6M6Wf4XCa hybvcoUgeBYbTS84D6koseY2fk71NX/qS6VtXeL/qI9DFAWjSOI9pafg4 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DjBgBV9uRU/4oNJK1bgwZSWgSDBLAnjUOBboVxAhyBA0MBAQEBAQF8hA0BAQQjVhACAQYCDh8SAwICAh8RFBECBA4FCYgSAxENnWGcbJJ4DYU5AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sPgkSBSBEBUAcCCIJeLoEUBYVeh3iBbYNZghaCB4FGgRk4gleGPoIohgQigjKBPG8BgQo5fwEBAQ X-IronPort-AV: E=Sophos;i="5.09,603,1418083200"; d="scan'208,217";a="124825035" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-5.cisco.com with ESMTP; 18 Feb 2015 20:35:49 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t1IKZmdv026630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 18 Feb 2015 20:35:49 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Wed, 18 Feb 2015 14:35:48 -0600 From: "Paul Quinn (paulq)" To: Alia Atlas Thread-Topic: [sfc] Kathleen Moriarty's No Objection on draft-ietf-sfc-problem-statement-12: (with COMMENT) Thread-Index: AQHQSwrHKc61Wc8NBE+e4iLhJSdBupz2LX6AgAEV9IA= Date: Wed, 18 Feb 2015 20:35:48 +0000 Message-ID: References: <20150217233754.22143.41495.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: multipart/alternative; boundary="_000_D98D572767D848788ADF284266AB695Aciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-problem-statement@ietf.org" , Kathleen Moriarty , The IESG , "Joel M. Halpern" Subject: Re: [sfc] Kathleen Moriarty's No Objection on draft-ietf-sfc-problem-statement-12: (with COMMENT) 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, 18 Feb 2015 20:36:12 -0000 --_000_D98D572767D848788ADF284266AB695Aciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxpYSwNCg0KWWVzLCB0aGV5IHdlcmUgbGFyZ2VseSBhZGRyZXNzZWQgaW4gdGhlIHByZXZpb3Vz IHJldi4gIFNwZWNpZmljIGNvbW1lbnRzIGJlbG93Lg0KDQpUaGFua3MhDQpQYXVsDQoNCk9uIEZl YiAxNywgMjAxNSwgYXQgMTE6MDAgUE0sIEFsaWEgQXRsYXMgPGFrYXRsYXNAZ21haWwuY29tPG1h aWx0bzpha2F0bGFzQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpQYXVsLA0KDQpIYXZlIHlvdSBsb29r ZWQgYXQgYW5kIGNvbnNpZGVyZWQgS2F0aGxlZW4ncyBjb21tZW50cz8NCg0KVGhhbmtzIGZvciB0 aGUgaGFyZCB3b3JrIHNvIGZhciwNCkFsaWENCg0KT24gVHVlLCBGZWIgMTcsIDIwMTUgYXQgNjoz NyBQTSwgS2F0aGxlZW4gTW9yaWFydHkgPEthdGhsZWVuLk1vcmlhcnR5LmlldGZAZ21haWwuY29t PG1haWx0bzpLYXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KS2F0aGxl ZW4gTW9yaWFydHkgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9y DQpkcmFmdC1pZXRmLXNmYy1wcm9ibGVtLXN0YXRlbWVudC0xMjogTm8gT2JqZWN0aW9uDQoNCldo ZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJl cGx5IHRvIGFsbA0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGlu ZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgsIGhvd2V2 ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVt ZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVT RyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQpodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLXByb2JsZW0tc3RhdGVtZW50 Lw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCuKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlA0KDQo8dHJpbW1lZD4NCg0KDQpTb21lIG5pdHMgKEkg ZG9uJ3QgdGhpbmsgb3RoZXJzIG1lbnRpb25lZCB0aGVzZSwgYnV0IHNvcnJ5IGlmIHRoZXkgd2Vy ZQ0KYWxyZWFkeSBhZGRyZXNzZWQpOg0KU2VjdGlvbiAyLjE6IDNyZCBwYXJhZ3JhcGg6DQpJcyB0 aGlzIGludGVuZGVkIHRvIG1lYW4gYWZ0ZXIgYSBuZXcgc2VydmljZSBmdW5jdGlvbiBpcyBhZGRl ZD8gIEkgY2FuJ3QNCmltYWdpbmUgdGhhdCB0aGlzIG91ciBoYXBwZW4gb24gdGhlIGZseSwgc28g SSB0aGluayB0aGF0J3MgdGhlIGNhc2UgYW5kDQphZGRpbmcgYSB3b3JkIG9yIHR3byBtYXkgaGVs cDoNCmZyb206DQogICBBcyBtb3JlIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSByZXF1aXJlZCAtIG9m dGVuIHdpdGggc3RyaWN0IG9yZGVyaW5nIC0NCiAgIHRvcG9sb2d5IGNoYW5nZXMgYXJlIG5lZWRl ZCBiZWZvcmUgYW5kIGFmdGVyIGVhY2ggc2VydmljZSBmdW5jdGlvbiBpcw0KYWRkZWQNCiAgIHJl c3VsdGluZyBpbiBjb21wbGV4IG5ldHdvcmsgY2hhbmdlcyBhbmQgZGV2aWNlIGNvbmZpZ3VyYXRp b24uDQoNClBRPiAgZHJhZnQgY2xhcmlmaWVzIOKAnGZyb2504oCdIHZzIOKAnGJlaGluZOKAnSB0 byBtYWtlIHRoaXMgY2xlYXIuDQoNCg0KDQo0dGggcGFyYWdyYXBoOiAgSSdtIGhhdmUgdHJvdWJs ZSByZWFkaW5nIHRoaXMgcGFyYWdyYXBoIGFzIEkgdGhpbmsgaXQNCmNvbnRyYWRpY3RzIGl0c2Vs ZiwgYnV0IHRoZSBleGFtcGxlIGluIHRoZSBmb2xsb3dpbmcgcGFyYWdyYXBoIGlzDQpoZWxwZnVs LiAgSWYgdG9wb2xvZ3kgZGljdGF0ZXMgcGxhY2VtZW50LCBob3cgY291bGQgdXNpbmcgdG9wb2xv Z3kgbm90IGJlDQp2aWFibGU/ICBNYXliZSByZXdvcmRpbmcgaXQgd291bGQgaGVscDoNCiAgIFRo ZSB0b3BvbG9naWNhbCBjb3VwbGluZyBsaW1pdHMgcGxhY2VtZW50IGFuZCBzZWxlY3Rpb24gb2Yg c2VydmljZQ0KICAgZnVuY3Rpb25zOiBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUgImZpeGVkIiBpbiBw bGFjZSBieSB0b3BvbG9neSBhbmQNCiAgIHRoZXJlZm9yZSBwbGFjZW1lbnQgYW5kIHNlcnZpY2Ug ZnVuY3Rpb24gc2VsZWN0aW9uIHRha2luZyBpbnRvDQogICBhY2NvdW50IG5ldHdvcmsgdG9wb2xv Z3kgaW5mb3JtYXRpb24gaXMgbm90IHZpYWJsZS4gIEZ1cnRoZXJtb3JlLA0KICAgYWx0ZXJpbmcg dGhlIHNlcnZpY2VzIHRyYXZlcnNlZCwgb3IgdGhlaXIgb3JkZXIsIGJhc2VkIG9uIGZsb3cNCiAg IGRpcmVjdGlvbiBpcyBub3QgcG9zc2libGUuDQoNClBRPiAgSSBiZWxpZXZlIHRoYXQgYSBjbGFy aWZpY2F0aW9uIHdhcyBhZGRlZCBhYm91dCBuZXR3b3JrIHRvcG9sb2d5IGluZm9ybWF0aW9uLg0K DQoNCg== --_000_D98D572767D848788ADF284266AB695Aciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0CE9AE7B19CE044BAC67A8C995EDB9CF@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KQWxpYSwNCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlllcywgdGhleSB3ZXJlIGxhcmdl bHkgYWRkcmVzc2VkIGluIHRoZSBwcmV2aW91cyByZXYuICZuYnNwO1NwZWNpZmljIGNvbW1lbnRz IGJlbG93LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+VGhhbmtzITwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5QYXVsPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gRmViIDE3LCAyMDE1LCBhdCAxMTowMCBQTSwgQWxpYSBB dGxhcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFrYXRsYXNAZ21haWwuY29tIiBjbGFzcz0iIj5ha2F0 bGFzQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRl cmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0i Ij5QYXVsLA0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+SGF2ZSB5b3UgbG9va2VkIGF0IGFuZCBjb25zaWRlcmVkIEthdGhsZWVuJ3MgY29tbWVudHM/ PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5UaGFua3MgZm9yIHRoZSBoYXJkIHdvcmsgc28gZmFyLDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5B bGlhPC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gVHVlLCBGZWIgMTcsIDIwMTUgYXQgNjozNyBQ TSwgS2F0aGxlZW4gTW9yaWFydHkgPHNwYW4gZGlyPSJsdHIiIGNsYXNzPSIiPg0KJmx0OzxhIGhy ZWY9Im1haWx0bzpLYXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiIGNsYXNzPSIiPkthdGhsZWVuLk1vcmlhcnR5LmlldGZAZ21haWwuY29tPC9hPiZndDs8L3Nw YW4+IHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIg c3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRp bmctbGVmdDoxZXgiPg0KS2F0aGxlZW4gTW9yaWFydHkgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2lu ZyBiYWxsb3QgcG9zaXRpb24gZm9yPGJyIGNsYXNzPSIiPg0KZHJhZnQtaWV0Zi1zZmMtcHJvYmxl bS1zdGF0ZW1lbnQtMTI6IE5vIE9iamVjdGlvbjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5k IHJlcGx5IHRvIGFsbDxiciBjbGFzcz0iIj4NCmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0 aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzPGJyIGNsYXNzPSIiPg0K aW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KUGxlYXNlIHJlZmVyIHRvIDxhIGhyZWY9Imh0dHA6Ly93d3cu aWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sIiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+DQpodHRwOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1 c3MtY3JpdGVyaWEuaHRtbDwvYT48YnIgY2xhc3M9IiI+DQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhl ciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZTo8YnIgY2xhc3M9IiI+DQo8YSBo cmVmPSJodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtc2ZjLXByb2Js ZW0tc3RhdGVtZW50LyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zZmMtcHJvYmxlbS1zdGF0ZW1lbnQvPC9hPjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnIgY2xhc3M9IiI+DQpDT01NRU5UOjxiciBjbGFzcz0iIj4NCuKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKA lOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlOKAlDxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PiZsdDt0cmltbWVkJmd0OzwvZGl2Pg0KPGRpdj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp bjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgi Pg0KPGJyIGNsYXNzPSIiPg0KU29tZSBuaXRzIChJIGRvbid0IHRoaW5rIG90aGVycyBtZW50aW9u ZWQgdGhlc2UsIGJ1dCBzb3JyeSBpZiB0aGV5IHdlcmU8YnIgY2xhc3M9IiI+DQphbHJlYWR5IGFk ZHJlc3NlZCk6PGJyIGNsYXNzPSIiPg0KU2VjdGlvbiAyLjE6IDNyZCBwYXJhZ3JhcGg6PGJyIGNs YXNzPSIiPg0KSXMgdGhpcyBpbnRlbmRlZCB0byBtZWFuIGFmdGVyIGEgbmV3IHNlcnZpY2UgZnVu Y3Rpb24gaXMgYWRkZWQ/Jm5ic3A7IEkgY2FuJ3Q8YnIgY2xhc3M9IiI+DQppbWFnaW5lIHRoYXQg dGhpcyBvdXIgaGFwcGVuIG9uIHRoZSBmbHksIHNvIEkgdGhpbmsgdGhhdCdzIHRoZSBjYXNlIGFu ZDxiciBjbGFzcz0iIj4NCmFkZGluZyBhIHdvcmQgb3IgdHdvIG1heSBoZWxwOjxiciBjbGFzcz0i Ij4NCmZyb206PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO0FzIG1vcmUgc2VydmljZSBmdW5j dGlvbnMgYXJlIHJlcXVpcmVkIC0gb2Z0ZW4gd2l0aCBzdHJpY3Qgb3JkZXJpbmcgLTxiciBjbGFz cz0iIj4NCiZuYnNwOyAmbmJzcDt0b3BvbG9neSBjaGFuZ2VzIGFyZSBuZWVkZWQgYmVmb3JlIGFu ZCBhZnRlciBlYWNoIHNlcnZpY2UgZnVuY3Rpb24gaXM8YnIgY2xhc3M9IiI+DQphZGRlZDxiciBj bGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtyZXN1bHRpbmcgaW4gY29tcGxleCBuZXR3b3JrIGNoYW5n ZXMgYW5kIGRldmljZSBjb25maWd1cmF0aW9uLjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2PlBRJmd0OyAmbmJzcDtkcmFmdCBjbGFyaWZpZXMg4oCcZnJvbnTigJ0g dnMg4oCcYmVoaW5k4oCdIHRvIG1ha2UgdGhpcyBjbGVhci48L2Rpdj4NCjxkaXY+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNs YXNzPSJnbWFpbF9xdW90ZSI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxl ZnQ6MWV4Ij4NCjxiciBjbGFzcz0iIj4NCjR0aCBwYXJhZ3JhcGg6Jm5ic3A7IEknbSBoYXZlIHRy b3VibGUgcmVhZGluZyB0aGlzIHBhcmFncmFwaCBhcyBJIHRoaW5rIGl0PGJyIGNsYXNzPSIiPg0K Y29udHJhZGljdHMgaXRzZWxmLCBidXQgdGhlIGV4YW1wbGUgaW4gdGhlIGZvbGxvd2luZyBwYXJh Z3JhcGggaXM8YnIgY2xhc3M9IiI+DQpoZWxwZnVsLiZuYnNwOyBJZiB0b3BvbG9neSBkaWN0YXRl cyBwbGFjZW1lbnQsIGhvdyBjb3VsZCB1c2luZyB0b3BvbG9neSBub3QgYmU8YnIgY2xhc3M9IiI+ DQp2aWFibGU/Jm5ic3A7IE1heWJlIHJld29yZGluZyBpdCB3b3VsZCBoZWxwOjxiciBjbGFzcz0i Ij4NCiZuYnNwOyAmbmJzcDtUaGUgdG9wb2xvZ2ljYWwgY291cGxpbmcgbGltaXRzIHBsYWNlbWVu dCBhbmQgc2VsZWN0aW9uIG9mIHNlcnZpY2U8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ZnVu Y3Rpb25zOiBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUgJnF1b3Q7Zml4ZWQmcXVvdDsgaW4gcGxhY2Ug YnkgdG9wb2xvZ3kgYW5kPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3RoZXJlZm9yZSBwbGFj ZW1lbnQgYW5kIHNlcnZpY2UgZnVuY3Rpb24gc2VsZWN0aW9uIHRha2luZyBpbnRvPGJyIGNsYXNz PSIiPg0KJm5ic3A7ICZuYnNwO2FjY291bnQgbmV0d29yayB0b3BvbG9neSBpbmZvcm1hdGlvbiBp cyBub3QgdmlhYmxlLiZuYnNwOyBGdXJ0aGVybW9yZSw8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5i c3A7YWx0ZXJpbmcgdGhlIHNlcnZpY2VzIHRyYXZlcnNlZCwgb3IgdGhlaXIgb3JkZXIsIGJhc2Vk IG9uIGZsb3c8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ZGlyZWN0aW9uIGlzIG5vdCBwb3Nz aWJsZS48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+UFEmZ3Q7ICZuYnNw O0kgYmVsaWV2ZSB0aGF0IGEgY2xhcmlmaWNhdGlvbiB3YXMgYWRkZWQgYWJvdXQgbmV0d29yayB0 b3BvbG9neSBpbmZvcm1hdGlvbi48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D98D572767D848788ADF284266AB695Aciscocom_-- From nobody Wed Feb 18 12:41: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 03D7B1A1A47; Wed, 18 Feb 2015 12:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.898 X-Spam-Level: X-Spam-Status: No, score=-101.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9l_488js8Ezj; Wed, 18 Feb 2015 12:41:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C631A1A4E; Wed, 18 Feb 2015 12:40:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alia Atlas" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150218204056.21205.65442.idtracker@ietfa.amsl.com> Date: Wed, 18 Feb 2015 12:40:56 -0800 Archived-At: Cc: draft-ietf-sfc-problem-statement@ietf.org, jmh@joelhalpern.com, sfc-chairs@ietf.org, sfc@ietf.org Subject: [sfc] Alia Atlas' Yes on draft-ietf-sfc-problem-statement-12 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, 18 Feb 2015 20:41:03 -0000 Alia Atlas has entered the following ballot position for draft-ietf-sfc-problem-statement-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ There are no remarks associated with this position. From nobody Thu Feb 19 06:28:50 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524821A87B2; Thu, 19 Feb 2015 06:28:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 2B8IOSDFAKlB; Thu, 19 Feb 2015 06:28:45 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2806A1A874E; Thu, 19 Feb 2015 06:28:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219142845.4029.85687.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 06:28:45 -0800 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-problem-statement-13.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 14:28:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining Problem Statement Authors : Paul Quinn Thomas Nadeau Filename : draft-ietf-sfc-problem-statement-13.txt Pages : 19 Date : 2015-02-19 Abstract: This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers, etc.) in large-scale environments. The term service function chaining is used to describe the definition and instantiation of an ordered list of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions. The set of enabled service function chains reflect operator service offerings and is designed in conjunction with application delivery and service and network policy. This document also identifies several key areas that the SFC working group will investigate to guide its architectural and protocol work and associated drafts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sfc-problem-statement-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 19 06:28: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 EBF1E1A87B2; Thu, 19 Feb 2015 06:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 JZuZR7tSMJDU; Thu, 19 Feb 2015 06:28:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 573001A8784; Thu, 19 Feb 2015 06:28:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219142845.4029.33018.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 06:28:45 -0800 Archived-At: Subject: [sfc] New Version Notification - draft-ietf-sfc-problem-statement-13.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 14:28:49 -0000 A new version (-13) has been submitted for draft-ietf-sfc-problem-statement: http://www.ietf.org/internet-drafts/draft-ietf-sfc-problem-statement-13.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-problem-statement-13 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. IETF Secretariat. From nobody Thu Feb 19 06:33:22 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 DB8CB1A87EC; Thu, 19 Feb 2015 06:33:20 -0800 (PST) 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 LQRjOc78TGxA; Thu, 19 Feb 2015 06:33:19 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2BD1A87C4; Thu, 19 Feb 2015 06:33:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=975; q=dns/txt; s=iport; t=1424356399; x=1425565999; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2xcxDRYn2LKEUd5N7R5MykpQTUtsQi1sUZ9Cj+j7ytc=; b=UBmOsteMIy9UAeXUXnv94blwAZ8UHiSYzguicRkk5KIlLyqaDm9jLJOh TaMJMrfax227GAdKDMHioW4//OgQnfnCEuAy/ryKGxpBbVEA58NhjW8s9 6eupOyLp1Zzt+lsOSjJrJ0EGn9WXG/arVMK7kcjtLts1ASgkJ/I8LFvtw k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AjBQBD8+VU/5tdJa1bgwZSVQUEwl0MhW8CgSBDAQEBAQEBfIQPAQEBAwEBAQE3NAkCBQsCAQgYHhAnCyUCBA4FCYgeCAgF0wMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXiw+EOzMHgxaBFAWPS4NchWWBGTiCW452IoNubwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.09,608,1418083200"; d="scan'208";a="397456991" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 19 Feb 2015 14:33:18 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1JEXI2K015129 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Feb 2015 14:33:18 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.229]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0195.001; Thu, 19 Feb 2015 08:33:18 -0600 From: "Paul Quinn (paulq)" To: "internet-drafts@ietf.org" Thread-Topic: [sfc] New Version Notification - draft-ietf-sfc-problem-statement-13.txt Thread-Index: AQHQTFB7z0ERo9t3002rzXK/xk3EmJz4bfMA Date: Thu, 19 Feb 2015 14:33:17 +0000 Message-ID: References: <20150219142845.4029.33018.idtracker@ietfa.amsl.com> In-Reply-To: <20150219142845.4029.33018.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.17.229] Content-Type: text/plain; charset="us-ascii" Content-ID: <8D8879BE5B7D524799176DB0ABE20875@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sfc-problem-statement@ietf.org" , "jmh@joelhalpern.com" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , "akatlas@gmail.com" Subject: Re: [sfc] New Version Notification - draft-ietf-sfc-problem-statement-13.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, 19 Feb 2015 14:33:21 -0000 Folks, This version correct typographical and grammatical errors identified by Ben= Kaduk. Thank you for the detailed and thorough review! Paul > On Feb 19, 2015, at 9:28 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A new version (-13) has been submitted for draft-ietf-sfc-problem-stateme= nt: > http://www.ietf.org/internet-drafts/draft-ietf-sfc-problem-statement-13.t= xt >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ >=20 > Diff from previous version: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-problem-statement-13 >=20 > 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. >=20 > IETF Secretariat. >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Feb 19 08:30:42 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588A41A9169; Thu, 19 Feb 2015 08:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 JyYxQBr6Qr4u; Thu, 19 Feb 2015 08:30:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FEA1A924A; Thu, 19 Feb 2015 08:30:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219163036.23195.64483.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 08:30:36 -0800 From: IETF Secretariat Archived-At: Subject: [sfc] ID Tracker State Update Notice: X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 16:30:39 -0000 IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ From nobody Thu Feb 19 11:39: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 8B8831A8792; Thu, 19 Feb 2015 11:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 uFHpGvuSbw09; Thu, 19 Feb 2015 11:39:11 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 544481A87B0; Thu, 19 Feb 2015 11:38:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150219193858.28097.74324.idtracker@ietfa.amsl.com> Date: Thu, 19 Feb 2015 11:38:58 -0800 From: IETF Secretariat Archived-At: Subject: [sfc] ID Tracker State Update Notice: X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 19:39:13 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ From nobody Thu Feb 19 11:47:49 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 E8E651A883E for ; Thu, 19 Feb 2015 11:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 lUjM-uR_e9EN for ; Thu, 19 Feb 2015 11:47:47 -0800 (PST) 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 7A8931A8839 for ; Thu, 19 Feb 2015 11:47:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 617432800CF for ; Thu, 19 Feb 2015 11:47:47 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (pool-70-106-135-240.clppva.east.verizon.net [70.106.135.240]) (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 D94D51C02DA for ; Thu, 19 Feb 2015 11:47:46 -0800 (PST) Message-ID: <54E63DA6.90205@joelhalpern.com> Date: Thu, 19 Feb 2015 14:46:46 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: sfc@ietf.org References: <20150219193858.28097.74324.idtracker@ietfa.amsl.com> In-Reply-To: <20150219193858.28097.74324.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] ID Tracker State Update Notice: 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, 19 Feb 2015 19:47:49 -0000 Congratulations to the authors on getting this through the process! Yours, Joel On 2/19/15 2:38 PM, IETF Secretariat wrote: > IESG state changed to Approved-announcement to be sent from IESG Evaluation > ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ > From nobody Fri Feb 20 03:25:58 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 B4D1E1A6F2E for ; Fri, 20 Feb 2015 03:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WUb2iD7t-Gx for ; Fri, 20 Feb 2015 03:25:54 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.150]) by ietfa.amsl.com (Postfix) with ESMTP id DD2321A6EF8 for ; Fri, 20 Feb 2015 03:25:53 -0800 (PST) Received: from [85.158.139.163] by server-14.bemta-5.messagelabs.com id 06/CD-02809-0C917E45; Fri, 20 Feb 2015 11:25:52 +0000 X-Env-Sender: walter.haeffner@vodafone.com X-Msg-Ref: server-13.tower-188.messagelabs.com!1424431550!7678936!4 X-Originating-IP: [195.232.224.75] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23450 invoked from network); 20 Feb 2015 11:25:52 -0000 Received: from mailout06.vodafone.com (HELO mailout06.vodafone.com) (195.232.224.75) by server-13.tower-188.messagelabs.com with SMTP; 20 Feb 2015 11:25:52 -0000 Received: from mailint06.vodafone.com (localhost [127.0.0.1]) by mailout06.vodafone.com (Postfix) with ESMTP id 1A6211400F1 for ; Fri, 20 Feb 2015 12:25:52 +0100 (CET) Received: from VOEXC06W.internal.vodafone.com (voexc06w.dc-ratingen.de [145.230.101.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint06.vodafone.com (Postfix) with ESMTPS id 0C6181400EE; Fri, 20 Feb 2015 12:25:52 +0100 (CET) Received: from VOEXC12W.internal.vodafone.com (145.230.101.14) by VOEXC06W.internal.vodafone.com (145.230.101.26) with Microsoft SMTP Server (TLS) id 14.3.224.2; Fri, 20 Feb 2015 12:25:51 +0100 Received: from VOEXM20W.internal.vodafone.com ([169.254.4.248]) by voexc12w.internal.vodafone.com ([145.230.101.14]) with mapi id 14.03.0224.002; Fri, 20 Feb 2015 12:25:50 +0100 From: "Haeffner, Walter, Vodafone DE" To: Narseo Vallina Rodriguez Thread-Topic: [sfc] [GRAYMAIL] Re: HTTP Header injection Thread-Index: AQHQRZcCmzoio6G3nES9eCOcisq+tpz5bHCA Date: Fri, 20 Feb 2015 11:25:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Stiemerling, Martin, Prof. Dr. \(martin.stiemerling@h-da.de\)" , "sfc@ietf.org" , Ron Parker Subject: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection 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, 20 Feb 2015 11:25:57 -0000 RGVhciBOYXJzZW8sDQoNClNvcnJ5IGZvciB0aGlzIGxhdGUgZmVlZGJhY2suIEkgd2FzIG91dCBv ZiBvZmZpY2UgZm9yIGEgd2hpbGUuIFlvdXIgYmxvZyBpcyBhIHZlcnkgdmFsdWFibGUgY29udHJp YnV0aW9uLiBJIHdpbGwgc2hhcmUgaXQgd2l0aCBhbGwgVm9kYWZvbmUgb3BlcmF0aW9uYWwgdW5p dHMgeW91IG1lbnRpb25lZC4gV3J0IFZvZGFmb25lIEdlcm1hbnkgSSBjYW4gdGVsbCB5b3UgdGhh dA0KLSB3ZSBvdmVyd3JpdGUgaHR0cCBoZWFkZXJzLiBNZWFucyB3aGF0ZXZlciBhIGNoZWF0ZXIg d291bGQgaW5qZWN0IGRvZXMgbm90IHN1cnZpdmUuDQotIGF0IHRoZSBtb21lbnQgd2UgdHJhbnNm ZXIgSU1TSSB0byB0aGlyZCBwYXJ0eSBzdWJzY3JpYmVycyB3ZSBoYXZlIGEgY29udHJhY3R1YWwg cmVsYXRpb25zaGlwLiBVc2UgY2FzZSBlLmcuIGlzIGNoYXJnaW5nIHJpbmcgdG9uZSBkb3dubG9h ZHMgKG9yIGdhbWVzIGV0YykNCi0gd2Ugd2lsbCBmdWxseSBibG9jayBJTVNJIHVzYWdlIGluIHRo ZSBmdXR1cmUgYW5kIGluc3RlYWQgdXNlIGFuIElQdjYgdXNlciBhZGRyZXNzLiBHZXR0aW5nIHRo ZSB1c2VyIGlkZW50aXR5IHRoZW4gcmVxdWlyZXMgYW4gYXV0aG9yaXplZCwgZW5jcnlwdGVkIExE QVAgcXVlcnkuDQpEbyB5b3Ugc2VlIGFueSBpc3N1ZXMgd2l0aCB0aGlzIHBsYW5uZWQgcHJvY2Vk dXJlPw0KDQpXcnQgdGhlIElFVEYgZHJhZnQgSSB3aWxsIHdvcmsgb3V0IGEgc21hbGwgcGFyYWdy YXBoIGRlc2NyaWJpbmcgdGhlc2UgZmFjdHMuIEJ1dCBJIHdhbnQgdG8gYXZvaWQgYSBzZWN1cml0 eSBkaXNjdXNzaW9uIG9uIHBvc3NpYmxlIHNvbHV0aW9ucy4gVGhpcyBtdXN0IGJlIHBhcnQgb2Yg dGhlIG90aGVyIFNGQyBkcmFmdHMuDQoNCkJlc3QgcmVnYXJkcywNCldhbHRlcg0KDQotLS0tLVVy c3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQpWb246IE5hcnNlbyBWYWxsaW5hIFJvZHJpZ3Vl eiBbbWFpbHRvOm5hcnNlb0BpY3NpLmJlcmtlbGV5LmVkdV0gDQpHZXNlbmRldDogTWl0dHdvY2gs IDExLiBGZWJydWFyIDIwMTUgMDI6MDcNCkFuOiBIYWVmZm5lciwgV2FsdGVyLCBWb2RhZm9uZSBE RQ0KQ2M6IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzsgU3RpZW1lcmxpbmcsIE1hcnRpbiwgUHJv Zi4gRHIuIChtYXJ0aW4uc3RpZW1lcmxpbmdAaC1kYS5kZSkNCkJldHJlZmY6IFJlOiBbc2ZjXSBb R1JBWU1BSUxdIFJlOiBIVFRQIEhlYWRlciBpbmplY3Rpb24NCg0KRGVhciBXYWx0ZXINCg0KVGhh bmtzIGEgbG90IGZvciB5b3VyIHJlc3BvbnNlLiBJdCdzIGFjdHVhbGx5IGEgcGxlYXN1cmUgdG8g cmVhZCB0aGUgZHJhZnQgYW5kIEkgdGhpbmsgaXQgaGFzIHNvbWUgdmVyeSBpbnRlcmVzdGluZyBw b2ludHMuIEknZCBhbHNvIGxvdmUgdG8gcmVhZCBNYXJ0aW4gU3RpZW1lcmxpbmcncyB0aG91Z2h0 cyBpZiB0aGV5IGFyZSBhdmFpbGFibGUgc29tZXdoZXJlLg0KDQpBIGZldyB3ZWVrcyBhZ28sIHdl IHdyb3RlIGEgc2hvcnQgYmxvZyBwb3N0IGFib3V0IG91ciB2aWV3IG9uIEhUVFAgaGVhZGVyIGlu amVjdGlvbiBhdCBhIGdsb2JhbCBzY2FsZS4NCg0KaHR0cDovL25ldGFseXpyLmljc2kuYmVya2Vs ZXkuZWR1L2Jsb2cvDQoNCldlJ3JlIHdvcmtpbmcgdG8gZXh0ZW5kIGl0IGFzIHBhcGVyIHRoYXQg d2lsbCBiZSBzdWJtaXR0ZWQgdGhpcyBtb250aC4NCk9mIGNvdXJzZSwgYW55IGZlZWRiYWNrIGFu ZCBjb21tZW50cywgc3BlY2lhbGx5IGRpZmZlcmVudCB2aWV3cyB0aGF0IG1heSBub3QgYmUgdW5k ZXIgb3VyIHJhZGFyLCB3aWxsIGJlIHZlcnkgd2VsY29tZSENCg0KSW4geW91ciByZXNwb25zZSwg eW91IG1lbnRpb24gcmVhbCB1c2UtY2FzZXMuIEFzIHlvdSBjYW4gc2VlIGluIHRoZSBibG9nIHBv c3QsIHdlIGhhdmUgZm91bmQgYSBkaXZlcnNlIGFycmF5IG9mIGhlYWRlcnMgdGhhdCBhcmUgdXNl ZCBmb3IgYSB3aWRlIHJhbmdlIG9mIGFjdGlvbnMuIFNvbWUgb2YgdGhlbSBjb3VsZCBiZSB1c2Vk IHRvIGlsbHVzdHJhdGUgdGhlIGJlbmVmaXRzIG9mIGhlYWRlciBlbnJpY2htZW50IG9yIHRvIGRl c2NyaWJlIHNvbWUgdXNlIGNhc2VzIHJhdGhlciB0aGFuIGluY2x1ZGluZyB1c2UtY2FzZXMgaW52 b2x2aW5nIHZlcnkgc2Vuc2l0aXZlIGluZm9ybWF0aW9uIHN1Y2ggYXMgdGhlIElNRUkvSU1TSSBv ciBldmVuIFBlcm1hLWNvb2tpZXMuIEZvciBpbnN0YW5jZSB0aGUgaGVhZGVycyByZXBvcnRpbmcg dGhlIHRyYW5zcG9ydC1sYXllciBwcm90b2NvbCBtYXkgYmUgYSBuaWNlIHVzZSBjYXNlLg0KDQpJ IHBlcnNvbmFsbHkgdGhpbmsgdGhhdCB0aGUgZHJhZnQgc2hvdWxkIGNsZWFybHkgc2F5IHRoYXQg dGhpcyBpbmZvcm1hdGlvbiBNVVNUIE5PVCBsZWF2ZSB0aGUgYWN0dWFsIGRvbWFpbiBvZiB0aGUg b3BlcmF0b3IgaW4gb3JkZXIgdG8gcHJldmVudCB1c2VyIHRyYWNraW5nIGJ5IDNyZCBwYXJ0eSBz ZXJ2aWNlcy4gSXQgY291bGQgYmUgd3JpdHRlbiBpbiB0aGUgc2FtZSB3YXkgdGhhdCB0aGUgSFRU UCBzdGFuZGFyZCBzYXlzIHRoYXQgYW55IHByb3h5IE1VU1QgYWR2ZXJ0aXNlIGl0cyBwcmVzZW5j ZSB1c2luZyB0aGUgVklBIGZpZWxkIChCVFcsIG9ubHkgYSBzbWFsbCBmcmFjdGlvbiBvZiB0aGUg bW9iaWxlIHByb3hpZXMgd2UndmUgc2VlbiBkZXBsb3llZCBpbiByZWFsIG5ldHdvcmtzIGRvZXMg YWN0dWFsbHkgaW5jbHVkZSB0aGUgc3RhbmRhcmQgVklBIGZpZWxkKS4gT25lIG1vcmUgdGhvdWdo dCBpcyB0aGF0IGdpdmVuIHRoYXQgdGhlIGhlYWRlcnMgYXJlIGluIHBsYWluIEhUVFAgdGV4dCwg d2hhdCBkb2VzIHByZXZlbnQgYSBjbGllbnQgZnJvbSBpbXBlcnNvbmF0aW5nIHNvbWVvbmUgZWxz ZSwgc3BlY2lhbGx5IGZvciBjaGFyZ2luZyBwdXJwb3NlcywgYnkgYWRkaW5nIHRoZWlyIG93biBo ZWFkZXJzPw0KDQpTbyB0byBzdW0gdXAsIGEgbmljZSBkZWZpbml0aW9uIG9mIHdoYXQga2luZCBv ZiBpbmZvcm1hdGlvbiBpcyBwcml2YWN5IHNlbnNpdGl2ZSBjb3VsZCBiZSB1c2VmdWwsIHNwZWNp YWxseSBpbiB0aGUgbW9iaWxlIHVzZSBjYXNlLiBUaGF0IHdvdWxkIGJlIGJldHRlciB0aGFuIGxl YXZpbmcgdGhlIGRlY2lzaW9uIHRvIHRoZSBvcGVyYXRvcidzIG9yIHByb3h5IHZlbmRvciBqdWRn ZW1lbnQuIENvdWxkIHRoYXQgYmUgcG9zc2libGU/IEFub3RoZXIgcG9pbnQgdG8gbWFrZSBpcyB0 aGF0IGVucmljaGluZyBzdWNoIGhlYWRlcnMgaXMgT0sgYXMgbG9uZyBhcyB0aGV5IGRvIG5vdCBs ZWF2ZSB0aGUgb3BlcmF0b3IncyBkb21haW4gYXMgUm9uIHN1Z2dlc3RlZC4NCg0KVGhlIFVTIHNl bmF0ZSBhcyB3ZWxsIGFzIHRoZSBGQ0MgYXJlIGFsc28gc2hvd2VkIHRoZWlyIGNvbmNlcm5zIG9u IHRoZSB1c2Ugb2YgcGVybWEgY29va2llcyBhbmQgb3RoZXIgaGVhZGVyIGVucmljaG1lbnQgdGVj aG5pcXVlczoNCg0KaHR0cHM6Ly93d3cuZWZmLm9yZy9kZWVwbGlua3MvMjAxNS8wMi91bmRlci1z ZW5hdGUtcHJlc3N1cmUtdmVyaXpvbi1pbXByb3Zlcy1pdHMtc3VwZXJjb29raWUtb3B0LW91dA0K DQoNCk9uIFR1ZSwgRmViIDEwLCAyMDE1IGF0IDQ6MDYgQU0sIEhhZWZmbmVyLCBXYWx0ZXIsIFZv ZGFmb25lIERFIDx3YWx0ZXIuaGFlZmZuZXJAdm9kYWZvbmUuY29tPiB3cm90ZToNCj4gRGVhciBO YXJzZW8sIGRlYXIgUm9uLA0KPg0KPiBOYXJzZW8sIHRoYW5rcyBmb3IgcmVhZGluZyBhbmQgY29t bWVudGluZyB0aGUgZHJhZnQuIEFuZCB0aGFua3MgdG8gUm9uIGZvciB0aGUgZXhwbGFuYXRpb25z Lg0KPg0KPiBJbmRlZWQsIHNvbWUgZGF5cyBhZ28gb25lIG9mIHRoZSBjby1hdXRob3JzIChNYXJ0 aW4gU3RpZW1lcmxpbmcpIG1lbnRpb25lZCB0aGF0IEhUVFAgSGVhZGVyIEVucmljaG1lbnQgbWF5 IGNvbWUgdW5kZXIgYXR0YWNrLiBJIHdpbGwgaW5jbHVkZSBhIHN0YXRlbWVudCB3LnIudC4geW91 ciBzZWN1cml0eSBjb25jZXJucy4gQnV0IGFzIHBvaW50ZWQgb3V0IGJ5IFJvbiwgdGhlIHNlY3Vy aXR5IGlzc3VlcyBhcmUgZXZlbiBtb3JlIGdlbmVyYWwuIEFuZCB3ZSBwcm9iYWJseSBjb3VsZCBo YXZlIHRoZSBzYW1lIGRpc2N1c3Npb24gd2l0aCBTSVAgUC1IZWFkZXJzOyBvciB3aXRoIGFueSBz dWJzY3JpYmVyLXJlbGF0ZWQgZGF0YSBleGNoYW5nZWQgYmV0d2VlbiBkaWZmZXJlbnQgY2Fycmll cnMgYW5kIElTUHMuDQo+DQo+IE91ciBpbnRlbnNpb24gZm9yIHRoZSBtb2JpbGl0eSB1c2UgY2Fz ZSBkcmFmdCB3YXMgdG8gbGlzdCBhIHNob3J0IG51bWJlciBvZiByZXByZXNlbnRhdGl2ZSBTRkMg dXNlIGNhc2VzIHdoaWNoIGFyZSB3aWRlbHkgaW4gcGxhY2UgYnV0IHdlIGRpZG4ndCByYXRlIHRo ZW0gdy5yLnQuIHNlY3VyaXR5LiBGb3Igc3VyZSwgeW91IGFyZSByaWdodCwgdGhlIGxpc3RlZCB1 c2UgY2FzZXMgYXJlIG5vdCB2ZXJ5IGNvaGVyZW50IHcuci50LiBzZWN1cml0eSByZXF1aXJlbWVu dHMuIEJ1dCB0aGF0IGlzIHdoYXQgeW91IGN1cnJlbnRseSAgZmluZCBvdXQgdGhlcmUgaW4gdGhl IG5ldHdvcmtzLg0KPg0KPiBJIHdpbGwgY2hlY2ssIGlmIHRoZSBTRkMgcHJvYmxlbSBzdGF0ZW1l bnQgZHJhZnQgaW5jbHVkZXMgc3VjaCBzZWN1cml0eSBjb25jZXJucy4gVGhpcyBpcyBwcm9iYWJs eSB0aGUgYmVzdCBwbGFjZSBmb3IgdGhlIHByaXZhY3kgaXNzdWVzLiBBdCBsZWFzdCwgdGhlIFNG QyBhcmNoaXRlY3R1cmUgZHJhZnQgaW5jbHVkZXMgYSBwYXJhZ3JhcGg6DQo+DQo+ICJBbiBvcGVy YXRvciBtYXkgY29uc2lkZXIgdGhlIFNGQyBNZXRhZGF0YSBhcyBzZW5zaXRpdmUuIFRoZXJlZm9y ZSwgDQo+IHNvbHV0aW9ucyBzaG91bGQgY29uc2lkZXIgd2hldGhlciB0aGVyZSBpcyBhIHJpc2sg b2Ygc2Vuc2l0aXZlIA0KPiBpbmZvcm1hdGlvbiBzbGlwcGluZyBvdXQgb2YgdGhlIG9wZXJhdG9y cyBjb250cm9sLiINCj4NCj4gTmFyc2VvLCBpZiB5b3UgaGF2ZSBhIHByb3Bvc2FsIHRvIGltcHJv dmUgdGhlIHRleHQsIHBsZWFzZSBmZWVsIGZyZWUgdG8gc2VuZCBpdCBvdmVyLg0KPg0KPiBCZXN0 IHJlZ2FyZHMsDQo+IFdhbHRlcg0KPg0KPiAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5hY2hyaWNodC0t LS0tDQo+IFZvbjogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcg dm9uIE5hcnNlbyBWYWxsaW5hIA0KPiBSb2RyaWd1ZXoNCj4gR2VzZW5kZXQ6IERpZW5zdGFnLCAx MC4gRmVicnVhciAyMDE1IDA4OjM0DQo+IEFuOiBSb24gUGFya2VyDQo+IENjOiBzZmNAaWV0Zi5v cmcNCj4gQmV0cmVmZjogUmU6IFtzZmNdIFtHUkFZTUFJTF0gUmU6IEhUVFAgSGVhZGVyIGluamVj dGlvbg0KPg0KPiBIaSBSb24NCj4NCj4gVGhhbmtzIGEgbG90IGZvciB5b3VyIGV4cGxhbmF0aW9u LiBJIGdldCBiZXR0ZXIgdGhlIHBvaW50IHRoYXQgeW91IHdlcmUgdHJ5aW5nIHRvIG1ha2Ugc28g SSB1bmRlcnN0YW5kIHlvdXIgcG9zaXRpb24gYW5kIEknbSBzdGFydGluZyB0byBnZXQgYSBiZXR0 ZXIgcGljdHVyZSBvZiB0aGUgd2hvbGUgZHJhZnQuDQo+DQo+IEkgd291bGQgYXBwcmVjaWF0ZSBv dGhlcidzIG9waW5pb25zIGFib3V0IHdoeSBzdWNoIGhlYWRlcnMgbWF5IGJlIG5lZWRlZCwgaW4g cGFydGljdWxhciBpbiB0aGUgbW9iaWxlIHNjZW5hcmlvLCBhbmQgaG93IHRoZSBhc3NvY2lhdGVk IHByaXZhY3kgaXNzdWVzIHRoYXQgdG9kYXkgZXhpc3Qgd2lsbCBiZSBhZGRyZXNzZWQuDQo+DQo+ IE1hbnkgdGhhbmtzIGFnYWluDQo+DQo+DQo+DQo+IE9uIE1vbiwgRmViIDksIDIwMTUgYXQgNDo1 NCBQTSwgUm9uIFBhcmtlciA8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4gd3JvdGU6 DQo+PiBOYXJzZW8sDQo+Pg0KPj4gVGhlIHBvaW50IEkgd2FzIHRyeWluZyB0byBtYWtlIGlzIHRo YXQgdGhlIHVzZSBvZiB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24gbWV0YWRhdGEgd2l0aGluIHRoZSBj YXJyaWVyJ3MgYWRtaW5pc3RyYXRpdmUgZG9tYWluLCBpbnN0ZWFkIG9mIEhUVFAgaGVhZGVyIGVu cmljaG1lbnQsIHdpbGwgYWRkcmVzcyB0aGVzZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4gICBU aGUgY3VycmVudCBTRkMgYXJjaGl0ZWN0dXJlIHN0YXRlcyB0aGF0IGl0IGlzIHN1cHBvcnRlZCB3 aXRoaW4gYSBzaW5nbGUgYWRtaW5pc3RyYXRpdmUgZG9tYWluIHdpdGggaW50ZXItZG9tYWluIFNG QyBmb3IgZnVydGhlciBzdHVkeS4gICBTdGF0ZWQgYW5vdGhlciB3YXksIGVuZC10by1lbmQgU0ZD IGlzIG5vdCBzdXBwb3J0ZWQuDQo+Pg0KPj4gICAgIFJvbg0KPj4NCj4+DQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBGcm9tOiBOYXJzZW8gVmFsbGluYSBS b2RyaWd1ZXogW25hcnNlb0BpY3NpLmJlcmtlbGV5LmVkdV0NCj4+IFNlbnQ6IE1vbmRheSwgRmVi cnVhcnkgMDksIDIwMTUgNzoyNiBQTQ0KPj4gVG86IFJvbiBQYXJrZXINCj4+IENjOiBzZmNAaWV0 Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbR1JBWU1BSUxdIFJlOiBbc2ZjXSBIVFRQIEhlYWRlciBp bmplY3Rpb24NCj4+DQo+PiBIaSBSb24NCj4+DQo+PiBUaGFua3MgZm9yIHRoZSBleHBsYW5hdGlv bi4gSSBzdGlsbCBoYXZlIHNvbWUgY29uY2VybnMgYWJvdXQgdGhlIA0KPj4gaGVhZGVyIGVucmlj aG1lbnQgdGhhdCBtYXkgYmUgd29ydGggZGlzY3Vzc2luZyBmdXJ0aGVyLiBMZXQgbWUgDQo+PiBy ZXNwb25kIGlubGluZS4NCj4+DQo+Pj4gVGhlIEhUVFAgWC1oZWFkZXJzIHJlbGF0ZWQgdG8gaWRl bnRpZmljYXRpb24gYXJlIHR5cGljYWxseSBpbnNlcnRlZCBieSB0aGUgU3Vic2NyaWJlciBNYW5h Z2VtZW50IFN5c3RlbSBmb3IgdGhlIGJlbmVmaXQgb2YgdHJhbnNwYXJlbnQgbWlkYm94ZXMgc3Vj aCBhcyB2aWRlbyBvcHRpbWl6ZXJzLCBJRFMvSVBTLCBGaXJld2FsbCwgZXRjLiAgIFRoZSBmYWN0 IHRoYXQgaXQgZ29lcyBhbGwgdGhlIHdheSB0byB0aGUgb3JpZ2luIHNlcnZlciBpcyBzb21ldGlt ZXMgaW5jaWRlbnRhbC4NCj4+Pg0KPj4NCj4+IFRoYXQncyBleGFjdGx5IG15IG1haW4gY29uY2Vy bi4gVGhlIGZpcnN0IGV4YW1wbGUgZm9yIFNGQyB1c2UgY2FzZXMgDQo+PiBpbiBtb2JpbGUgbmV0 d29ya3MgaXMgZnVuY3Rpb25zIHRvIHByb3RlY3QgdGhlIGNhcnJpZXIgbmV0d29yayBhbmQgDQo+ PiB0aGUgcHJpdmFjeSBvZiBpdHMgdXNlcnMuIFRoaXMgaXMgY29udHJhZGljdG9yeSB3aXRoIG1h bnkgb3RoZXIgcGFydHMgDQo+PiBvZiB0aGUgZHJhZnQgYXMgaW4gdGhlIGNhc2UgdGhhdCB3ZSdy ZSBkaXNjdXNzaW5nIHVubGVzcyB0aGVyZSBhcmUgDQo+PiBvdGhlciByZWFzb25zIGJlaGluZCBz dWNoIGFzIG1vbmV0aXppbmcgdXNlcidzIG1ldGFkYXRhLg0KPj4NCj4+IElmIG5vdCwgd2h5IGlz IHRoaXMgaW5mb3JtYXRpb24gbGVhdmluZyB0aGUgbmV0d29yayBhbmQgcmVhY2hpbmcgdGhlIA0K Pj4gb3JpZ2luIHNlcnZlciB3aXRob3V0IGFueSBjb250cm9sIGdpdmVuIGhvdyBzZW5zaXRpdmUg aXQgaXM/DQo+Pg0KPj4gQXMgeW91IGZyYW1lIGl0LCBpdCBzb3VuZHMgbGlrZSBFbmQtdG8tRW5k IFNGQyBpcyBub3QgdGhlIGdvYWwgaW4gDQo+PiB0aGlzIGNhc2UuIElmIHNvLCBhcmVuJ3QgYmV0 dGVyIHdheXMgb2YgZG9pbmcgcGVyZm9ybWFuY2UgZW5oYW5jZW1lbnQgDQo+PiBhcyBpbiB0aGUg dmlkZW8gc3RyZWFtaW5nIGNhc2Ugd2l0aG91dCBsZWFraW5nIHBlcnNvbmFsIGRhdGEgYXMgdXNp bmcgDQo+PiAiZGlmZmVyZW50aWFsIiB2YWx1ZXMgcmF0aGVyIHRoYW4gdW5pcXVlIGFic29sdXRl IG9uZXMgb24gYSBwZXItdXNlciANCj4+IGJhc2lzPw0KPj4NCj4+IEZyb20gbXkgcGVyc3BlY3Rp dmUsICBhZGRpbmcgdGhlc2UgaGVhZGVycyBkb2VzIG5vdCBhZGQgbXVjaCB2YWx1ZSB0byANCj4+ IHRoZSB3aG9sZSBjaGFpbiwgYnV0IHN0aWxsIHByZXNlbnQgYSBzZXJpb3VzIHByaXZhY3kgY29u Y2VybiBmb3IgbW9zdCANCj4+IHVzZXJzIHNvIHRoYXQncyB3aHkgSSB3b3VsZCBsaWtlIHRvIGtu b3cgYWJvdXQgYSByZWFsIHVzZSBjYXNlIGluIA0KPj4gd2hpY2ggdGhlIHVuY29udHJvbGxlZCBs ZWFrIGJleW9uZCB0aGUgc2NvcGUgb2YgdGhlIG9wZXJhdG9yIChhbmQgdGhlIA0KPj4gYWRkaXRp b24gb2YgdGhlIGhlYWRlcnMpIGlzIGNvbXBsZXRlbHkganVzdGlmeS4NCj4+DQo+PiBKdXN0IGZv ciByZWZlcmVuY2UsIHdlIGhhdmUgaWRlbnRpZmllZCB0aGUgZm9sbG93aW5nIGhlYWRlcnMgYWRk ZWQgYnkgDQo+PiBtb2JpbGUgcHJveGllcy4gV2UgaGF2ZSByZWNvcmRzIGdvaW5nIGJhY2sgdG8g Tm92ZW1iZXIgMjAxMw0KPj4NCj4+IFRoZSAzIGhlYWRlcnMgbGlzdGVkIGJlbG93IGFyZSBwZXJt YS1jb29raWVzICh0aGUgRUZGIHNob3dlZCB0aGVpciANCj4+IGNvbmNlcm5zIHdpdGggc3VjaCBo ZWFkZXJzKSwgd2hpY2ggZG8gbm90IG1hcCB0byBhbnkgdW5pcXVlIA0KPj4gaWRlbnRpZmllciBz dWNoIGFzIElNRUkvSU1TSSBidXQgdGhleSBzdGlsbCBpZGVudGlmeSB0aGUgdXNlciANCj4+IHVu aXF1ZWx5LiBXZSBoYXZlIG9ic2VydmVkIHRoZW0gaW4gYSBidW5jaCBvZiBvcGVyYXRvcnMgYWxs IG92ZXIgdGhlIHdvcmxkLg0KPj4NCj4+IHgtYWNyDQo+PiBYLVVJREgNCj4+IFgtVkYtQUNSDQo+ Pg0KPj4gVGhlIGhlYWRlcnMgYmVsb3cgbGVhayBkaXJlY3RseSByYXcgdmFsdWVzIHdpdGhvdXQg YW55IGFub255bWl6YXRpb24gDQo+PiBhcyB5b3UgcHJvcG9zZWQsIHRodXMgYmVjb21pbmcgc2Vy aW91cyBwcml2YWN5IGxlYWtzLiBJbiBmYWN0LCB0aGVzZSANCj4+IGFyZSBzb21lIG9mIHRoZSB2 YWx1ZXMgdGhhdCBhcmUgbGlzdGVkIG9uIHRoZSBkcmFmdCBhcyBwb3NzaWJsZSANCj4+IHZhbHVl cyB0byBiZSBpbmNsdWRlZCwgd2hpY2ggaXMgd29ycnlpbmcgYW5kIGFsc28gY29udHJhZGljdGlu ZyB0aGUgDQo+PiBwcml2YWN5IHByZXNlcnZpbmcgdXNlIGNhc2UuDQo+Pg0KPj4gTEJTLUV2ZW50 VGltZTogSGVhZGVyIHByb2JhYmx5IHJlbGF0ZWQgdG8gbG9jYXRpb24tYmFzZWQgc2VydmljZXMu DQo+PiBMQlMtWm9uZUlEOiBJZGVtDQo+PiBNU0lTRE46IFN1YnNjcmliZXIgcGhvbmUgbnVtYmVy Lg0KPj4geC11cC0zZ3BwLWltZWlzdjogRGV2aWNlIElNRUkuIElkZW50aWZpZXMgdGhlIGRldmlj ZSB1bmlxdWVseS4NCj4+IHgtdXAtbmFpOiBFbWFpbC1saWtlIG5hbWUgdGhhdCBpZGVudGlmaWVz IHRoZSB1c2VyIGFuZCBvcGVyYXRvci4NCj4+IHgtdXAtY2FsbGluZy1saW5lLWlkOiBTdWJzY3Jp YmVyIHBob25lIG51bWJlci4NCj4+IHgtdXAtdm9kYWNvbWd3LXN1YmlkOiBTdWJzY3JpYmVyIHBo b25lIG51bWJlci4NCj4+DQo+Pj4gQnV0LCB0aGlzIHRlY2huaXF1ZSBpcyBsaW1pdGVkIHRvIG9u bHkgY2xlYXItdGV4dCBIVFRQLiAgIEFzIGVuZC10by1lbmQgSFRUUFMgaW5jcmVhc2VzLCB0aGUg cG9ydGlvbiBvZiBmbG93cyB0aGF0IGNhbiBiZSBlbnJpY2hlZCBpbiB0aGlzIG1hbm5lciBkZWNy ZWFzZXMuDQo+Pj4NCj4+DQo+PiBTdGlsbCwgYSBsYXJnZSBmcmFjdGlvbiBvZiB1c2VycycgdHJh ZmZpYyBpcyBzdGlsbCBIVFRQLCBhcyBpbiB0aGUgDQo+PiBjYXNlIG9mIGFkLXRyYWZmaWMgdGhh dCBhY3R1YWxseSBpbnZvbHZlIG1vcmUgdGhhbiBvbmUgcGFydHkuIEp1c3QgDQo+PiBjaGVjayBh IG5vcm1hbCBvbmxpbmUgbmV3c3BhcGVyIG9yIG1hZ2F6aW5lLiBBcyBhIHJlc3VsdCwgdGhpcyAN Cj4+IGluZm9ybWF0aW9uIGlzIGJlaW5nIGNvbGxlY3RlZCBieSBhbiB1bmNvbnRyb2xsZWQgbnVt YmVyIG9mIG9ubGluZSANCj4+IHNlcnZpY2VzLiBTb21lIG9mIHRoZW0sIG1heSBub3QgYmUgdHJ1 c3R3b3J0aHkuDQo+Pg0KPj4+IFNGQyBoYXMgdGhlIHBvdGVudGlhbCB0byBzb2x2ZSB0aGUgcHJv YmxlbSBvZiBwcm92aWRpbmcgcG9saWN5IGhvb2tzIHRvIG1pZGJveGVzIGluIGEgbW9yZSB1bml2 ZXJzYWwgYW5kIGVsZWdhbnQgZmFzaGlvbiB0aHJvdWdoIHRoZSB1c2Ugb2YgdGhlIG1ldGFkYXRh IGNhcGFiaWxpdGllcyBpbmhlcmVudCBpbiB0aGUgU0ZDIGVuY2Fwc3VsYXRpb24gaGVhZGVyLg0K Pj4+DQo+Pg0KPj4gU28gaXMgdGhlIHBvaW50IHRvIGVuYWJsZSBFMkUgU0ZDPyBPbmNlIG1vcmUs IGNvdWxkbid0IHRoaXMgYmUgZG9uZSANCj4+IHdpdGhvdXQgZW5hYmxpbmcgdXNlcnMnIHRyYWNr aW5nIGFuZCBsZWFraW5nIHRoZWlyIHBlcnNvbmFsIGRhdGE/DQo+Pg0KPj4gSG93IHdpbGwgbWlk ZGxlYm94ZXMgdGFrZSBhZHZhbnRhZ2Ugb2YgdGhlbSBpZiB0aGUgeC1oZWFkZXJzIGFyZSBub3Qg DQo+PiBzdGFuZGFyZGlzZWQgYW5kIGFyZSBoaWdobHkgY3VzdG9taXplZCBieSBvcGVyYXRvcnMg YW5kIHByb3h5IA0KPj4gbWFudWZhY3R1cmVycz8NCj4+DQo+DQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNmYyBtYWlsaW5nIGxpc3QNCj4gc2Zj QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ DQo= From nobody Fri Feb 20 14:43: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 4633F1A032D for ; Fri, 20 Feb 2015 14:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPW3Ly1zjivX for ; Fri, 20 Feb 2015 14:43:50 -0800 (PST) Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 952251A0334 for ; Fri, 20 Feb 2015 14:43:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 865BB2C406A for ; Fri, 20 Feb 2015 14:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2U8DI-jGCVQ2 for ; Fri, 20 Feb 2015 14:43:50 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (Authenticated sender: narseo) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 8C2332C406B for ; Fri, 20 Feb 2015 14:43:48 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id w8so14671534qac.1 for ; Fri, 20 Feb 2015 14:43:46 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.107.75 with SMTP id g69mr11201956qgf.103.1424472226710; Fri, 20 Feb 2015 14:43:46 -0800 (PST) Received: by 10.96.136.39 with HTTP; Fri, 20 Feb 2015 14:43:46 -0800 (PST) In-Reply-To: References: Date: Fri, 20 Feb 2015 14:43:46 -0800 Message-ID: From: Narseo Vallina Rodriguez To: "Haeffner, Walter, Vodafone DE" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Stiemerling, Martin, Prof. Dr. \(martin.stiemerling@h-da.de\)" , "sfc@ietf.org" , Ron Parker Subject: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection 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, 20 Feb 2015 22:43:53 -0000 Hi Walter Thanks for the feedback. I'm glad to see that operators are taking these considerations into account. Regarding the IPv6 addition, that is still a quite sensitive leak in my opinion. If all the traffic is being proxied, and the client IPv6 address is included on a HTTP header, which is unique, then any server will be able to track the client independently of the LDAP lookup. If the LDAP lookup is going to be implemented nonetheless, a better way could be generating a random temporal key that expires in a relative short term. Then the server will perform the lookup but the key will be randomly generated, making harder any tracking. I'd also suggest that the VIA field is also included in the header as the HTTP standards indicate so both client and server know that the HTTP traffic has been proxied. Does it make sense? Cheers On Fri, Feb 20, 2015 at 3:25 AM, Haeffner, Walter, Vodafone DE wrote: > Dear Narseo, > > Sorry for this late feedback. I was out of office for a while. Your blog = is a very valuable contribution. I will share it with all Vodafone operatio= nal units you mentioned. Wrt Vodafone Germany I can tell you that > - we overwrite http headers. Means whatever a cheater would inject does n= ot survive. > - at the moment we transfer IMSI to third party subscribers we have a con= tractual relationship. Use case e.g. is charging ring tone downloads (or ga= mes etc) > - we will fully block IMSI usage in the future and instead use an IPv6 us= er address. Getting the user identity then requires an authorized, encrypte= d LDAP query. > Do you see any issues with this planned procedure? > > Wrt the IETF draft I will work out a small paragraph describing these fac= ts. But I want to avoid a security discussion on possible solutions. This m= ust be part of the other SFC drafts. > > Best regards, > Walter > > -----Urspr=C3=BCngliche Nachricht----- > Von: Narseo Vallina Rodriguez [mailto:narseo@icsi.berkeley.edu] > Gesendet: Mittwoch, 11. Februar 2015 02:07 > An: Haeffner, Walter, Vodafone DE > Cc: Ron Parker; sfc@ietf.org; Stiemerling, Martin, Prof. Dr. (martin.stie= merling@h-da.de) > Betreff: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection > > Dear Walter > > Thanks a lot for your response. It's actually a pleasure to read the draf= t and I think it has some very interesting points. I'd also love to read Ma= rtin Stiemerling's thoughts if they are available somewhere. > > A few weeks ago, we wrote a short blog post about our view on HTTP header= injection at a global scale. > > http://netalyzr.icsi.berkeley.edu/blog/ > > We're working to extend it as paper that will be submitted this month. > Of course, any feedback and comments, specially different views that may = not be under our radar, will be very welcome! > > In your response, you mention real use-cases. As you can see in the blog = post, we have found a diverse array of headers that are used for a wide ran= ge of actions. Some of them could be used to illustrate the benefits of hea= der enrichment or to describe some use cases rather than including use-case= s involving very sensitive information such as the IMEI/IMSI or even Perma-= cookies. For instance the headers reporting the transport-layer protocol ma= y be a nice use case. > > I personally think that the draft should clearly say that this informatio= n MUST NOT leave the actual domain of the operator in order to prevent user= tracking by 3rd party services. It could be written in the same way that t= he HTTP standard says that any proxy MUST advertise its presence using the = VIA field (BTW, only a small fraction of the mobile proxies we've seen depl= oyed in real networks does actually include the standard VIA field). One mo= re thought is that given that the headers are in plain HTTP text, what does= prevent a client from impersonating someone else, specially for charging p= urposes, by adding their own headers? > > So to sum up, a nice definition of what kind of information is privacy se= nsitive could be useful, specially in the mobile use case. That would be be= tter than leaving the decision to the operator's or proxy vendor judgement.= Could that be possible? Another point to make is that enriching such heade= rs is OK as long as they do not leave the operator's domain as Ron suggeste= d. > > The US senate as well as the FCC are also showed their concerns on the us= e of perma cookies and other header enrichment techniques: > > https://www.eff.org/deeplinks/2015/02/under-senate-pressure-verizon-impro= ves-its-supercookie-opt-out > > > On Tue, Feb 10, 2015 at 4:06 AM, Haeffner, Walter, Vodafone DE wrote: >> Dear Narseo, dear Ron, >> >> Narseo, thanks for reading and commenting the draft. And thanks to Ron f= or the explanations. >> >> Indeed, some days ago one of the co-authors (Martin Stiemerling) mention= ed that HTTP Header Enrichment may come under attack. I will include a stat= ement w.r.t. your security concerns. But as pointed out by Ron, the securit= y issues are even more general. And we probably could have the same discuss= ion with SIP P-Headers; or with any subscriber-related data exchanged betwe= en different carriers and ISPs. >> >> Our intension for the mobility use case draft was to list a short number= of representative SFC use cases which are widely in place but we didn't ra= te them w.r.t. security. For sure, you are right, the listed use cases are = not very coherent w.r.t. security requirements. But that is what you curren= tly find out there in the networks. >> >> I will check, if the SFC problem statement draft includes such security = concerns. This is probably the best place for the privacy issues. At least,= the SFC architecture draft includes a paragraph: >> >> "An operator may consider the SFC Metadata as sensitive. Therefore, >> solutions should consider whether there is a risk of sensitive >> information slipping out of the operators control." >> >> Narseo, if you have a proposal to improve the text, please feel free to = send it over. >> >> Best regards, >> Walter >> >> -----Urspr=C3=BCngliche Nachricht----- >> Von: sfc [mailto:sfc-bounces@ietf.org] Im Auftrag von Narseo Vallina >> Rodriguez >> Gesendet: Dienstag, 10. Februar 2015 08:34 >> An: Ron Parker >> Cc: sfc@ietf.org >> Betreff: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection >> >> Hi Ron >> >> Thanks a lot for your explanation. I get better the point that you were = trying to make so I understand your position and I'm starting to get a bett= er picture of the whole draft. >> >> I would appreciate other's opinions about why such headers may be needed= , in particular in the mobile scenario, and how the associated privacy issu= es that today exist will be addressed. >> >> Many thanks again >> >> >> >> On Mon, Feb 9, 2015 at 4:54 PM, Ron Parker wrote: >>> Narseo, >>> >>> The point I was trying to make is that the use of the SFC encapsulation= metadata within the carrier's administrative domain, instead of HTTP heade= r enrichment, will address these security considerations. The current SFC= architecture states that it is supported within a single administrative do= main with inter-domain SFC for further study. Stated another way, end-to-= end SFC is not supported. >>> >>> Ron >>> >>> >>> ________________________________________ >>> From: Narseo Vallina Rodriguez [narseo@icsi.berkeley.edu] >>> Sent: Monday, February 09, 2015 7:26 PM >>> To: Ron Parker >>> Cc: sfc@ietf.org >>> Subject: Re: [GRAYMAIL] Re: [sfc] HTTP Header injection >>> >>> Hi Ron >>> >>> Thanks for the explanation. I still have some concerns about the >>> header enrichment that may be worth discussing further. Let me >>> respond inline. >>> >>>> The HTTP X-headers related to identification are typically inserted by= the Subscriber Management System for the benefit of transparent midboxes s= uch as video optimizers, IDS/IPS, Firewall, etc. The fact that it goes al= l the way to the origin server is sometimes incidental. >>>> >>> >>> That's exactly my main concern. The first example for SFC use cases >>> in mobile networks is functions to protect the carrier network and >>> the privacy of its users. This is contradictory with many other parts >>> of the draft as in the case that we're discussing unless there are >>> other reasons behind such as monetizing user's metadata. >>> >>> If not, why is this information leaving the network and reaching the >>> origin server without any control given how sensitive it is? >>> >>> As you frame it, it sounds like End-to-End SFC is not the goal in >>> this case. If so, aren't better ways of doing performance enhancement >>> as in the video streaming case without leaking personal data as using >>> "differential" values rather than unique absolute ones on a per-user >>> basis? >>> >>> From my perspective, adding these headers does not add much value to >>> the whole chain, but still present a serious privacy concern for most >>> users so that's why I would like to know about a real use case in >>> which the uncontrolled leak beyond the scope of the operator (and the >>> addition of the headers) is completely justify. >>> >>> Just for reference, we have identified the following headers added by >>> mobile proxies. We have records going back to November 2013 >>> >>> The 3 headers listed below are perma-cookies (the EFF showed their >>> concerns with such headers), which do not map to any unique >>> identifier such as IMEI/IMSI but they still identify the user >>> uniquely. We have observed them in a bunch of operators all over the wo= rld. >>> >>> x-acr >>> X-UIDH >>> X-VF-ACR >>> >>> The headers below leak directly raw values without any anonymization >>> as you proposed, thus becoming serious privacy leaks. In fact, these >>> are some of the values that are listed on the draft as possible >>> values to be included, which is worrying and also contradicting the >>> privacy preserving use case. >>> >>> LBS-EventTime: Header probably related to location-based services. >>> LBS-ZoneID: Idem >>> MSISDN: Subscriber phone number. >>> x-up-3gpp-imeisv: Device IMEI. Identifies the device uniquely. >>> x-up-nai: Email-like name that identifies the user and operator. >>> x-up-calling-line-id: Subscriber phone number. >>> x-up-vodacomgw-subid: Subscriber phone number. >>> >>>> But, this technique is limited to only clear-text HTTP. As end-to-en= d HTTPS increases, the portion of flows that can be enriched in this manner= decreases. >>>> >>> >>> Still, a large fraction of users' traffic is still HTTP, as in the >>> case of ad-traffic that actually involve more than one party. Just >>> check a normal online newspaper or magazine. As a result, this >>> information is being collected by an uncontrolled number of online >>> services. Some of them, may not be trustworthy. >>> >>>> SFC has the potential to solve the problem of providing policy hooks t= o midboxes in a more universal and elegant fashion through the use of the m= etadata capabilities inherent in the SFC encapsulation header. >>>> >>> >>> So is the point to enable E2E SFC? Once more, couldn't this be done >>> without enabling users' tracking and leaking their personal data? >>> >>> How will middleboxes take advantage of them if the x-headers are not >>> standardised and are highly customized by operators and proxy >>> manufacturers? >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > From nobody Mon Feb 23 11:23: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 874911A6F0B; Mon, 23 Feb 2015 11:23:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 4A8ZuzcgGr13; Mon, 23 Feb 2015 11:23:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A8C2C1A3BA4; Mon, 23 Feb 2015 11:23:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150223192314.25551.17375.idtracker@ietfa.amsl.com> Date: Mon, 23 Feb 2015 11:23:14 -0800 From: IETF Secretariat Archived-At: Subject: [sfc] ID Tracker State Update Notice: X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 19:23:15 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ From nobody Mon Feb 23 11:23:25 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 EE16A1A6F0E; Mon, 23 Feb 2015 11:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ehCqjkkXQ0T9; Mon, 23 Feb 2015 11:23:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C99A41A6F02; Mon, 23 Feb 2015 11:23:14 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150223192314.25551.42551.idtracker@ietfa.amsl.com> Date: Mon, 23 Feb 2015 11:23:14 -0800 Archived-At: Cc: sfc chair , sfc mailing list , RFC Editor Subject: [sfc] Document Action: 'Service Function Chaining Problem Statement' to Informational RFC (draft-ietf-sfc-problem-statement-13.txt) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 19:23:18 -0000 The IESG has approved the following document: - 'Service Function Chaining Problem Statement' (draft-ietf-sfc-problem-statement-13.txt) as Informational RFC This document is the product of the Service Function Chaining Working Group. The IESG contact persons are Adrian Farrel and Alia Atlas. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ Technical Summary This document provides an overview of the issues associated with the deployment of service functions (such as firewalls, load balancers) in large-scale environments. The term service function chaining is used to describe the definition and instantiation of an ordered set of instances of such service functions, and the subsequent "steering" of traffic flows through those service functions. Working Group Summary This document has been reviewed multiple times by many participants in the working group. Much of the content is widely supported, with minimal controversy. There has been some controversy around the content of section 3, which describes at a very high level the components of a service chaining solution. The working group chairs have concluded that the working group rough consensus is in favor of retaining that text in this document. Document Quality The document is in good shape, and the shepherd agrees with the chairs conclusion that it is ready for publication as an Informational RFC. There has been no formal review by outside experts, as this is an informational problem statement and does not therefore need any specified formal reviews. The shepherd has observed that the wg has received confirmation from all authors that all relevant IPR has been disclosed. There is one IPR disclosure which has caused the working group some concern. The chairs concluded that the WG had rough consensus to publish the document in the presence of the IPR disclosure. Personnel Document Shepherd: Joel Halpern Responsible Area Director: Alia Atlas From nobody Mon Feb 23 12:06: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 EFCA21A6F17; Mon, 23 Feb 2015 12:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 w_5OBqqGZ7sA; Mon, 23 Feb 2015 12:06:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A72A01A6F32; Mon, 23 Feb 2015 12:06:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150223200616.16670.52999.idtracker@ietfa.amsl.com> Date: Mon, 23 Feb 2015 12:06:16 -0800 From: IETF Secretariat Archived-At: Subject: [sfc] ID Tracker State Update Notice: X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 20:06:27 -0000 IANA action state changed to No IC ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ From nobody Mon Feb 23 14:35:49 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 F04F21A036F; Mon, 23 Feb 2015 14:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 YnP9tU6tLjVP; Mon, 23 Feb 2015 14:35:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A0B1A0018; Mon, 23 Feb 2015 14:35:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.11.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150223223546.1489.14380.idtracker@ietfa.amsl.com> Date: Mon, 23 Feb 2015 14:35:46 -0800 From: IETF Secretariat Archived-At: Subject: [sfc] ID Tracker State Update Notice: X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Feb 2015 22:35:48 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-sfc-problem-statement/ From nobody Tue Feb 24 01:59:11 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 7DFB51A0379 for ; Tue, 24 Feb 2015 01:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ah-7uBV6cP0j for ; Tue, 24 Feb 2015 01:59:06 -0800 (PST) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.109]) by ietfa.amsl.com (Postfix) with ESMTP id 9482C1A874C for ; Tue, 24 Feb 2015 01:59:05 -0800 (PST) Received: from [193.109.255.99] by server-5.bemta-14.messagelabs.com id 51/28-03170-86B4CE45; Tue, 24 Feb 2015 09:59:04 +0000 X-Env-Sender: walter.haeffner@vodafone.com X-Msg-Ref: server-3.tower-48.messagelabs.com!1424771943!8591297!1 X-Originating-IP: [195.232.224.73] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27813 invoked from network); 24 Feb 2015 09:59:03 -0000 Received: from mailout04.vodafone.com (HELO mailout04.vodafone.com) (195.232.224.73) by server-3.tower-48.messagelabs.com with SMTP; 24 Feb 2015 09:59:03 -0000 Received: from mailint04.vodafone.com (localhost [127.0.0.1]) by mailout04.vodafone.com (Postfix) with ESMTP id A683D800C1 for ; Tue, 24 Feb 2015 10:59:03 +0100 (CET) Received: from VOEXC06W.internal.vodafone.com (voexc06w.dc-ratingen.de [145.230.101.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint04.vodafone.com (Postfix) with ESMTPS id 9602A8014D; Tue, 24 Feb 2015 10:59:03 +0100 (CET) Received: from VOEXC29W.internal.vodafone.com (145.230.103.201) by VOEXC06W.internal.vodafone.com (145.230.101.26) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 24 Feb 2015 10:59:03 +0100 Received: from VOEXM20W.internal.vodafone.com ([169.254.4.248]) by voexc29w ([145.230.103.201]) with mapi id 14.03.0224.002; Tue, 24 Feb 2015 10:59:02 +0100 From: "Haeffner, Walter, Vodafone DE" To: Narseo Vallina Rodriguez Thread-Topic: [sfc] [GRAYMAIL] Re: HTTP Header injection Thread-Index: AQHQRZcCmzoio6G3nES9eCOcisq+tpz5bHCAgAC0/QCABYJ4wA== Date: Tue, 24 Feb 2015 09:59:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Stiemerling, Martin, Prof. Dr. \(martin.stiemerling@h-da.de\)" , "sfc@ietf.org" , Ron Parker Subject: Re: [sfc] [GRAYMAIL] Re: HTTP Header injection 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, 24 Feb 2015 09:59:09 -0000 SGkgTmFyc2VvLA0KDQpXZSBhbHNvIGRpc2N1c3MgaW50ZXJuYWxseSBpZiBJUHY2IHNob3VsZCBi ZSBsZWFrZWQgb3Igbm90LiBJbmRlZWQgd2UgYWxzbyBoYXZlIGEgc29sdXRpb24gaW4gcGxhY2Ug YW5kIHJlYWR5IHRvIGltcGxlbWVudCB3aGljaCBpcyBiYXNlZCBvbiBhIG9uZS10aW1lLCBzZXNz aW9uLWJhc2VkIGtleSBleGNoYW5nZWQgYmV0d2VlbiB1c2VyIGVxdWlwbWVudCBhbmQgdGhpcmQg cGFydHkgT1RUIHNlcnZpY2UgcGxhdGZvcm0uIEd1ZXNzIHRoaXMgbWV0aG9kIGJhc2ljYWxseSBy ZWZsZWN0cyB5b3VyIGlkZWEgYmVsb3cuIA0KDQpDaGVlcnMsDQpXYWx0ZXINCg0KLS0tLS1VcnNw csO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBOYXJzZW8gVmFsbGluYSBSb2RyaWd1ZXog W21haWx0bzpuYXJzZW9AaWNzaS5iZXJrZWxleS5lZHVdIA0KR2VzZW5kZXQ6IEZyZWl0YWcsIDIw LiBGZWJydWFyIDIwMTUgMjM6NDQNCkFuOiBIYWVmZm5lciwgV2FsdGVyLCBWb2RhZm9uZSBERQ0K Q2M6IFJvbiBQYXJrZXI7IHNmY0BpZXRmLm9yZzsgU3RpZW1lcmxpbmcsIE1hcnRpbiwgUHJvZi4g RHIuIChtYXJ0aW4uc3RpZW1lcmxpbmdAaC1kYS5kZSkNCkJldHJlZmY6IFJlOiBbc2ZjXSBbR1JB WU1BSUxdIFJlOiBIVFRQIEhlYWRlciBpbmplY3Rpb24NCg0KSGkgV2FsdGVyDQoNClRoYW5rcyBm b3IgdGhlIGZlZWRiYWNrLiBJJ20gZ2xhZCB0byBzZWUgdGhhdCBvcGVyYXRvcnMgYXJlIHRha2lu ZyB0aGVzZSBjb25zaWRlcmF0aW9ucyBpbnRvIGFjY291bnQuDQoNClJlZ2FyZGluZyB0aGUgSVB2 NiBhZGRpdGlvbiwgdGhhdCBpcyBzdGlsbCBhIHF1aXRlIHNlbnNpdGl2ZSBsZWFrIGluIG15IG9w aW5pb24uIElmIGFsbCB0aGUgdHJhZmZpYyBpcyBiZWluZyBwcm94aWVkLCBhbmQgdGhlIGNsaWVu dCBJUHY2IGFkZHJlc3MgaXMgaW5jbHVkZWQgb24gYSBIVFRQIGhlYWRlciwgd2hpY2ggaXMgdW5p cXVlLCB0aGVuIGFueSBzZXJ2ZXIgd2lsbCBiZSBhYmxlIHRvIHRyYWNrIHRoZSBjbGllbnQgaW5k ZXBlbmRlbnRseSBvZiB0aGUgTERBUCBsb29rdXAuDQoNCklmIHRoZSBMREFQIGxvb2t1cCBpcyBn b2luZyB0byBiZSBpbXBsZW1lbnRlZCBub25ldGhlbGVzcywgYSBiZXR0ZXIgd2F5IGNvdWxkIGJl IGdlbmVyYXRpbmcgYSByYW5kb20gdGVtcG9yYWwga2V5IHRoYXQgZXhwaXJlcyBpbiBhIHJlbGF0 aXZlIHNob3J0IHRlcm0uIFRoZW4gdGhlIHNlcnZlciB3aWxsIHBlcmZvcm0gdGhlIGxvb2t1cCBi dXQgdGhlIGtleSB3aWxsIGJlIHJhbmRvbWx5IGdlbmVyYXRlZCwgbWFraW5nIGhhcmRlciBhbnkg dHJhY2tpbmcuIEknZCBhbHNvIHN1Z2dlc3QgdGhhdCB0aGUgVklBIGZpZWxkIGlzIGFsc28gaW5j bHVkZWQgaW4gdGhlIGhlYWRlciBhcyB0aGUgSFRUUCBzdGFuZGFyZHMgaW5kaWNhdGUgc28gYm90 aCBjbGllbnQgYW5kIHNlcnZlciBrbm93IHRoYXQgdGhlIEhUVFAgdHJhZmZpYyBoYXMgYmVlbiBw cm94aWVkLg0KDQpEb2VzIGl0IG1ha2Ugc2Vuc2U/DQoNCkNoZWVycw0KDQpPbiBGcmksIEZlYiAy MCwgMjAxNSBhdCAzOjI1IEFNLCBIYWVmZm5lciwgV2FsdGVyLCBWb2RhZm9uZSBERSA8d2FsdGVy LmhhZWZmbmVyQHZvZGFmb25lLmNvbT4gd3JvdGU6DQo+IERlYXIgTmFyc2VvLA0KPg0KPiBTb3Jy eSBmb3IgdGhpcyBsYXRlIGZlZWRiYWNrLiBJIHdhcyBvdXQgb2Ygb2ZmaWNlIGZvciBhIHdoaWxl LiBZb3VyIA0KPiBibG9nIGlzIGEgdmVyeSB2YWx1YWJsZSBjb250cmlidXRpb24uIEkgd2lsbCBz aGFyZSBpdCB3aXRoIGFsbCANCj4gVm9kYWZvbmUgb3BlcmF0aW9uYWwgdW5pdHMgeW91IG1lbnRp b25lZC4gV3J0IFZvZGFmb25lIEdlcm1hbnkgSSBjYW4gDQo+IHRlbGwgeW91IHRoYXQNCj4gLSB3 ZSBvdmVyd3JpdGUgaHR0cCBoZWFkZXJzLiBNZWFucyB3aGF0ZXZlciBhIGNoZWF0ZXIgd291bGQg aW5qZWN0IGRvZXMgbm90IHN1cnZpdmUuDQo+IC0gYXQgdGhlIG1vbWVudCB3ZSB0cmFuc2ZlciBJ TVNJIHRvIHRoaXJkIHBhcnR5IHN1YnNjcmliZXJzIHdlIGhhdmUgYSANCj4gY29udHJhY3R1YWwg cmVsYXRpb25zaGlwLiBVc2UgY2FzZSBlLmcuIGlzIGNoYXJnaW5nIHJpbmcgdG9uZSANCj4gZG93 bmxvYWRzIChvciBnYW1lcyBldGMpDQo+IC0gd2Ugd2lsbCBmdWxseSBibG9jayBJTVNJIHVzYWdl IGluIHRoZSBmdXR1cmUgYW5kIGluc3RlYWQgdXNlIGFuIElQdjYgdXNlciBhZGRyZXNzLiBHZXR0 aW5nIHRoZSB1c2VyIGlkZW50aXR5IHRoZW4gcmVxdWlyZXMgYW4gYXV0aG9yaXplZCwgZW5jcnlw dGVkIExEQVAgcXVlcnkuDQo+IERvIHlvdSBzZWUgYW55IGlzc3VlcyB3aXRoIHRoaXMgcGxhbm5l ZCBwcm9jZWR1cmU/DQo+DQo+IFdydCB0aGUgSUVURiBkcmFmdCBJIHdpbGwgd29yayBvdXQgYSBz bWFsbCBwYXJhZ3JhcGggZGVzY3JpYmluZyB0aGVzZSBmYWN0cy4gQnV0IEkgd2FudCB0byBhdm9p ZCBhIHNlY3VyaXR5IGRpc2N1c3Npb24gb24gcG9zc2libGUgc29sdXRpb25zLiBUaGlzIG11c3Qg YmUgcGFydCBvZiB0aGUgb3RoZXIgU0ZDIGRyYWZ0cy4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPiBX YWx0ZXINCj4NCj4gLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KPiBWb246IE5h cnNlbyBWYWxsaW5hIFJvZHJpZ3VleiBbbWFpbHRvOm5hcnNlb0BpY3NpLmJlcmtlbGV5LmVkdV0N Cj4gR2VzZW5kZXQ6IE1pdHR3b2NoLCAxMS4gRmVicnVhciAyMDE1IDAyOjA3DQo+IEFuOiBIYWVm Zm5lciwgV2FsdGVyLCBWb2RhZm9uZSBERQ0KPiBDYzogUm9uIFBhcmtlcjsgc2ZjQGlldGYub3Jn OyBTdGllbWVybGluZywgTWFydGluLCBQcm9mLiBEci4gDQo+IChtYXJ0aW4uc3RpZW1lcmxpbmdA aC1kYS5kZSkNCj4gQmV0cmVmZjogUmU6IFtzZmNdIFtHUkFZTUFJTF0gUmU6IEhUVFAgSGVhZGVy IGluamVjdGlvbg0KPg0KPiBEZWFyIFdhbHRlcg0KPg0KPiBUaGFua3MgYSBsb3QgZm9yIHlvdXIg cmVzcG9uc2UuIEl0J3MgYWN0dWFsbHkgYSBwbGVhc3VyZSB0byByZWFkIHRoZSBkcmFmdCBhbmQg SSB0aGluayBpdCBoYXMgc29tZSB2ZXJ5IGludGVyZXN0aW5nIHBvaW50cy4gSSdkIGFsc28gbG92 ZSB0byByZWFkIE1hcnRpbiBTdGllbWVybGluZydzIHRob3VnaHRzIGlmIHRoZXkgYXJlIGF2YWls YWJsZSBzb21ld2hlcmUuDQo+DQo+IEEgZmV3IHdlZWtzIGFnbywgd2Ugd3JvdGUgYSBzaG9ydCBi bG9nIHBvc3QgYWJvdXQgb3VyIHZpZXcgb24gSFRUUCBoZWFkZXIgaW5qZWN0aW9uIGF0IGEgZ2xv YmFsIHNjYWxlLg0KPg0KPiBodHRwOi8vbmV0YWx5enIuaWNzaS5iZXJrZWxleS5lZHUvYmxvZy8N Cj4NCj4gV2UncmUgd29ya2luZyB0byBleHRlbmQgaXQgYXMgcGFwZXIgdGhhdCB3aWxsIGJlIHN1 Ym1pdHRlZCB0aGlzIG1vbnRoLg0KPiBPZiBjb3Vyc2UsIGFueSBmZWVkYmFjayBhbmQgY29tbWVu dHMsIHNwZWNpYWxseSBkaWZmZXJlbnQgdmlld3MgdGhhdCBtYXkgbm90IGJlIHVuZGVyIG91ciBy YWRhciwgd2lsbCBiZSB2ZXJ5IHdlbGNvbWUhDQo+DQo+IEluIHlvdXIgcmVzcG9uc2UsIHlvdSBt ZW50aW9uIHJlYWwgdXNlLWNhc2VzLiBBcyB5b3UgY2FuIHNlZSBpbiB0aGUgYmxvZyBwb3N0LCB3 ZSBoYXZlIGZvdW5kIGEgZGl2ZXJzZSBhcnJheSBvZiBoZWFkZXJzIHRoYXQgYXJlIHVzZWQgZm9y IGEgd2lkZSByYW5nZSBvZiBhY3Rpb25zLiBTb21lIG9mIHRoZW0gY291bGQgYmUgdXNlZCB0byBp bGx1c3RyYXRlIHRoZSBiZW5lZml0cyBvZiBoZWFkZXIgZW5yaWNobWVudCBvciB0byBkZXNjcmli ZSBzb21lIHVzZSBjYXNlcyByYXRoZXIgdGhhbiBpbmNsdWRpbmcgdXNlLWNhc2VzIGludm9sdmlu ZyB2ZXJ5IHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBzdWNoIGFzIHRoZSBJTUVJL0lNU0kgb3IgZXZl biBQZXJtYS1jb29raWVzLiBGb3IgaW5zdGFuY2UgdGhlIGhlYWRlcnMgcmVwb3J0aW5nIHRoZSB0 cmFuc3BvcnQtbGF5ZXIgcHJvdG9jb2wgbWF5IGJlIGEgbmljZSB1c2UgY2FzZS4NCj4NCj4gSSBw ZXJzb25hbGx5IHRoaW5rIHRoYXQgdGhlIGRyYWZ0IHNob3VsZCBjbGVhcmx5IHNheSB0aGF0IHRo aXMgaW5mb3JtYXRpb24gTVVTVCBOT1QgbGVhdmUgdGhlIGFjdHVhbCBkb21haW4gb2YgdGhlIG9w ZXJhdG9yIGluIG9yZGVyIHRvIHByZXZlbnQgdXNlciB0cmFja2luZyBieSAzcmQgcGFydHkgc2Vy dmljZXMuIEl0IGNvdWxkIGJlIHdyaXR0ZW4gaW4gdGhlIHNhbWUgd2F5IHRoYXQgdGhlIEhUVFAg c3RhbmRhcmQgc2F5cyB0aGF0IGFueSBwcm94eSBNVVNUIGFkdmVydGlzZSBpdHMgcHJlc2VuY2Ug dXNpbmcgdGhlIFZJQSBmaWVsZCAoQlRXLCBvbmx5IGEgc21hbGwgZnJhY3Rpb24gb2YgdGhlIG1v YmlsZSBwcm94aWVzIHdlJ3ZlIHNlZW4gZGVwbG95ZWQgaW4gcmVhbCBuZXR3b3JrcyBkb2VzIGFj dHVhbGx5IGluY2x1ZGUgdGhlIHN0YW5kYXJkIFZJQSBmaWVsZCkuIE9uZSBtb3JlIHRob3VnaHQg aXMgdGhhdCBnaXZlbiB0aGF0IHRoZSBoZWFkZXJzIGFyZSBpbiBwbGFpbiBIVFRQIHRleHQsIHdo YXQgZG9lcyBwcmV2ZW50IGEgY2xpZW50IGZyb20gaW1wZXJzb25hdGluZyBzb21lb25lIGVsc2Us IHNwZWNpYWxseSBmb3IgY2hhcmdpbmcgcHVycG9zZXMsIGJ5IGFkZGluZyB0aGVpciBvd24gaGVh ZGVycz8NCj4NCj4gU28gdG8gc3VtIHVwLCBhIG5pY2UgZGVmaW5pdGlvbiBvZiB3aGF0IGtpbmQg b2YgaW5mb3JtYXRpb24gaXMgcHJpdmFjeSBzZW5zaXRpdmUgY291bGQgYmUgdXNlZnVsLCBzcGVj aWFsbHkgaW4gdGhlIG1vYmlsZSB1c2UgY2FzZS4gVGhhdCB3b3VsZCBiZSBiZXR0ZXIgdGhhbiBs ZWF2aW5nIHRoZSBkZWNpc2lvbiB0byB0aGUgb3BlcmF0b3IncyBvciBwcm94eSB2ZW5kb3IganVk Z2VtZW50LiBDb3VsZCB0aGF0IGJlIHBvc3NpYmxlPyBBbm90aGVyIHBvaW50IHRvIG1ha2UgaXMg dGhhdCBlbnJpY2hpbmcgc3VjaCBoZWFkZXJzIGlzIE9LIGFzIGxvbmcgYXMgdGhleSBkbyBub3Qg bGVhdmUgdGhlIG9wZXJhdG9yJ3MgZG9tYWluIGFzIFJvbiBzdWdnZXN0ZWQuDQo+DQo+IFRoZSBV UyBzZW5hdGUgYXMgd2VsbCBhcyB0aGUgRkNDIGFyZSBhbHNvIHNob3dlZCB0aGVpciBjb25jZXJu cyBvbiB0aGUgdXNlIG9mIHBlcm1hIGNvb2tpZXMgYW5kIG90aGVyIGhlYWRlciBlbnJpY2htZW50 IHRlY2huaXF1ZXM6DQo+DQo+IGh0dHBzOi8vd3d3LmVmZi5vcmcvZGVlcGxpbmtzLzIwMTUvMDIv dW5kZXItc2VuYXRlLXByZXNzdXJlLXZlcml6b24taW0NCj4gcHJvdmVzLWl0cy1zdXBlcmNvb2tp ZS1vcHQtb3V0DQo+DQo+DQo+IE9uIFR1ZSwgRmViIDEwLCAyMDE1IGF0IDQ6MDYgQU0sIEhhZWZm bmVyLCBXYWx0ZXIsIFZvZGFmb25lIERFIDx3YWx0ZXIuaGFlZmZuZXJAdm9kYWZvbmUuY29tPiB3 cm90ZToNCj4+IERlYXIgTmFyc2VvLCBkZWFyIFJvbiwNCj4+DQo+PiBOYXJzZW8sIHRoYW5rcyBm b3IgcmVhZGluZyBhbmQgY29tbWVudGluZyB0aGUgZHJhZnQuIEFuZCB0aGFua3MgdG8gUm9uIGZv ciB0aGUgZXhwbGFuYXRpb25zLg0KPj4NCj4+IEluZGVlZCwgc29tZSBkYXlzIGFnbyBvbmUgb2Yg dGhlIGNvLWF1dGhvcnMgKE1hcnRpbiBTdGllbWVybGluZykgbWVudGlvbmVkIHRoYXQgSFRUUCBI ZWFkZXIgRW5yaWNobWVudCBtYXkgY29tZSB1bmRlciBhdHRhY2suIEkgd2lsbCBpbmNsdWRlIGEg c3RhdGVtZW50IHcuci50LiB5b3VyIHNlY3VyaXR5IGNvbmNlcm5zLiBCdXQgYXMgcG9pbnRlZCBv dXQgYnkgUm9uLCB0aGUgc2VjdXJpdHkgaXNzdWVzIGFyZSBldmVuIG1vcmUgZ2VuZXJhbC4gQW5k IHdlIHByb2JhYmx5IGNvdWxkIGhhdmUgdGhlIHNhbWUgZGlzY3Vzc2lvbiB3aXRoIFNJUCBQLUhl YWRlcnM7IG9yIHdpdGggYW55IHN1YnNjcmliZXItcmVsYXRlZCBkYXRhIGV4Y2hhbmdlZCBiZXR3 ZWVuIGRpZmZlcmVudCBjYXJyaWVycyBhbmQgSVNQcy4NCj4+DQo+PiBPdXIgaW50ZW5zaW9uIGZv ciB0aGUgbW9iaWxpdHkgdXNlIGNhc2UgZHJhZnQgd2FzIHRvIGxpc3QgYSBzaG9ydCBudW1iZXIg b2YgcmVwcmVzZW50YXRpdmUgU0ZDIHVzZSBjYXNlcyB3aGljaCBhcmUgd2lkZWx5IGluIHBsYWNl IGJ1dCB3ZSBkaWRuJ3QgcmF0ZSB0aGVtIHcuci50LiBzZWN1cml0eS4gRm9yIHN1cmUsIHlvdSBh cmUgcmlnaHQsIHRoZSBsaXN0ZWQgdXNlIGNhc2VzIGFyZSBub3QgdmVyeSBjb2hlcmVudCB3LnIu dC4gc2VjdXJpdHkgcmVxdWlyZW1lbnRzLiBCdXQgdGhhdCBpcyB3aGF0IHlvdSBjdXJyZW50bHkg IGZpbmQgb3V0IHRoZXJlIGluIHRoZSBuZXR3b3Jrcy4NCj4+DQo+PiBJIHdpbGwgY2hlY2ssIGlm IHRoZSBTRkMgcHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQgaW5jbHVkZXMgc3VjaCBzZWN1cml0eSBj b25jZXJucy4gVGhpcyBpcyBwcm9iYWJseSB0aGUgYmVzdCBwbGFjZSBmb3IgdGhlIHByaXZhY3kg aXNzdWVzLiBBdCBsZWFzdCwgdGhlIFNGQyBhcmNoaXRlY3R1cmUgZHJhZnQgaW5jbHVkZXMgYSBw YXJhZ3JhcGg6DQo+Pg0KPj4gIkFuIG9wZXJhdG9yIG1heSBjb25zaWRlciB0aGUgU0ZDIE1ldGFk YXRhIGFzIHNlbnNpdGl2ZS4gVGhlcmVmb3JlLCANCj4+IHNvbHV0aW9ucyBzaG91bGQgY29uc2lk ZXIgd2hldGhlciB0aGVyZSBpcyBhIHJpc2sgb2Ygc2Vuc2l0aXZlIA0KPj4gaW5mb3JtYXRpb24g c2xpcHBpbmcgb3V0IG9mIHRoZSBvcGVyYXRvcnMgY29udHJvbC4iDQo+Pg0KPj4gTmFyc2VvLCBp ZiB5b3UgaGF2ZSBhIHByb3Bvc2FsIHRvIGltcHJvdmUgdGhlIHRleHQsIHBsZWFzZSBmZWVsIGZy ZWUgdG8gc2VuZCBpdCBvdmVyLg0KPj4NCj4+IEJlc3QgcmVnYXJkcywNCj4+IFdhbHRlcg0KPj4N Cj4+IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4+IFZvbjogc2ZjIFttYWls dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcgdm9uIE5hcnNlbyBWYWxsaW5hIA0K Pj4gUm9kcmlndWV6DQo+PiBHZXNlbmRldDogRGllbnN0YWcsIDEwLiBGZWJydWFyIDIwMTUgMDg6 MzQNCj4+IEFuOiBSb24gUGFya2VyDQo+PiBDYzogc2ZjQGlldGYub3JnDQo+PiBCZXRyZWZmOiBS ZTogW3NmY10gW0dSQVlNQUlMXSBSZTogSFRUUCBIZWFkZXIgaW5qZWN0aW9uDQo+Pg0KPj4gSGkg Um9uDQo+Pg0KPj4gVGhhbmtzIGEgbG90IGZvciB5b3VyIGV4cGxhbmF0aW9uLiBJIGdldCBiZXR0 ZXIgdGhlIHBvaW50IHRoYXQgeW91IHdlcmUgdHJ5aW5nIHRvIG1ha2Ugc28gSSB1bmRlcnN0YW5k IHlvdXIgcG9zaXRpb24gYW5kIEknbSBzdGFydGluZyB0byBnZXQgYSBiZXR0ZXIgcGljdHVyZSBv ZiB0aGUgd2hvbGUgZHJhZnQuDQo+Pg0KPj4gSSB3b3VsZCBhcHByZWNpYXRlIG90aGVyJ3Mgb3Bp bmlvbnMgYWJvdXQgd2h5IHN1Y2ggaGVhZGVycyBtYXkgYmUgbmVlZGVkLCBpbiBwYXJ0aWN1bGFy IGluIHRoZSBtb2JpbGUgc2NlbmFyaW8sIGFuZCBob3cgdGhlIGFzc29jaWF0ZWQgcHJpdmFjeSBp c3N1ZXMgdGhhdCB0b2RheSBleGlzdCB3aWxsIGJlIGFkZHJlc3NlZC4NCj4+DQo+PiBNYW55IHRo YW5rcyBhZ2Fpbg0KPj4NCj4+DQo+Pg0KPj4gT24gTW9uLCBGZWIgOSwgMjAxNSBhdCA0OjU0IFBN LCBSb24gUGFya2VyIDxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPiB3cm90ZToNCj4+ PiBOYXJzZW8sDQo+Pj4NCj4+PiBUaGUgcG9pbnQgSSB3YXMgdHJ5aW5nIHRvIG1ha2UgaXMgdGhh dCB0aGUgdXNlIG9mIHRoZSBTRkMgZW5jYXBzdWxhdGlvbiBtZXRhZGF0YSB3aXRoaW4gdGhlIGNh cnJpZXIncyBhZG1pbmlzdHJhdGl2ZSBkb21haW4sIGluc3RlYWQgb2YgSFRUUCBoZWFkZXIgZW5y aWNobWVudCwgd2lsbCBhZGRyZXNzIHRoZXNlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLiAgIFRo ZSBjdXJyZW50IFNGQyBhcmNoaXRlY3R1cmUgc3RhdGVzIHRoYXQgaXQgaXMgc3VwcG9ydGVkIHdp dGhpbiBhIHNpbmdsZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4gd2l0aCBpbnRlci1kb21haW4gU0ZD IGZvciBmdXJ0aGVyIHN0dWR5LiAgIFN0YXRlZCBhbm90aGVyIHdheSwgZW5kLXRvLWVuZCBTRkMg aXMgbm90IHN1cHBvcnRlZC4NCj4+Pg0KPj4+ICAgICBSb24NCj4+Pg0KPj4+DQo+Pj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IEZyb206IE5hcnNlbyBWYWxs aW5hIFJvZHJpZ3VleiBbbmFyc2VvQGljc2kuYmVya2VsZXkuZWR1XQ0KPj4+IFNlbnQ6IE1vbmRh eSwgRmVicnVhcnkgMDksIDIwMTUgNzoyNiBQTQ0KPj4+IFRvOiBSb24gUGFya2VyDQo+Pj4gQ2M6 IHNmY0BpZXRmLm9yZw0KPj4+IFN1YmplY3Q6IFJlOiBbR1JBWU1BSUxdIFJlOiBbc2ZjXSBIVFRQ IEhlYWRlciBpbmplY3Rpb24NCj4+Pg0KPj4+IEhpIFJvbg0KPj4+DQo+Pj4gVGhhbmtzIGZvciB0 aGUgZXhwbGFuYXRpb24uIEkgc3RpbGwgaGF2ZSBzb21lIGNvbmNlcm5zIGFib3V0IHRoZSANCj4+ PiBoZWFkZXIgZW5yaWNobWVudCB0aGF0IG1heSBiZSB3b3J0aCBkaXNjdXNzaW5nIGZ1cnRoZXIu IExldCBtZSANCj4+PiByZXNwb25kIGlubGluZS4NCj4+Pg0KPj4+PiBUaGUgSFRUUCBYLWhlYWRl cnMgcmVsYXRlZCB0byBpZGVudGlmaWNhdGlvbiBhcmUgdHlwaWNhbGx5IGluc2VydGVkIGJ5IHRo ZSBTdWJzY3JpYmVyIE1hbmFnZW1lbnQgU3lzdGVtIGZvciB0aGUgYmVuZWZpdCBvZiB0cmFuc3Bh cmVudCBtaWRib3hlcyBzdWNoIGFzIHZpZGVvIG9wdGltaXplcnMsIElEUy9JUFMsIEZpcmV3YWxs LCBldGMuICAgVGhlIGZhY3QgdGhhdCBpdCBnb2VzIGFsbCB0aGUgd2F5IHRvIHRoZSBvcmlnaW4g c2VydmVyIGlzIHNvbWV0aW1lcyBpbmNpZGVudGFsLg0KPj4+Pg0KPj4+DQo+Pj4gVGhhdCdzIGV4 YWN0bHkgbXkgbWFpbiBjb25jZXJuLiBUaGUgZmlyc3QgZXhhbXBsZSBmb3IgU0ZDIHVzZSBjYXNl cyANCj4+PiBpbiBtb2JpbGUgbmV0d29ya3MgaXMgZnVuY3Rpb25zIHRvIHByb3RlY3QgdGhlIGNh cnJpZXIgbmV0d29yayBhbmQgDQo+Pj4gdGhlIHByaXZhY3kgb2YgaXRzIHVzZXJzLiBUaGlzIGlz IGNvbnRyYWRpY3Rvcnkgd2l0aCBtYW55IG90aGVyIA0KPj4+IHBhcnRzIG9mIHRoZSBkcmFmdCBh cyBpbiB0aGUgY2FzZSB0aGF0IHdlJ3JlIGRpc2N1c3NpbmcgdW5sZXNzIHRoZXJlIA0KPj4+IGFy ZSBvdGhlciByZWFzb25zIGJlaGluZCBzdWNoIGFzIG1vbmV0aXppbmcgdXNlcidzIG1ldGFkYXRh Lg0KPj4+DQo+Pj4gSWYgbm90LCB3aHkgaXMgdGhpcyBpbmZvcm1hdGlvbiBsZWF2aW5nIHRoZSBu ZXR3b3JrIGFuZCByZWFjaGluZyB0aGUgDQo+Pj4gb3JpZ2luIHNlcnZlciB3aXRob3V0IGFueSBj b250cm9sIGdpdmVuIGhvdyBzZW5zaXRpdmUgaXQgaXM/DQo+Pj4NCj4+PiBBcyB5b3UgZnJhbWUg aXQsIGl0IHNvdW5kcyBsaWtlIEVuZC10by1FbmQgU0ZDIGlzIG5vdCB0aGUgZ29hbCBpbiANCj4+ PiB0aGlzIGNhc2UuIElmIHNvLCBhcmVuJ3QgYmV0dGVyIHdheXMgb2YgZG9pbmcgcGVyZm9ybWFu Y2UgDQo+Pj4gZW5oYW5jZW1lbnQgYXMgaW4gdGhlIHZpZGVvIHN0cmVhbWluZyBjYXNlIHdpdGhv dXQgbGVha2luZyBwZXJzb25hbCANCj4+PiBkYXRhIGFzIHVzaW5nICJkaWZmZXJlbnRpYWwiIHZh bHVlcyByYXRoZXIgdGhhbiB1bmlxdWUgYWJzb2x1dGUgb25lcyANCj4+PiBvbiBhIHBlci11c2Vy IGJhc2lzPw0KPj4+DQo+Pj4gRnJvbSBteSBwZXJzcGVjdGl2ZSwgIGFkZGluZyB0aGVzZSBoZWFk ZXJzIGRvZXMgbm90IGFkZCBtdWNoIHZhbHVlIA0KPj4+IHRvIHRoZSB3aG9sZSBjaGFpbiwgYnV0 IHN0aWxsIHByZXNlbnQgYSBzZXJpb3VzIHByaXZhY3kgY29uY2VybiBmb3IgDQo+Pj4gbW9zdCB1 c2VycyBzbyB0aGF0J3Mgd2h5IEkgd291bGQgbGlrZSB0byBrbm93IGFib3V0IGEgcmVhbCB1c2Ug Y2FzZSANCj4+PiBpbiB3aGljaCB0aGUgdW5jb250cm9sbGVkIGxlYWsgYmV5b25kIHRoZSBzY29w ZSBvZiB0aGUgb3BlcmF0b3IgKGFuZCANCj4+PiB0aGUgYWRkaXRpb24gb2YgdGhlIGhlYWRlcnMp IGlzIGNvbXBsZXRlbHkganVzdGlmeS4NCj4+Pg0KPj4+IEp1c3QgZm9yIHJlZmVyZW5jZSwgd2Ug aGF2ZSBpZGVudGlmaWVkIHRoZSBmb2xsb3dpbmcgaGVhZGVycyBhZGRlZCANCj4+PiBieSBtb2Jp bGUgcHJveGllcy4gV2UgaGF2ZSByZWNvcmRzIGdvaW5nIGJhY2sgdG8gTm92ZW1iZXIgMjAxMw0K Pj4+DQo+Pj4gVGhlIDMgaGVhZGVycyBsaXN0ZWQgYmVsb3cgYXJlIHBlcm1hLWNvb2tpZXMgKHRo ZSBFRkYgc2hvd2VkIHRoZWlyIA0KPj4+IGNvbmNlcm5zIHdpdGggc3VjaCBoZWFkZXJzKSwgd2hp Y2ggZG8gbm90IG1hcCB0byBhbnkgdW5pcXVlIA0KPj4+IGlkZW50aWZpZXIgc3VjaCBhcyBJTUVJ L0lNU0kgYnV0IHRoZXkgc3RpbGwgaWRlbnRpZnkgdGhlIHVzZXIgDQo+Pj4gdW5pcXVlbHkuIFdl IGhhdmUgb2JzZXJ2ZWQgdGhlbSBpbiBhIGJ1bmNoIG9mIG9wZXJhdG9ycyBhbGwgb3ZlciB0aGUg d29ybGQuDQo+Pj4NCj4+PiB4LWFjcg0KPj4+IFgtVUlESA0KPj4+IFgtVkYtQUNSDQo+Pj4NCj4+ PiBUaGUgaGVhZGVycyBiZWxvdyBsZWFrIGRpcmVjdGx5IHJhdyB2YWx1ZXMgd2l0aG91dCBhbnkg YW5vbnltaXphdGlvbiANCj4+PiBhcyB5b3UgcHJvcG9zZWQsIHRodXMgYmVjb21pbmcgc2VyaW91 cyBwcml2YWN5IGxlYWtzLiBJbiBmYWN0LCB0aGVzZSANCj4+PiBhcmUgc29tZSBvZiB0aGUgdmFs dWVzIHRoYXQgYXJlIGxpc3RlZCBvbiB0aGUgZHJhZnQgYXMgcG9zc2libGUgDQo+Pj4gdmFsdWVz IHRvIGJlIGluY2x1ZGVkLCB3aGljaCBpcyB3b3JyeWluZyBhbmQgYWxzbyBjb250cmFkaWN0aW5n IHRoZSANCj4+PiBwcml2YWN5IHByZXNlcnZpbmcgdXNlIGNhc2UuDQo+Pj4NCj4+PiBMQlMtRXZl bnRUaW1lOiBIZWFkZXIgcHJvYmFibHkgcmVsYXRlZCB0byBsb2NhdGlvbi1iYXNlZCBzZXJ2aWNl cy4NCj4+PiBMQlMtWm9uZUlEOiBJZGVtDQo+Pj4gTVNJU0ROOiBTdWJzY3JpYmVyIHBob25lIG51 bWJlci4NCj4+PiB4LXVwLTNncHAtaW1laXN2OiBEZXZpY2UgSU1FSS4gSWRlbnRpZmllcyB0aGUg ZGV2aWNlIHVuaXF1ZWx5Lg0KPj4+IHgtdXAtbmFpOiBFbWFpbC1saWtlIG5hbWUgdGhhdCBpZGVu dGlmaWVzIHRoZSB1c2VyIGFuZCBvcGVyYXRvci4NCj4+PiB4LXVwLWNhbGxpbmctbGluZS1pZDog U3Vic2NyaWJlciBwaG9uZSBudW1iZXIuDQo+Pj4geC11cC12b2RhY29tZ3ctc3ViaWQ6IFN1YnNj cmliZXIgcGhvbmUgbnVtYmVyLg0KPj4+DQo+Pj4+IEJ1dCwgdGhpcyB0ZWNobmlxdWUgaXMgbGlt aXRlZCB0byBvbmx5IGNsZWFyLXRleHQgSFRUUC4gICBBcyBlbmQtdG8tZW5kIEhUVFBTIGluY3Jl YXNlcywgdGhlIHBvcnRpb24gb2YgZmxvd3MgdGhhdCBjYW4gYmUgZW5yaWNoZWQgaW4gdGhpcyBt YW5uZXIgZGVjcmVhc2VzLg0KPj4+Pg0KPj4+DQo+Pj4gU3RpbGwsIGEgbGFyZ2UgZnJhY3Rpb24g b2YgdXNlcnMnIHRyYWZmaWMgaXMgc3RpbGwgSFRUUCwgYXMgaW4gdGhlIA0KPj4+IGNhc2Ugb2Yg YWQtdHJhZmZpYyB0aGF0IGFjdHVhbGx5IGludm9sdmUgbW9yZSB0aGFuIG9uZSBwYXJ0eS4gSnVz dCANCj4+PiBjaGVjayBhIG5vcm1hbCBvbmxpbmUgbmV3c3BhcGVyIG9yIG1hZ2F6aW5lLiBBcyBh IHJlc3VsdCwgdGhpcyANCj4+PiBpbmZvcm1hdGlvbiBpcyBiZWluZyBjb2xsZWN0ZWQgYnkgYW4g dW5jb250cm9sbGVkIG51bWJlciBvZiBvbmxpbmUgDQo+Pj4gc2VydmljZXMuIFNvbWUgb2YgdGhl bSwgbWF5IG5vdCBiZSB0cnVzdHdvcnRoeS4NCj4+Pg0KPj4+PiBTRkMgaGFzIHRoZSBwb3RlbnRp YWwgdG8gc29sdmUgdGhlIHByb2JsZW0gb2YgcHJvdmlkaW5nIHBvbGljeSBob29rcyB0byBtaWRi b3hlcyBpbiBhIG1vcmUgdW5pdmVyc2FsIGFuZCBlbGVnYW50IGZhc2hpb24gdGhyb3VnaCB0aGUg dXNlIG9mIHRoZSBtZXRhZGF0YSBjYXBhYmlsaXRpZXMgaW5oZXJlbnQgaW4gdGhlIFNGQyBlbmNh cHN1bGF0aW9uIGhlYWRlci4NCj4+Pj4NCj4+Pg0KPj4+IFNvIGlzIHRoZSBwb2ludCB0byBlbmFi bGUgRTJFIFNGQz8gT25jZSBtb3JlLCBjb3VsZG4ndCB0aGlzIGJlIGRvbmUgDQo+Pj4gd2l0aG91 dCBlbmFibGluZyB1c2VycycgdHJhY2tpbmcgYW5kIGxlYWtpbmcgdGhlaXIgcGVyc29uYWwgZGF0 YT8NCj4+Pg0KPj4+IEhvdyB3aWxsIG1pZGRsZWJveGVzIHRha2UgYWR2YW50YWdlIG9mIHRoZW0g aWYgdGhlIHgtaGVhZGVycyBhcmUgbm90IA0KPj4+IHN0YW5kYXJkaXNlZCBhbmQgYXJlIGhpZ2hs eSBjdXN0b21pemVkIGJ5IG9wZXJhdG9ycyBhbmQgcHJveHkgDQo+Pj4gbWFudWZhY3R1cmVycz8N Cj4+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiBzZmNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+Pg0KPg0K From nobody Tue Feb 24 13:48:43 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED9F1A9036 for ; Tue, 24 Feb 2015 13:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.888 X-Spam-Level: X-Spam-Status: No, score=-13.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, 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 rSdZXExPpEXB for ; Tue, 24 Feb 2015 13:48:39 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684901A9033 for ; Tue, 24 Feb 2015 13:48:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6851; q=dns/txt; s=iport; t=1424814521; x=1426024121; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=1Itd5mtG/RhuH75VcPhbBoxIYjGcVjoeqcqQ/Nz+8Ik=; b=Dc2UxQn+jTf2meajO6PiwfpkrhusSxHK8y4+2J8lTGWVPy3EosGy7Mou THZkDIpW+RolnG92k2FtGsrHu3zrnTyduZ4kQ62gfqQ0DvLzmIV+Nx6eY RcdU0YbZY5UqoVYlHMi3XZD5GS1MQtl0iPQW4gwe/8JXGx3sI96LQ3C6x g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BjBQB68OxU/4kNJK1bgkNDUloEvSuFcoVwAoEvQwEBAQEBAXyEEAEBBIEJAgETBzQyFw4CBIhCDdUNAQEBAQEBAQMBAQEBAQEBFwSPfQuEKwWPW4NghWWTOyKDbm8BgUN/AQEB X-IronPort-AV: E=Sophos;i="5.09,641,1418083200"; d="scan'208,217";a="398790271" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP; 24 Feb 2015 21:48:40 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1OLmcbu022966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 24 Feb 2015 21:48:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.248]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Tue, 24 Feb 2015 15:48:38 -0600 From: "Reinaldo Penno (repenno)" To: "sfc@ietf.org" Thread-Topic: SFC ODL IETF-92 Hackton Thread-Index: AQHQUHul4IdRkomCw0a9ghDM83OOYQ== Date: Tue, 24 Feb 2015 21:48:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.24.219.253] Content-Type: multipart/alternative; boundary="_000_D11231A0B2EArapennogmailcom_" MIME-Version: 1.0 Archived-At: Subject: [sfc] SFC ODL IETF-92 Hackton 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, 24 Feb 2015 21:48:41 -0000 --_000_D11231A0B2EArapennogmailcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Event details: https://developer.cisco.com/site/ietf-hackathon Link to register: https://www.ietf.org/meeting/92/hackathon-signup.html SFC Program: Services Function Chaining in Opendaylight (Reinaldo Penno, Jim Guichard) SFC ODL page: https://wiki.opendaylight.org/view/Service_Function_Chaining:= Main Strongly recommend watching the webex titled "Reinaldo SFC demo=94 at the b= ottom of the page above. * Introduction to SFC architecture in Opendaylight * Architecture of SFC Agent and data plane * Work items will cover both control and data plane: * SFC Agent auto-provisioning (SF/SFF configuration-less deployments) (= Python) * SFC Agent Yang models (Yang) * SFC-OVS integration. (Java) * SFC/NSH Traceroute (Python, Standards work) * SFC Classifier (Python, Linux IPtables) * Netconf integration (Java) * Review of SFC Yang models and feedback into ODL (Yang, standards) * Implementation of Variable Length NSH packets (MD Type 02) in the dat= a plane (Python) We welcome comments on the program and suggestions Thanks, Reinaldo --_000_D11231A0B2EArapennogmailcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1E4C330F575E054AB7B132C6DE1DAC1D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Event details: 
https://developer.cisco.com/site/ietf-hackathon
Link to register: https://www.ietf.org/meeting/92/hackathon-signup.=
html
SFC Program:
Services Function Chaining in Opendaylight (Reina=
ldo Penno, Jim Guichard)


Strongly recommend watching the webex titled "Reinaldo=
 SFC demo=94 at the bottom of the page above.
  • Introductio=
n to SFC architecture in Opendaylight 
  • Architecture of SFC Agent and data plane
  • Work items will cover both control and data plane:
  • SFC Agent auto-provisioning (SF=
/SFF configuration-less deployments) (Python)
    • SFC-OVS integration. (Java)
    • SFC=
/NSH Traceroute (Python, Standards work)
    • SFC Classifier (Python, Linux IPtables)
    • Netconf integration (Java)=

    • Review of SFC Yang m=
odels and feedback into ODL (Yang, standards)
    • Implementation of Variable Length NSH packets (MD Type 02) in the da=
ta plane (Python)
We welcome comments on the program and suggestions
=


Thanks,

Reinaldo

 --_000_D11231A0B2EArapennogmailcom_-- From nobody Wed Feb 25 07:03: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 82AD71A8724 for ; Wed, 25 Feb 2015 07:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 dADU16968XE7 for ; Wed, 25 Feb 2015 07:03:38 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6D41A871E for ; Wed, 25 Feb 2015 07:03:37 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 168391B8B48; Wed, 25 Feb 2015 16:03:36 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id E582FC8145; Wed, 25 Feb 2015 16:03:35 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Wed, 25 Feb 2015 16:03:35 +0100 From: To: "paulq@cisco.com" Thread-Topic: draft-quinn-sfc-nsh: version number Thread-Index: AdBRDDloSX0/55xiS1KsQav7+px1wQ== Date: Wed, 25 Feb 2015 15:03:35 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049140B4@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330049140B4OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.25.52118 Archived-At: Cc: "sfc@ietf.org" Subject: [sfc] draft-quinn-sfc-nsh: version number 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, 25 Feb 2015 15:03:40 -0000 --_000_787AE7BB302AE849A7480A190F8B9330049140B4OPEXCLILM23corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, all, What is the purpose of having a version number in the header? Is there a ki= nd of version negotiation that needs to be in place? I checked the I-D but failed to find text that explains the rationale, the = use of the such field and whether an error will be returned if the version = is not supported by the receiving node. Wouldn't be preferable to get rid of this field given that SFC header can b= e extended using optional objects and consistent setup & configuration with= in an SFC-enabled domain should be assumed? Thank you Cheers, Med --_000_787AE7BB302AE849A7480A190F8B9330049140B4OPEXCLILM23corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul, all,

 

What is the purpose of having a version num= ber in the header? Is there a kind of version negotiation that needs to be = in place?

 

I checked the I-D but failed to find text t= hat explains the rationale, the use of the such field and whether an error = will be returned if the version is not supported by the receiving node.

 

Wouldn’t be preferable to get rid of = this field given that SFC header can be extended using optional objects and= consistent setup & configuration within an SFC-enabled domain should be assumed?

 

Thank you

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B9330049140B4OPEXCLILM23corp_-- From nobody Wed Feb 25 07:09: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 618071A040C for ; Wed, 25 Feb 2015 07:09:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 RYVbLGOffxPp for ; Wed, 25 Feb 2015 07:09:12 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94E91A1A8A for ; Wed, 25 Feb 2015 07:09:11 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 680C53B4D96; Wed, 25 Feb 2015 16:09:09 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 45A1C18008E; Wed, 25 Feb 2015 16:09:09 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Wed, 25 Feb 2015 16:09:09 +0100 From: To: "paulq@cisco.com" Thread-Topic: draft-quinn-sfc-nsh: MD Types Thread-Index: AdBRDQCmmLZUJ+uJSzez6NQrzJVyCQ== Date: Wed, 25 Feb 2015 15:09:08 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049140D1@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330049140D1OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.25.52118 Archived-At: Cc: "sfc@ietf.org" Subject: [sfc] draft-quinn-sfc-nsh: MD Types 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, 25 Feb 2015 15:09:14 -0000 --_000_787AE7BB302AE849A7480A190F8B9330049140D1OPEXCLILM23corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, all, What is the rationale for defining two MD Types? Why MD Type#1 is mandatory= to support? Wouldn't the format in Section 3.5 enough for the SFC use case= s? What is the rationale for defining these mandatory contexts headers? What i= s the motivation for defining mandatory context header? The current text does not explain those aspects. Can you please clarify? Th= ank you. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B9330049140D1OPEXCLILM23corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul, all,

 

What is the rationale for defining two MD Types? =
Why MD Type#1 is mandatory to support? Wouldn’t the format in Section=
 3.5 enough for the SFC use cases?
What is the rationale for defining these mandator=
y contexts headers? What is the motivation for defining mandatory context h=
eader?
 
The current text does not explain those aspects. =
Can you please clarify? Thank you.
 
Cheers,
Med

 

--_000_787AE7BB302AE849A7480A190F8B9330049140D1OPEXCLILM23corp_-- From nobody Wed Feb 25 07:10:04 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 CF4811A86F1 for ; Wed, 25 Feb 2015 07:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 wHauqh_TnJOf for ; Wed, 25 Feb 2015 07:10:01 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33C41A872D for ; Wed, 25 Feb 2015 07:09:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 9F39E1BC1E68; Wed, 25 Feb 2015 07:09:56 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.95.128.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 193401BC1E66; Wed, 25 Feb 2015 07:09:56 -0800 (PST) Message-ID: <54EDE5B7.6080102@joelhalpern.com> Date: Wed, 25 Feb 2015 10:09:43 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "paulq@cisco.com" References: <787AE7BB302AE849A7480A190F8B9330049140B4@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330049140B4@OPEXCLILM23.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] draft-quinn-sfc-nsh: version number 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, 25 Feb 2015 15:10:03 -0000 I would really prefer to keep the version number. Even though we have the MD-type identifier and for some MD we have the TLVs. The reason is that we may want to change the base header. For example, suppose that the ciscussion about including a flow identifier in the base header had not come up now. If it came up later, we would want to be able to have the discussion and make the choice, rather than being constrained by the lack of a version field. Yours, Joel On 2/25/15 10:03 AM, mohamed.boucadair@orange.com wrote: > Hi Paul, all, > > What is the purpose of having a version number in the header? Is there a > kind of version negotiation that needs to be in place? > > I checked the I-D but failed to find text that explains the rationale, > the use of the such field and whether an error will be returned if the > version is not supported by the receiving node. > > Wouldn’t be preferable to get rid of this field given that SFC header > can be extended using optional objects and consistent setup & > configuration within an SFC-enabled domain should be assumed? > > Thank you > > Cheers, > > Med > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Feb 25 07:13:46 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 AED881A1A91 for ; Wed, 25 Feb 2015 07:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 5zBOYvhu3qjf for ; Wed, 25 Feb 2015 07:13:43 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CB041A1A55 for ; Wed, 25 Feb 2015 07:13:43 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 5DEF0324ABC; Wed, 25 Feb 2015 16:13:41 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0D00B238082; Wed, 25 Feb 2015 16:13:41 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Wed, 25 Feb 2015 16:13:40 +0100 From: To: "paulq@cisco.com" Thread-Topic: draft-quinn-sfc-nsh: relatniship with the use cases drafts Thread-Index: AdBRDaI7xfMTZEmzRd6IIps3ZiTmog== Date: Wed, 25 Feb 2015 15:13:40 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049140FD@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330049140FDOPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.25.52118 Archived-At: Cc: "sfc@ietf.org" Subject: [sfc] draft-quinn-sfc-nsh: relatniship with the use cases drafts 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, 25 Feb 2015 15:13:44 -0000 --_000_787AE7BB302AE849A7480A190F8B9330049140FDOPEXCLILM23corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re-, It is unfortunate the current NSH specification does not rely on the SFC us= e cases as documented by the WG. Does this mean that those are useless? That no (common) requirements can be= derived from those I-Ds to guide the specification of the NSH header? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B9330049140FDOPEXCLILM23corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Re-,

 

It is unfortunate the current NSH specifica= tion does not rely on the SFC use cases as documented by the WG.

 

Does this mean that those are useless? That= no (common) requirements can be derived from those I-Ds to guide the speci= fication of the NSH header?

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B9330049140FDOPEXCLILM23corp_-- From nobody Wed Feb 25 07:16:16 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 B88521A1BE4 for ; Wed, 25 Feb 2015 07:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 82WRBCGfl8CL for ; Wed, 25 Feb 2015 07:16:13 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052D81A1B86 for ; Wed, 25 Feb 2015 07:16:13 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 40158324CD3; Wed, 25 Feb 2015 16:16:11 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1CB7F35C060; Wed, 25 Feb 2015 16:16:11 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Wed, 25 Feb 2015 16:16:11 +0100 From: To: "paulq@cisco.com" Thread-Topic: draft-quinn-sfc-nsh: Remove Section 2.2 Thread-Index: AdBRDfvGncaUVepTRKWBBq+ZY1ywcw== Date: Wed, 25 Feb 2015 15:16:10 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004914121@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933004914121OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.25.52118 Archived-At: Cc: "sfc@ietf.org" Subject: [sfc] draft-quinn-sfc-nsh: Remove Section 2.2 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, 25 Feb 2015 15:16:14 -0000 --_000_787AE7BB302AE849A7480A190F8B933004914121OPEXCLILM23corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, I suggest to remove Section 2.2. A pointer to the SFC PS I-D would suffice.= No need to be redundant here. Thank you. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B933004914121OPEXCLILM23corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul,

 

I suggest to remove Section 2.2. A pointer = to the SFC PS I-D would suffice. No need to be redundant here.

 

Thank you.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B933004914121OPEXCLILM23corp_-- From nobody Wed Feb 25 07:20: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 86B951A040C for ; Wed, 25 Feb 2015 07:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 V6bwePfu1_SV for ; Wed, 25 Feb 2015 07:20:10 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3251A1B2E for ; Wed, 25 Feb 2015 07:20:10 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id B80323B42C2; Wed, 25 Feb 2015 16:20:08 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 954FB35C0A6; Wed, 25 Feb 2015 16:20:08 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Wed, 25 Feb 2015 16:20:08 +0100 From: To: "paulq@cisco.com" Thread-Topic: draft-quinn-sfc-nsh: Relatnship with the SFC Architecture I-D Thread-Index: AdBRDomOOT0eIim0Q9CLRef0gO0ktg== Date: Wed, 25 Feb 2015 15:20:07 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004914138@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933004914138OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.25.52118 Archived-At: Cc: "sfc@ietf.org" Subject: [sfc] draft-quinn-sfc-nsh: Relatnship with the SFC Architecture I-D 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, 25 Feb 2015 15:20:11 -0000 --_000_787AE7BB302AE849A7480A190F8B933004914138OPEXCLILM23corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, The current NSH I-D cites the SFC architecture draft once. This weak adhere= nce with the SFC architecture is alarming given that the WG had a lot of di= scussion about various aspects of the overall procedure: e.g., fully distri= buted forwarding path, force the forwarding path, a mix of those, etc. Including a description of how these aspects are fulfilled in the current N= SH specification would avoid having the same discussion we had in the list. Thank you. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B933004914138OPEXCLILM23corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul,

 

The current NSH I-D cites the SFC architect= ure draft once. This weak adherence with the SFC architecture is alarming g= iven that the WG had a lot of discussion about various aspects of the overall procedure: e.g., fully distributed forwarding path,= force the forwarding path, a mix of those, etc.

 

Including a description of how these aspect= s are fulfilled in the current NSH specification would avoid having the sam= e discussion we had in the list.

 

Thank you.

 

Cheers,

Med

 

 

 

--_000_787AE7BB302AE849A7480A190F8B933004914138OPEXCLILM23corp_-- From nobody Wed Feb 25 07:38: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 B9BD01A9078 for ; Wed, 25 Feb 2015 07:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 bIg0GA1ysHmO for ; Wed, 25 Feb 2015 07:38:06 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78291A8878 for ; Wed, 25 Feb 2015 07:38:05 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 7CE283B4C4B; Wed, 25 Feb 2015 16:38:04 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.16]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 5D2D54C077; Wed, 25 Feb 2015 16:38:04 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH05.corporate.adroot.infra.ftgroup ([10.114.31.16]) with mapi id 14.03.0224.002; Wed, 25 Feb 2015 16:38:04 +0100 From: To: "paulq@cisco.com" Thread-Topic: draft-quinn-sfc-nsh: Service Index Thread-Index: AdBREQqj5oD1Ue4YR+yaXvgR38hh1Q== Date: Wed, 25 Feb 2015 15:38:03 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004914174@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933004914174OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.25.52118 Archived-At: Cc: "sfc@ietf.org" Subject: [sfc] draft-quinn-sfc-nsh: Service Index 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, 25 Feb 2015 15:38:08 -0000 --_000_787AE7BB302AE849A7480A190F8B933004914174OPEXCLILM23corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, The current text is clear about the Service Index but is it mandatory to in= clude it in the header? Wouldn't this information be available locally in t= he service nodes? The text explain that SI allows to detect loops, but isn't the loop detecte= d too late in the service chain? Wouldn't be optimal to detect the loop ear= lier? BTW, what is the behavior when several SFs are embedded in the same node (w= hich information is used to direct the traffic to the appropriate SF)? Thank you. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B933004914174OPEXCLILM23corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul,

 

The current text is clear about the Service= Index but is it mandatory to include it in the header? Wouldn’t this= information be available locally in the service nodes?

 

The text explain that SI allows to detect l= oops, but isn’t the loop detected too late in the service chain? Woul= dn’t be optimal to detect the loop earlier?

 

BTW, what is the behavior when several SFs = are embedded in the same node (which information is used to direct the traf= fic to the appropriate SF)?  

 

Thank you.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B933004914174OPEXCLILM23corp_-- From nobody Wed Feb 25 07:53: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 10E7B1A1AB1 for ; Wed, 25 Feb 2015 07:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 70BuiLHhyq-w for ; Wed, 25 Feb 2015 07:53:47 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85E761A1A55 for ; Wed, 25 Feb 2015 07:53:46 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 3E3CC264C90; Wed, 25 Feb 2015 16:53:45 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1D0CD4C070; Wed, 25 Feb 2015 16:53:45 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Wed, 25 Feb 2015 16:53:45 +0100 From: To: "paulq@cisco.com" Thread-Topic: draft-quinn-sfc-nsh: O bit Thread-Index: AdBREzsXkwltKcHTSMi8A93b3Y+HuA== Date: Wed, 25 Feb 2015 15:53:44 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049141E3@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330049141E3OPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.25.52118 Archived-At: Cc: "sfc@ietf.org" Subject: [sfc] draft-quinn-sfc-nsh: O bit 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, 25 Feb 2015 15:53:49 -0000 --_000_787AE7BB302AE849A7480A190F8B9330049141E3OPEXCLILM23corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, The current text states: " O bit: Indicates that this packet is an operations and management (OAM) packet. SFF and SFs nodes MUST examine the payload and take appropriate action (e.g. return status information). OAM message specifics and handling details are outside the scope of this document. " Is there any particular reason why this is declared out of scope? If the current scope is to be maintained, then you can remove this sentence= as it is useless since appropriate actions are not defined in the document= . "SFF and SFs nodes MUST examine the payload and take appropriate action (e.g. return status information)." Thank you. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B9330049141E3OPEXCLILM23corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul,

 

The current text states:  <= /span>

 

“

   O bit:= Indicates that this packet is an operations and management

   (OAM) = packet.  SFF and SFs nodes MUST examine the payload and take

   approp= riate action (e.g. return status information).

 

   OAM me= ssage specifics and handling details are outside the scope of

   this document.

“

 

Is there any particular reason why this is = declared out of scope?

 

If the current scope is to be maintained, t= hen you can remove this sentence as it is useless since appropriate actions= are not defined in the document.

 

“SFF and SFs nodes MUST examine the payload and take

   approp= riate action (e.g. return status information).”

 

Thank you.

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B9330049141E3OPEXCLILM23corp_-- From nobody Wed Feb 25 08:04:44 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 BA4571A90E6 for ; Wed, 25 Feb 2015 08:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 p6B7pK6emzHJ for ; Wed, 25 Feb 2015 08:04:40 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410151A8828 for ; Wed, 25 Feb 2015 08:04:40 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id 7EED0C08A1; Wed, 25 Feb 2015 17:04:38 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 52F8B15815A; Wed, 25 Feb 2015 17:04:38 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0224.002; Wed, 25 Feb 2015 17:04:38 +0100 From: To: "paulq@cisco.com" Thread-Topic: draft-quinn-sfc-nsh: critical metadata Thread-Index: AdBRFMCmQC9M1QDDShK2hhv6x8RZ1g== Date: Wed, 25 Feb 2015 16:04:38 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300491420A@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300491420AOPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.25.52118 Archived-At: Cc: "sfc@ietf.org" Subject: [sfc] draft-quinn-sfc-nsh: critical metadata 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, 25 Feb 2015 16:04:42 -0000 --_000_787AE7BB302AE849A7480A190F8B93300491420AOPEXCLILM23corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, You are defining two codepoints for "critical" and "no critical" metadata. This terminology is confusing given the "criticality" of a metadata is depl= oyment-specific. An operator will make sure that involved elements are upgr= aded to support a given context information that is mandatory-to-support fo= r his deployment. Why you there will be mandatory-to-implement metadata? Shouldn't this be ac= hieved by configuration locally to each SF-involved element? Furthermore, the current text says: If a receiver receives an encapsulated packet containing a TLV with the Critical bit set in the Type field and it does not understand how to process the Type, it MUST drop the packet. Transit devices MUST NOT drop packets based on the setting of this bit. Dropping the packet without even sending a notification to the sender is to= o aggressive IMHO. Why such behavior is proposed in the draft? Wouldn't tha= t behavior lead to more service degradation when SFC in enabled compared to= current service deployment schemes? Cheers, Med --_000_787AE7BB302AE849A7480A190F8B93300491420AOPEXCLILM23corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul,

 

You are defining two codepoints for “= critical” and “no critical” metadata.

 

This terminology is confusing given the = 220;criticality” of a metadata is deployment-specific. An operator wi= ll make sure that involved elements are upgraded to support a given context information that is mandatory-to-support for his deploymen= t.

 

Why you there will be mandatory-to-implemen= t metadata? Shouldn’t this be achieved by configuration locally to ea= ch SF-involved element?

 

Furthermore, the current text says:

 

   If a r= eceiver receives an encapsulated packet containing a TLV with

   the Cr= itical bit set in the Type field and it does not understand how<= /span>

   to pro= cess the Type, it MUST drop the packet.  Transit devices MUST

   NOT dr= op packets based on the setting of this bit.

 

Dropping the packet without even sending a = notification to the sender is too aggressive IMHO. Why such behavior is pro= posed in the draft? Wouldn’t that behavior lead to more service degradation when SFC in enabled compared to current servic= e deployment schemes?

 

Cheers,

Med

--_000_787AE7BB302AE849A7480A190F8B93300491420AOPEXCLILM23corp_-- From nobody Wed Feb 25 08:12: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 C042D1A9038 for ; Tue, 24 Feb 2015 13:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.769 X-Spam-Level: X-Spam-Status: No, score=0.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=2.767, MIME_QP_LONG_LINE=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 xDGQjVHq1CJU for ; Tue, 24 Feb 2015 13:46:32 -0800 (PST) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D43701A9036 for ; Tue, 24 Feb 2015 13:46:31 -0800 (PST) Received: by padbj1 with SMTP id bj1so39156383pad.5 for ; Tue, 24 Feb 2015 13:46:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-type; bh=yqRuHFq6rdWnXeRkH1p8PmXpsf2YOgx90qYDJid7yLI=; b=Ywf0yiGU7dZkriHBJYhck/ETjtfpRhxV7iZMxhT4NralP+mLBEj6EaZKwzoSFsYXsu EtwXKcR+/yGDtwGnFa6Kjzra4aTzzQPuGiSkLmLS4xB3jIfX0QfwktyZajUd90h4O3zt GZEbK8E976TRhc1RphD4B3Mz9ieHIqeG8r/d2PPf47OspNvud9M4+ScOovunJXAqvdWn lk/Xqjqiijaut4jVfNckJDvS5aHTXu6n4rqHwKILjFwC0r6/qmyxZJifP8Si9b2EV9yh +iaqDw6WWW4jWGxaC8RTxdI8OwabrFLCEnwXsKzEQL5beGQPa4c0QXW5+KeNUBlliVHh GLJg== X-Received: by 10.66.141.176 with SMTP id rp16mr32800039pab.11.1424814391075; Tue, 24 Feb 2015 13:46:31 -0800 (PST) Received: from [10.24.219.253] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPSA id t13sm9148608pdj.58.2015.02.24.13.46.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 24 Feb 2015 13:46:30 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.4.7.141117 Date: Tue, 24 Feb 2015 13:46:24 -0800 From: Reinaldo Penno To: "sfc-dev@lists.opendaylight.org" , "Charles Eckel (eckelcu)" Message-ID: Thread-Topic: SFC ODL IETF-92 Hackton Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3507630391_21017853" Archived-At: X-Mailman-Approved-At: Wed, 25 Feb 2015 08:12:25 -0800 Cc: sfc@ietf.org Subject: [sfc] SFC ODL IETF-92 Hackton 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, 24 Feb 2015 21:46:33 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3507630391_21017853 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Event details:=20 https://developer.cisco.com/site/ietf-hackathon Link to register: https://www.ietf.org/meeting/92/hackathon-signup.html SFC Program: Services Function Chaining in Opendaylight (Reinaldo Penno, Jim Guichard) SFC ODL page:=20 https://wiki.opendaylight.org/view/Service_Function_Chaining:Main Strongly recommend watching the webex titled "Reinaldo SFC demo=B2 at the bottom of the page above. * Introduction to SFC architecture in Opendaylight * Architecture of SFC Agent and data plane * Work items will cover both control and data plane: * SFC Agent auto-provisioning (SF/SFF configuration-less deployments) (Python) > * SFC Agent Yang models (Yang) * SFC-OVS integration. (Java) * SFC/NSH Traceroute (Python, Standards work) * SFC Classifier (Python, Linux IPtables) * Netconf integration (Java) * Review of SFC Yang models and feedback into ODL (Yang, standards) * Implementation of Variable Length NSH packets (MD Type 02) in the data plane (Python) We welcome comments on the program and suggestions Thanks, Reinaldo --B_3507630391_21017853 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable 
Event details: 
https:/=
/developer.cisco.com/site/ietf-hackathon
Link to register: https://www.ietf.org/meeting/92/hackathon-signup.html<=
/a>
SFC Program:


Strongly recommend watching the webex titled "Reinaldo SFC =
demo” at the bottom of the page above.
  • Introduction to SFC architectu=
re in Opendaylight 
  • Architecture of S=
FC Agent and data plane
  • Work items will cover both cont=
rol and data plane:
  • SFC Agen=
t auto-provisioning (SF/SFF configuration-less deployments) (Python)<=
ul style=3D"color: rgb(0, 0, 0);">
  • SFC Agent Yang models (Yang)
  • SFC-OVS integration. (Java)
  • =
SFC/NSH Traceroute (Python, Standards work)
  • SFC Classifier (Python, Linux IPtables)
    • =

  • Netconf integration (Java)
    • Review of SFC Yang models and feedback int=
o ODL (Yang, standards)
  • Implementation of Var=
iable Length NSH packets (MD Type 02) in the data plane (Python)
    • =


    We welcome commen=
ts on the program and suggestions

    Thanks,

    Reinaldo

    --B_3507630391_21017853-- From nobody Wed Feb 25 08:43: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 5B8F91A8758 for ; Wed, 25 Feb 2015 08:43:30 -0800 (PST) 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 VVxzrHc_xHDL for ; Wed, 25 Feb 2015 08:43:28 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F51A1A1B78 for ; Wed, 25 Feb 2015 08:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9129; q=dns/txt; s=iport; t=1424882607; x=1426092207; h=from:to:subject:date:message-id:mime-version; bh=2DiBJnjwraI9+fNtu6IgnoxT+8xDgD/QiR50d4kCJBY=; b=Vy3SD7h8aTTXjsJCy5unSiqSb56YhQk7cnLaZgd2uP835GPCjvkzC4ol cCKWmPCHlTmUBSMTW2gHWYUE5mcZ4nuts79jmOCabz3QOD4v/2WxhXQlQ B+ffX6w+iWFSibeMuHOTS+odvdHhq03yaagMgF1z1PuoN8COHVZ38tD0P Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DFBQAr++1U/5tdJa1bgj9DUloEvS2FcoVwgSlDAQEBAQEBfIQPAQIEgQsBCBEBAgECKDkUAwYKBAESiC8N1XEBAQEBAQUBAQEBAQEYBIsThF0NhDYFj1yDYIVlgRuDGY8KIoNubwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.09,645,1418083200"; d="scan'208,217";a="399399238" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 25 Feb 2015 16:43:26 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1PGhQVg017006 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 25 Feb 2015 16:43:26 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.45]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Wed, 25 Feb 2015 10:43:26 -0600 From: "Charles Eckel (eckelcu)" To: "Reinaldo Penno (repenno)" , "sfc@ietf.org" Thread-Topic: [sfc] SFC ODL IETF-92 Hackton Thread-Index: AQHQURothLb8D7TXvkSpy0EZg7FFiw== Date: Wed, 25 Feb 2015 16:43:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.24.213.76] Content-Type: multipart/alternative; boundary="_000_D1133B003E76Feckelcuciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] SFC ODL IETF-92 Hackton 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, 25 Feb 2015 16:43:30 -0000 --_000_D1133B003E76Feckelcuciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We are still in the process of updating the event information and registrat= ion pages to include SFC. If you go to register in the meantime and do not = see SFC listed as a technology, you can enter =93SFC=94 in the =93Other=94 = area. Also, please be aware that due to room capacity limits, registration is cap= ped at 40 participants. Cheers, Charles From: "Reinaldo Penno (repenno)" > Date: Tuesday, February 24, 2015 at 1:48 PM To: "sfc@ietf.org" > Subject: [sfc] SFC ODL IETF-92 Hackton Event details: https://developer.cisco.com/site/ietf-hackathon Link to register: https://www.ietf.org/meeting/92/hackathon-signup.html SFC Program: Services Function Chaining in Opendaylight (Reinaldo Penno, Jim Guichard) SFC ODL page: https://wiki.opendaylight.org/view/Service_Function_Chaining:= Main Strongly recommend watching the webex titled "Reinaldo SFC demo=94 at the b= ottom of the page above. * Introduction to SFC architecture in Opendaylight * Architecture of SFC Agent and data plane * Work items will cover both control and data plane: * SFC Agent auto-provisioning (SF/SFF configuration-less deployments) (= Python) * SFC Agent Yang models (Yang) * SFC-OVS integration. (Java) * SFC/NSH Traceroute (Python, Standards work) * SFC Classifier (Python, Linux IPtables) * Netconf integration (Java) * Review of SFC Yang models and feedback into ODL (Yang, standards) * Implementation of Variable Length NSH packets (MD Type 02) in the dat= a plane (Python) We welcome comments on the program and suggestions Thanks, Reinaldo --_000_D1133B003E76Feckelcuciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <2405CA6062E2DD459D64D46737F5392F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    We are still in the process of updating the event information and regi= stration pages to include SFC. If you go to register in the meantime and do= not see SFC listed as a technology, you can enter =93SFC=94 in the =93Othe= r=94 area.
    Also, please be aware that due to room capacity limits, registration i= s capped at 40 participants.

    Cheers,
    Charles

    From: "Reinaldo Penno (repenno= )" <repenno@cisco.com><= br> Date: Tuesday, February 24, 2015 at= 1:48 PM
    To: "sfc@ietf.org" <sfc@ietf.= org>
    Subject: [sfc] SFC ODL IETF-92 Hack= ton

    Event details: 
    https://developer.cisco.com/site/ietf-hackathon
Link to register: https://www.ietf.org/meeting/92/hackathon-signup.=
html
    SFC Program:
    Services Function Chaining in Opendaylight (Reina=
ldo Penno, Jim Guichard)


    Strongly recommend watching the webex titled "Reinaldo=
 SFC demo=94 at the bottom of the page above.
    • Introductio=
n to SFC architecture in Opendaylight 
    • Architecture of SFC Agent and data plane
    • Work items will cover both control and data plane:
    • SFC Agent auto-provisioning (SF=
/SFF configuration-less deployments) (Python)
      • SFC-OVS integration. (Java)
      • SFC=
/NSH Traceroute (Python, Standards work)
      • SFC Classifier (Python, Linux IPtables)
      • Netconf integration (Java)=

      • Review of SFC Yang m=
odels and feedback into ODL (Yang, standards)
      • Implementation of Variable Length NSH packets (MD Type 02) in the da=
ta plane (Python)
    We welcome comments on the program and suggestions
    =


    Thanks,

    Reinaldo

     --_000_D1133B003E76Feckelcuciscocom_-- From nobody Wed Feb 25 08:52:47 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 225B21A1A24 for ; Wed, 25 Feb 2015 08:52:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xe1MOtNllDsl for ; Wed, 25 Feb 2015 08:52:44 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87801A87C1 for ; Wed, 25 Feb 2015 08:52:35 -0800 (PST) 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 BPP95713; Wed, 25 Feb 2015 16:52:34 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Feb 2015 16:52:33 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Wed, 25 Feb 2015 08:52:28 -0800 From: Linda Dunbar To: Joel Halpern , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 Thread-Index: AdBRG3N71HhtcFa0RsuzFw1dT6iegw== Date: Wed, 25 Feb 2015 16:52:27 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.138] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645EE226Ddfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 25 Feb 2015 16:52:46 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645EE226Ddfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joel and Carlos, The current definition of RSP is: Rendered Service Path (RSP): The Service Function Path is a constrained specification of where packets using a certain service chain must go. While it may be so constrained as to identify the exact locations, it can also be less specific. Packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. Some suggestions: - I would think it is more accurate to call it "Rendered Service F= unction Path (RSFP)". - Why do you say "packets using a certain service chain"? It is mo= re accurate to say "packets belonging to a certain service function chain". Here is my suggested wording for RSP (or RSFP): - The sequence of actual SFFs and SFs in the network traversed by = packets belonging to a specific Service Function Chain is known as the Rend= ered Service Function Path (RSFP). Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645EE226Ddfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Joel and Carlos,

     

    The current definition of RSP is:

     

    Rendered Service Path (RSP)= : The Service Function Path is a

    constrained specification o= f where packets using a certain

    service chain must go. Whil= e it may be so constrained as to

    identify the exact location= s, it can also be less specific.

    Packets themselves are of c= ourse transmitted from and to

    specific places in the netw= ork, visiting a specific sequence of

    SFFs and SFs. This sequence= of actual visits by a packet to

    specific SFFs and SFs in th= e network is known as the Rendered

    Service Path (RSP). This de= finition is included here for use by

    later documents, such as wh= en solutions may need to discuss the

    actual sequence of location= s the packets visit.

     

     

    Some suggestions:

    -     &= nbsp;    I would think it is more accurate to call it “= ;Rendered Service Function Path (RSFP)”.

    -     &= nbsp;    Why do you say “packets using a certain servi= ce chain”? It is more accurate to say “packets belonging to a c= ertain service function chain”.

     

     

    Here is my suggested wording for RSP (or RSFP):=

     

    -     &= nbsp;    The sequence of actual SFFs and SFs in the network = traversed by packets belonging to a specific Service Function Chain is know= n as the Rendered Service Function Path (RSFP).

     

    Cheers,

     

    Linda Dunbar

     

    --_000_4A95BA014132FF49AE685FAB4B9F17F645EE226Ddfweml701chm_-- From nobody Wed Feb 25 09:08: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 419551A1B48 for ; Wed, 25 Feb 2015 09:08:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40Q5UIn619Mz for ; Wed, 25 Feb 2015 09:08:27 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4481A1A13 for ; Wed, 25 Feb 2015 09:08:26 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPP96900; Wed, 25 Feb 2015 17:08:25 +0000 (GMT) Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Feb 2015 17:08:24 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0158.001; Wed, 25 Feb 2015 09:08:13 -0800 From: Linda Dunbar To: Joel Halpern , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 Thread-Index: AdBRG3N71HhtcFa0RsuzFw1dT6iegwAAMTdQAABKvqA= Date: Wed, 25 Feb 2015 17:08:12 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.138] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645EE22B4dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 25 Feb 2015 17:08:30 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645EE22B4dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joel, What does it mean by saying packets "using" a service chain? How does packets "use" a service chain? I am confused. Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Wednesday, February 25, 2015 10:59 AM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I don't think adding another word to the term will help comprehension, and = it will complicate usage. So I would prefer not to do that. As for the other change, packets don't belong to a service chain. They may= be using a service chain. They may be assigned by a classifier to a servi= ce chain, but they don't "belong" to the chain as I understand the words. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 11:52 AM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: wording Suggestion for the Rendered Service Path (RSP) in draft-ie= tf-sfc-architecture-05 Joel and Carlos, The current definition of RSP is: Rendered Service Path (RSP): The Service Function Path is a constrained specification of where packets using a certain service chain must go. While it may be so constrained as to identify the exact locations, it can also be less specific. Packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. Some suggestions: - I would think it is more accurate to call it "Rendered Service F= unction Path (RSFP)". - Why do you say "packets using a certain service chain"? It is mo= re accurate to say "packets belonging to a certain service function chain". Here is my suggested wording for RSP (or RSFP): - The sequence of actual SFFs and SFs in the network traversed by = packets belonging to a specific Service Function Chain is known as the Rend= ered Service Function Path (RSFP). Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645EE22B4dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Joel,

     

    What does it mean by s= aying packets “using” a service chain?

     

    How does packets  = ;“use” a service chain? I am confused.

     

    Linda

     

    From: Joel Hal= pern [mailto:joel.halpern@ericsson.com]
    Sent: Wednesday, February 25, 2015 10:59 AM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I don’t think ad= ding another word to the term will help comprehension, and it will complica= te usage.  So I would prefer not to do that.

     

    As for the other chang= e, packets don’t belong to a service chain.  They may be using a= service chain.  They may be assigned by a classifier to a service cha= in, but they don’t “belong” to the chain as I understand the words.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Wednesday, February 25, 2015 11:52 AM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: wording Suggestion for the Rendered Service Path (RSP) in d= raft-ietf-sfc-architecture-05

     

    Joel and Carlos,

     

    The current definition of RSP is:

     

    Rendered Service Path (RSP)= : The Service Function Path is a

    constrained specification o= f where packets using a certain

    service chain must go. Whil= e it may be so constrained as to

    identify the exact location= s, it can also be less specific.

    Packets themselves are of c= ourse transmitted from and to

    specific places in the netw= ork, visiting a specific sequence of

    SFFs and SFs. This sequence= of actual visits by a packet to

    specific SFFs and SFs in th= e network is known as the Rendered

    Service Path (RSP). This de= finition is included here for use by

    later documents, such as wh= en solutions may need to discuss the

    actual sequence of location= s the packets visit.

     

     

    Some suggestions:

    -     &= nbsp;    I would think it is more accurate to call it “= ;Rendered Service Function Path (RSFP)”.

    -     &= nbsp;    Why do you say “packets using a certain servi= ce chain”? It is more accurate to say “packets belonging to a c= ertain service function chain”.

     

     

    Here is my suggested wording for RSP (or RSFP):=

     

    -     &= nbsp;    The sequence of actual SFFs and SFs in the network = traversed by packets belonging to a specific Service Function Chain is know= n as the Rendered Service Function Path (RSFP).

     

    Cheers,

     

    Linda Dunbar

     

    --_000_4A95BA014132FF49AE685FAB4B9F17F645EE22B4dfweml701chm_-- From nobody Wed Feb 25 09:18: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 69A0E1A8780 for ; Wed, 25 Feb 2015 08:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wUgZlSP3cfF for ; Wed, 25 Feb 2015 08:59:23 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE2C1A1A0F for ; Wed, 25 Feb 2015 08:59:22 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-0e-54ed9ee25624 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id BE.53.25146.2EE9DE45; Wed, 25 Feb 2015 11:07:30 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Wed, 25 Feb 2015 11:59:17 -0500 From: Joel Halpern To: Linda Dunbar , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 Thread-Index: AdBRG3N71HhtcFa0RsuzFw1dT6iegwAAMTdQ Date: Wed, 25 Feb 2015 16:59:16 +0000 Message-ID: <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_6BCE198E4EAEFC4CAB45D75826EFB0760334F522eusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyuXSPt+6jeW9DDCbv17T49G4Hi8XdlolM Fk8ebGV3YPaY8nsjq0fLkbesHkuW/GQKYI7isklJzcksSy3St0vgypjb94mp4EN8xcSrz9gb GKeEdDFycEgImEhcPibXxcgJZIpJXLi3nq2LkYtDSOAIo8SMz1uYQRJCAssZJZbPcAKx2QT0 JNa+f8wEYosI1Euc2fCTHcQWFkiXuHxpNjNEPEPi9NpeNgjbSOLE1Dtg9SwCqhLb12xhBdnL K+Arcb9TAMQUEnCR+HcvHaSCU8BV4vCiFrApjEDnfD+1BqyTWUBc4taT+UwQZwpILNlznhnC FpV4+fgfK4StKLGvfzo7RH2+xPs5s1lAbF4BQYmTM5+wTGAUmYVk1CwkZbOQlEHEdSQW7P7E BmFrSyxb+JoZxj5z4DETsvgCRvZVjBylxalluelGhpsYgbF0TILNcQfjgk+WhxgFOBiVeHgN Xr4OEWJNLCuuzD3EKM3BoiTOW3blYIiQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRgeHP1yf TnEcf753N6Of7/eXto9rlmlGT6zfLDUvfEv1bxs7gb0lCQ6K73SWTK+83Sn/Ifl++JX9Ozb/ WxlTHHFJdPIvsWVa2Rn3YuTSVxVPYvr4L8ZplY5XiXz8160LWmd4ddunf5myijm5JeOC2J3D /E7+fP1n10WVGXMG2fufDJyyonamoBJLcUaioRZzUXEiAF22qNqGAgAA Archived-At: X-Mailman-Approved-At: Wed, 25 Feb 2015 09:18:31 -0800 Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 25 Feb 2015 16:59:26 -0000 --_000_6BCE198E4EAEFC4CAB45D75826EFB0760334F522eusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't think adding another word to the term will help comprehension, and = it will complicate usage. So I would prefer not to do that. As for the other change, packets don't belong to a service chain. They may= be using a service chain. They may be assigned by a classifier to a servi= ce chain, but they don't "belong" to the chain as I understand the words. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 11:52 AM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: wording Suggestion for the Rendered Service Path (RSP) in draft-ie= tf-sfc-architecture-05 Joel and Carlos, The current definition of RSP is: Rendered Service Path (RSP): The Service Function Path is a constrained specification of where packets using a certain service chain must go. While it may be so constrained as to identify the exact locations, it can also be less specific. Packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. Some suggestions: - I would think it is more accurate to call it "Rendered Service F= unction Path (RSFP)". - Why do you say "packets using a certain service chain"? It is mo= re accurate to say "packets belonging to a certain service function chain". Here is my suggested wording for RSP (or RSFP): - The sequence of actual SFFs and SFs in the network traversed by = packets belonging to a specific Service Function Chain is known as the Rend= ered Service Function Path (RSFP). Cheers, Linda Dunbar --_000_6BCE198E4EAEFC4CAB45D75826EFB0760334F522eusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I don’t think ad= ding another word to the term will help comprehension, and it will complica= te usage.  So I would prefer not to do that.

     

    As for the other chang= e, packets don’t belong to a service chain.  They may be using a= service chain.  They may be assigned by a classifier to a service cha= in, but they don’t “belong” to the chain as I understand the words.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei.com]
    Sent: Wednesday, February 25, 2015 11:52 AM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: wording Suggestion for the Rendered Service Path (RSP) in d= raft-ietf-sfc-architecture-05

     

    Joel and Carlos,

     

    The current definition of RSP is:

     

    Rendered Service Path (RSP)= : The Service Function Path is a

    constrained specification o= f where packets using a certain

    service chain must go. Whil= e it may be so constrained as to

    identify the exact location= s, it can also be less specific.

    Packets themselves are of c= ourse transmitted from and to

    specific places in the netw= ork, visiting a specific sequence of

    SFFs and SFs. This sequence= of actual visits by a packet to

    specific SFFs and SFs in th= e network is known as the Rendered

    Service Path (RSP). This de= finition is included here for use by

    later documents, such as wh= en solutions may need to discuss the

    actual sequence of location= s the packets visit.

     

     

    Some suggestions:

    -     &= nbsp;    I would think it is more accurate to call it “= ;Rendered Service Function Path (RSFP)”.

    -     &= nbsp;    Why do you say “packets using a certain servi= ce chain”? It is more accurate to say “packets belonging to a c= ertain service function chain”.

     

     

    Here is my suggested wording for RSP (or RSFP):=

     

    -     &= nbsp;    The sequence of actual SFFs and SFs in the network = traversed by packets belonging to a specific Service Function Chain is know= n as the Rendered Service Function Path (RSFP).

     

    Cheers,

     

    Linda Dunbar

     

    --_000_6BCE198E4EAEFC4CAB45D75826EFB0760334F522eusaamb101erics_-- From nobody Wed Feb 25 09:18:34 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74CAC1A6F33 for ; Wed, 25 Feb 2015 09:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BjlIjhdhAT5 for ; Wed, 25 Feb 2015 09:10:54 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351D21A1B43 for ; Wed, 25 Feb 2015 09:10:54 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-f5-54edadc48f18 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 39.C6.03307.4CDADE45; Wed, 25 Feb 2015 12:11:00 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0210.002; Wed, 25 Feb 2015 12:10:52 -0500 From: Joel Halpern To: Linda Dunbar , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 Thread-Index: AdBRG3N71HhtcFa0RsuzFw1dT6iegwAAMTdQAABKvqAAABrE4A== Date: Wed, 25 Feb 2015 17:10:52 +0000 Message-ID: <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_6BCE198E4EAEFC4CAB45D75826EFB0760334F5DEeusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXRPuO6RtW9DDObPkrT49G4Hi8XdlolM Fk8ebGV3YPaY8nsjq0fLkbesHkuW/GQKYI7isklJzcksSy3St0vgynj95Rp7QXs7Y8WCzmNs DYwPy7oYOTkkBEwk9q9ewAZhi0lcuLcezBYSOMIoMfFEVBcjF5C9nFHiwN4vLCAJNgE9ibXv HzOB2CIC9RJnNvxkB7GFBdIlLl+azQwRz5A4vbaXDcJ2kpgx+zpYnEVAVWLqgeNgNq+Ar0T/ tyXMEAsOM0pcmbafESTBKeAqcejbVbBljEAXfT+1BmwZs4C4xK0n85kgLhWQWLLnPDOELSrx 8vE/VghbUWJf/3R2iPp8ibb3FxghlglKnJz5hGUCo8gsJKNmISmbhaQMIq4jsWD3JzYIW1ti 2cLXzDD2mQOPmZDFFzCyr2LkKC1OLctNNzLYxAiMqmMSbLo7GPe8tDzEKMDBqMTDa/DydYgQ a2JZcWXuIUZpDhYlcd5FDw6GCAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamD0cry9YfuKhRe6 FHUX/pbpNmWptRA6vclpTmg/61mtiwYG7T8958namYUpxuy58f4Dw+TlPxhq3P3/GclzKrXc 2vM4JW//U44Va3d/aDdl0oi5EPjyBfulrT62H0q0Jjy+toF54RWTLY8SLprc2+P3xGqfZv9l ebWCqnlsQldEIgpe/s8PPHNdiaU4I9FQi7moOBEA78SspIsCAAA= Archived-At: X-Mailman-Approved-At: Wed, 25 Feb 2015 09:18:31 -0800 Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 25 Feb 2015 17:10:57 -0000 --_000_6BCE198E4EAEFC4CAB45D75826EFB0760334F5DEeusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry. A packet is technically using a service function path. It is doing= so if the information in the SFC defined header indicates that the packet = is to forwarded along that service function path. Thus, the assignment / u= sage can be determined from examining the packet. The RSP itself requires = a rather omniscient observer perspective to determine, but does exist conce= ptually. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 12:08 PM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Joel, What does it mean by saying packets "using" a service chain? How does packets "use" a service chain? I am confused. Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Wednesday, February 25, 2015 10:59 AM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I don't think adding another word to the term will help comprehension, and = it will complicate usage. So I would prefer not to do that. As for the other change, packets don't belong to a service chain. They may= be using a service chain. They may be assigned by a classifier to a servi= ce chain, but they don't "belong" to the chain as I understand the words. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 11:52 AM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: wording Suggestion for the Rendered Service Path (RSP) in draft-ie= tf-sfc-architecture-05 Joel and Carlos, The current definition of RSP is: Rendered Service Path (RSP): The Service Function Path is a constrained specification of where packets using a certain service chain must go. While it may be so constrained as to identify the exact locations, it can also be less specific. Packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. Some suggestions: - I would think it is more accurate to call it "Rendered Service F= unction Path (RSFP)". - Why do you say "packets using a certain service chain"? It is mo= re accurate to say "packets belonging to a certain service function chain". Here is my suggested wording for RSP (or RSFP): - The sequence of actual SFFs and SFs in the network traversed by = packets belonging to a specific Service Function Chain is known as the Rend= ered Service Function Path (RSFP). Cheers, Linda Dunbar --_000_6BCE198E4EAEFC4CAB45D75826EFB0760334F5DEeusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Sorry.  A packet = is technically using a service function path.  It is doing so if the i= nformation in the SFC defined header indicates that the packet is to forwar= ded along that service function path.  Thus, the assignment / usage can be determined from examining the packet.  The = RSP itself requires a rather omniscient observer perspective to determine, = but does exist conceptually.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei.com]
    Sent: Wednesday, February 25, 2015 12:08 PM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Joel,

     

    What does it mean by s= aying packets “using” a service chain?

     

    How does packets  = ;“use” a service chain? I am confused.

     

    Linda

     

    From: Joel Hal= pern [mailto:joel.halpern@= ericsson.com]
    Sent: Wednesday, February 25, 2015 10:59 AM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I don’t think ad= ding another word to the term will help comprehension, and it will complica= te usage.  So I would prefer not to do that.

     

    As for the other chang= e, packets don’t belong to a service chain.  They may be using a= service chain.  They may be assigned by a classifier to a service cha= in, but they don’t “belong” to the chain as I understand the words.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Wednesday, February 25, 2015 11:52 AM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: wording Suggestion for the Rendered Service Path (RSP) in d= raft-ietf-sfc-architecture-05

     

    Joel and Carlos,

     

    The current definition of RSP is:

     

    Rendered Service Path (RSP)= : The Service Function Path is a

    constrained specification o= f where packets using a certain

    service chain must go. Whil= e it may be so constrained as to

    identify the exact location= s, it can also be less specific.

    Packets themselves are of c= ourse transmitted from and to

    specific places in the netw= ork, visiting a specific sequence of

    SFFs and SFs. This sequence= of actual visits by a packet to

    specific SFFs and SFs in th= e network is known as the Rendered

    Service Path (RSP). This de= finition is included here for use by

    later documents, such as wh= en solutions may need to discuss the

    actual sequence of location= s the packets visit.

     

     

    Some suggestions:

    -     &= nbsp;    I would think it is more accurate to call it “= ;Rendered Service Function Path (RSFP)”.

    -     &= nbsp;    Why do you say “packets using a certain servi= ce chain”? It is more accurate to say “packets belonging to a c= ertain service function chain”.

     

     

    Here is my suggested wording for RSP (or RSFP):=

     

    -     &= nbsp;    The sequence of actual SFFs and SFs in the network = traversed by packets belonging to a specific Service Function Chain is know= n as the Rendered Service Function Path (RSFP).

     

    Cheers,

     

    Linda Dunbar

     

    --_000_6BCE198E4EAEFC4CAB45D75826EFB0760334F5DEeusaamb101erics_-- From nobody Wed Feb 25 09:21:18 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086781A1B72 for ; Wed, 25 Feb 2015 09:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGXNwW4uqKBD for ; Wed, 25 Feb 2015 09:21:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D57F1A040C for ; Wed, 25 Feb 2015 09:21:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPP97966; Wed, 25 Feb 2015 17:21:11 +0000 (GMT) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Feb 2015 17:21:10 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Wed, 25 Feb 2015 09:21:06 -0800 From: Linda Dunbar To: Joel Halpern , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 Thread-Index: AdBRG3N71HhtcFa0RsuzFw1dT6iegwAAMTdQAABKvqAAABrE4AAASCFQ Date: Wed, 25 Feb 2015 17:21:06 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645EE22FE@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.138] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645EE22FEdfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 25 Feb 2015 17:21:17 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645EE22FEdfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Packets being "assigned" to a Service Function Chain (path) makes sense. But packets "using" a service function chain/path is quite odd. Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Wednesday, February 25, 2015 11:11 AM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Sorry. A packet is technically using a service function path. It is doing= so if the information in the SFC defined header indicates that the packet = is to forwarded along that service function path. Thus, the assignment / u= sage can be determined from examining the packet. The RSP itself requires = a rather omniscient observer perspective to determine, but does exist conce= ptually. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 12:08 PM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Joel, What does it mean by saying packets "using" a service chain? How does packets "use" a service chain? I am confused. Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Wednesday, February 25, 2015 10:59 AM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I don't think adding another word to the term will help comprehension, and = it will complicate usage. So I would prefer not to do that. As for the other change, packets don't belong to a service chain. They may= be using a service chain. They may be assigned by a classifier to a servi= ce chain, but they don't "belong" to the chain as I understand the words. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 11:52 AM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: wording Suggestion for the Rendered Service Path (RSP) in draft-ie= tf-sfc-architecture-05 Joel and Carlos, The current definition of RSP is: Rendered Service Path (RSP): The Service Function Path is a constrained specification of where packets using a certain service chain must go. While it may be so constrained as to identify the exact locations, it can also be less specific. Packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. Some suggestions: - I would think it is more accurate to call it "Rendered Service F= unction Path (RSFP)". - Why do you say "packets using a certain service chain"? It is mo= re accurate to say "packets belonging to a certain service function chain". Here is my suggested wording for RSP (or RSFP): - The sequence of actual SFFs and SFs in the network traversed by = packets belonging to a specific Service Function Chain is known as the Rend= ered Service Function Path (RSFP). Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645EE22FEdfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Packets being “a= ssigned” to a Service Function Chain (path) makes sense.

     

    But packets “usi= ng” a service function chain/path is quite odd.

     

    Linda

     

    From: Joel Hal= pern [mailto:joel.halpern@ericsson.com]
    Sent: Wednesday, February 25, 2015 11:11 AM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Sorry.  A packet = is technically using a service function path.  It is doing so if the i= nformation in the SFC defined header indicates that the packet is to forwar= ded along that service function path.  Thus, the assignment / usage can be determined from examining the packet.  The = RSP itself requires a rather omniscient observer perspective to determine, = but does exist conceptually.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Wednesday, February 25, 2015 12:08 PM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Joel,

     

    What does it mean by s= aying packets “using” a service chain?

     

    How does packets  = ;“use” a service chain? I am confused.

     

    Linda

     

    From: Joel Hal= pern [mailto:joel.halpern@= ericsson.com]
    Sent: Wednesday, February 25, 2015 10:59 AM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I don’t think ad= ding another word to the term will help comprehension, and it will complica= te usage.  So I would prefer not to do that.

     

    As for the other chang= e, packets don’t belong to a service chain.  They may be using a= service chain.  They may be assigned by a classifier to a service cha= in, but they don’t “belong” to the chain as I understand the words.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Wednesday, February 25, 2015 11:52 AM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: wording Suggestion for the Rendered Service Path (RSP) in d= raft-ietf-sfc-architecture-05

     

    Joel and Carlos,

     

    The current definition of RSP is:

     

    Rendered Service Path (RSP)= : The Service Function Path is a

    constrained specification o= f where packets using a certain

    service chain must go. Whil= e it may be so constrained as to

    identify the exact location= s, it can also be less specific.

    Packets themselves are of c= ourse transmitted from and to

    specific places in the netw= ork, visiting a specific sequence of

    SFFs and SFs. This sequence= of actual visits by a packet to

    specific SFFs and SFs in th= e network is known as the Rendered

    Service Path (RSP). This de= finition is included here for use by

    later documents, such as wh= en solutions may need to discuss the

    actual sequence of location= s the packets visit.

     

     

    Some suggestions:

    -     &= nbsp;    I would think it is more accurate to call it “= ;Rendered Service Function Path (RSFP)”.

    -     &= nbsp;    Why do you say “packets using a certain servi= ce chain”? It is more accurate to say “packets belonging to a c= ertain service function chain”.

     

     

    Here is my suggested wording for RSP (or RSFP):=

     

    -     &= nbsp;    The sequence of actual SFFs and SFs in the network = traversed by packets belonging to a specific Service Function Chain is know= n as the Rendered Service Function Path (RSFP).

     

    Cheers,

     

    Linda Dunbar

     

    --_000_4A95BA014132FF49AE685FAB4B9F17F645EE22FEdfweml701chm_-- From nobody Wed Feb 25 09:26:46 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 3D9D21A1AB0 for ; Wed, 25 Feb 2015 09:26:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 OP_DAzK5GVtq for ; Wed, 25 Feb 2015 09:26:34 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1FF1A1AFB for ; Wed, 25 Feb 2015 09:26:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 1F7251BC1CA3; Wed, 25 Feb 2015 09:26:32 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.95.128.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 677C61BC1C95; Wed, 25 Feb 2015 09:26:31 -0800 (PST) Message-ID: <54EE05BA.1010405@joelhalpern.com> Date: Wed, 25 Feb 2015 12:26:18 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Linda Dunbar , Joel Halpern , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22FE@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645EE22FE@dfweml701-chm> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 25 Feb 2015 17:26:43 -0000 I could live with replacing "using" with "assigned to". Yours, Joel On 2/25/15 12:21 PM, Linda Dunbar wrote: > Packets being “assigned” to a Service Function Chain (path) makes sense. > > But packets “using” a service function chain/path is quite odd. > > Linda > > *From:*Joel Halpern [mailto:joel.halpern@ericsson.com] > *Sent:* Wednesday, February 25, 2015 11:11 AM > *To:* Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org > *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in > draft-ietf-sfc-architecture-05 > > Sorry. A packet is technically using a service function path. It is > doing so if the information in the SFC defined header indicates that the > packet is to forwarded along that service function path. Thus, the > assignment / usage can be determined from examining the packet. The RSP > itself requires a rather omniscient observer perspective to determine, > but does exist conceptually. > > Yours, > > Joel > > *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com] > *Sent:* Wednesday, February 25, 2015 12:08 PM > *To:* Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org > > *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in > draft-ietf-sfc-architecture-05 > > Joel, > > What does it mean by saying packets “using” a service chain? > > How does packets “use” a service chain? I am confused. > > Linda > > *From:*Joel Halpern [mailto:joel.halpern@ericsson.com] > > *Sent:* Wednesday, February 25, 2015 10:59 AM > *To:* Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org > > *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in > draft-ietf-sfc-architecture-05 > > I don’t think adding another word to the term will help comprehension, > and it will complicate usage. So I would prefer not to do that. > > As for the other change, packets don’t belong to a service chain. They > may be using a service chain. They may be assigned by a classifier to a > service chain, but they don’t “belong” to the chain as I understand the > words. > > Yours, > > Joel > > *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com] > *Sent:* Wednesday, February 25, 2015 11:52 AM > *To:* Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org > > *Subject:* wording Suggestion for the Rendered Service Path (RSP) in > draft-ietf-sfc-architecture-05 > > Joel and Carlos, > > The current definition of RSP is: > > Rendered Service Path (RSP): The Service Function Path is a > > constrained specification of where packets using a certain > > service chain must go. While it may be so constrained as to > > identify the exact locations, it can also be less specific. > > Packets themselves are of course transmitted from and to > > specific places in the network, visiting a specific sequence of > > SFFs and SFs. This sequence of actual visits by a packet to > > specific SFFs and SFs in the network is known as the Rendered > > Service Path (RSP). This definition is included here for use by > > later documents, such as when solutions may need to discuss the > > actual sequence of locations the packets visit. > > Some suggestions: > > -I would think it is more accurate to call it “Rendered Service Function > Path (RSFP)”. > > -Why do you say “packets using a certain service chain”? It is more > accurate to say “packets belonging to a certain service function chain”. > > Here is my suggested wording for RSP (or RSFP): > > -The sequence of actual SFFs and SFs in the network traversed by packets > belonging to a specific Service Function Chain is known as the Rendered > Service Function Path (RSFP). > > Cheers, > > Linda Dunbar > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Wed Feb 25 09:28:37 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE981A1A48 for ; Wed, 25 Feb 2015 09:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 iCWcc1k2BhiO for ; Wed, 25 Feb 2015 09:28:31 -0800 (PST) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) by ietfa.amsl.com (Postfix) with ESMTP id 8241B1A1B13 for ; Wed, 25 Feb 2015 09:28:31 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 037FB72E0EF; Wed, 25 Feb 2015 12:28:31 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpvbsrv1.mitre.org (Postfix) with ESMTP id E89B3B2E163; Wed, 25 Feb 2015 12:28:30 -0500 (EST) Received: from imshyb02.MITRE.ORG (129.83.29.3) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 25 Feb 2015 12:28:30 -0500 Received: from imshyb01.MITRE.ORG (129.83.29.2) by imshyb02.MITRE.ORG (129.83.29.3) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Wed, 25 Feb 2015 12:28:30 -0500 Received: from na01-bn1-obe.outbound.protection.outlook.com (10.140.19.249) by imshyb01.MITRE.ORG (129.83.29.2) with Microsoft SMTP Server (TLS) id 15.0.1044.25 via Frontend Transport; Wed, 25 Feb 2015 12:28:30 -0500 Received: from BY1PR09MB0440.namprd09.prod.outlook.com (25.160.109.22) by BY1PR09MB0440.namprd09.prod.outlook.com (25.160.109.22) with Microsoft SMTP Server (TLS) id 15.1.93.16; Wed, 25 Feb 2015 17:28:28 +0000 Received: from BY1PR09MB0440.namprd09.prod.outlook.com ([25.160.109.22]) by BY1PR09MB0440.namprd09.prod.outlook.com ([25.160.109.22]) with mapi id 15.01.0093.004; Wed, 25 Feb 2015 17:28:28 +0000 From: "Natale, Bob" To: Linda Dunbar , Joel Halpern , "Carlos Pignataro (cpignata)" Thread-Topic: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 Thread-Index: AdBRG3N71HhtcFa0RsuzFw1dT6iegwAAMTdQAABKvqAAABrE4AAASCFQAABMzLA= Importance: low X-Priority: 5 Date: Wed, 25 Feb 2015 17:28:28 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22FE@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645EE22FE@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.29.234.167] authentication-results: spf=none (sender IP is ) smtp.mailfrom=RNATALE@mitre.org; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0440; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BY1PR09MB0440; x-forefront-prvs: 049897979A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(199003)(189002)(62966003)(76576001)(19300405004)(86362001)(2950100001)(2900100001)(106356001)(97736003)(92566002)(102836002)(15975445007)(77156002)(68736005)(46102003)(122556002)(19625215002)(33656002)(105586002)(99286002)(230783001)(19609705001)(19580405001)(19580395003)(87936001)(2656002)(93886004)(54356999)(76176999)(74316001)(16236675004)(66066001)(40100003)(50986999)(81686999)(101416001)(64706001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY1PR09MB0440; H:BY1PR09MB0440.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BY1PR09MB0440C47EAE04023472CA1F2FA8170BY1PR09MB0440namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2015 17:28:28.2747 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR09MB0440 X-OriginatorOrg: mitre.org Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 25 Feb 2015 17:28:35 -0000 --_000_BY1PR09MB0440C47EAE04023472CA1F2FA8170BY1PR09MB0440namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am agnostic about the "using" vs. "assigned" vs. something else nomenclat= ure, but feel it's important to follow Joel's explicit use of "service func= tion path" in this context ... a given "service function chain" can be conf= igured over multiple different "paths", even concurrently. Avanti, BobN From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, February 25, 2015 12:21 PM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) i= n draft-ietf-sfc-architecture-05 Packets being "assigned" to a Service Function Chain (path) makes sense. But packets "using" a service function chain/path is quite odd. Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Wednesday, February 25, 2015 11:11 AM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Sorry. A packet is technically using a service function path. It is doing= so if the information in the SFC defined header indicates that the packet = is to forwarded along that service function path. Thus, the assignment / u= sage can be determined from examining the packet. The RSP itself requires = a rather omniscient observer perspective to determine, but does exist conce= ptually. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 12:08 PM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Joel, What does it mean by saying packets "using" a service chain? How does packets "use" a service chain? I am confused. Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Wednesday, February 25, 2015 10:59 AM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I don't think adding another word to the term will help comprehension, and = it will complicate usage. So I would prefer not to do that. As for the other change, packets don't belong to a service chain. They may= be using a service chain. They may be assigned by a classifier to a servi= ce chain, but they don't "belong" to the chain as I understand the words. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 11:52 AM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: wording Suggestion for the Rendered Service Path (RSP) in draft-ie= tf-sfc-architecture-05 Joel and Carlos, The current definition of RSP is: Rendered Service Path (RSP): The Service Function Path is a constrained specification of where packets using a certain service chain must go. While it may be so constrained as to identify the exact locations, it can also be less specific. Packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. Some suggestions: - I would think it is more accurate to call it "Rendered Service F= unction Path (RSFP)". - Why do you say "packets using a certain service chain"? It is mo= re accurate to say "packets belonging to a certain service function chain". Here is my suggested wording for RSP (or RSFP): - The sequence of actual SFFs and SFs in the network traversed by = packets belonging to a specific Service Function Chain is known as the Rend= ered Service Function Path (RSFP). Cheers, Linda Dunbar --_000_BY1PR09MB0440C47EAE04023472CA1F2FA8170BY1PR09MB0440namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I am = agnostic about the “using” vs. “assigned” vs. somet= hing else nomenclature, but feel it’s important to follow Joel’= s explicit use of “service function path” in this context ̷= 0; a given “service function chain” can be configured over multiple different “pat= hs”, even concurrently.

    =  

    Avant= i,

    BobN<= o:p>

    =  

    From: sfc [mailto:sfc-bounces@ietf.org] On= Behalf Of Linda Dunbar
    Sent: Wednesday, February 25, 2015 12:21 PM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: Re: [sfc] wording Suggestion for the Rendered Service Path = (RSP) in draft-ietf-sfc-architecture-05

     

    Packets being “a= ssigned” to a Service Function Chain (path) makes sense.

     

    But packets “usi= ng” a service function chain/path is quite odd.

     

    Linda

     

    From: Joel Halpern [mailto:joel.halpern@ericsson.com]
    Sent: Wednesday, February 25, 2015 11:11 AM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Sorry.  A packet = is technically using a service function path.  It is doing so if the i= nformation in the SFC defined header indicates that the packet is to forwar= ded along that service function path.  Thus, the assignment / usage can be determined from examining the packet.  The = RSP itself requires a rather omniscient observer perspective to determine, = but does exist conceptually.

     

    Yours,

    Joel=

     

    From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
    Sent: Wednesday, February 25, 2015 12:08 PM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Joel,

     

    What does it mean by s= aying packets “using” a service chain?

     

    How does packets  = ;“use” a service chain? I am confused.

     

    Linda

     

    From: Joel Halpern [mailto:joel.halpern@= ericsson.com]
    Sent: Wednesday, February 25, 2015 10:59 AM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I don’t think ad= ding another word to the term will help comprehension, and it will complica= te usage.  So I would prefer not to do that.

     

    As for the other chang= e, packets don’t belong to a service chain.  They may be using a= service chain.  They may be assigned by a classifier to a service cha= in, but they don’t “belong” to the chain as I understand the words.

     

    Yours,

    Joel=

     

    From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
    Sent: Wednesday, February 25, 2015 11:52 AM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: wording Suggestion for the Rendered Service Path (RSP) in d= raft-ietf-sfc-architecture-05

     

    Joel and Carlos,

     

    The current definition of RSP is:

     

    Rendered Service Path (RSP)= : The Service Function Path is a

    constrained specification o= f where packets using a certain

    service chain must go. Whil= e it may be so constrained as to

    identify the exact location= s, it can also be less specific.

    Packets themselves are of c= ourse transmitted from and to

    specific places in the netw= ork, visiting a specific sequence of

    SFFs and SFs. This sequence= of actual visits by a packet to

    specific SFFs and SFs in th= e network is known as the Rendered

    Service Path (RSP). This de= finition is included here for use by

    later documents, such as wh= en solutions may need to discuss the

    actual sequence of location= s the packets visit.

     

     

    Some suggestions:

    -     &= nbsp;    I would think it is more accurate to call it “= ;Rendered Service Function Path (RSFP)”.

    -     &= nbsp;    Why do you say “packets using a certain servi= ce chain”? It is more accurate to say “packets belonging to a c= ertain service function chain”.

     

     

    Here is my suggested wording for RSP (or RSFP):=

     

    -     &= nbsp;    The sequence of actual SFFs and SFs in the network = traversed by packets belonging to a specific Service Function Chain is know= n as the Rendered Service Function Path (RSFP).

     

    Cheers,

     

    Linda Dunbar

     

    --_000_BY1PR09MB0440C47EAE04023472CA1F2FA8170BY1PR09MB0440namp_-- From nobody Wed Feb 25 09:53:18 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A531A0015 for ; Wed, 25 Feb 2015 09:53:14 -0800 (PST) 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 1KYoTCcGqkaS for ; Wed, 25 Feb 2015 09:53:13 -0800 (PST) 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 527E41A0024 for ; Wed, 25 Feb 2015 09:53:13 -0800 (PST) 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; Wed, 25 Feb 2015 09:53:12 -0800 From: Ron Parker To: "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "paulq@cisco.com" Thread-Topic: [sfc] draft-quinn-sfc-nsh: version number Thread-Index: AdBRDDloSX0/55xiS1KsQav7+px1wQAQ+ouAAAsc3+A= Date: Wed, 25 Feb 2015 17:53:12 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B9330049140B4@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EDE5B7.6080102@joelhalpern.com> In-Reply-To: <54EDE5B7.6080102@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] draft-quinn-sfc-nsh: version number 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, 25 Feb 2015 17:53:15 -0000 Joel, I agree that version is valuable, dinstinctly from the MD-type. While you= could overload MD-type (i.e., for some new base flavor we have MD-types 3 = and 4 corresponding to the old 1 and 2), this would be far less elegant and= make the implementations somewhat trickier. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Wednesday, February 25, 2015 10:10 AM To: mohamed.boucadair@orange.com; paulq@cisco.com Cc: sfc@ietf.org Subject: Re: [sfc] draft-quinn-sfc-nsh: version number I would really prefer to keep the version number. Even though we have the = MD-type identifier and for some MD we have the TLVs. The reason is that we may want to change the base header. For example, sup= pose that the ciscussion about including a flow identifier in the base head= er had not come up now. If it came up later, we would want to be able to h= ave the discussion and make the choice, rather than being constrained by th= e lack of a version field. Yours, Joel On 2/25/15 10:03 AM, mohamed.boucadair@orange.com wrote: > Hi Paul, all, > > What is the purpose of having a version number in the header? Is there=20 > a kind of version negotiation that needs to be in place? > > I checked the I-D but failed to find text that explains the rationale,=20 > the use of the such field and whether an error will be returned if the=20 > version is not supported by the receiving node. > > Wouldn't be preferable to get rid of this field given that SFC header=20 > can be extended using optional objects and consistent setup &=20 > configuration within an SFC-enabled domain should be assumed? > > Thank you > > Cheers, > > Med > > > > _______________________________________________ > 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 Wed Feb 25 10:02:04 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 046D41A037A for ; Wed, 25 Feb 2015 10:02:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bafPZ5fULdkY for ; Wed, 25 Feb 2015 10:01:59 -0800 (PST) Received: from hub021-ca-1.exch021.serverdata.net (hub021-ca-1.exch021.serverdata.net [64.78.22.168]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91A541A1A14 for ; Wed, 25 Feb 2015 10:01:57 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0224.002; Wed, 25 Feb 2015 10:01:56 -0800 From: Ron Parker To: Joel Halpern , Linda Dunbar , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 Thread-Index: AdBRG3N71HhtcFa0RsuzFw1dT6iegwAAMTdQAABKvqAAABrE4AABrb3g Date: Wed, 25 Feb 2015 18:01:57 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B2E834C5FMBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 25 Feb 2015 18:02:03 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B2E834C5FMBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the key concept here is that of a 3 level hierarchy of SFC, SFP, RS= P. I don't think that comes out clearly in the current description, espec= ially when RSP references Service Function Chain rather than Service Functi= on Path. The way I think of it: * SFC - specify the sequence of service function types that need to = be visited * SFP - specify the sequence of service function types that need to = be visited, but also optionally specify instance selection constraining pol= icies for some or all of the types * RSP - specify the exact sequence of service function instances tha= t need to be visited (with the understanding that an instance may optionall= y perform its own internal load balancing) Thanks. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Sent: Wednesday, February 25, 2015 12:11 PM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Service P= ath (RSP) in draft-ietf-sfc-architecture-05 Sorry. A packet is technically using a service function path. It is doing= so if the information in the SFC defined header indicates that the packet = is to forwarded along that service function path. Thus, the assignment / u= sage can be determined from examining the packet. The RSP itself requires = a rather omniscient observer perspective to determine, but does exist conce= ptually. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 12:08 PM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Joel, What does it mean by saying packets "using" a service chain? How does packets "use" a service chain? I am confused. Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Wednesday, February 25, 2015 10:59 AM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I don't think adding another word to the term will help comprehension, and = it will complicate usage. So I would prefer not to do that. As for the other change, packets don't belong to a service chain. They may= be using a service chain. They may be assigned by a classifier to a servi= ce chain, but they don't "belong" to the chain as I understand the words. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 11:52 AM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: wording Suggestion for the Rendered Service Path (RSP) in draft-ie= tf-sfc-architecture-05 Joel and Carlos, The current definition of RSP is: Rendered Service Path (RSP): The Service Function Path is a constrained specification of where packets using a certain service chain must go. While it may be so constrained as to identify the exact locations, it can also be less specific. Packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. Some suggestions: - I would think it is more accurate to call it "Rendered Service Fun= ction Path (RSFP)". - Why do you say "packets using a certain service chain"? It is more= accurate to say "packets belonging to a certain service function chain". Here is my suggested wording for RSP (or RSFP): - The sequence of actual SFFs and SFs in the network traversed by pa= ckets belonging to a specific Service Function Chain is known as the Render= ed Service Function Path (RSFP). Cheers, Linda Dunbar --_000_CDF2F015F4429F458815ED2A6C2B6B0B2E834C5FMBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I think the key concep= t here is that of a 3 level hierarchy of SFC, SFP, RSP.   I don&#= 8217;t think that comes out clearly in the current description, especially = when RSP references Service Function Chain rather than Service Function Path.   The way I think of it:

     

    ·        SFC – sp= ecify the sequence of service function types that need to be visited

    ·        SFP – sp= ecify the sequence of service function types that need to be visited, but a= lso optionally specify instance selection constraining policies for some or= all of the types

    ·        RSP – sp= ecify the exact sequence of service function instances that need to be visi= ted (with the understanding that an instance may optionally perform its own= internal load balancing)

     

    Thanks.

     

       Ron<= /o:p>

     

     

    From: sfc [mailto:sfc-bounces@ietf.org] On= Behalf Of Joel Halpern
    Sent: Wednesday, February 25, 2015 12:11 PM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Se= rvice Path (RSP) in draft-ietf-sfc-architecture-05

     

    Sorry.  A packet = is technically using a service function path.  It is doing so if the i= nformation in the SFC defined header indicates that the packet is to forwar= ded along that service function path.  Thus, the assignment / usage can be determined from examining the packet.  The = RSP itself requires a rather omniscient observer perspective to determine, = but does exist conceptually.

     

    Yours,

    Joel=

     

    From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
    Sent: Wednesday, February 25, 2015 12:08 PM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Joel,

     

    What does it mean by s= aying packets “using” a service chain?

     

    How does packets  = ;“use” a service chain? I am confused.

     

    Linda

     

    From: Joel Halpern [mailto:joel.halpern@= ericsson.com]
    Sent: Wednesday, February 25, 2015 10:59 AM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I don’t think ad= ding another word to the term will help comprehension, and it will complica= te usage.  So I would prefer not to do that.

     

    As for the other chang= e, packets don’t belong to a service chain.  They may be using a= service chain.  They may be assigned by a classifier to a service cha= in, but they don’t “belong” to the chain as I understand the words.

     

    Yours,

    Joel=

     

    From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
    Sent: Wednesday, February 25, 2015 11:52 AM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: wording Suggestion for the Rendered Service Path (RSP) in d= raft-ietf-sfc-architecture-05

     

    Joel and Carlos,

     

    The current definition of RSP is:

     

    Rendered Service Path (RSP)= : The Service Function Path is a

    constrained specification o= f where packets using a certain

    service chain must go. Whil= e it may be so constrained as to

    identify the exact location= s, it can also be less specific.

    Packets themselves are of c= ourse transmitted from and to

    specific places in the netw= ork, visiting a specific sequence of

    SFFs and SFs. This sequence= of actual visits by a packet to

    specific SFFs and SFs in th= e network is known as the Rendered

    Service Path (RSP). This de= finition is included here for use by

    later documents, such as wh= en solutions may need to discuss the

    actual sequence of location= s the packets visit.

     

     

    Some suggestions:

    -     &= nbsp;  I would think it is more accurate to call it “= ;Rendered Service Function Path (RSFP)”.

    -     &= nbsp;  Why do you say “packets using a certain servi= ce chain”? It is more accurate to say “packets belonging to a c= ertain service function chain”.

     

     

    Here is my suggested wording for RSP (or RSFP):=

     

    -     &= nbsp;  The sequence of actual SFFs and SFs in the network = traversed by packets belonging to a specific Service Function Chain is know= n as the Rendered Service Function Path (RSFP).

     

    Cheers,

     

    Linda Dunbar

     

    --_000_CDF2F015F4429F458815ED2A6C2B6B0B2E834C5FMBX021W3CA2exch_-- From nobody Wed Feb 25 10:18: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 6C48D1A1A46 for ; Wed, 25 Feb 2015 10:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ym3Um59KTYsZ for ; Wed, 25 Feb 2015 10:18:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E553C1A037D for ; Wed, 25 Feb 2015 10:18:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPQ01470; Wed, 25 Feb 2015 18:18:30 +0000 (GMT) Received: from DFWEML704-CHM.china.huawei.com (10.193.5.141) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 25 Feb 2015 18:18:29 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml704-chm ([10.193.5.141]) with mapi id 14.03.0158.001; Wed, 25 Feb 2015 10:18:23 -0800 From: Linda Dunbar To: Ron Parker , Joel Halpern , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 Thread-Index: AdBRG3N71HhtcFa0RsuzFw1dT6iegwAAMTdQAABKvqAAABrE4AABrb3gAACLwhA= Date: Wed, 25 Feb 2015 18:18:23 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645EE23D6@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.140.138] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645EE23D6dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 25 Feb 2015 18:18:37 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645EE23D6dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I like Ron's suggestion, except that the RSP should be "the sequence of ac= tual SFFs and SFs in the network traversed". RSP may not be "specified". D= ifferent packets assigned to the same service function path can traverse th= rough different RSPs. Linda From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 25, 2015 12:02 PM To: Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I think the key concept here is that of a 3 level hierarchy of SFC, SFP, RS= P. I don't think that comes out clearly in the current description, espec= ially when RSP references Service Function Chain rather than Service Functi= on Path. The way I think of it: * SFC - specify the sequence of service function types that need to = be visited * SFP - specify the sequence of service function types that need to = be visited, but also optionally specify instance selection constraining pol= icies for some or all of the types * RSP - specify the exact sequence of service function instances tha= t need to be visited (with the understanding that an instance may optionall= y perform its own internal load balancing) Thanks. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Sent: Wednesday, February 25, 2015 12:11 PM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Service P= ath (RSP) in draft-ietf-sfc-architecture-05 Sorry. A packet is technically using a service function path. It is doing= so if the information in the SFC defined header indicates that the packet = is to forwarded along that service function path. Thus, the assignment / u= sage can be determined from examining the packet. The RSP itself requires = a rather omniscient observer perspective to determine, but does exist conce= ptually. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 12:08 PM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Joel, What does it mean by saying packets "using" a service chain? How does packets "use" a service chain? I am confused. Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Wednesday, February 25, 2015 10:59 AM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I don't think adding another word to the term will help comprehension, and = it will complicate usage. So I would prefer not to do that. As for the other change, packets don't belong to a service chain. They may= be using a service chain. They may be assigned by a classifier to a servi= ce chain, but they don't "belong" to the chain as I understand the words. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 11:52 AM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: wording Suggestion for the Rendered Service Path (RSP) in draft-ie= tf-sfc-architecture-05 Joel and Carlos, The current definition of RSP is: Rendered Service Path (RSP): The Service Function Path is a constrained specification of where packets using a certain service chain must go. While it may be so constrained as to identify the exact locations, it can also be less specific. Packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. Some suggestions: - I would think it is more accurate to call it "Rendered Service Fun= ction Path (RSFP)". - Why do you say "packets using a certain service chain"? It is more= accurate to say "packets belonging to a certain service function chain". Here is my suggested wording for RSP (or RSFP): - The sequence of actual SFFs and SFs in the network traversed by pa= ckets belonging to a specific Service Function Chain is known as the Render= ed Service Function Path (RSFP). Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645EE23D6dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I like Ron’s sug= gestion, except that the RSP should be  “the sequence of actual SFFs and SFs in= the network traversed”.  RSP may not be “specified”= . Different packets assigned to the same service function path can traverse= through different RSPs.

     

    Linda

     

     

     

    From: Ron Park= er [mailto:Ron_Parker@affirmednetworks.com]
    Sent: Wednesday, February 25, 2015 12:02 PM
    To: Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); sfc@iet= f.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I think the key concep= t here is that of a 3 level hierarchy of SFC, SFP, RSP.   I don&#= 8217;t think that comes out clearly in the current description, especially = when RSP references Service Function Chain rather than Service Function Path.   The way I think of it:

     

    ·SFC – specify the sequence of se= rvice function types that need to be visited

    ·SFP – specify the sequence of se= rvice function types that need to be visited, but also optionally specify i= nstance selection constraining policies for some or all of the types

    ·RSP – specify the exact sequence= of service function instances that need to be visited (with the understand= ing that an instance may optionally perform its own internal load balancing= )

     

    Thanks.

     

       Ron<= /o:p>

     

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern
    Sent: Wednesday, February 25, 2015 12:11 PM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Se= rvice Path (RSP) in draft-ietf-sfc-architecture-05

     

    Sorry.  A packet = is technically using a service function path.  It is doing so if the i= nformation in the SFC defined header indicates that the packet is to forwar= ded along that service function path.  Thus, the assignment / usage can be determined from examining the packet.  The = RSP itself requires a rather omniscient observer perspective to determine, = but does exist conceptually.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Wednesday, February 25, 2015 12:08 PM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Joel,

     

    What does it mean by s= aying packets “using” a service chain?

     

    How does packets  = ;“use” a service chain? I am confused.

     

    Linda

     

    From: Joel Hal= pern [mailto:joel.halpern@= ericsson.com]
    Sent: Wednesday, February 25, 2015 10:59 AM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I don’t think ad= ding another word to the term will help comprehension, and it will complica= te usage.  So I would prefer not to do that.

     

    As for the other chang= e, packets don’t belong to a service chain.  They may be using a= service chain.  They may be assigned by a classifier to a service cha= in, but they don’t “belong” to the chain as I understand the words.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Wednesday, February 25, 2015 11:52 AM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: wording Suggestion for the Rendered Service Path (RSP) in d= raft-ietf-sfc-architecture-05

     

    Joel and Carlos,

     

    The current definition of RSP is:

     

    Rendered Service Path (RSP)= : The Service Function Path is a

    constrained specification o= f where packets using a certain

    service chain must go. Whil= e it may be so constrained as to

    identify the exact location= s, it can also be less specific.

    Packets themselves are of c= ourse transmitted from and to

    specific places in the netw= ork, visiting a specific sequence of

    SFFs and SFs. This sequence= of actual visits by a packet to

    specific SFFs and SFs in th= e network is known as the Rendered

    Service Path (RSP). This de= finition is included here for use by

    later documents, such as wh= en solutions may need to discuss the

    actual sequence of location= s the packets visit.

     

     

    Some suggestions:

    -=         I would think it is more accurate to call it “Rendered Service= Function Path (RSFP)”.

    -=         Why do you say “packets using a certain service chain”? = It is more accurate to say “packets belonging to a certain service fu= nction chain”.

     

     

    Here is my suggested wording for RSP (or RSFP):=

     

    -=         The sequence of actual SFFs and SFs in the network traversed by pack= ets belonging to a specific Service Function Chain is known as the Rendered= Service Function Path (RSFP).

     

    Cheers,

     

    Linda Dunbar

     

    --_000_4A95BA014132FF49AE685FAB4B9F17F645EE23D6dfweml701chm_-- From nobody Wed Feb 25 10:52: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 BFD6F1A19FE for ; Wed, 25 Feb 2015 10:52:21 -0800 (PST) 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 BaXauMi8mkam for ; Wed, 25 Feb 2015 10:52:20 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDDAC1A0387 for ; Wed, 25 Feb 2015 10:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4610; q=dns/txt; s=iport; t=1424890340; x=1426099940; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ET5D9fBKKrynZhSO2HGtGU9d2LX9jvTKwiNXGSbfjF0=; b=Z/hvQlSeQ2X0iZ38347T2irCQMG+lDLd94hIrCqC96koXDV7ICUGyaXS +WNdDQrqq+CIOWmPBGD1AaTvFdDGpgt0JMo84kpxHfaedyDd3rJRM7JB/ KCoAC7aqQJtW722ux0MhfO+JfxiEUbwU8FEdFoFHi0Uf4ez37vjs95dJg s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgBgCqaeJU/4UNJK1RCoMGUloEwBKCIAqFcQKBGEMBAQEBAQF8hAwBAQEEAQEBaxsCAQgRAQMBAQEnBycLFAMGCAIEARIbiBINzigBAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsMhBEpOoQqBY84iTeBGIMNjmgigjKBPG+BRH8BAQE X-IronPort-AV: E=Sophos;i="5.09,646,1418083200"; d="scan'208";a="398895146" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP; 25 Feb 2015 18:52:19 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t1PIqJHR013776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Feb 2015 18:52:19 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.138]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 25 Feb 2015 12:52:18 -0600 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" , Linda Dunbar , Joel Halpern , "sfc@ietf.org" Thread-Topic: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 Thread-Index: AdBRG3N71HhtcFa0RsuzFw1dT6iegwAAMTdQAABKvqAAABrE4AAASCFQAAzhcAD//8QxgA== Date: Wed, 25 Feb 2015 18:52:17 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22FE@dfweml701-chm> <54EE05BA.1010405@joelhalpern.com> In-Reply-To: <54EE05BA.1010405@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.131.12.111] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 25 Feb 2015 18:52:21 -0000 Sure =8B this change + replacing chain with path, made in the working copy. These are useful, but very narrow editorials, which to me reinforces the fact that the doc is ready to be sent to the IESG. Chairs, This document=B9s WGLC ended on 2014-11-14 (over 3.5 months ago). Is there something else needed? Can you please request pub? Thanks, =8B Carlos. On 2/25/15, 12:26 PM, "Joel M. Halpern" wrote: >I could live with replacing "using" with "assigned to". >Yours, >Joel > >On 2/25/15 12:21 PM, Linda Dunbar wrote: >> Packets being =B3assigned=B2 to a Service Function Chain (path) makes se= nse. >> >> But packets =B3using=B2 a service function chain/path is quite odd. >> >> Linda >> >> *From:*Joel Halpern [mailto:joel.halpern@ericsson.com] >> *Sent:* Wednesday, February 25, 2015 11:11 AM >> *To:* Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org >> *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in >> draft-ietf-sfc-architecture-05 >> >> Sorry. A packet is technically using a service function path. It is >> doing so if the information in the SFC defined header indicates that the >> packet is to forwarded along that service function path. Thus, the >> assignment / usage can be determined from examining the packet. The RSP >> itself requires a rather omniscient observer perspective to determine, >> but does exist conceptually. >> >> Yours, >> >> Joel >> >> *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com] >> *Sent:* Wednesday, February 25, 2015 12:08 PM >> *To:* Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org >> >> *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in >> draft-ietf-sfc-architecture-05 >> >> Joel, >> >> What does it mean by saying packets =B3using=B2 a service chain? >> >> How does packets =B3use=B2 a service chain? I am confused. >> >> Linda >> >> *From:*Joel Halpern [mailto:joel.halpern@ericsson.com] >> >> *Sent:* Wednesday, February 25, 2015 10:59 AM >> *To:* Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org >> >> *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in >> draft-ietf-sfc-architecture-05 >> >> I don=B9t think adding another word to the term will help comprehension, >> and it will complicate usage. So I would prefer not to do that. >> >> As for the other change, packets don=B9t belong to a service chain. The= y >> may be using a service chain. They may be assigned by a classifier to a >> service chain, but they don=B9t =B3belong=B2 to the chain as I understan= d the >> words. >> >> Yours, >> >> Joel >> >> *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com] >> *Sent:* Wednesday, February 25, 2015 11:52 AM >> *To:* Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org >> >> *Subject:* wording Suggestion for the Rendered Service Path (RSP) in >> draft-ietf-sfc-architecture-05 >> >> Joel and Carlos, >> >> The current definition of RSP is: >> >> Rendered Service Path (RSP): The Service Function Path is a >> >> constrained specification of where packets using a certain >> >> service chain must go. While it may be so constrained as to >> >> identify the exact locations, it can also be less specific. >> >> Packets themselves are of course transmitted from and to >> >> specific places in the network, visiting a specific sequence of >> >> SFFs and SFs. This sequence of actual visits by a packet to >> >> specific SFFs and SFs in the network is known as the Rendered >> >> Service Path (RSP). This definition is included here for use by >> >> later documents, such as when solutions may need to discuss the >> >> actual sequence of locations the packets visit. >> >> Some suggestions: >> >> -I would think it is more accurate to call it =B3Rendered Service Functi= on >> Path (RSFP)=B2. >> >> -Why do you say =B3packets using a certain service chain=B2? It is more >> accurate to say =B3packets belonging to a certain service function chain= =B2. >> >> Here is my suggested wording for RSP (or RSFP): >> >> -The sequence of actual SFFs and SFs in the network traversed by packets >> belonging to a specific Service Function Chain is known as the Rendered >> Service Function Path (RSFP). >> >> Cheers, >> >> Linda Dunbar >> >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> From nobody Wed Feb 25 11:56: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 C5B881A87AD for ; Wed, 25 Feb 2015 11:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.896 X-Spam-Level: X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-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 KFCNWqermwF3 for ; Wed, 25 Feb 2015 11:56:04 -0800 (PST) Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id B89521A87A3 for ; Wed, 25 Feb 2015 11:56:03 -0800 (PST) Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 342122F47CC2; Wed, 25 Feb 2015 14:56:03 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_E3CCF1F5-B56B-43B7-B3E0-B553F03763D6" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: "Thomas D. Nadeau" In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> Date: Wed, 25 Feb 2015 14:56:02 -0500 Message-Id: <34C64016-4D73-4859-A09C-141CC518664F@lucidvision.com> References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> To: Joel Halpern X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 25 Feb 2015 19:56:06 -0000 --Apple-Mail=_E3CCF1F5-B56B-43B7-B3E0-B553F03763D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 > On Feb 25, 2015:11:59 AM, at 11:59 AM, Joel Halpern = wrote: >=20 > I don=E2=80=99t think adding another word to the term will help = comprehension, and it will complicate usage. So I would prefer not to = do that. > =20 > As for the other change, packets don=E2=80=99t belong to a service = chain. They may be using a service chain. They may be assigned by a = classifier to a service chain, but they don=E2=80=99t =E2=80=9Cbelong=E2=80= =9D to the chain as I understand the words. > =20 > Yours, > Joel > =20 > From: Linda Dunbar [mailto:linda.dunbar@huawei.com = ]=20 > Sent: Wednesday, February 25, 2015 11:52 AM > To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org = > Subject: wording Suggestion for the Rendered Service Path (RSP) in = draft-ietf-sfc-architecture-05 > =20 > Joel and Carlos,=20 > =20 > The current definition of RSP is: > =20 > Rendered Service Path (RSP): The Service Function Path is a > constrained specification of where packets using a certain > service chain must go. While it may be so constrained as to > identify the exact locations, it can also be less specific. > Packets themselves are of course transmitted from and to > specific places in the network, visiting a specific sequence of > SFFs and SFs. This sequence of actual visits by a packet to > specific SFFs and SFs in the network is known as the Rendered > Service Path (RSP). This definition is included here for use by > later documents, such as when solutions may need to discuss the > actual sequence of locations the packets visit. > =20 > =20 > Some suggestions: > - I would think it is more accurate to call it =E2=80=9CRendere= d Service Function Path (RSFP)=E2=80=9D. > - Why do you say =E2=80=9Cpackets using a certain service = chain=E2=80=9D? It is more accurate to say =E2=80=9Cpackets belonging to = a certain service function chain=E2=80=9D. > =20 > =20 > Here is my suggested wording for RSP (or RSFP): > =20 > - The sequence of actual SFFs and SFs in the network = traversed by packets belonging to a specific Service Function Chain is = known as the Rendered Service Function Path (RSFP). > =20 > Cheers,=20 > =20 > Linda Dunbar > =20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc = --Apple-Mail=_E3CCF1F5-B56B-43B7-B3E0-B553F03763D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

    On Feb 25, 2015:11:59 AM, at 11:59 AM, Joel = Halpern <joel.halpern@ericsson.com> wrote:

    I don=E2=80=99t think = adding another word to the term will help comprehension, and it will = complicate usage.  So I would prefer not to do that.
     
    As for the other change, packets don=E2=80=99t belong = to a service chain.  They may be using a service chain.  They = may be assigned by a classifier to a service chain, but they don=E2=80=99t= =E2=80=9Cbelong=E2=80=9D to the chain as I understand the words.
     
    Yours,
    Joel
     
    From: Linda = Dunbar [mailto:linda.dunbar@huawei.com] 
    Sent: Wednesday, February 25, = 2015 11:52 AM
    To: Joel Halpern; Carlos = Pignataro (cpignata); sfc@ietf.org
    Subject: wording Suggestion for the = Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05
     
    Joel and Carlos, 
     
    The = current definition of RSP is:
     
    Rendered Service Path (RSP): The = Service Function Path is a
    constrained specification of where = packets using a certain
    service chain must go. While it may be = so constrained as to
    identify the exact locations, it can = also be less specific.
    Packets themselves are of course = transmitted from and to
    specific places in the network, = visiting a specific sequence of
    SFFs and SFs. This sequence of actual = visits by a packet to
    specific SFFs and SFs in the network = is known as the Rendered
    Service Path (RSP). This definition is = included here for use by
    later documents, such as when = solutions may need to discuss the
    actual sequence of locations the = packets visit.
     
     
    Some suggestions:
    -          I would think = it is more accurate to call it =E2=80=9CRendered Service Function Path = (RSFP)=E2=80=9D.
    -          Why do you = say =E2=80=9Cpackets using a certain service chain=E2=80=9D? It is more = accurate to say =E2=80=9Cpackets belonging to a certain service function = chain=E2=80=9D.
     
     
    Here is my suggested wording for RSP (or RSFP):
     
    -          The sequence = of actual SFFs and SFs in the network traversed by packets belonging to = a specific Service Function Chain is known as the Rendered Service = Function Path (RSFP).
     
    Cheers, 
     
    Linda = Dunbar
     
    _______________________________________________
    sfc mailing list
    sfc@ietf.org
    https://www.ietf.org/mailman/listinfo/sfc

    = --Apple-Mail=_E3CCF1F5-B56B-43B7-B3E0-B553F03763D6-- From nobody Wed Feb 25 17:13:00 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 642B21A6FF6 for ; Wed, 25 Feb 2015 17:12:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76wy2iScpcdC for ; Wed, 25 Feb 2015 17:12:57 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id F40BA1A0406 for ; Wed, 25 Feb 2015 17:12:56 -0800 (PST) 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 t1Q1Cg1s031908; Thu, 26 Feb 2015 10:12:42 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id BA6265F612; Thu, 26 Feb 2015 10:12:41 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id A7C6F5F58A; Thu, 26 Feb 2015 10:12:41 +0900 (JST) Received: from [IPv6:::1] ([129.60.13.28]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t1Q1CYWR013645; Thu, 26 Feb 2015 10:12:41 +0900 Message-ID: <54EE734A.3000908@lab.ntt.co.jp> Date: Thu, 26 Feb 2015 10:13:46 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit To: Ron Parker , Joel Halpern , Linda Dunbar , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" X-TM-AS-MML: disable Archived-At: Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 26 Feb 2015 01:12:59 -0000 I think that Ron's definitions are much clear. Also, I suppose that SFP includes SFF that need to be visited additionally. Is this correct? Cheers, Shunsuke On 2015/02/26 3:01, Ron Parker wrote: > I think the key concept here is that of a 3 level hierarchy of SFC, SFP, > RSP. I don’t think that comes out clearly in the current description, > especially when RSP references Service Function Chain rather than > Service Function Path. The way I think of it: > > ·SFC – specify the sequence of service function types that need to be > visited > > ·SFP – specify the sequence of service function types that need to be > visited, but also optionally specify instance selection constraining > policies for some or all of the types > > ·RSP – specify the exact sequence of service function instances that > need to be visited (with the understanding that an instance may > optionally perform its own internal load balancing) > > Thanks. > > Ron > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Joel Halpern > *Sent:* Wednesday, February 25, 2015 12:11 PM > *To:* Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org > *Subject:* [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered > Service Path (RSP) in draft-ietf-sfc-architecture-05 > > Sorry. A packet is technically using a service function path. It is > doing so if the information in the SFC defined header indicates that the > packet is to forwarded along that service function path. Thus, the > assignment / usage can be determined from examining the packet. The RSP > itself requires a rather omniscient observer perspective to determine, > but does exist conceptually. > > Yours, > > Joel > > *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com] > *Sent:* Wednesday, February 25, 2015 12:08 PM > *To:* Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org > > *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in > draft-ietf-sfc-architecture-05 > > Joel, > > What does it mean by saying packets “using” a service chain? > > How does packets “use” a service chain? I am confused. > > Linda > > *From:*Joel Halpern [mailto:joel.halpern@ericsson.com] > > *Sent:* Wednesday, February 25, 2015 10:59 AM > *To:* Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org > > *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in > draft-ietf-sfc-architecture-05 > > I don’t think adding another word to the term will help comprehension, > and it will complicate usage. So I would prefer not to do that. > > As for the other change, packets don’t belong to a service chain. They > may be using a service chain. They may be assigned by a classifier to a > service chain, but they don’t “belong” to the chain as I understand the > words. > > Yours, > > Joel > > *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com] > *Sent:* Wednesday, February 25, 2015 11:52 AM > *To:* Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org > > *Subject:* wording Suggestion for the Rendered Service Path (RSP) in > draft-ietf-sfc-architecture-05 > > Joel and Carlos, > > The current definition of RSP is: > > Rendered Service Path (RSP): The Service Function Path is a > > constrained specification of where packets using a certain > > service chain must go. While it may be so constrained as to > > identify the exact locations, it can also be less specific. > > Packets themselves are of course transmitted from and to > > specific places in the network, visiting a specific sequence of > > SFFs and SFs. This sequence of actual visits by a packet to > > specific SFFs and SFs in the network is known as the Rendered > > Service Path (RSP). This definition is included here for use by > > later documents, such as when solutions may need to discuss the > > actual sequence of locations the packets visit. > > Some suggestions: > > -I would think it is more accurate to call it “Rendered Service Function > Path (RSFP)”. > > -Why do you say “packets using a certain service chain”? It is more > accurate to say “packets belonging to a certain service function chain”. > > Here is my suggested wording for RSP (or RSFP): > > -The sequence of actual SFFs and SFs in the network traversed by packets > belonging to a specific Service Function Chain is known as the Rendered > Service Function Path (RSFP). > > Cheers, > > Linda Dunbar > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service System Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Wed Feb 25 17:26: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 2F12C1A92BB for ; Wed, 25 Feb 2015 17:26:46 -0800 (PST) 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 fWXxX7rYPpgn for ; Wed, 25 Feb 2015 17:26:44 -0800 (PST) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4D61A007A for ; Wed, 25 Feb 2015 17:26:44 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0224.002; Wed, 25 Feb 2015 17:26:43 -0800 From: Ron Parker To: Shunsuke Homma Thread-Topic: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 Thread-Index: AdBRG3N71HhtcFa0RsuzFw1dT6iegwAAMTdQAABKvqAAABrE4AABrb3gACAAMQD//32Big== Date: Thu, 26 Feb 2015 01:26:42 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> , <54EE734A.3000908@lab.ntt.co.jp> In-Reply-To: <54EE734A.3000908@lab.ntt.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , Joel Halpern , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 26 Feb 2015 01:26:46 -0000 I think if we state that RSP is the exact sequence of SF instances, we indi= rectly resolve the sequence of SFFs, too, since the SFC system must know th= e SF instance to SFF (s) bindings. I was hesitant to state that RSP was t= he sequence of SF instances and SFFs, as has been suggested, because of the= possibility that SF instances COULD be multi-homed to SFFs.=20 Ron > On Feb 25, 2015, at 8:12 PM, Shunsuke Homma wrote: >=20 > I think that Ron's definitions are much clear. Also, I suppose that SFP i= ncludes SFF that need to be visited additionally. Is this correct? >=20 > Cheers, > Shunsuke >=20 >> On 2015/02/26 3:01, Ron Parker wrote: >> I think the key concept here is that of a 3 level hierarchy of SFC, SFP, >> RSP. I don=92t think that comes out clearly in the current description= , >> especially when RSP references Service Function Chain rather than >> Service Function Path. The way I think of it: >>=20 >> =B7SFC =96 specify the sequence of service function types that need to b= e >> visited >>=20 >> =B7SFP =96 specify the sequence of service function types that need to b= e >> visited, but also optionally specify instance selection constraining >> policies for some or all of the types >>=20 >> =B7RSP =96 specify the exact sequence of service function instances that >> need to be visited (with the understanding that an instance may >> optionally perform its own internal load balancing) >>=20 >> Thanks. >>=20 >> Ron >>=20 >> *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Joel Halpern >> *Sent:* Wednesday, February 25, 2015 12:11 PM >> *To:* Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org >> *Subject:* [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered >> Service Path (RSP) in draft-ietf-sfc-architecture-05 >>=20 >> Sorry. A packet is technically using a service function path. It is >> doing so if the information in the SFC defined header indicates that the >> packet is to forwarded along that service function path. Thus, the >> assignment / usage can be determined from examining the packet. The RSP >> itself requires a rather omniscient observer perspective to determine, >> but does exist conceptually. >>=20 >> Yours, >>=20 >> Joel >>=20 >> *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com] >> *Sent:* Wednesday, February 25, 2015 12:08 PM >> *To:* Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org >> >> *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in >> draft-ietf-sfc-architecture-05 >>=20 >> Joel, >>=20 >> What does it mean by saying packets =93using=94 a service chain? >>=20 >> How does packets =93use=94 a service chain? I am confused. >>=20 >> Linda >>=20 >> *From:*Joel Halpern [mailto:joel.halpern@ericsson.com] >> >> *Sent:* Wednesday, February 25, 2015 10:59 AM >> *To:* Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org >> >> *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in >> draft-ietf-sfc-architecture-05 >>=20 >> I don=92t think adding another word to the term will help comprehension, >> and it will complicate usage. So I would prefer not to do that. >>=20 >> As for the other change, packets don=92t belong to a service chain. The= y >> may be using a service chain. They may be assigned by a classifier to a >> service chain, but they don=92t =93belong=94 to the chain as I understan= d the >> words. >>=20 >> Yours, >>=20 >> Joel >>=20 >> *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com] >> *Sent:* Wednesday, February 25, 2015 11:52 AM >> *To:* Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org >> >> *Subject:* wording Suggestion for the Rendered Service Path (RSP) in >> draft-ietf-sfc-architecture-05 >>=20 >> Joel and Carlos, >>=20 >> The current definition of RSP is: >>=20 >> Rendered Service Path (RSP): The Service Function Path is a >>=20 >> constrained specification of where packets using a certain >>=20 >> service chain must go. While it may be so constrained as to >>=20 >> identify the exact locations, it can also be less specific. >>=20 >> Packets themselves are of course transmitted from and to >>=20 >> specific places in the network, visiting a specific sequence of >>=20 >> SFFs and SFs. This sequence of actual visits by a packet to >>=20 >> specific SFFs and SFs in the network is known as the Rendered >>=20 >> Service Path (RSP). This definition is included here for use by >>=20 >> later documents, such as when solutions may need to discuss the >>=20 >> actual sequence of locations the packets visit. >>=20 >> Some suggestions: >>=20 >> -I would think it is more accurate to call it =93Rendered Service Functi= on >> Path (RSFP)=94. >>=20 >> -Why do you say =93packets using a certain service chain=94? It is more >> accurate to say =93packets belonging to a certain service function chain= =94. >>=20 >> Here is my suggested wording for RSP (or RSFP): >>=20 >> -The sequence of actual SFFs and SFs in the network traversed by packets >> belonging to a specific Service Function Chain is known as the Rendered >> Service Function Path (RSFP). >>=20 >> Cheers, >>=20 >> Linda Dunbar >>=20 >>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 >=20 > --=20 > ---------------------------------- > Shunsuke Homma > > TEL: +81 422 59 3486 > FAX: +81 422 60 7460 >=20 > NTT Network Service System Labs. > Musashino city, Tokyo, Japan > ---------------------------------- From nobody Wed Feb 25 18:24:49 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 886741A1B7C for ; Wed, 25 Feb 2015 18:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIz3AK5qDl0V for ; Wed, 25 Feb 2015 18:24:47 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id D0EB21A1B03 for ; Wed, 25 Feb 2015 18:24:46 -0800 (PST) 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 t1Q2ObPJ001798; Thu, 26 Feb 2015 11:24:38 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 6CE405F623; Thu, 26 Feb 2015 11:24:37 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 3DAE85F611; Thu, 26 Feb 2015 11:24:37 +0900 (JST) Received: from [IPv6:::1] ([129.60.13.28]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t1Q2OT7N005989; Thu, 26 Feb 2015 11:24:36 +0900 Message-ID: <54EE8425.8080705@lab.ntt.co.jp> Date: Thu, 26 Feb 2015 11:25:41 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> , <54EE734A.3000908@lab.ntt.co.jp> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit To: Ron Parker X-TM-AS-MML: disable Archived-At: Cc: "Carlos Pignataro \(cpignata\)" , Joel Halpern , "sfc@ietf.org" , Linda Dunbar Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 26 Feb 2015 02:24:48 -0000 Ron, Thank you for your reply. I understand and agree with your opinion regarding RSP. Is SFF also the same? Shunsuke On 2015/02/26 10:26, Ron Parker wrote: > I think if we state that RSP is the exact sequence of SF instances, we indirectly resolve the sequence of SFFs, too, since the SFC system must know the SF instance to SFF (s) bindings. I was hesitant to state that RSP was the sequence of SF instances and SFFs, as has been suggested, because of the possibility that SF instances COULD be multi-homed to SFFs. > > Ron > > > >> On Feb 25, 2015, at 8:12 PM, Shunsuke Homma wrote: >> >> I think that Ron's definitions are much clear. Also, I suppose that SFP includes SFF that need to be visited additionally. Is this correct? >> >> Cheers, >> Shunsuke >> >>> On 2015/02/26 3:01, Ron Parker wrote: >>> I think the key concept here is that of a 3 level hierarchy of SFC, SFP, >>> RSP. I don’t think that comes out clearly in the current description, >>> especially when RSP references Service Function Chain rather than >>> Service Function Path. The way I think of it: >>> >>> ·SFC – specify the sequence of service function types that need to be >>> visited >>> >>> ·SFP – specify the sequence of service function types that need to be >>> visited, but also optionally specify instance selection constraining >>> policies for some or all of the types >>> >>> ·RSP – specify the exact sequence of service function instances that >>> need to be visited (with the understanding that an instance may >>> optionally perform its own internal load balancing) >>> >>> Thanks. >>> >>> Ron >>> >>> *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Joel Halpern >>> *Sent:* Wednesday, February 25, 2015 12:11 PM >>> *To:* Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org >>> *Subject:* [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered >>> Service Path (RSP) in draft-ietf-sfc-architecture-05 >>> >>> Sorry. A packet is technically using a service function path. It is >>> doing so if the information in the SFC defined header indicates that the >>> packet is to forwarded along that service function path. Thus, the >>> assignment / usage can be determined from examining the packet. The RSP >>> itself requires a rather omniscient observer perspective to determine, >>> but does exist conceptually. >>> >>> Yours, >>> >>> Joel >>> >>> *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com] >>> *Sent:* Wednesday, February 25, 2015 12:08 PM >>> *To:* Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org >>> >>> *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in >>> draft-ietf-sfc-architecture-05 >>> >>> Joel, >>> >>> What does it mean by saying packets “using” a service chain? >>> >>> How does packets “use” a service chain? I am confused. >>> >>> Linda >>> >>> *From:*Joel Halpern [mailto:joel.halpern@ericsson.com] >>> >>> *Sent:* Wednesday, February 25, 2015 10:59 AM >>> *To:* Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org >>> >>> *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in >>> draft-ietf-sfc-architecture-05 >>> >>> I don’t think adding another word to the term will help comprehension, >>> and it will complicate usage. So I would prefer not to do that. >>> >>> As for the other change, packets don’t belong to a service chain. They >>> may be using a service chain. They may be assigned by a classifier to a >>> service chain, but they don’t “belong” to the chain as I understand the >>> words. >>> >>> Yours, >>> >>> Joel >>> >>> *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com] >>> *Sent:* Wednesday, February 25, 2015 11:52 AM >>> *To:* Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org >>> >>> *Subject:* wording Suggestion for the Rendered Service Path (RSP) in >>> draft-ietf-sfc-architecture-05 >>> >>> Joel and Carlos, >>> >>> The current definition of RSP is: >>> >>> Rendered Service Path (RSP): The Service Function Path is a >>> >>> constrained specification of where packets using a certain >>> >>> service chain must go. While it may be so constrained as to >>> >>> identify the exact locations, it can also be less specific. >>> >>> Packets themselves are of course transmitted from and to >>> >>> specific places in the network, visiting a specific sequence of >>> >>> SFFs and SFs. This sequence of actual visits by a packet to >>> >>> specific SFFs and SFs in the network is known as the Rendered >>> >>> Service Path (RSP). This definition is included here for use by >>> >>> later documents, such as when solutions may need to discuss the >>> >>> actual sequence of locations the packets visit. >>> >>> Some suggestions: >>> >>> -I would think it is more accurate to call it “Rendered Service Function >>> Path (RSFP)”. >>> >>> -Why do you say “packets using a certain service chain”? It is more >>> accurate to say “packets belonging to a certain service function chain”. >>> >>> Here is my suggested wording for RSP (or RSFP): >>> >>> -The sequence of actual SFFs and SFs in the network traversed by packets >>> belonging to a specific Service Function Chain is known as the Rendered >>> Service Function Path (RSFP). >>> >>> Cheers, >>> >>> Linda Dunbar >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> >> -- >> ---------------------------------- >> Shunsuke Homma >> >> TEL: +81 422 59 3486 >> FAX: +81 422 60 7460 >> >> NTT Network Service System Labs. >> Musashino city, Tokyo, Japan >> ---------------------------------- > > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service System Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Wed Feb 25 23:16:24 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3940B1A1AAF for ; Wed, 25 Feb 2015 23:16:23 -0800 (PST) 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 iyLtpIYPdR_E for ; Wed, 25 Feb 2015 23:16:20 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2381A1AAE for ; Wed, 25 Feb 2015 23:16:19 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id E41603B4D48; Thu, 26 Feb 2015 08:16:17 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id A880BC81F4; Thu, 26 Feb 2015 08:16:17 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Thu, 26 Feb 2015 08:16:17 +0100 From: To: "Joel M. Halpern" , "paulq@cisco.com" Thread-Topic: [sfc] draft-quinn-sfc-nsh: version number Thread-Index: AdBRDDloSX0/55xiS1KsQav7+px1wf//8PSA//7vVzA= Date: Thu, 26 Feb 2015 07:16:16 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049156A9@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049140B4@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EDE5B7.6080102@joelhalpern.com> In-Reply-To: <54EDE5B7.6080102@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.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] draft-quinn-sfc-nsh: version number 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, 26 Feb 2015 07:16:23 -0000 Hi Joel, I fully agree with the extendibility of the header, but the question is why= having a version number will be of help in the context of SFC? Second, hav= ing a version number without specifying the behavior when several versions = are supported, when the version number is not supported by an SFC-aware ele= ment, etc. leaves open issues out of the spec.=20 The other problem is that the current I-D includes several open doors left = for extending the header: * version * reserved bits * optional data This is too much for a header that is supposed to be compact and simple! There are other means to extend the header without signaling the version in= the packet. Having a distinct RFC number may be just fine in the context o= f an unidirectional stream such as SFC.=20 Let us consider the situation where a version number is not explicitly sign= aled in the packet (but a new RFC updates the base SFC header). Several opt= ions can be considered, indeed (those are provided as examples for illustra= tion purposes):=20 * An operator can make sure that its SFC-enabled domain is configured in a = consistent manner to support one and only one version of the header. No int= eroperability issues is encountered in this case. * An operator that wants to upgrade its SFC-enabled domain to support a new= specification of the SFC header: An operator can decide to proceed to a so= ftware/hardware updates but can maintain the old header in operation until = all involved elements are upgraded to support the new version. Once the SFC= -enabled domain is upgraded, then the new header can be enabled.=20 Let's consider now that a version is signaled in the packet: to what extent= signaling this information simplifies the SFC operations, and whether it i= ncreases/decreases the serviceability of an SFC-enabled domain? Let's also = assess to what extent having the version number add more complexity in the = SFC header treatment when several versions are supported by a node/within a= n SFC enabled domain? How it helps interoperability? Some points for discus= sion are elaborated below: * If the SFC-enabled domain is configured to support the same version (whic= h is likely): having the version number is not of any help. * If the SFC-enabled domain involves some nodes that support version (v1) w= hile others support (v2) (simple case): If these version are not backward c= ompatible, this will lead to failures when two adjacent elements in a servi= ce chain do not support the same version. The SFC system is broken. Having = the version number is not of any help in this case. * If the SFC-enabled domain involves some nodes that support version (v1) w= hile others support (v1 and v2):=20 (a) The nodes that support both v1 and v2 should be instructed to decide wh= ich version to be used. This can be either part of the specification or be = driven by configuration. If a version number is included in the spec, I wou= ld expect to clarify the behavior in such case. (b) Suppose a node that supports only v1 receives a packet with header (v2)= : If this node does not support a notification procedure to inform the sour= ce that it does not support that header version, then FAILURES are introduc= ed in the network. This is a degradation of the service compared to legacy = scheme to structure services. This is not recommended, IMHO. (c) If a notification is received from an element about its supported versi= on: a node can use another version (the logic to select other version is an= other point to discuss) for that communication, but what to do for the next= flows in the context of the same service chain or other chains that involv= es these two nodes as adjacent elements in the same chain? Shouldn't these = nodes cache the version to use for subsequent exchange to avoid receiving t= he notification error each time? Wouldn't that complexity the behavior of t= he SFC-aware elements? (d) If a notification is received from an element about its supported versi= on: As this may occurs in various segments of a given service chain, e.g., = (A(v1), B(v1,v2), C(v2), D(v1,v2), E(v1)). Notifying the adjacent node each= time there is a version mismatch induce an extra delay, that may be not be= acceptable for every flow. =20 I hope this clarifies my initial concern. Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Envoy=E9=A0: mercredi 25 f=E9vrier 2015 16:10 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; paulq@cisco.com > Cc=A0: sfc@ietf.org > Objet=A0: Re: [sfc] draft-quinn-sfc-nsh: version number >=20 > I would really prefer to keep the version number. Even though we have > the MD-type identifier and for some MD we have the TLVs. >=20 > The reason is that we may want to change the base header. For example, > suppose that the ciscussion about including a flow identifier in the > base header had not come up now. If it came up later, we would want to > be able to have the discussion and make the choice, rather than being > constrained by the lack of a version field. >=20 > Yours, > Joel >=20 >=20 > On 2/25/15 10:03 AM, mohamed.boucadair@orange.com wrote: > > Hi Paul, all, > > > > What is the purpose of having a version number in the header? Is there = a > > kind of version negotiation that needs to be in place? > > > > I checked the I-D but failed to find text that explains the rationale, > > the use of the such field and whether an error will be returned if the > > version is not supported by the receiving node. > > > > Wouldn't be preferable to get rid of this field given that SFC header > > can be extended using optional objects and consistent setup & > > configuration within an SFC-enabled domain should be assumed? > > > > Thank you > > > > Cheers, > > > > Med > > > > > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > From nobody Thu Feb 26 04:47: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 7DB3B1A885D for ; Thu, 26 Feb 2015 04:47:07 -0800 (PST) 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 zeTGr3qFZXeI for ; Thu, 26 Feb 2015 04:47:04 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 490861A87A2 for ; Thu, 26 Feb 2015 04:47:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5922; q=dns/txt; s=iport; t=1424954825; x=1426164425; h=from:to:subject:date:message-id:mime-version; bh=5DvC1iLVQRY072rhXBxibDn3A/gWUnu0VVqTfJhVjGE=; b=lrUcqzRTKna7mA7DOfKM5niVtSXWmaHVKDta9hjkBCWNw/t9Ag/247Jw FI4FdRJjkCXMqHtt8LA+QbEfbQ7/hBi5ds7hSJL169WKqBCvBK7vewEM+ iSPXv0RC7UxoyIF1/IL/TOB4EGjv9+TTiRx3IY9Iw3aLyTHR59PjOvMVz c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CuBgBgFe9U/4cNJK1bgj9DUlsDskaNSIFzhXCBJU0BAQEBAQF8hBYdbgGBACcEiEINrHKpPwwgjx8RAUyENgWPb4NghWWBGzmCZY8QI4ICHIFQgXo5fwEBAQ X-IronPort-AV: E=Sophos;i="5.09,652,1418083200"; d="scan'208,217";a="127159674" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP; 26 Feb 2015 12:47:05 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t1QCl3SC030282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Feb 2015 12:47:03 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.159]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 06:47:03 -0600 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: WG call for adoption of draft-quinn-sfc-nsh Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWpw== Date: Thu, 26 Feb 2015 12:47:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.98.43.180] Content-Type: multipart/alternative; boundary="_000_D1147FF5844Djguicharciscocom_" MIME-Version: 1.0 Archived-At: Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 26 Feb 2015 12:47:07 -0000 --_000_D1147FF5844Djguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Greetings WG: The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft= -quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc= -sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined = the NSH document so that the WG can focus on a single encapsulation documen= t going forward. This new version of NSH includes an open items section bas= ed on discussion between co-authors and members of the list. The WG will wo= rk through this list (and any other issues that need to be added) over the = next weeks. We appreciate and recognize the hard work of both the NSH and S= CH authors in pushing the SFC encapsulation work forward. With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n= sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3= /12/2015. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG=92s decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Jim & Thomas --_000_D1147FF5844Djguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
    Greetings WG:

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/dra= ft-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draf= t-zhang-sfc-sch/) have joined the NSH document so that the WG can focus= on a single encapsulation document going forward. This new version of NSH includes an open items secti= on based on discussion between co-authors and members of the list. The WG w= ill work through this list (and any other issues that need to be added) ove= r the next weeks. We appreciate and recognize the hard work of both the NSH and SCH authors in pushing the= SFC encapsulation work forward.

    With that said, the chairs are calling for WG adoption of draft= -quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 we= eks ending 3/12/2015.

    Please note t= hat this is a call for adoption, and not a last call for content of the doc= ument. Adopting a WG document simply means that the WG will focus its effor= ts on that particular draft going forward, and use that document for resolving open issues and documenting the WG=92s= decisions.

    Please indica= te whether you support adoption for not, and if not why. Issues you have wi= th the current document itself can also be raised, but they should be raise= d in the context of what should be changed in the document going forward, rather than a pre-condition for adoption.&n= bsp;

    Finally, now = is also a good time to poll for knowledge of any IPR that applies to this d= raft, in line with the IPR disclosure obligations for WG participants (see = RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please respond to this em= ail (to the chairs) whether or not you are aware of any relevant IPR.

    Jim & Thomas
    --_000_D1147FF5844Djguicharciscocom_-- From nobody Thu Feb 26 05:00: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 828991A00E9 for ; Thu, 26 Feb 2015 05:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 3bb2OkXZ2yQ5 for ; Thu, 26 Feb 2015 05:00:30 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8DFE1A00E5 for ; Thu, 26 Feb 2015 05:00:28 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id EFCF018C8E9; Thu, 26 Feb 2015 14:00:26 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.30]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id CE33B4C094; Thu, 26 Feb 2015 14:00:26 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH02.corporate.adroot.infra.ftgroup ([10.114.31.30]) with mapi id 14.03.0224.002; Thu, 26 Feb 2015 14:00:26 +0100 From: To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG call for adoption of draft-quinn-sfc-nsh Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50C4+xg Date: Thu, 26 Feb 2015 13:00:26 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300491598C@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: In-Reply-To: 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93300491598COPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.26.121820 Archived-At: Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 26 Feb 2015 13:00:34 -0000 --_000_787AE7BB302AE849A7480A190F8B93300491598COPEXCLILM23corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I support the adoption of this I-D as a WG document. I have several open issues but I'm confident those will be addressed once t= he document is adopted as a WG item. BTW, it would be easier to track the i= ssues using the IETF tracker tool. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar= ) Envoy=E9 : jeudi 26 f=E9vrier 2015 13:47 =C0 : sfc@ietf.org Objet : [sfc] WG call for adoption of draft-quinn-sfc-nsh Greetings WG: The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft= -quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc= -sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined = the NSH document so that the WG can focus on a single encapsulation documen= t going forward. This new version of NSH includes an open items section bas= ed on discussion between co-authors and members of the list. The WG will wo= rk through this list (and any other issues that need to be added) over the = next weeks. We appreciate and recognize the hard work of both the NSH and S= CH authors in pushing the SFC encapsulation work forward. With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n= sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3= /12/2015. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Jim & Thomas --_000_787AE7BB302AE849A7480A190F8B93300491598COPEXCLILM23corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Hi all,

     

    I support the adoption of this = I-D as a WG document.

     

    I have several open issues but = I’m confident those will be addressed once the document is adopted as= a WG item. BTW, it would be easier to track the issues using the IETF tracker tool.

     

    Cheers,

    Med

     

    De : sfc = [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar)
    Envoy=E9 : jeudi 26 f=E9vrier 2015 13:47
    =C0 : sfc@ietf.org
    Objet : [sfc] WG call for adoption of draft-quinn-sfc-nsh<= /o:p>

     

    Greetings WG:

     =

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/dr= aft-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draf= t-zhang-sfc-sch/) have joined the NSH document so that the WG can focus= on a single encapsulation document going forward. This new version of NSH includes an open items secti= on based on discussion between co-authors and members of the list. The WG w= ill work through this list (and any other issues that need to be added) ove= r the next weeks. We appreciate and recognize the hard work of both the NSH and SCH authors in pushing the= SFC encapsulation work forward.

     =

    With that said, the chairs are calling for WG adoption of draf= t-quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 w= eeks ending 3/12/2015.=

     =

    Please note that this is a call for adoption, and not a last call for cont= ent of the document. Adopting a WG document simply means that the WG will f= ocus its efforts on that particular draft going forward, and use that document for resolving open issues and d= ocumenting the WG’s decisions.

     

    Please indicate whether you support adoption for not, and if not why. Issu= es you have with the current document itself can also be raised, but they s= hould be raised in the context of what should be changed in the document going forward, rather than a pre-conditi= on for adoption. 

     

    Finally, now is also a good time to poll for knowledge of any IPR that app= lies to this draft, in line with the IPR disclosure obligations for WG part= icipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please = respond to this email (to the chairs) whether or not you are aware of any r= elevant IPR.

     

    Jim & Thomas

    --_000_787AE7BB302AE849A7480A190F8B93300491598COPEXCLILM23corp_-- From nobody Thu Feb 26 05:28:24 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D9D1A00F8 for ; Thu, 26 Feb 2015 05:28:21 -0800 (PST) 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 0eKDnjFalCGy for ; Thu, 26 Feb 2015 05:28:19 -0800 (PST) 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 A84361A00E0 for ; Thu, 26 Feb 2015 05:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6730; q=dns/txt; s=iport; t=1424957299; x=1426166899; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OAxQ/uLTYW8rw2YQ+DXwEumsxeCbZbIa6Ps6qnSnLBs=; b=h8LqkKJlMgHIh8uwtM1VM+zRBcRQIqAU42n4/STN5+7+TDd0QhtX7Dts 5xDrsuBZ3CIYMhqWz7Puf8CC2iNfM78WwU1luZMt0g0YoyirfIY+E4f2L rbzfSNJRteAekoNGaoZZ8KfzgYtBDrVGqNcl+Sxy7G82pzp1EX+0BQptI I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A6BwABH+9U/4YNJK1bgj9DUk4MskqNSIFpAQmFcAKBIU0BAQEBAQF8hBABAQQBAQEaUQsQAgEIPwcnCxQRAgQOBYgvDdYxAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sThAwRAUwEBgGDF4EUBY9vg2CFZYEbOYJljxAjggIcgVBvgQuBOAEBAQ X-IronPort-AV: E=Sophos;i="5.09,652,1418083200"; d="scan'208,217";a="127168516" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP; 26 Feb 2015 13:28:18 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t1QDSIVb029434 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Feb 2015 13:28:18 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.138]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 07:28:18 -0600 From: "Ken Gray (kegray)" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] WG call for adoption of draft-quinn-sfc-nsh Thread-Index: AQHQUcgUirvgIVUNLECJHLtksAdoxQ== Date: Thu, 26 Feb 2015 13:28:17 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_CCF0B10B3D5B482DB4925297D1430697ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 26 Feb 2015 13:28:21 -0000 --_000_CCF0B10B3D5B482DB4925297D1430697ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Support Sent from my iPhone On Feb 26, 2015, at 7:47 AM, "Jim Guichard (jguichar)" > wrote: Greetings WG: The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft= -quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc= -sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined = the NSH document so that the WG can focus on a single encapsulation documen= t going forward. This new version of NSH includes an open items section bas= ed on discussion between co-authors and members of the list. The WG will wo= rk through this list (and any other issues that need to be added) over the = next weeks. We appreciate and recognize the hard work of both the NSH and S= CH authors in pushing the SFC encapsulation work forward. With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n= sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3= /12/2015. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG=92s decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Jim & Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_CCF0B10B3D5B482DB4925297D1430697ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    Support

    Sent from my iPhone

    On Feb 26, 2015, at 7:47 AM, "Jim Guichard (jguichar)" <jguichar@cisco.com> wrote:

    Greetings WG:

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/dra= ft-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draf= t-zhang-sfc-sch/) have joined the NSH document so that the WG can focus= on a single encapsulation document going forward. This new version of NSH includes an open items secti= on based on discussion between co-authors and members of the list. The WG w= ill work through this list (and any other issues that need to be added) ove= r the next weeks. We appreciate and recognize the hard work of both the NSH and SCH authors in pushing the= SFC encapsulation work forward.

    With that said, the chairs are calling for WG adoption of draft= -quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 we= eks ending 3/12/2015.

    Please note t= hat this is a call for adoption, and not a last call for content of the doc= ument. Adopting a WG document simply means that the WG will focus its effor= ts on that particular draft going forward, and use that document for resolving open issues and documenting the WG=92s= decisions.

    Please indica= te whether you support adoption for not, and if not why. Issues you have wi= th the current document itself can also be raised, but they should be raise= d in the context of what should be changed in the document going forward, rather than a pre-condition for adoption.&n= bsp;

    Finally, now = is also a good time to poll for knowledge of any IPR that applies to this d= raft, in line with the IPR disclosure obligations for WG participants (see = RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please respond to this em= ail (to the chairs) whether or not you are aware of any relevant IPR.

    Jim & Thomas
    _______________________________________________
    sfc mailing list
    sfc@ietf.org
    https://www.iet= f.org/mailman/listinfo/sfc
    --_000_CCF0B10B3D5B482DB4925297D1430697ciscocom_-- From nobody Thu Feb 26 05:42:50 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9C11A011D for ; Thu, 26 Feb 2015 05:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 SoU4qe46bsvk for ; Thu, 26 Feb 2015 05:42:45 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550291A00D8 for ; Thu, 26 Feb 2015 05:42:45 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 7F1D23B48AA; Thu, 26 Feb 2015 14:42:43 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 5C9E1384131; Thu, 26 Feb 2015 14:42:43 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Thu, 26 Feb 2015 14:42:43 +0100 From: To: "sfc@ietf.org" Thread-Topic: draft-quinn-sfc-nsh: Support of SF Spirals Thread-Index: AdBRyhUadMfMQp0TQVyP+AHUYniSlA== Date: Thu, 26 Feb 2015 13:42:43 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> 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: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B9330049159ECOPEXCLILM23corp_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.26.125120 Archived-At: Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" Subject: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals 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, 26 Feb 2015 13:42:48 -0000 --_000_787AE7BB302AE849A7480A190F8B9330049159ECOPEXCLILM23corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul, all, There were a discussion in the mailing list (http://www.ietf.org/mail-archi= ve/web/sfc/current/msg01701.html) that led to defining what is meant by SF = Spirals: (below is provided an excerpt from http://tools.ietf.org/html/draf= t-boucadair-sfc-requirements-06 where the conclusions of that discussion we= re recorded) " o Service Function Spiral: denotes a Service Function Chain in which data is handled by a Service Function, forwarded onwards, and arrives once again at that Service Function. * Note that some Service Functions support built-in functions to accommodate spirals; these service-specific functions may require that the data received in a spiral should differ in a way that will result in a different processing decision than the original data. This document does not make such assumption. * A Service Function Chain may involve one or more Service Function Spirals. * Unlike Service Function loop, spirals are not considered as errors." And this companion requirement: " A. Service Functions MAY be invoked multiple times in the same Service Function Chain (denoted as SF Spiral), but the solution MUST prevent infinite forwarding loops. > Reading the current draft-quinn-sfc-nsh, I don't see how this is met. Can you please clarify whether this is supported and how? Thank you. Cheers, Med --_000_787AE7BB302AE849A7480A190F8B9330049159ECOPEXCLILM23corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Paul, all,

     

    There were a discussion in the mailing list= (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html) that led to defining what is meant by SF Spirals: (below is provided an ex= cerpt from = http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where th= e conclusions of that discussion were recorded)

     

     

    “   = ;o  Service Function Spiral: denotes a Service Function Chain in which=

       &= nbsp;  data is handled by a Service Function, forwarded onwards, and

       &= nbsp;  arrives once again at that Service Function.<= /p>

     

       &= nbsp;  *  Note that some Service Functions support built-in funct= ions to

       &= nbsp;     accommodate spirals; these service-specific f= unctions may

       &= nbsp;     require that the data received in a spiral sh= ould differ in a

       &= nbsp;     way that will result in a different processin= g decision than

       &= nbsp;     the original data.  This document does n= ot make such

       &= nbsp;     assumption.

     

       &= nbsp;  *  A Service Function Chain may involve one or more Servic= e

       &= nbsp;     Function Spirals.

     

       &= nbsp;  *  Unlike Service Function loop, spirals are not considere= d as

       &= nbsp;     errors."

     

    And this companion requirement:

     

    “       =
        A.  Service Functions MAY b=
e invoked multiple times in
            &=
nbsp;          the same Servic=
e Function Chain (denoted as SF
            &=
nbsp;          Spiral), but th=
e solution MUST prevent infinite
             =
          forwarding loop=
s. »

     

     

    Reading the current draft-quinn-sfc-nsh, I = don’t see how this is met.

     

    Can you please clarify whether this is supp= orted and how?

     

    Thank you.

     

    Cheers,

    Med

    --_000_787AE7BB302AE849A7480A190F8B9330049159ECOPEXCLILM23corp_-- From nobody Thu Feb 26 06:07: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 038361A0162 for ; Thu, 26 Feb 2015 06:07:25 -0800 (PST) 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 wQxA_oxjGDuU for ; Thu, 26 Feb 2015 06:07:20 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AECD41A0146 for ; Thu, 26 Feb 2015 06:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12927; q=dns/txt; s=iport; t=1424959639; x=1426169239; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=qOwxnzixzyyeVCa6+Nk1pTZC3DcHllOf7TGXf5Y3YPI=; b=XiqOaLIjhs2H3Z4RQPhvsutQH8nCyAL5Q1G0MIGHzLAXLulJNSym1CYM DdVxhsRNLrB9/hu+nUjXyxFPSMtrRo12JpN9suxYDiZ15A+lIAoPTbhBk s5jyMMo4Ywlhj+diPzoAMZiPIkOJqUhoTVQXmyW2yOgwRgFb6Hvpg5Eel 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DfBwAhKO9U/4kNJK1bgj9DUloEskaNDDyBc4VwAoEiTQEBAQEBAXyEDwEBAQQdEFwCAQgRBAEBCx0HMhQJCAIEARIIiCcN1jUBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixOEDBEBHy0KAYMXgRQFiiqFRYNghwA5gmWPECOCAhyBUG+BCzl/AQEB X-IronPort-AV: E=Sophos;i="5.09,652,1418083200"; d="scan'208,217";a="399327004" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP; 26 Feb 2015 14:07:07 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1QE77le005331 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Feb 2015 14:07:07 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.156]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 08:07:07 -0600 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" , "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG call for adoption of draft-quinn-sfc-nsh Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50C4+xggAATbYA= Date: Thu, 26 Feb 2015 14:07:06 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A366A87E6@xmb-rcd-x10.cisco.com> References: <787AE7BB302AE849A7480A190F8B93300491598C@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300491598C@OPEXCLILM23.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.47.232] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A366A87E6xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 26 Feb 2015 14:07:25 -0000 --_000_913383AAA69FF945B8F946018B75898A366A87E6xmbrcdx10ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 to WG adoption. -Tiru From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Thursday, February 26, 2015 6:30 PM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh Hi all, I support the adoption of this I-D as a WG document. I have several open issues but I'm confident those will be addressed once t= he document is adopted as a WG item. BTW, it would be easier to track the i= ssues using the IETF tracker tool. Cheers, Med De : sfc [mailto:sfc-bounces@ietf.org] De la part de Jim Guichard (jguichar= ) Envoy=E9 : jeudi 26 f=E9vrier 2015 13:47 =C0 : sfc@ietf.org Objet : [sfc] WG call for adoption of draft-quinn-sfc-nsh Greetings WG: The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft= -quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc= -sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined = the NSH document so that the WG can focus on a single encapsulation documen= t going forward. This new version of NSH includes an open items section bas= ed on discussion between co-authors and members of the list. The WG will wo= rk through this list (and any other issues that need to be added) over the = next weeks. We appreciate and recognize the hard work of both the NSH and S= CH authors in pushing the SFC encapsulation work forward. With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n= sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3= /12/2015. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Jim & Thomas --_000_913383AAA69FF945B8F946018B75898A366A87E6xmbrcdx10ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    +1 to WG adoption.

     <= /p>

    -Tiru

     <= /p>

    From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com
    Sent: Thursday, February 26, 2015 6:30 PM
    To: Jim Guichard (jguichar); sfc@ietf.org
    Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh<= /o:p>

     

    Hi all,

     

    I support the adoption of this I-D as a WG doc= ument.

     

    I have several open issues but I’m confi= dent those will be addressed once the document is adopted as a WG item. BTW= , it would be easier to track the issues using the IETF tracker tool.

     

    Cheers,

    Med

     

    De : sfc [mailto:sfc= -bounces@ietf.org] De la part de Jim Guichard (jguichar)
    Envoy=E9 : jeudi 26 f=E9vrier 2015 13:47
    =C0 : sfc@ietf.org
    Objet : [sfc] WG call for adoption of draft-quinn-sfc-nsh<= /o:p>

     

    Greetings WG:

     <= /o:p>

    The document draft-quinn-sfc-nsh-07 (https://datatracker.iet= f.org/doc/draft-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.iet= f.org/doc/draft-zhang-sfc-sch/) have joined the NSH document so that th= e WG can focus on a single encapsulation document going forward. This new version of NSH includes an open items = section based on discussion between co-authors and members of the list.= The WG will work through this list (and any other issues that need to be a= dded) over the next weeks. We appreciate and recognize the hard work of both the NSH and SCH authors in pushing the= SFC encapsulation work forward.

     <= /o:p>

    With that said, the chairs are calling for WG adop= tion of draft-quinn-sfc-nsh-07 as a WG document. The call for adoption will= run for 2 weeks ending 3/12/2015.

     <= /o:p>

    Please note that this is a call for adoption, and not a last c= all for content of the document. Adopting a WG document simply means that t= he WG will focus its efforts on that particular draft going forward, and use that document for resolving open issues and d= ocumenting the WG’s decisions.

     

    Please indicate whether you support adoption for not, and if n= ot why. Issues you have with the current document itself can also be raised= , but they should be raised in the context of what should be changed in the document going forward, rather than a pre= -condition for adoption. 

     

    Finally, now is also a good time to poll for knowledge of any = IPR that applies to this draft, in line with the IPR disclosure obligations= for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author pl= ease respond to this email (to the chairs) whether or not you are aware of = any relevant IPR.

     

    Jim & Thomas

    --_000_913383AAA69FF945B8F946018B75898A366A87E6xmbrcdx10ciscoc_-- From nobody Thu Feb 26 06:24:49 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 BE51B1A011B for ; Thu, 26 Feb 2015 06:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 xLB2wUI7hXq3 for ; Thu, 26 Feb 2015 06:24:46 -0800 (PST) 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 AD1F51A010E for ; Thu, 26 Feb 2015 06:24:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8D8401C0C1A; Thu, 26 Feb 2015 06:24:46 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.95.128.180]) (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 DC08E1C03A5; Thu, 26 Feb 2015 06:24:45 -0800 (PST) Message-ID: <54EF2C9A.3040008@joelhalpern.com> Date: Thu, 26 Feb 2015 09:24:26 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "paulq@cisco.com" References: <787AE7BB302AE849A7480A190F8B9330049140B4@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EDE5B7.6080102@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330049156A9@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330049156A9@OPEXCLILM23.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] draft-quinn-sfc-nsh: version number 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, 26 Feb 2015 14:24:48 -0000 In one sense you are correct. If you could count on everything being upgraded at once, sure you could just assume common interpretation. However, we have found over the years that such simultaneous upgrading never works. You need to be able to transition. I do agree that we should add text about what to do with version numbers that are not understood. There are multiple choices that affect how we can make changes. My personal preference is: If an packet presumed to carry an NSH header is received at an SFF, and the SFF does not understnad the version of the protocol as indicated in the base header, the packet MUST be discarded, and the event SHOULD be logged. This would allow an orderly transition, where devices can be upgraded to understand a new version, then generation of the new version header can be enabled. If a configuration error is made, the packets will be dropped and operators following good practices will get notifications. Yours, Joel On 2/26/15 2:16 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > I fully agree with the extendibility of the header, but the question is why having a version number will be of help in the context of SFC? Second, having a version number without specifying the behavior when several versions are supported, when the version number is not supported by an SFC-aware element, etc. leaves open issues out of the spec. > > The other problem is that the current I-D includes several open doors left for extending the header: > * version > * reserved bits > * optional data > > This is too much for a header that is supposed to be compact and simple! > > There are other means to extend the header without signaling the version in the packet. Having a distinct RFC number may be just fine in the context of an unidirectional stream such as SFC. > > Let us consider the situation where a version number is not explicitly signaled in the packet (but a new RFC updates the base SFC header). Several options can be considered, indeed (those are provided as examples for illustration purposes): > * An operator can make sure that its SFC-enabled domain is configured in a consistent manner to support one and only one version of the header. No interoperability issues is encountered in this case. > * An operator that wants to upgrade its SFC-enabled domain to support a new specification of the SFC header: An operator can decide to proceed to a software/hardware updates but can maintain the old header in operation until all involved elements are upgraded to support the new version. Once the SFC-enabled domain is upgraded, then the new header can be enabled. > > Let's consider now that a version is signaled in the packet: to what extent signaling this information simplifies the SFC operations, and whether it increases/decreases the serviceability of an SFC-enabled domain? Let's also assess to what extent having the version number add more complexity in the SFC header treatment when several versions are supported by a node/within an SFC enabled domain? How it helps interoperability? Some points for discussion are elaborated below: > > * If the SFC-enabled domain is configured to support the same version (which is likely): having the version number is not of any help. > * If the SFC-enabled domain involves some nodes that support version (v1) while others support (v2) (simple case): If these version are not backward compatible, this will lead to failures when two adjacent elements in a service chain do not support the same version. The SFC system is broken. Having the version number is not of any help in this case. > * If the SFC-enabled domain involves some nodes that support version (v1) while others support (v1 and v2): > > (a) The nodes that support both v1 and v2 should be instructed to decide which version to be used. This can be either part of the specification or be driven by configuration. If a version number is included in the spec, I would expect to clarify the behavior in such case. > > (b) Suppose a node that supports only v1 receives a packet with header (v2): If this node does not support a notification procedure to inform the source that it does not support that header version, then FAILURES are introduced in the network. This is a degradation of the service compared to legacy scheme to structure services. This is not recommended, IMHO. > > (c) If a notification is received from an element about its supported version: a node can use another version (the logic to select other version is another point to discuss) for that communication, but what to do for the next flows in the context of the same service chain or other chains that involves these two nodes as adjacent elements in the same chain? Shouldn't these nodes cache the version to use for subsequent exchange to avoid receiving the notification error each time? Wouldn't that complexity the behavior of the SFC-aware elements? > > (d) If a notification is received from an element about its supported version: As this may occurs in various segments of a given service chain, e.g., (A(v1), B(v1,v2), C(v2), D(v1,v2), E(v1)). Notifying the adjacent node each time there is a version mismatch induce an extra delay, that may be not be acceptable for every flow. > > I hope this clarifies my initial concern. > > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoyé : mercredi 25 février 2015 16:10 >> Ŕ : BOUCADAIR Mohamed IMT/OLN; paulq@cisco.com >> Cc : sfc@ietf.org >> Objet : Re: [sfc] draft-quinn-sfc-nsh: version number >> >> I would really prefer to keep the version number. Even though we have >> the MD-type identifier and for some MD we have the TLVs. >> >> The reason is that we may want to change the base header. For example, >> suppose that the ciscussion about including a flow identifier in the >> base header had not come up now. If it came up later, we would want to >> be able to have the discussion and make the choice, rather than being >> constrained by the lack of a version field. >> >> Yours, >> Joel >> >> >> On 2/25/15 10:03 AM, mohamed.boucadair@orange.com wrote: >>> Hi Paul, all, >>> >>> What is the purpose of having a version number in the header? Is there a >>> kind of version negotiation that needs to be in place? >>> >>> I checked the I-D but failed to find text that explains the rationale, >>> the use of the such field and whether an error will be returned if the >>> version is not supported by the receiving node. >>> >>> Wouldn't be preferable to get rid of this field given that SFC header >>> can be extended using optional objects and consistent setup & >>> configuration within an SFC-enabled domain should be assumed? >>> >>> Thank you >>> >>> Cheers, >>> >>> Med >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> > From nobody Thu Feb 26 06:40: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 54C271A00FB for ; Thu, 26 Feb 2015 06:40:12 -0800 (PST) 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 nfoy0ctLP7bG for ; Thu, 26 Feb 2015 06:40:10 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B38F31A0155 for ; Thu, 26 Feb 2015 06:40:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6722; q=dns/txt; s=iport; t=1424961606; x=1426171206; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vspzLZMDQaK+waec6m7xuJLeipe7y9kpgkOv/oV3xgk=; b=T79zi+WzZOxiinSh95sPFR9Ye3OxPXe5hugXXumPiiMZX7bDzFzmm9a4 EAawzEkP3doO35jDFqE9ScSL/cYLxvDIpEvDR4HihoeP76XULaSbkwjBy N3B8tE87S7W3Zyw/wreub+nNV4f01/s7A+ykCkW0QdrOlzWO+T4bEyC+2 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A6BwCjL+9U/4oNJK1bgj9DUk4MskqNSIFpAQmFcAKBIk0BAQEBAQF8hBABAQQBAQEaUQsQAgEIPwcnCxQRAgQOBYgvDdZAAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sThAwRAUwEBgGDF4EUBY12gXmDYIVlgRs5gmWPECOCAhyBUG+BC4E4AQEB X-IronPort-AV: E=Sophos;i="5.09,652,1418083200"; d="scan'208,217";a="399696577" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP; 26 Feb 2015 14:40:05 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t1QEe4sV011355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Feb 2015 14:40:04 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.45]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 08:40:04 -0600 From: "Victor Moreno (vimoreno)" To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] WG call for adoption of draft-quinn-sfc-nsh Thread-Index: AQHQUdIbgzIAmYoQ8E+Yvx/nKf7M8g== Date: Thu, 26 Feb 2015 14:40:04 +0000 Message-ID: <55F70A7D-5386-40EB-BB4D-DBAC696C3704@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_55F70A7D538640EBBB4DDBAC696C3704ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 26 Feb 2015 14:40:12 -0000 --_000_55F70A7D538640EBBB4DDBAC696C3704ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Support WG adoption. Victor On Feb 26, 2015, at 4:47 AM, Jim Guichard (jguichar) > wrote: Greetings WG: The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft= -quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc= -sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined = the NSH document so that the WG can focus on a single encapsulation documen= t going forward. This new version of NSH includes an open items section bas= ed on discussion between co-authors and members of the list. The WG will wo= rk through this list (and any other issues that need to be added) over the = next weeks. We appreciate and recognize the hard work of both the NSH and S= CH authors in pushing the SFC encapsulation work forward. With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n= sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3= /12/2015. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG=92s decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Jim & Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_55F70A7D538640EBBB4DDBAC696C3704ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    Support WG adoption. 

    Victor

    On Feb 26, 2015, at 4:47 AM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

    Greetings WG:

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/dra= ft-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draf= t-zhang-sfc-sch/) have joined the NSH document so that the WG can focus= on a single encapsulation document going forward. This new version of NSH includes an open items secti= on based on discussion between co-authors and members of the list. The WG w= ill work through this list (and any other issues that need to be added) ove= r the next weeks. We appreciate and recognize the hard work of both the NSH and SCH authors in pushing the= SFC encapsulation work forward.

    With that said, the chairs are calling for WG adoption of draft= -quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 we= eks ending 3/12/2015.

    Please note t= hat this is a call for adoption, and not a last call for content of the doc= ument. Adopting a WG document simply means that the WG will focus its effor= ts on that particular draft going forward, and use that document for resolving open issues and documenting the WG=92s= decisions.

    Please indica= te whether you support adoption for not, and if not why. Issues you have wi= th the current document itself can also be raised, but they should be raise= d in the context of what should be changed in the document going forward, rather than a pre-condition for adoption.&n= bsp;

    Finally, now = is also a good time to poll for knowledge of any IPR that applies to this d= raft, in line with the IPR disclosure obligations for WG participants (see = RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please respond to this em= ail (to the chairs) whether or not you are aware of any relevant IPR.

    Jim & Thomas
    _______________________________________________
    sfc mailing list
    sfc@ietf.org
    https://www.iet= f.org/mailman/listinfo/sfc
    --_000_55F70A7D538640EBBB4DDBAC696C3704ciscocom_-- From nobody Thu Feb 26 06:41: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 4DFCE1A00FB for ; Thu, 26 Feb 2015 06:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ElISZfNwQjdm for ; Thu, 26 Feb 2015 06:41:30 -0800 (PST) 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 F38B71A0149 for ; Thu, 26 Feb 2015 06:41:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CBF831C03A5; Thu, 26 Feb 2015 06:41:29 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.95.128.180]) (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 279A81C030A; Thu, 26 Feb 2015 06:41:29 -0800 (PST) Message-ID: <54EF3086.8040700@joelhalpern.com> Date: Thu, 26 Feb 2015 09:41:10 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "sfc@ietf.org" References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals 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, 26 Feb 2015 14:41:34 -0000 The SF Spirals requirement is one of the key drivers for the index. The index allows one to tell where one is in the spiral, and also to break a loop if one has a loop instead of a spiral. Is there text that we could add that would help make this clear, since your earlier question about the path index suggests that it is not as clear as it should be? Yours, Joel On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote: > Hi Paul, all, > > There were a discussion in the mailing list > (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html) that > led to defining what is meant by SF Spirals: (below is provided an > excerpt from > http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where the > conclusions of that discussion were recorded) > > “ o Service Function Spiral: denotes a Service Function Chain in which > > data is handled by a Service Function, forwarded onwards, and > > arrives once again at that Service Function. > > * Note that some Service Functions support built-in functions to > > accommodate spirals; these service-specific functions may > > require that the data received in a spiral should differ in a > > way that will result in a different processing decision than > > the original data. This document does not make such > > assumption. > > * A Service Function Chain may involve one or more Service > > Function Spirals. > > * Unlike Service Function loop, spirals are not considered as > > errors." > > And this companion requirement: > > “ A. Service Functions MAY be invoked multiple times in > > the same Service Function Chain (denoted as SF > > Spiral), but the solution MUST prevent infinite > > forwarding loops. » > > Reading the current draft-quinn-sfc-nsh, I don’t see how this is met. > > Can you please clarify whether this is supported and how? > > Thank you. > > Cheers, > > Med > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Feb 26 06:43:49 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 6CB041A0199 for ; Thu, 26 Feb 2015 06:43:48 -0800 (PST) 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 Zkhm8WGAoEJL for ; Thu, 26 Feb 2015 06:43:46 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F451A0149 for ; Thu, 26 Feb 2015 06:43:42 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9486222CC29; Thu, 26 Feb 2015 15:43:40 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.56]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 6F3D127C07F; Thu, 26 Feb 2015 15:43:40 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH04.corporate.adroot.infra.ftgroup ([10.114.31.56]) with mapi id 14.03.0224.002; Thu, 26 Feb 2015 15:43:40 +0100 From: To: "Joel M. Halpern" , "paulq@cisco.com" Thread-Topic: [sfc] draft-quinn-sfc-nsh: version number Thread-Index: AdBRDDloSX0/55xiS1KsQav7+px1wQAw8FlSAAAxqEA= Date: Thu, 26 Feb 2015 14:43:39 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004915ADE@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049140B4@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EDE5B7.6080102@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330049156A9@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF2C9A.3040008@joelhalpern.com> In-Reply-To: <54EF2C9A.3040008@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.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.26.125120 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] draft-quinn-sfc-nsh: version number 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, 26 Feb 2015 14:43:48 -0000 Hi Joel, mmm... an "operator following good practices" won't put into production a n= ode that does not support a version that is not backward compatible with ot= her nodes within an SFC enabled domain; worse, if your proposed behavior is= followed, service chains involving that node will be broken !=20 IMHO, the points raised in my initial message are still open. Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Envoy=E9=A0: jeudi 26 f=E9vrier 2015 15:24 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; paulq@cisco.com > Cc=A0: sfc@ietf.org > Objet=A0: Re: [sfc] draft-quinn-sfc-nsh: version number >=20 > In one sense you are correct. If you could count on everything being > upgraded at once, sure you could just assume common interpretation. > However, we have found over the years that such simultaneous upgrading > never works. You need to be able to transition. >=20 > I do agree that we should add text about what to do with version numbers > that are not understood. There are multiple choices that affect how we > can make changes. My personal preference is: >=20 > If an packet presumed to carry an NSH header is received at an SFF, and > the SFF does not understnad the version of the protocol as indicated in > the base header, the packet MUST be discarded, and the event SHOULD be > logged. >=20 > This would allow an orderly transition, where devices can be upgraded to > understand a new version, then generation of the new version header can > be enabled. If a configuration error is made, the packets will be > dropped and operators following good practices will get notifications. >=20 > Yours, > Joel >=20 > On 2/26/15 2:16 AM, mohamed.boucadair@orange.com wrote: > > Hi Joel, > > > > I fully agree with the extendibility of the header, but the question is > why having a version number will be of help in the context of SFC? Second= , > having a version number without specifying the behavior when several > versions are supported, when the version number is not supported by an > SFC-aware element, etc. leaves open issues out of the spec. > > > > The other problem is that the current I-D includes several open doors > left for extending the header: > > * version > > * reserved bits > > * optional data > > > > This is too much for a header that is supposed to be compact and simple= ! > > > > There are other means to extend the header without signaling the versio= n > in the packet. Having a distinct RFC number may be just fine in the > context of an unidirectional stream such as SFC. > > > > Let us consider the situation where a version number is not explicitly > signaled in the packet (but a new RFC updates the base SFC header). > Several options can be considered, indeed (those are provided as examples > for illustration purposes): > > * An operator can make sure that its SFC-enabled domain is configured i= n > a consistent manner to support one and only one version of the header. No > interoperability issues is encountered in this case. > > * An operator that wants to upgrade its SFC-enabled domain to support a > new specification of the SFC header: An operator can decide to proceed to > a software/hardware updates but can maintain the old header in operation > until all involved elements are upgraded to support the new version. Once > the SFC-enabled domain is upgraded, then the new header can be enabled. > > > > Let's consider now that a version is signaled in the packet: to what > extent signaling this information simplifies the SFC operations, and > whether it increases/decreases the serviceability of an SFC-enabled > domain? Let's also assess to what extent having the version number add > more complexity in the SFC header treatment when several versions are > supported by a node/within an SFC enabled domain? How it helps > interoperability? Some points for discussion are elaborated below: > > > > * If the SFC-enabled domain is configured to support the same version > (which is likely): having the version number is not of any help. > > * If the SFC-enabled domain involves some nodes that support version > (v1) while others support (v2) (simple case): If these version are not > backward compatible, this will lead to failures when two adjacent element= s > in a service chain do not support the same version. The SFC system is > broken. Having the version number is not of any help in this case. > > * If the SFC-enabled domain involves some nodes that support version > (v1) while others support (v1 and v2): > > > > (a) The nodes that support both v1 and v2 should be instructed to decid= e > which version to be used. This can be either part of the specification or > be driven by configuration. If a version number is included in the spec, = I > would expect to clarify the behavior in such case. > > > > (b) Suppose a node that supports only v1 receives a packet with header > (v2): If this node does not support a notification procedure to inform th= e > source that it does not support that header version, then FAILURES are > introduced in the network. This is a degradation of the service compared > to legacy scheme to structure services. This is not recommended, IMHO. > > > > (c) If a notification is received from an element about its supported > version: a node can use another version (the logic to select other versio= n > is another point to discuss) for that communication, but what to do for > the next flows in the context of the same service chain or other chains > that involves these two nodes as adjacent elements in the same chain? > Shouldn't these nodes cache the version to use for subsequent exchange to > avoid receiving the notification error each time? Wouldn't that complexit= y > the behavior of the SFC-aware elements? > > > > (d) If a notification is received from an element about its supported > version: As this may occurs in various segments of a given service chain, > e.g., (A(v1), B(v1,v2), C(v2), D(v1,v2), E(v1)). Notifying the adjacent > node each time there is a version mismatch induce an extra delay, that ma= y > be not be acceptable for every flow. > > > > I hope this clarifies my initial concern. > > > > Thank you. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Envoy=E9 : mercredi 25 f=E9vrier 2015 16:10 > >> =C0 : BOUCADAIR Mohamed IMT/OLN; paulq@cisco.com > >> Cc : sfc@ietf.org > >> Objet : Re: [sfc] draft-quinn-sfc-nsh: version number > >> > >> I would really prefer to keep the version number. Even though we have > >> the MD-type identifier and for some MD we have the TLVs. > >> > >> The reason is that we may want to change the base header. For example= , > >> suppose that the ciscussion about including a flow identifier in the > >> base header had not come up now. If it came up later, we would want t= o > >> be able to have the discussion and make the choice, rather than being > >> constrained by the lack of a version field. > >> > >> Yours, > >> Joel > >> > >> > >> On 2/25/15 10:03 AM, mohamed.boucadair@orange.com wrote: > >>> Hi Paul, all, > >>> > >>> What is the purpose of having a version number in the header? Is ther= e > a > >>> kind of version negotiation that needs to be in place? > >>> > >>> I checked the I-D but failed to find text that explains the rationale= , > >>> the use of the such field and whether an error will be returned if th= e > >>> version is not supported by the receiving node. > >>> > >>> Wouldn't be preferable to get rid of this field given that SFC header > >>> can be extended using optional objects and consistent setup & > >>> configuration within an SFC-enabled domain should be assumed? > >>> > >>> Thank you > >>> > >>> Cheers, > >>> > >>> Med > >>> > >>> > >>> > >>> _______________________________________________ > >>> sfc mailing list > >>> sfc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sfc > >>> > > From nobody Thu Feb 26 06:44:55 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF991A0158 for ; Thu, 26 Feb 2015 06:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 wFfNghjnYIbU for ; Thu, 26 Feb 2015 06:44:52 -0800 (PST) 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 D5E7B1A0141 for ; Thu, 26 Feb 2015 06:44:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id A8B221C01CA; Thu, 26 Feb 2015 06:44:52 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.95.128.180]) (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 3396B1C030A; Thu, 26 Feb 2015 06:44:52 -0800 (PST) Message-ID: <54EF3151.5000802@joelhalpern.com> Date: Thu, 26 Feb 2015 09:44:33 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Jim Guichard (jguichar)" , "sfc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 26 Feb 2015 14:44:54 -0000 Thank you Jim. Support as a co-author. Yours, Joel On 2/26/15 7:47 AM, Jim Guichard (jguichar) wrote: > Greetings WG: > > The document draft-quinn-sfc-nsh-07 > (https://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/) has recently > been reissued. ... > With that said, the chairs are calling for WG adoption of > draft-quinn-sfc-nsh-07 as a WG document. The call for adoption will run > for 2 weeks ending 3/12/2015. ... From nobody Thu Feb 26 06:50:57 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 D1B391A01A8 for ; Thu, 26 Feb 2015 06:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 vfR0yeeBigH4 for ; Thu, 26 Feb 2015 06:50:53 -0800 (PST) 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 6651F1A017D for ; Thu, 26 Feb 2015 06:50:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4679A1C030A; Thu, 26 Feb 2015 06:50:53 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.95.128.180]) (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 6D0D51C01CA; Thu, 26 Feb 2015 06:50:52 -0800 (PST) Message-ID: <54EF32B9.20307@joelhalpern.com> Date: Thu, 26 Feb 2015 09:50:33 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "Joel M. Halpern" , "paulq@cisco.com" References: <787AE7BB302AE849A7480A190F8B9330049140B4@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EDE5B7.6080102@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330049156A9@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF2C9A.3040008@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915ADE@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933004915ADE@OPEXCLILM23.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] draft-quinn-sfc-nsh: version number 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, 26 Feb 2015 14:50:56 -0000 Obviously, if the header never changes, the version number is indeed wasted bits. However, I tend to perefer to design assuming that we have not made all the right calls, and will need to make changes in the future. If an operator has running SFC insfrastructure, and we make introduce a new version, then by definition the operator, still following good practices, will have devices in his network that do not support the new header. He will have to upgrade. He will try to upgrade cleanly. But: 1) Even if he gets all the upgrades done well, he needs a way to turn on the new features cleanly. Since reconfiguring all devices at the same time is a non-starter, the devices will need to be able to tell new from old. 2) Operators have to allow for operational error. It may be that not all the devices have gotten upgraded, even if the process he uses should have resulted in that. We have all seen things go wrong in practice. So a version number field serves as an error check against these sorts of problems. Thus, on the one hand version numbering allows for migration, and on the other hand it enables robust operation. Seems like a very good trade. Yours, Joel On 2/26/15 9:43 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > mmm... an "operator following good practices" won't put into production a node that does not support a version that is not backward compatible with other nodes within an SFC enabled domain; worse, if your proposed behavior is followed, service chains involving that node will be broken ! > > IMHO, the points raised in my initial message are still open. > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoyé : jeudi 26 février 2015 15:24 >> Ŕ : BOUCADAIR Mohamed IMT/OLN; paulq@cisco.com >> Cc : sfc@ietf.org >> Objet : Re: [sfc] draft-quinn-sfc-nsh: version number >> >> In one sense you are correct. If you could count on everything being >> upgraded at once, sure you could just assume common interpretation. >> However, we have found over the years that such simultaneous upgrading >> never works. You need to be able to transition. >> >> I do agree that we should add text about what to do with version numbers >> that are not understood. There are multiple choices that affect how we >> can make changes. My personal preference is: >> >> If an packet presumed to carry an NSH header is received at an SFF, and >> the SFF does not understnad the version of the protocol as indicated in >> the base header, the packet MUST be discarded, and the event SHOULD be >> logged. >> >> This would allow an orderly transition, where devices can be upgraded to >> understand a new version, then generation of the new version header can >> be enabled. If a configuration error is made, the packets will be >> dropped and operators following good practices will get notifications. >> >> Yours, >> Joel >> >> On 2/26/15 2:16 AM, mohamed.boucadair@orange.com wrote: >>> Hi Joel, >>> >>> I fully agree with the extendibility of the header, but the question is >> why having a version number will be of help in the context of SFC? Second, >> having a version number without specifying the behavior when several >> versions are supported, when the version number is not supported by an >> SFC-aware element, etc. leaves open issues out of the spec. >>> >>> The other problem is that the current I-D includes several open doors >> left for extending the header: >>> * version >>> * reserved bits >>> * optional data >>> >>> This is too much for a header that is supposed to be compact and simple! >>> >>> There are other means to extend the header without signaling the version >> in the packet. Having a distinct RFC number may be just fine in the >> context of an unidirectional stream such as SFC. >>> >>> Let us consider the situation where a version number is not explicitly >> signaled in the packet (but a new RFC updates the base SFC header). >> Several options can be considered, indeed (those are provided as examples >> for illustration purposes): >>> * An operator can make sure that its SFC-enabled domain is configured in >> a consistent manner to support one and only one version of the header. No >> interoperability issues is encountered in this case. >>> * An operator that wants to upgrade its SFC-enabled domain to support a >> new specification of the SFC header: An operator can decide to proceed to >> a software/hardware updates but can maintain the old header in operation >> until all involved elements are upgraded to support the new version. Once >> the SFC-enabled domain is upgraded, then the new header can be enabled. >>> >>> Let's consider now that a version is signaled in the packet: to what >> extent signaling this information simplifies the SFC operations, and >> whether it increases/decreases the serviceability of an SFC-enabled >> domain? Let's also assess to what extent having the version number add >> more complexity in the SFC header treatment when several versions are >> supported by a node/within an SFC enabled domain? How it helps >> interoperability? Some points for discussion are elaborated below: >>> >>> * If the SFC-enabled domain is configured to support the same version >> (which is likely): having the version number is not of any help. >>> * If the SFC-enabled domain involves some nodes that support version >> (v1) while others support (v2) (simple case): If these version are not >> backward compatible, this will lead to failures when two adjacent elements >> in a service chain do not support the same version. The SFC system is >> broken. Having the version number is not of any help in this case. >>> * If the SFC-enabled domain involves some nodes that support version >> (v1) while others support (v1 and v2): >>> >>> (a) The nodes that support both v1 and v2 should be instructed to decide >> which version to be used. This can be either part of the specification or >> be driven by configuration. If a version number is included in the spec, I >> would expect to clarify the behavior in such case. >>> >>> (b) Suppose a node that supports only v1 receives a packet with header >> (v2): If this node does not support a notification procedure to inform the >> source that it does not support that header version, then FAILURES are >> introduced in the network. This is a degradation of the service compared >> to legacy scheme to structure services. This is not recommended, IMHO. >>> >>> (c) If a notification is received from an element about its supported >> version: a node can use another version (the logic to select other version >> is another point to discuss) for that communication, but what to do for >> the next flows in the context of the same service chain or other chains >> that involves these two nodes as adjacent elements in the same chain? >> Shouldn't these nodes cache the version to use for subsequent exchange to >> avoid receiving the notification error each time? Wouldn't that complexity >> the behavior of the SFC-aware elements? >>> >>> (d) If a notification is received from an element about its supported >> version: As this may occurs in various segments of a given service chain, >> e.g., (A(v1), B(v1,v2), C(v2), D(v1,v2), E(v1)). Notifying the adjacent >> node each time there is a version mismatch induce an extra delay, that may >> be not be acceptable for every flow. >>> >>> I hope this clarifies my initial concern. >>> >>> Thank you. >>> >>> Cheers, >>> Med >>> >>>> -----Message d'origine----- >>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Envoyé : mercredi 25 février 2015 16:10 >>>> Ŕ : BOUCADAIR Mohamed IMT/OLN; paulq@cisco.com >>>> Cc : sfc@ietf.org >>>> Objet : Re: [sfc] draft-quinn-sfc-nsh: version number >>>> >>>> I would really prefer to keep the version number. Even though we have >>>> the MD-type identifier and for some MD we have the TLVs. >>>> >>>> The reason is that we may want to change the base header. For example, >>>> suppose that the ciscussion about including a flow identifier in the >>>> base header had not come up now. If it came up later, we would want to >>>> be able to have the discussion and make the choice, rather than being >>>> constrained by the lack of a version field. >>>> >>>> Yours, >>>> Joel >>>> >>>> >>>> On 2/25/15 10:03 AM, mohamed.boucadair@orange.com wrote: >>>>> Hi Paul, all, >>>>> >>>>> What is the purpose of having a version number in the header? Is there >> a >>>>> kind of version negotiation that needs to be in place? >>>>> >>>>> I checked the I-D but failed to find text that explains the rationale, >>>>> the use of the such field and whether an error will be returned if the >>>>> version is not supported by the receiving node. >>>>> >>>>> Wouldn't be preferable to get rid of this field given that SFC header >>>>> can be extended using optional objects and consistent setup & >>>>> configuration within an SFC-enabled domain should be assumed? >>>>> >>>>> Thank you >>>>> >>>>> Cheers, >>>>> >>>>> Med >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>> From nobody Thu Feb 26 06:52:37 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB141A016B for ; Thu, 26 Feb 2015 06:52:35 -0800 (PST) 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 yyvxckMWJWJS for ; Thu, 26 Feb 2015 06:52:34 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C8C1A0158 for ; Thu, 26 Feb 2015 06:52:34 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 3DD54374286; Thu, 26 Feb 2015 15:52:32 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.55]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 1B10F18006C; Thu, 26 Feb 2015 15:52:32 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([10.114.31.55]) with mapi id 14.03.0224.002; Thu, 26 Feb 2015 15:52:32 +0100 From: To: "Joel M. Halpern" , "sfc@ietf.org" Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals Thread-Index: AdBRyhUadMfMQp0TQVyP+AHUYniSlP///5cA///tVjA= Date: Thu, 26 Feb 2015 14:52:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> In-Reply-To: <54EF3086.8040700@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.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.26.125120 Archived-At: Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals 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, 26 Feb 2015 14:52:36 -0000 Re-, Spiral is not mentioned in the draft, but SF loop is. I'm asking the question because I don't get from the draft how spirals coul= d work (that is a SF invoked several time in the context of the same SFC).= =20 Before proposing text, I would like to understand first how it works. If yo= u can provide an example, this will be even great. Thank you. Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Envoy=E9=A0: jeudi 26 f=E9vrier 2015 15:41 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org > Cc=A0: Ben Wright (Ben.Wright@metaswitch.com) > Objet=A0: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >=20 > The SF Spirals requirement is one of the key drivers for the index. The > index allows one to tell where one is in the spiral, and also to break a > loop if one has a loop instead of a spiral. >=20 > Is there text that we could add that would help make this clear, since > your earlier question about the path index suggests that it is not as > clear as it should be? >=20 > Yours, > Joel >=20 > On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote: > > Hi Paul, all, > > > > There were a discussion in the mailing list > > (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html) that > > led to defining what is meant by SF Spirals: (below is provided an > > excerpt from > > http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where th= e > > conclusions of that discussion were recorded) > > > > " o Service Function Spiral: denotes a Service Function Chain in > which > > > > data is handled by a Service Function, forwarded onwards, and > > > > arrives once again at that Service Function. > > > > * Note that some Service Functions support built-in functions t= o > > > > accommodate spirals; these service-specific functions may > > > > require that the data received in a spiral should differ in a > > > > way that will result in a different processing decision than > > > > the original data. This document does not make such > > > > assumption. > > > > * A Service Function Chain may involve one or more Service > > > > Function Spirals. > > > > * Unlike Service Function loop, spirals are not considered as > > > > errors." > > > > And this companion requirement: > > > > " A. Service Functions MAY be invoked multiple times in > > > > the same Service Function Chain (denoted as SF > > > > Spiral), but the solution MUST prevent infinite > > > > forwarding loops. =BB > > > > Reading the current draft-quinn-sfc-nsh, I don't see how this is met. > > > > Can you please clarify whether this is supported and how? > > > > Thank you. > > > > Cheers, > > > > Med > > > > > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc > > From nobody Thu Feb 26 07:02:56 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 CF6341A01F2 for ; Thu, 26 Feb 2015 07:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 1hy43aIdt9Tp for ; Thu, 26 Feb 2015 07:02:50 -0800 (PST) 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 E8B9D1A0158 for ; Thu, 26 Feb 2015 07:02:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D76671C0C1A; Thu, 26 Feb 2015 07:02:48 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.95.128.180]) (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 248A91C0DC2; Thu, 26 Feb 2015 07:02:48 -0800 (PST) Message-ID: <54EF3584.2080005@joelhalpern.com> Date: Thu, 26 Feb 2015 10:02:28 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "sfc@ietf.org" References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals 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, 26 Feb 2015 15:02:55 -0000 There are two different aspects of Spirals. One of the two aspects is enabling a packet that repeatedly arrives at the same SFF to get the correct services provided each time it arrives, and to go to the correct next SFF each time it arrives. The Service Path Index, used by the SFF to select service functions and next SFF, provides that capability. The other aspect is how the Service Functions themselves handle spirals. To a large degree, that depends upon the individual service function. I normally assume that it would use packet context (as described in the text you quote) to determine what to do. Since I would prefer that service functions are independent of the underlying service function chaining infrastructure, and are not sensitive to how many functions are before or after them in the chain, I would personally prefer that they not use the path index for that. I would recommend that if the packet does not carry enough context that the service function could and should use metadata to carry its needed state information. But neither I personally nor the SFC Working Group get to tell folks how to build their service functions. So they may come up with other methods for addressing their needs. Which is also fine. Thus, I would not expect this document to discuss how service functions themselves handle revisiting. But metadata clearly allows for a range of behaviors that will work. And the path index handles the SFF needs relative to spirals, which is what we need to handle. Yours, Joel On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote: > Re-, > > Spiral is not mentioned in the draft, but SF loop is. > > I'm asking the question because I don't get from the draft how spirals could work (that is a SF invoked several time in the context of the same SFC). > > Before proposing text, I would like to understand first how it works. If you can provide an example, this will be even great. > > Thank you. > > Cheers, > Med > >> -----Message d'origine----- >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Envoyé : jeudi 26 février 2015 15:41 >> Ŕ : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org >> Cc : Ben Wright (Ben.Wright@metaswitch.com) >> Objet : Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >> >> The SF Spirals requirement is one of the key drivers for the index. The >> index allows one to tell where one is in the spiral, and also to break a >> loop if one has a loop instead of a spiral. >> >> Is there text that we could add that would help make this clear, since >> your earlier question about the path index suggests that it is not as >> clear as it should be? >> >> Yours, >> Joel >> >> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote: >>> Hi Paul, all, >>> >>> There were a discussion in the mailing list >>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html) that >>> led to defining what is meant by SF Spirals: (below is provided an >>> excerpt from >>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where the >>> conclusions of that discussion were recorded) >>> >>> " o Service Function Spiral: denotes a Service Function Chain in >> which >>> >>> data is handled by a Service Function, forwarded onwards, and >>> >>> arrives once again at that Service Function. >>> >>> * Note that some Service Functions support built-in functions to >>> >>> accommodate spirals; these service-specific functions may >>> >>> require that the data received in a spiral should differ in a >>> >>> way that will result in a different processing decision than >>> >>> the original data. This document does not make such >>> >>> assumption. >>> >>> * A Service Function Chain may involve one or more Service >>> >>> Function Spirals. >>> >>> * Unlike Service Function loop, spirals are not considered as >>> >>> errors." >>> >>> And this companion requirement: >>> >>> " A. Service Functions MAY be invoked multiple times in >>> >>> the same Service Function Chain (denoted as SF >>> >>> Spiral), but the solution MUST prevent infinite >>> >>> forwarding loops. » >>> >>> Reading the current draft-quinn-sfc-nsh, I don't see how this is met. >>> >>> Can you please clarify whether this is supported and how? >>> >>> Thank you. >>> >>> Cheers, >>> >>> Med >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> > From nobody Thu Feb 26 07:08: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 278021A0263 for ; Thu, 26 Feb 2015 07:08:31 -0800 (PST) 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 PbEi80svD1kT for ; Thu, 26 Feb 2015 07:08:27 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC30B1A0187 for ; Thu, 26 Feb 2015 07:08:26 -0800 (PST) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 89E0337453C; Thu, 26 Feb 2015 16:08:24 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.5]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 6AA6E18008E; Thu, 26 Feb 2015 16:08:24 +0100 (CET) Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([169.254.2.231]) by OPEXCLILH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Thu, 26 Feb 2015 16:08:24 +0100 From: To: "Joel M. Halpern" , "paulq@cisco.com" Thread-Topic: [sfc] draft-quinn-sfc-nsh: version number Thread-Index: AdBRDDloSX0/55xiS1KsQav7+px1wQAx2ePdAAAlN4A= Date: Thu, 26 Feb 2015 15:08:23 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933004915B3D@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <787AE7BB302AE849A7480A190F8B9330049140B4@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EDE5B7.6080102@joelhalpern.com> <787AE7BB302AE849A7480A190F8B9330049156A9@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF2C9A.3040008@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915ADE@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF32B9.20307@joelhalpern.com> In-Reply-To: <54EF32B9.20307@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.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.16.134821 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] draft-quinn-sfc-nsh: version number 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, 26 Feb 2015 15:08:31 -0000 Re-, Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Envoy=E9=A0: jeudi 26 f=E9vrier 2015 15:51 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Joel M. Halpern; paulq@cisco.com > Cc=A0: sfc@ietf.org > Objet=A0: Re: [sfc] draft-quinn-sfc-nsh: version number >=20 > Obviously, if the header never changes, the version number is indeed > wasted bits. > However, I tend to perefer to design assuming that we have not made all > the right calls, and will need to make changes in the future. [Med] There are various means to make changes. The current spec includes to= o many: * optional elements * reserved bits * version * MD type Is this really justified for a header that is supposed to be compact (avoid= fragmentation as much as possible)? Having the version number is not the o= nly way to extend the header.=20 >=20 > If an operator has running SFC insfrastructure, and we make introduce a > new version, then by definition the operator, still following good > practices, will have devices in his network that do not support the new > header. He will have to upgrade. He will try to upgrade cleanly.=20 But: > 1) Even if he gets all the upgrades done well, he needs a way to turn on > the new features cleanly. Since reconfiguring all devices at the same > time is a non-starter, the devices will need to be able to tell new from > old. [Med] co-existence of both versions of the header are likely during transit= ion period. Disrupting the service should be avoided. If this can be manage= d by the protocol, this will be optimal. If not, the operator should be pre= pared to make an action plan to coordinate the migration steps.=20 > 2) Operators have to allow for operational error. It may be that not > all the devices have gotten upgraded, even if the process he uses should > have resulted in that. We have all seen things go wrong in practice. > So a version number field serves as an error check against these sorts > of problems. [Med] This is exactly the same situation when no version is signaled in the= packet but the node does not support the new RFC that updates the header. = A node that receives a packet destined to it (as indicated at the transport= encapsulation level) but cannot parse the header will log a failure. >=20 > Thus, on the one hand version numbering allows for migration, [Med] How is that unique to version numbering ? I see a value in version nu= mbering if it is used by the protocol to maintain the serviceability of a n= etwork.=20 and on the > other hand it enables robust operation. [Med] What is that mean? Seems like a very good trade. >=20 > Yours, > Joel >=20 > On 2/26/15 9:43 AM, mohamed.boucadair@orange.com wrote: > > Hi Joel, > > > > mmm... an "operator following good practices" won't put into production > a node that does not support a version that is not backward compatible > with other nodes within an SFC enabled domain; worse, if your proposed > behavior is followed, service chains involving that node will be broken ! > > > > IMHO, the points raised in my initial message are still open. > > > > Cheers, > > Med > > > >> -----Message d'origine----- > >> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Envoy=E9 : jeudi 26 f=E9vrier 2015 15:24 > >> =C0 : BOUCADAIR Mohamed IMT/OLN; paulq@cisco.com > >> Cc : sfc@ietf.org > >> Objet : Re: [sfc] draft-quinn-sfc-nsh: version number > >> > >> In one sense you are correct. If you could count on everything being > >> upgraded at once, sure you could just assume common interpretation. > >> However, we have found over the years that such simultaneous upgrading > >> never works. You need to be able to transition. > >> > >> I do agree that we should add text about what to do with version > numbers > >> that are not understood. There are multiple choices that affect how w= e > >> can make changes. My personal preference is: > >> > >> If an packet presumed to carry an NSH header is received at an SFF, an= d > >> the SFF does not understnad the version of the protocol as indicated i= n > >> the base header, the packet MUST be discarded, and the event SHOULD be > >> logged. > >> > >> This would allow an orderly transition, where devices can be upgraded > to > >> understand a new version, then generation of the new version header ca= n > >> be enabled. If a configuration error is made, the packets will be > >> dropped and operators following good practices will get notifications. > >> > >> Yours, > >> Joel > >> > >> On 2/26/15 2:16 AM, mohamed.boucadair@orange.com wrote: > >>> Hi Joel, > >>> > >>> I fully agree with the extendibility of the header, but the question > is > >> why having a version number will be of help in the context of SFC? > Second, > >> having a version number without specifying the behavior when several > >> versions are supported, when the version number is not supported by an > >> SFC-aware element, etc. leaves open issues out of the spec. > >>> > >>> The other problem is that the current I-D includes several open doors > >> left for extending the header: > >>> * version > >>> * reserved bits > >>> * optional data > >>> > >>> This is too much for a header that is supposed to be compact and > simple! > >>> > >>> There are other means to extend the header without signaling the > version > >> in the packet. Having a distinct RFC number may be just fine in the > >> context of an unidirectional stream such as SFC. > >>> > >>> Let us consider the situation where a version number is not explicitl= y > >> signaled in the packet (but a new RFC updates the base SFC header). > >> Several options can be considered, indeed (those are provided as > examples > >> for illustration purposes): > >>> * An operator can make sure that its SFC-enabled domain is configured > in > >> a consistent manner to support one and only one version of the header. > No > >> interoperability issues is encountered in this case. > >>> * An operator that wants to upgrade its SFC-enabled domain to support > a > >> new specification of the SFC header: An operator can decide to proceed > to > >> a software/hardware updates but can maintain the old header in > operation > >> until all involved elements are upgraded to support the new version. > Once > >> the SFC-enabled domain is upgraded, then the new header can be enabled= . > >>> > >>> Let's consider now that a version is signaled in the packet: to what > >> extent signaling this information simplifies the SFC operations, and > >> whether it increases/decreases the serviceability of an SFC-enabled > >> domain? Let's also assess to what extent having the version number add > >> more complexity in the SFC header treatment when several versions are > >> supported by a node/within an SFC enabled domain? How it helps > >> interoperability? Some points for discussion are elaborated below: > >>> > >>> * If the SFC-enabled domain is configured to support the same version > >> (which is likely): having the version number is not of any help. > >>> * If the SFC-enabled domain involves some nodes that support version > >> (v1) while others support (v2) (simple case): If these version are not > >> backward compatible, this will lead to failures when two adjacent > elements > >> in a service chain do not support the same version. The SFC system is > >> broken. Having the version number is not of any help in this case. > >>> * If the SFC-enabled domain involves some nodes that support version > >> (v1) while others support (v1 and v2): > >>> > >>> (a) The nodes that support both v1 and v2 should be instructed to > decide > >> which version to be used. This can be either part of the specification > or > >> be driven by configuration. If a version number is included in the > spec, I > >> would expect to clarify the behavior in such case. > >>> > >>> (b) Suppose a node that supports only v1 receives a packet with heade= r > >> (v2): If this node does not support a notification procedure to inform > the > >> source that it does not support that header version, then FAILURES are > >> introduced in the network. This is a degradation of the service > compared > >> to legacy scheme to structure services. This is not recommended, IMHO. > >>> > >>> (c) If a notification is received from an element about its supported > >> version: a node can use another version (the logic to select other > version > >> is another point to discuss) for that communication, but what to do fo= r > >> the next flows in the context of the same service chain or other chain= s > >> that involves these two nodes as adjacent elements in the same chain? > >> Shouldn't these nodes cache the version to use for subsequent exchange > to > >> avoid receiving the notification error each time? Wouldn't that > complexity > >> the behavior of the SFC-aware elements? > >>> > >>> (d) If a notification is received from an element about its supported > >> version: As this may occurs in various segments of a given service > chain, > >> e.g., (A(v1), B(v1,v2), C(v2), D(v1,v2), E(v1)). Notifying the adjacen= t > >> node each time there is a version mismatch induce an extra delay, that > may > >> be not be acceptable for every flow. > >>> > >>> I hope this clarifies my initial concern. > >>> > >>> Thank you. > >>> > >>> Cheers, > >>> Med > >>> > >>>> -----Message d'origine----- > >>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] > >>>> Envoy=E9 : mercredi 25 f=E9vrier 2015 16:10 > >>>> =C0 : BOUCADAIR Mohamed IMT/OLN; paulq@cisco.com > >>>> Cc : sfc@ietf.org > >>>> Objet : Re: [sfc] draft-quinn-sfc-nsh: version number > >>>> > >>>> I would really prefer to keep the version number. Even though we > have > >>>> the MD-type identifier and for some MD we have the TLVs. > >>>> > >>>> The reason is that we may want to change the base header. For > example, > >>>> suppose that the ciscussion about including a flow identifier in the > >>>> base header had not come up now. If it came up later, we would want > to > >>>> be able to have the discussion and make the choice, rather than bein= g > >>>> constrained by the lack of a version field. > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> > >>>> On 2/25/15 10:03 AM, mohamed.boucadair@orange.com wrote: > >>>>> Hi Paul, all, > >>>>> > >>>>> What is the purpose of having a version number in the header? Is > there > >> a > >>>>> kind of version negotiation that needs to be in place? > >>>>> > >>>>> I checked the I-D but failed to find text that explains the > rationale, > >>>>> the use of the such field and whether an error will be returned if > the > >>>>> version is not supported by the receiving node. > >>>>> > >>>>> Wouldn't be preferable to get rid of this field given that SFC > header > >>>>> can be extended using optional objects and consistent setup & > >>>>> configuration within an SFC-enabled domain should be assumed? > >>>>> > >>>>> Thank you > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Med > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> sfc mailing list > >>>>> sfc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/sfc > >>>>> > >>> From nobody Thu Feb 26 07:22:28 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 34D361A038F for ; Thu, 26 Feb 2015 07:22:28 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 581mMBcsbIf4 for ; Thu, 26 Feb 2015 07:22:24 -0800 (PST) Received: from smtptc.telefonica.com (smtptc.telefonica.com [195.76.34.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415221A0362 for ; Thu, 26 Feb 2015 07:22:23 -0800 (PST) Received: from smtptc.telefonica.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 90F9160362 for ; Thu, 26 Feb 2015 16:22:20 +0100 (CET) Received: from ESTGVMSP111.EUROPE.telefonica.corp (unknown [10.92.4.9]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtptc.telefonica.com (Postfix) with ESMTPS id 7618160224 for ; Thu, 26 Feb 2015 16:22:20 +0100 (CET) Received: from emea01-am1-obe.outbound.protection.outlook.com (10.92.5.139) by tls.telefonica.com (10.92.6.54) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 26 Feb 2015 16:22:19 +0100 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com (25.161.13.142) by DB4PR06MB0621.eurprd06.prod.outlook.com (25.161.13.139) with Microsoft SMTP Server (TLS) id 15.1.93.16; Thu, 26 Feb 2015 15:22:19 +0000 Received: from DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) by DB4PR06MB0624.eurprd06.prod.outlook.com ([25.161.13.142]) with mapi id 15.01.0093.004; Thu, 26 Feb 2015 15:22:18 +0000 From: DIEGO LOPEZ GARCIA To: "sfc@ietf.org" Thread-Topic: [sfc] WG call for adoption of draft-quinn-sfc-nsh Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50DAfOAgAAKjAA= Date: Thu, 26 Feb 2015 15:22:18 +0000 Message-ID: <1858CC48-3A2B-409C-9466-27B55D4EE155@telefonica.com> References: <54EF3151.5000802@joelhalpern.com> In-Reply-To: <54EF3151.5000802@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.13.70.231] authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0621; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB0621; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(199003)(252514010)(189002)(377454003)(24454002)(62966003)(110136001)(106116001)(122556002)(40100003)(450100001)(77156002)(106356001)(2351001)(76176999)(50986999)(107886001)(54356999)(2501003)(36756003)(86362001)(105586002)(92566002)(230783001)(16236675004)(83716003)(82746002)(2900100001)(2950100001)(68736005)(19580395003)(102836002)(19580405001)(15975445007)(97736003)(101416001)(46102003)(87936001)(33656002)(19617315012)(2656002)(64706001)(66066001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB0621; H:DB4PR06MB0624.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_1858CC483A2B409C946627B55D4EE155telefonicacom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2015 15:22:18.6482 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR06MB0621 X-OriginatorOrg: telefonica.com X-TM-AS-MML: No Archived-At: Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 26 Feb 2015 15:22:28 -0000 --_000_1858CC483A2B409C946627B55D4EE155telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I support it as well, On 26 Feb 2015, at 15:44 , Joel M. Halpern > wrote: Thank you Jim. Support as a co-author. Yours, Joel On 2/26/15 7:47 AM, Jim Guichard (jguichar) wrote: Greetings WG: The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/) has recently been reissued. ... With that said, the chairs are calling for WG adoption of draft-quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 weeks ending 3/12/2015. ... _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego.r.lopez@telefonica.com Tel: +34 913 129 041 Mobile: +34 682 051 091 ---------------------------------- ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=C3=B3n privilegiada o confidencial y es para uso exc= lusivo de la persona o entidad de destino. Si no es usted. el destinatario = indicado, queda notificado de que la lectura, utilizaci=C3=B3n, divulgaci= =C3=B3n y/o copia sin autorizaci=C3=B3n puede estar prohibida en virtud de = la legislaci=C3=B3n vigente. Si ha recibido este mensaje por error, le roga= mos que nos lo comunique inmediatamente por esta misma v=C3=ADa y proceda a= su destrucci=C3=B3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura= , utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem autoriza= =C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o vigent= e. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imedi= atamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o --_000_1858CC483A2B409C946627B55D4EE155telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: <5DEC7C745B659C4FB582AE9E1C3B120F@eurprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable I support it as well,

    On 26 Feb 2015, at 15:44 , Joel M. Halpern <jmh@joelhalpern.com> wrote:

    Thank you Jim.
    Support as a co-author.

    Yours,
    Joel

    On 2/26/15 7:47 AM, Jim Guichard (jguichar) wrote:
    Greetings WG:

    The document draft-quinn-sfc-nsh-07
    (https://= datatracker.ietf.org/doc/draft-quinn-sfc-nsh/) has recently
    been reissued. ...

    With that said, the chairs are calling for WG ado= ption of
    draft-quinn-sfc-nsh-07 as a WG document. The call for adoption will run
    for 2 weeks ending 3/12/2015.
    ...

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

    --
    "Esta vez no fallaremos, Doctor Infierno"

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

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



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

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

    Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=C3=A1= rio, pode conter informa=C3=A7=C3=A3o privilegiada ou confidencial e =C3=A9= para uso exclusivo da pessoa ou entidade de destino. Se n=C3=A3o =C3=A9 vo= ssa senhoria o destinat=C3=A1rio indicado, fica notificado de que a leitura, utiliza=C3=A7=C3=A3o, divulga=C3=A7=C3=A3o e/ou c=C3=B3pia sem au= toriza=C3=A7=C3=A3o pode estar proibida em virtude da legisla=C3=A7=C3=A3o = vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique= imediatamente por esta mesma via e proceda a sua destrui=C3=A7=C3=A3o
     --_000_1858CC483A2B409C946627B55D4EE155telefonicacom_-- From nobody Thu Feb 26 07:41:26 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88161A0250 for ; Thu, 26 Feb 2015 07:41:25 -0800 (PST) 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 mwX0YuElI6Wm for ; Thu, 26 Feb 2015 07:41:23 -0800 (PST) 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 374411A01F9 for ; Thu, 26 Feb 2015 07:41:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7422; q=dns/txt; s=iport; t=1424965283; x=1426174883; h=from:to:subject:date:message-id:mime-version; bh=+Xvyu+Sihl9nL72t7omr9fHFSruh6/8xH5YTzuA7A9I=; b=VOxBpoS6Jb1kVc3zajVEo6d+QcIfOkIaS0J/LFK/t1jD7+DVVlWSbi9C I/5FeNkrMPPK9XBLMrRl50rle6djSsoFKUMHuIMQp9MWew01uv5jdVcXO A7CbhuCt4YyGHnkqISCemaKURDT6XpAR+RCpboDQEh1AUaaOVeJ2AIjSA c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A2BwAnPu9U/5JdJa1bgj9DUloEskaNSIFzhXACgSRNAQEBAQEBfIQPAQIEHW4BCBEDAQIoORQJCgQBEogvDdZTAQEBBwEBAQEBHYsThAwRAT8NCoQsBY12gXmDYIVlgRs5gmWPECOCAhyBUG+BCzl/AQEB X-IronPort-AV: E=Sophos;i="5.09,653,1418083200"; d="scan'208,217";a="399433898" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-4.cisco.com with ESMTP; 26 Feb 2015 15:41:22 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t1QFfMsA021605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Feb 2015 15:41:22 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.43]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 09:41:22 -0600 From: "Surendra Kumar (smkumar)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] WG call for adoption of draft-quinn-sfc-nsh Thread-Index: AQHQUdqqZDObBxbiIUWmIP9lX1xWpw== Date: Thu, 26 Feb 2015 15:41:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.24.66.42] Content-Type: multipart/alternative; boundary="_000_D1147E8F17691smkumarciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 26 Feb 2015 15:41:25 -0000 --_000_D1147E8F17691smkumarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Support as a co-author. Surendra. From: "Jim Guichard (jguichar)" > Date: Thursday, February 26, 2015 at 4:47 AM To: "sfc@ietf.org" > Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh Greetings WG: The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft= -quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc= -sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined = the NSH document so that the WG can focus on a single encapsulation documen= t going forward. This new version of NSH includes an open items section bas= ed on discussion between co-authors and members of the list. The WG will wo= rk through this list (and any other issues that need to be added) over the = next weeks. We appreciate and recognize the hard work of both the NSH and S= CH authors in pushing the SFC encapsulation work forward. With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n= sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3= /12/2015. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG=92s decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Jim & Thomas --_000_D1147E8F17691smkumarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
    Support as a co-author.

    Surendra.

    From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
    Date: Thursday, February 26, 2015 a= t 4:47 AM
    To: "sfc@ietf.org" <sfc@ietf.= org>
    Subject: [sfc] WG call for adoption= of draft-quinn-sfc-nsh

    Greetings WG:

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/dra= ft-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draf= t-zhang-sfc-sch/) have joined the NSH document so that the WG can focus= on a single encapsulation document going forward. This new version of NSH includes an open items secti= on based on discussion between co-authors and members of the list. The WG w= ill work through this list (and any other issues that need to be added) ove= r the next weeks. We appreciate and recognize the hard work of both the NSH and SCH authors in pushing the= SFC encapsulation work forward.

    With that said, the chairs are calling for WG adoption of draft= -quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 we= eks ending 3/12/2015.

    Please note t= hat this is a call for adoption, and not a last call for content of the doc= ument. Adopting a WG document simply means that the WG will focus its effor= ts on that particular draft going forward, and use that document for resolving open issues and documenting the WG=92s= decisions.

    Please indica= te whether you support adoption for not, and if not why. Issues you have wi= th the current document itself can also be raised, but they should be raise= d in the context of what should be changed in the document going forward, rather than a pre-condition for adoption.&n= bsp;

    Finally, now = is also a good time to poll for knowledge of any IPR that applies to this d= raft, in line with the IPR disclosure obligations for WG participants (see = RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please respond to this em= ail (to the chairs) whether or not you are aware of any relevant IPR.

    Jim & Thomas
     --_000_D1147E8F17691smkumarciscocom_-- From nobody Thu Feb 26 07:50:26 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E9F1A0461 for ; Thu, 26 Feb 2015 07:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ndQaxyqmLqvg for ; Thu, 26 Feb 2015 07:50:23 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.149]) by ietfa.amsl.com (Postfix) with ESMTP id 99AF51A01F9 for ; Thu, 26 Feb 2015 07:50:23 -0800 (PST) Received: from [85.158.139.163] by server-13.bemta-5.messagelabs.com id 60/48-02801-EB04FE45; Thu, 26 Feb 2015 15:50:22 +0000 X-Env-Sender: walter.haeffner@vodafone.com X-Msg-Ref: server-15.tower-188.messagelabs.com!1424965821!7629991!1 X-Originating-IP: [195.232.224.79] X-StarScan-Received: X-StarScan-Version: 6.13.4; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32327 invoked from network); 26 Feb 2015 15:50:21 -0000 Received: from mailout10.vodafone.com (HELO mailout10.vodafone.com) (195.232.224.79) by server-15.tower-188.messagelabs.com with SMTP; 26 Feb 2015 15:50:21 -0000 Received: from mailint10.vodafone.com (localhost [127.0.0.1]) by mailout10.vodafone.com (Postfix) with ESMTP id A229E3002D6 for ; Thu, 26 Feb 2015 16:50:21 +0100 (CET) Received: from VOEXC05W.internal.vodafone.com (mail5.nl.mx.vodafone.com [145.230.101.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint10.vodafone.com (Postfix) with ESMTPS id 956EE3002B8; Thu, 26 Feb 2015 16:50:21 +0100 (CET) Received: from VOEXC20W.internal.vodafone.com (145.230.103.125) by VOEXC05W.internal.vodafone.com (145.230.101.25) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 26 Feb 2015 16:50:21 +0100 Received: from VOEXM20W.internal.vodafone.com ([169.254.4.248]) by VOEXC20W.internal.vodafone.com ([145.230.103.125]) with mapi id 14.03.0224.002; Thu, 26 Feb 2015 16:50:20 +0100 From: "Haeffner, Walter, Vodafone DE" To: Jim Guichard , "sfc@ietf.org" Thread-Topic: [sfc] WG call for adoption of draft-quinn-sfc-nsh Thread-Index: AQHQUdvsiTFsg2OwtkGaBW0BUV1kLw== Date: Thu, 26 Feb 2015 15:50:20 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_C8C844F84E550E43865561FAE10471854C5E4290VOEXM20Winterna_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 26 Feb 2015 15:50:26 -0000 --_000_C8C844F84E550E43865561FAE10471854C5E4290VOEXM20Winterna_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Support nsh draft doc - Walter Gesendet mit meinem HTC ----- Reply message ----- Von: "Jim Guichard (jguichar)" An: "sfc@ietf.org" Betreff: [sfc] WG call for adoption of draft-quinn-sfc-nsh Datum: Do., Feb 26, 2015 13:47 Greetings WG: The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft= -quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc= -sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined = the NSH document so that the WG can focus on a single encapsulation documen= t going forward. This new version of NSH includes an open items section bas= ed on discussion between co-authors and members of the list. The WG will wo= rk through this list (and any other issues that need to be added) over the = next weeks. We appreciate and recognize the hard work of both the NSH and S= CH authors in pushing the SFC encapsulation work forward. With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n= sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3= /12/2015. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG=92s decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Jim & Thomas --_000_C8C844F84E550E43865561FAE10471854C5E4290VOEXM20Winterna_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    Support nsh draft doc - Walter

    Gesendet mit meinem HTC

    ----- Reply message -----
    Von: "Jim Guichard (jguichar)" <jguichar@cisco.com>
    An: "sfc@ietf.org" <sfc@ietf.org>
    Betreff: [sfc] WG call for adoption of draft-quinn-sfc-nsh
    Datum: Do., Feb 26, 2015 13:47

    Greetings WG:

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft-qui= nn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sf= c-sch/) have joined the NSH document so that the WG can focus on a sing= le encapsulation document going forward. This new version of NSH includes an open items section based on dis= cussion between co-authors and members of the list. The WG will work throug= h this list (and any other issues that need to be added) over the next week= s. We appreciate and recognize the hard work of both the NSH and SCH authors in pushing the SFC encapsulation= work forward.

    With that said, the chairs are calling for WG adoption of draft-quinn= -sfc-nsh-07 as a WG document. The call for adoption will run for 2 weeks en= ding 3/12/2015.

    Please note tha= t this is a call for adoption, and not a last call for content of the docum= ent. Adopting a WG document simply means that the WG will focus its efforts= on that particular draft going forward, and use that document for resolving open issues and documenting the WG=92s= decisions.

    Please indicate= whether you support adoption for not, and if not why. Issues you have with= the current document itself can also be raised, but they should be raised = in the context of what should be changed in the document going forward, rather than a pre-condition for adoption.&n= bsp;

    Finally, now is= also a good time to poll for knowledge of any IPR that applies to this dra= ft, in line with the IPR disclosure obligations for WG participants (see RF= Cs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please respond to this em= ail (to the chairs) whether or not you are aware of any relevant IPR.

    Jim & Thomas
    --_000_C8C844F84E550E43865561FAE10471854C5E4290VOEXM20Winterna_-- From nobody Thu Feb 26 08:14: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 28FCF1A8756 for ; Thu, 26 Feb 2015 08:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZ6l8XmObYhP for ; Thu, 26 Feb 2015 08:14:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AEB61A8734 for ; Thu, 26 Feb 2015 08:14:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPQ96218; Thu, 26 Feb 2015 16:14:22 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Feb 2015 16:14:21 +0000 Received: from SZXEMA503-MBX.china.huawei.com ([169.254.5.5]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Fri, 27 Feb 2015 00:14:14 +0800 From: Xingjun Chu To: Reinaldo Penno , "sfc-dev@lists.opendaylight.org" Thread-Topic: SFC ODL IETF-92 Hackton Thread-Index: AQHQUHthuNvtImjaiE+daliE6BBJC50DHQpg Date: Thu, 26 Feb 2015 16:14:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.70.227] Content-Type: multipart/alternative; boundary="_000_A80FD691ED8CBE458269B48D68F2E45E0B038F44SZXEMA503MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] SFC ODL IETF-92 Hackton 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, 26 Feb 2015 16:14:27 -0000 --_000_A80FD691ED8CBE458269B48D68F2E45E0B038F44SZXEMA503MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't see SFC explicitly listed on the agenda as defined in the event lin= k. Regards Xingjun From: sfc-dev-bounces@lists.opendaylight.org [mailto:sfc-dev-bounces@lists.= opendaylight.org] On Behalf Of Reinaldo Penno Sent: Tuesday, February 24, 2015 4:46 PM To: sfc-dev@lists.opendaylight.org; Charles Eckel (eckelcu) Cc: sfc@ietf.org Subject: [sfc-dev] SFC ODL IETF-92 Hackton Event details: https://developer.cisco.com/site/ietf-hackathon Link to register: https://www.ietf.org/meeting/92/hackathon-signup.html SFC Program: Services Function Chaining in Opendaylight (Reinaldo Penno, Jim Guichard) SFC ODL page: https://wiki.opendaylight.org/view/Service_Function_Chaining:= Main Strongly recommend watching the webex titled "Reinaldo SFC demo" at the bot= tom of the page above. * Introduction to SFC architecture in Opendaylight * Architecture of SFC Agent and data plane * Work items will cover both control and data plane: * SFC Agent auto-provisioning (SF/SFF configuration-less deployment= s) (Python) o SFC Agent Yang models (Yang) * SFC-OVS integration. (Java) * SFC/NSH Traceroute (Python, Standards work) * SFC Classifier (Python, Linux IPtables) * Netconf integration (Java) * Review of SFC Yang models and feedback into ODL (Yang, standards) * Implementation of Variable Length NSH packets (MD Type 02) in the= data plane (Python) We welcome comments on the program and suggestions Thanks, Reinaldo --_000_A80FD691ED8CBE458269B48D68F2E45E0B038F44SZXEMA503MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I don’t see SFC exp= licitly listed on the agenda as defined in the event link.

     <= /p>

    Regards=

    Xingjun=

     <= /p>

    From: sfc-dev-= bounces@lists.opendaylight.org [mailto:sfc-dev-bounces@lists.opendaylight.o= rg] On Behalf Of Reinaldo Penno
    Sent: Tuesday, February 24, 2015 4:46 PM
    To: sfc-dev@lists.opendaylight.org; Charles Eckel (eckelcu)
    Cc: sfc@ietf.org
    Subject: [sfc-dev] SFC ODL IETF-92 Hackton

     

    Event details: 
    https://developer.cisco.com/site/ietf-hackathon
    Link to register: https://www.ietf.org/meeting/92/hack=
athon-signup.html
    SFC Program:
    Services Function Chainin=
g in Opendaylight (Reinaldo Penno, Jim Guichard)
     
     <=
/pre>

    Strongly recommend&n=
bsp;watching the webex titled "Reinaldo SFC demo” at the bottom =
of the page above.
    =
· =
        <=
span style=3D"font-size:10.5pt;color:#525252">Introduction to SFC architect=
ure in Opendaylight 
    =
· =
        <=
span style=3D"font-size:10.5pt;color:#525252">Architecture of SFC Agent and=
 data plane
    =
·=
   &n=
bsp;     Work items will cover both control and data plane:=

    =
· =
        <=
span style=3D"font-size:10.5pt;color:#525252">SFC Agent auto-provisioning (=
SF/SFF configuration-less deployments) (Python)
    =
o    SFC Agent=
 Yang models (Yang)
    =
· =
        <=
span style=3D"font-size:10.5pt;color:#525252">SFC-OVS integration. (Java)
    =
· =
        <=
span style=3D"font-size:10.5pt;color:#525252">SFC/NSH Traceroute (Python, S=
tandards work)
    =
· &n=
bsp;       SFC Classifier (Python, Li=
nux IPtables)=

    =
· &n=
bsp;       Netconf integration (Java)
    =
· &n=
bsp;       Review of SFC Yang models and f=
eedback into ODL (Yang, standards)
    =
· &n=
bsp;       Implementation of Variable Length=
 NSH packets (MD Type 02) in the data plane (Python)

     
    We welcome comments on the program and sugges=
tions
     
    Thanks,
     
    Reinaldo
     
    --_000_A80FD691ED8CBE458269B48D68F2E45E0B038F44SZXEMA503MBXchi_-- From nobody Thu Feb 26 08:17:44 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 055E91A8754 for ; Thu, 26 Feb 2015 08:17:43 -0800 (PST) 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 AH-KlPRMc_yO for ; Thu, 26 Feb 2015 08:17:41 -0800 (PST) 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 C09AC1A1BD1 for ; Thu, 26 Feb 2015 08:17:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19095; q=dns/txt; s=iport; t=1424967460; x=1426177060; h=from:to:cc:subject:date:message-id:mime-version; bh=Jn2hbDDIe9t34IZuNF51Krc5aQWLaX1MBvsLpBn0hkI=; b=cr7DjdFm8j6zNcICUkWHcmEdQB0GTwDlj3bdcg+S4CXvIm1pP129WKIH NvweRI5NWGQjDsrzHN1tRU1co0WNWriYJI44YwEVUOzSrLywQPlejaI8c ZK5zvYniHRytR0qLQFxnP79j6CWPJN6I15sUGYnM/18+Ujn4G3F9epNIx Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CUBQCXRu9U/5ldJa1bgj9DUloEwXcBCYVwAoEkTQEBAQEBAXyEDwEBAQQBAipMEgEIEQECAQEBIQcoBwoUAwYKBAENBYgbAxEN0RsNhUABAQEBAQEBAQEBAQEBAQEBAQEBAQETBIsTgkSBSBEBLBMNBAYDhCkFj2+DYINGWYFGjUCGCSODbm8BgQo5fwEBAQ X-IronPort-AV: E=Sophos;i="5.09,653,1418083200"; d="scan'208,217";a="127168134" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP; 26 Feb 2015 16:17:40 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t1QGHdXR017861 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Feb 2015 16:17:39 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.159]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 10:17:39 -0600 From: "Jim Guichard (jguichar)" To: Xingjun Chu , Reinaldo Penno , "sfc-dev@lists.opendaylight.org" Thread-Topic: [sfc-dev] SFC ODL IETF-92 Hackton Thread-Index: AQHQUd+9eO+LH+R8FkmKaWxebHK3oQ== Date: Thu, 26 Feb 2015 16:17:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.98.43.180] Content-Type: multipart/alternative; boundary="_000_D114B124865Cjguicharciscocom_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] [sfc-dev] SFC ODL IETF-92 Hackton 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, 26 Feb 2015 16:17:43 -0000 --_000_D114B124865Cjguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Xingjun, You must have missed Charles=92s other email that stated: =93We are still in the process of updating the event information and regist= ration pages to include SFC. If you go to register in the meantime and do n= ot see SFC listed as a technology, you can enter =93SFC=94 in the =93Other= =94 area=94. From: Xingjun Chu > Date: Thursday, February 26, 2015 at 11:14 AM To: Reinaldo Penno >, "sfc-dev@= lists.opendaylight.org" > Cc: "sfc@ietf.org" > Subject: Re: [sfc-dev] SFC ODL IETF-92 Hackton I don=92t see SFC explicitly listed on the agenda as defined in the event l= ink. Regards Xingjun From: sfc-dev-bounces@lists.opendaylight.org [mailto:sfc-dev-bounces@lists.opendaylight.org] On Behalf = Of Reinaldo Penno Sent: Tuesday, February 24, 2015 4:46 PM To: sfc-dev@lists.opendaylight.org; = Charles Eckel (eckelcu) Cc: sfc@ietf.org Subject: [sfc-dev] SFC ODL IETF-92 Hackton Event details: https://developer.cisco.com/site/ietf-hackathon Link to register: https://www.ietf.org/meeting/92/hackathon-signup.html SFC Program: Services Function Chaining in Opendaylight (Reinaldo Penno, Jim Guichard) SFC ODL page: https://wiki.opendaylight.org/view/Service_Function_Chaining:= Main Strongly recommend watching the webex titled "Reinaldo SFC demo=94 at the b= ottom of the page above. =B7 Introduction to SFC architecture in Opendaylight =B7 Architecture of SFC Agent and data plane =B7 Work items will cover both control and data plane: =B7 SFC Agent auto-provisioning (SF/SFF configuration-less deployme= nts) (Python) o SFC Agent Yang models (Yang) =B7 SFC-OVS integration. (Java) =B7 SFC/NSH Traceroute (Python, Standards work) =B7 SFC Classifier (Python, Linux IPtables) =B7 Netconf integration (Java) =B7 Review of SFC Yang models and feedback into ODL (Yang, standard= s) =B7 Implementation of Variable Length NSH packets (MD Type 02) in t= he data plane (Python) We welcome comments on the program and suggestions Thanks, Reinaldo --_000_D114B124865Cjguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <603E3716AEB0484A8536F357816C4117@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    Hi Xingjun,

    You must have missed Charles=92s other email that stated:

    =93We are still in the process of updating the event information and r= egistration pages to include SFC. If you go to register in the meantime and= do not see SFC listed as a technology, you can enter =93SFC=94 in the =93O= ther=94 area=94.

    From: Xingjun Chu <Xingjun.Chu@huawei.com>
    Date: Thursday, February 26, 2015 a= t 11:14 AM
    To: Reinaldo Penno <rapenno@gmail.com>, "sfc-dev@lists.opendaylight.org" &= lt;sfc-dev@lists.opendayl= ight.org>
    Cc: "sfc@ietf.org" <sfc@ietf.= org>
    Subject: Re: [sfc-dev] SFC ODL IETF= -92 Hackton

    I don=92t see SFC explicitly listed= on the agenda as defined in the event link.

     

    Regards

    Xingjun

     

    From: sfc-dev-bounces@l= ists.opendaylight.org [mailto:sfc-dev-bounces@lists.opendaylight.org] On Behalf Of Reinaldo Penno
    Sent: Tuesday, February 24, 2015 4:46 PM
    To: sfc-dev@lists.= opendaylight.org; Charles Eckel (eckelcu)
    Cc: sfc@ietf.org
    Subject: [sfc-dev] SFC ODL IETF-92 Hackton

     

    Event details: 
    ht=
tps://developer.cisco.com/site/ietf-hackathon
    Link to register: https://www.ietf.org/meeting/92/hackathon-signup.html=

    SFC Program:
    Services Function Chainin=
g in Opendaylight (Reinaldo Penno, Jim Guichard)<=
/span>
     
     <=
/pre>

    Strongly recommend&n=
bsp;watching the webex titled "Reinaldo SFC demo=94 at the bottom of t=
he page above.
    =B7Introduction to S=
FC architecture in Opendaylight 
    =B7Architecture of S=
FC Agent and data plane
    =B7   &nb=
sp;     Work items will cover both control and data pl=
ane:
    =B7SFC Agent auto-pr=
ovisioning (SF/SFF configuration-less deployments) (Python)
    o &nbs=
p;  SFC Agent Yang models (Yang)
    =B7SFC-OVS integrati=
on. (Java)
    =B7SFC/NSH Tracerout=
e (Python, Standards work)
    =B7 &n=
bsp;       =B7 &n=
bsp;       =B7 &n=
bsp;       =B7 &n=
bsp;        Each node in the chain selects the context for processing and the next =
hop on the basis of BOTH path ID and Index, while decrementing the index fo=
r the next hop.

That behavior supports spiraling.



-Dave


-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
Sent: Thursday, February 26, 2015 10:02 AM
To: mohamed.boucadair@orange.com; sfc@ietf.org
Cc: Ben Wright (Ben.Wright@metaswitch.com)
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals

There are two different aspects of Spirals.

One of the two aspects is enabling a packet that repeatedly arrives at=20
the same SFF to get the correct services provided each time it arrives,=20
and to go to the correct next SFF each time it arrives.  The Service=20
Path Index, used by the SFF to select service functions and next SFF,=20
provides that capability.

The other aspect is how the Service Functions themselves handle spirals.=20
  To a large degree, that depends upon the individual service function.=20
  I normally assume that it would use packet context (as described in=20
the text you quote) to determine what to do.

Since I would prefer that service functions are independent of the=20
underlying service function chaining infrastructure, and are not=20
sensitive to how many functions are before or after them in the chain, I=20
would personally prefer that they not use the path index for that.  I=20
would recommend that if the packet does not carry enough context that=20
the service function could and should use metadata to carry its needed=20
state information.  But neither I personally nor the SFC Working Group=20
get to tell folks how to build their service functions.  So they may=20
come up with other methods for addressing their needs.  Which is also fine.

Thus, I would not expect this document to discuss how service functions=20
themselves handle revisiting.  But metadata clearly allows for a range=20
of behaviors that will work.  And the path index handles the SFF needs=20
relative to spirals, which is what we need to handle.

Yours,
Joel

On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote:
> Re-,
>
> Spiral is not mentioned in the draft, but SF loop is.
>
> I'm asking the question because I don't get from the draft how spirals co=
uld work (that is a SF invoked several time in the context of the same SFC)=
.
>
> Before proposing text, I would like to understand first how it works. If =
you can provide an example, this will be even great.
>
> Thank you.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> Envoy=E9 : jeudi 26 f=E9vrier 2015 15:41
>> =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org
>> Cc : Ben Wright (Ben.Wright@metaswitch.com)
>> Objet : Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>>
>> The SF Spirals requirement is one of the key drivers for the index.  The
>> index allows one to tell where one is in the spiral, and also to break a
>> loop if one has a loop instead of a spiral.
>>
>> Is there text that we could add that would help make this clear, since
>> your earlier question about the path index suggests that it is not as
>> clear as it should be?
>>
>> Yours,
>> Joel
>>
>> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote:
>>> Hi Paul, all,
>>>
>>> There were a discussion in the mailing list
>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html) that
>>> led to defining what is meant by SF Spirals: (below is provided an
>>> excerpt from
>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where th=
e
>>> conclusions of that discussion were recorded)
>>>
>>> "   o  Service Function Spiral: denotes a Service Function Chain in
>> which
>>>
>>>         data is handled by a Service Function, forwarded onwards, and
>>>
>>>         arrives once again at that Service Function.
>>>
>>>         *  Note that some Service Functions support built-in functions =
to
>>>
>>>            accommodate spirals; these service-specific functions may
>>>
>>>            require that the data received in a spiral should differ in =
a
>>>
>>>            way that will result in a different processing decision than
>>>
>>>            the original data.  This document does not make such
>>>
>>>            assumption.
>>>
>>>         *  A Service Function Chain may involve one or more Service
>>>
>>>            Function Spirals.
>>>
>>>         *  Unlike Service Function loop, spirals are not considered as
>>>
>>>            errors."
>>>
>>> And this companion requirement:
>>>
>>> "               A.  Service Functions MAY be invoked multiple times in
>>>
>>>                      the same Service Function Chain (denoted as SF
>>>
>>>                      Spiral), but the solution MUST prevent infinite
>>>
>>>                      forwarding loops. =BB
>>>
>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is met.
>>>
>>> Can you please clarify whether this is supported and how?
>>>
>>> Thank you.
>>>
>>> Cheers,
>>>
>>> Med
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 Thu Feb 26 08:22: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 3A2641A871A for ; Thu, 26 Feb 2015 08:22:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.896
X-Spam-Level: 
X-Spam-Status: No, score=0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_HELO_PASS=-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 qbnKMXIv-j2A for ; Thu, 26 Feb 2015 08:22:10 -0800 (PST)
Received: from lucidvision.com (unknown [50.255.148.178]) by ietfa.amsl.com (Postfix) with ESMTP id A23C61A0264 for ; Thu, 26 Feb 2015 08:22:10 -0800 (PST)
Received: from [192.168.1.134] (unknown [50.255.148.177]) by lucidvision.com (Postfix) with ESMTP id 3B9702F5737C; Thu, 26 Feb 2015 11:22:10 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_3BCCE379-BF78-4C69-B9A2-AF1EC7723572"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: "Thomas D. Nadeau" 
In-Reply-To: 
Date: Thu, 26 Feb 2015 11:22:09 -0500
Message-Id: 
References: 
To: Guichard Jim 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "sfc@ietf.org" 
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh
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, 26 Feb 2015 16:22:16 -0000

--Apple-Mail=_3BCCE379-BF78-4C69-B9A2-AF1EC7723572
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

+1 to accept but I would recommend pruning down the contributor list on =
the front page to a few editors.

I do not know of any IPR.

=97Tom


> On Feb 26, 2015:7:47 AM, at 7:47 AM, Jim Guichard (jguichar) =
 wrote:
>=20
> Greetings WG:
>=20
> The document draft-quinn-sfc-nsh-07 =
(https://datatracker.ietf.org/doc/draft-quinn-sfc-nsh =
/) has recently =
been reissued. The authors of draft-zhang-sfc-sch-03 =
(http://datatracker.ietf.org/doc/draft-zhang-sfc-sch =
/) have joined the =
NSH document so that the WG can focus on a single encapsulation document =
going forward. This new version of NSH includes an open items section =
based on discussion between co-authors and members of the list. The WG =
will work through this list (and any other issues that need to be added) =
over the next weeks. We appreciate and recognize the hard work of both =
the NSH and SCH authors in pushing the SFC encapsulation work forward.
>=20
> With that said, the chairs are calling for WG adoption of =
draft-quinn-sfc-nsh-07 as a WG document. The call for adoption will run =
for 2 weeks ending 3/12/2015.
>=20
> Please note that this is a call for adoption, and not a last call for =
content of the document. Adopting a WG document simply means that the WG =
will focus its efforts on that particular draft going forward, and use =
that document for resolving open issues and documenting the WG=92s =
decisions.
>=20
> Please indicate whether you support adoption for not, and if not why. =
Issues you have with the current document itself can also be raised, but =
they should be raised in the context of what should be changed in the =
document going forward, rather than a pre-condition for adoption.=20
>=20
> Finally, now is also a good time to poll for knowledge of any IPR that =
applies to this draft, in line with the IPR disclosure obligations for =
WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). =
If you are listed as a document author please respond to this email (to =
the chairs) whether or not you are aware of any relevant IPR.
>=20
> Jim & Thomas
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc


--Apple-Mail=_3BCCE379-BF78-4C69-B9A2-AF1EC7723572
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

+1 to accept but I would recommend pruning down the =
contributor list on the front page to a few editors.

    I do not know of any IPR.

    =97Tom


    On =
Feb 26, 2015:7:47 AM, at 7:47 AM, Jim Guichard (jguichar) <jguichar@cisco.com> =
wrote:

    




    

    

    Greetings WG:
    


    

    

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/) =
has recently been
 reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) =
have joined the NSH document so that the WG can focus on a single =
encapsulation document
 going forward. This new version of NSH includes an open =
items section based on discussion between co-authors and members of =
the list. The WG will work through this list (and any other issues that =
need to be added) over the next weeks. We appreciate
 and recognize the hard work of both the NSH and SCH authors in pushing =
the SFC encapsulation work forward.
    


    

    

    With that said, the chairs are calling for WG adoption =
of draft-quinn-sfc-nsh-07 as a WG document. The call for adoption will =
run for 2 weeks ending 3/12/2015.
    


    

    

    Please note that this is a call =
for adoption, and not a last call for content of the document. Adopting =
a WG document simply means that the WG will focus its efforts on that =
particular draft going forward,
 and use that document for resolving open issues and documenting the =
WG=92s decisions.
    


    

    

    Please indicate whether you =
support adoption for not, and if not why. Issues you have with the =
current document itself can also be raised, but they should be raised in =
the context of what should be changed
 in the document going forward, rather than a pre-condition for =
adoption. 
    


    

    

    Finally, now is also a good time =
to poll for knowledge of any IPR that applies to this draft, in line =
with the IPR disclosure obligations for WG participants (see RFCs 3979, =
4879, 3669 and 5378 for more
 details). If you are listed as a document author please respond to this =
email (to the chairs) whether or not you are aware of any relevant =
IPR.
    

    


    

    

    Jim & Thomas
    

    

    

    

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

    =

--Apple-Mail=_3BCCE379-BF78-4C69-B9A2-AF1EC7723572--


From nobody Thu Feb 26 08: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 6359E1A87BF for ; Thu, 26 Feb 2015 08:30:34 -0800 (PST)
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 OcnBJuTsxbQu for ; Thu, 26 Feb 2015 08:30:32 -0800 (PST)
Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E461A03F9 for ; Thu, 26 Feb 2015 08:30:32 -0800 (PST)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0224.002; Thu, 26 Feb 2015 08:30:31 -0800
From: Ron Parker 
To: Dave Dolson , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" 
Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
Thread-Index: AdBRyhUadMfMQp0TQVyP+AHUYniSlAASzvcAAABleoAAAFj2AAACvdgAABC+XSA=
Date: Thu, 26 Feb 2015 16:30:30 +0000
Message-ID: 
References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3584.2080005@joelhalpern.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.203.66.100]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" 
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
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, 26 Feb 2015 16:30:34 -0000

Hi, Dave.

I agree that on the wire, this is the way it would work.  =20

But, when composing the chain, it seems like information would be lacking i=
f a chain were expressed simply as {SF-foo, SF-bar, SF-foo, SF-foobar}.    =
It is completely implicit that since SF-foo appears twice, it perhaps shoul=
d perform some different duty when index =3D 0 vs when index =3D 2.   =20

At first, I thought that an alternative way to handle this would be to use =
multiple logical identities for SF-foo.  In this case, the chain above woul=
d be expressed as {SF-foo-first-behavior, SF-bar, SF-foo-second-behavior, S=
F-foobar}.   But, the problem here is selecting the RSP, assuming that SF-f=
oo has multiple instances.   Nothing in this second flavor of chain says th=
at the same instance of SF-foo-* must be selected to satisfy SF-foo-first-b=
ehavior and SF-foo-second-behavior (which may not be required, but should b=
e possible to force as such).

I guess what I'm saying is that spiraling has a subtlety to it that isn't y=
et adequately addressed and that I don't have a specific proposal to solve =
it, either.

   Ron


-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Thursday, February 26, 2015 11:21 AM
To: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org
Cc: Ben Wright (Ben.Wright@metaswitch.com)
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals

If I may try to put it simply, I've always thought of it this way:
--> Each node in the chain selects the context for processing and the next =
hop on the basis of BOTH path ID and Index, while decrementing the index fo=
r the next hop.

That behavior supports spiraling.



-Dave


-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
Sent: Thursday, February 26, 2015 10:02 AM
To: mohamed.boucadair@orange.com; sfc@ietf.org
Cc: Ben Wright (Ben.Wright@metaswitch.com)
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals

There are two different aspects of Spirals.

One of the two aspects is enabling a packet that repeatedly arrives at the =
same SFF to get the correct services provided each time it arrives, and to =
go to the correct next SFF each time it arrives.  The Service Path Index, u=
sed by the SFF to select service functions and next SFF, provides that capa=
bility.

The other aspect is how the Service Functions themselves handle spirals.=20
  To a large degree, that depends upon the individual service function.=20
  I normally assume that it would use packet context (as described in the t=
ext you quote) to determine what to do.

Since I would prefer that service functions are independent of the underlyi=
ng service function chaining infrastructure, and are not sensitive to how m=
any functions are before or after them in the chain, I would personally pre=
fer that they not use the path index for that.  I would recommend that if t=
he packet does not carry enough context that the service function could and=
 should use metadata to carry its needed state information.  But neither I =
personally nor the SFC Working Group get to tell folks how to build their s=
ervice functions.  So they may come up with other methods for addressing th=
eir needs.  Which is also fine.

Thus, I would not expect this document to discuss how service functions the=
mselves handle revisiting.  But metadata clearly allows for a range of beha=
viors that will work.  And the path index handles the SFF needs relative to=
 spirals, which is what we need to handle.

Yours,
Joel

On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote:
> Re-,
>
> Spiral is not mentioned in the draft, but SF loop is.
>
> I'm asking the question because I don't get from the draft how spirals co=
uld work (that is a SF invoked several time in the context of the same SFC)=
.
>
> Before proposing text, I would like to understand first how it works. If =
you can provide an example, this will be even great.
>
> Thank you.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : jeudi 26=20
>> f=E9vrier 2015 15:41 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Cc :=
=20
>> Ben Wright (Ben.Wright@metaswitch.com) Objet : Re: [sfc]=20
>> draft-quinn-sfc-nsh: Support of SF Spirals
>>
>> The SF Spirals requirement is one of the key drivers for the index. =20
>> The index allows one to tell where one is in the spiral, and also to=20
>> break a loop if one has a loop instead of a spiral.
>>
>> Is there text that we could add that would help make this clear,=20
>> since your earlier question about the path index suggests that it is=20
>> not as clear as it should be?
>>
>> Yours,
>> Joel
>>
>> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote:
>>> Hi Paul, all,
>>>
>>> There were a discussion in the mailing list
>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html)=20
>>> that led to defining what is meant by SF Spirals: (below is provided=20
>>> an excerpt from
>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where=20
>>> the conclusions of that discussion were recorded)
>>>
>>> "   o  Service Function Spiral: denotes a Service Function Chain in
>> which
>>>
>>>         data is handled by a Service Function, forwarded onwards,=20
>>> and
>>>
>>>         arrives once again at that Service Function.
>>>
>>>         *  Note that some Service Functions support built-in=20
>>> functions to
>>>
>>>            accommodate spirals; these service-specific functions may
>>>
>>>            require that the data received in a spiral should differ=20
>>> in a
>>>
>>>            way that will result in a different processing decision=20
>>> than
>>>
>>>            the original data.  This document does not make such
>>>
>>>            assumption.
>>>
>>>         *  A Service Function Chain may involve one or more Service
>>>
>>>            Function Spirals.
>>>
>>>         *  Unlike Service Function loop, spirals are not considered=20
>>> as
>>>
>>>            errors."
>>>
>>> And this companion requirement:
>>>
>>> "               A.  Service Functions MAY be invoked multiple times in
>>>
>>>                      the same Service Function Chain (denoted as SF
>>>
>>>                      Spiral), but the solution MUST prevent infinite
>>>
>>>                      forwarding loops. =BB
>>>
>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is met.
>>>
>>> Can you please clarify whether this is supported and how?
>>>
>>> Thank you.
>>>
>>> Cheers,
>>>
>>> Med
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 Thu Feb 26 08:42:50 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9525E1A1BB9 for ; Thu, 26 Feb 2015 08:42:46 -0800 (PST)
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 ruD1r4y0_STM for ; Thu, 26 Feb 2015 08:42:44 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A278D1A0171 for ; Thu, 26 Feb 2015 08:42:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7742; q=dns/txt; s=iport; t=1424968962; x=1426178562; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oTL0KASY37gy6FE+OA//lCkIlAYf2xKidBl1TdeqYt4=; b=jhzY56HohBgkTMNHQFE75BYbcdkf9mmLIoiHoSk/CaH6cYRktmzNFPAy qVnr8ZrfwoGfggEOonFx4xq9Y+2RVGLZG3G23kWInH7LOrp4x0WRCYpbs Qu8+59gMVEHdd6quhz/I7u1SyBKmPhiRUP6xrsRBOgWNkJOxlRWcGRHOw o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CSBQAJTO9U/5FdJa1bgwJSWgTBeAqFcAKBJE0BAQEBAQF8hA8BAQEEAQEBJEcLDAQCAQgRBAEBAScHJwsUCQgCBAENBQkSiBQN1lwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixOEHQEBHAgrAgUCBIQlBYVthD2FRYNghWWBGzmCZYtSgz4jggIcgVBvAYEKOX8BAQE
X-IronPort-AV: E=Sophos;i="5.09,653,1418083200"; d="scan'208";a="399337498"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP; 26 Feb 2015 16:42:41 +0000
Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t1QGgfST009201 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Feb 2015 16:42:41 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.159]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 10:42:41 -0600
From: "Jim Guichard (jguichar)" 
To: Ron Parker , Dave Dolson , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" 
Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
Thread-Index: AdBRyhUadMfMQp0TQVyP+AHUYniSlAAOnhUAAABleoAAAFj2AAACvdgAAABVPAD//6+SAA==
Date: Thu, 26 Feb 2015 16:42:40 +0000
Message-ID: 
References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3584.2080005@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.4.7.141117
x-originating-ip: [10.98.43.180]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <2830CCB89832A3418FC0CE6EBBB8B904@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" 
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
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, 26 Feb 2015 16:42:46 -0000

Surely the responsibility of the SFC infrastructure is to deliver packets
to the SF where said SF =B3does it thing=B2. It seems to me that if you wan=
t
different behavior each time you visit a given SF then you need to provide
it context within the metadata so it can perform the right task.

On 2/26/15, 11:30 AM, "Ron Parker"  wrote:

>Hi, Dave.
>
>I agree that on the wire, this is the way it would work.
>
>But, when composing the chain, it seems like information would be lacking
>if a chain were expressed simply as {SF-foo, SF-bar, SF-foo, SF-foobar}.
>  It is completely implicit that since SF-foo appears twice, it perhaps
>should perform some different duty when index =3D 0 vs when index =3D 2.
>
>At first, I thought that an alternative way to handle this would be to
>use multiple logical identities for SF-foo.  In this case, the chain
>above would be expressed as {SF-foo-first-behavior, SF-bar,
>SF-foo-second-behavior, SF-foobar}.   But, the problem here is selecting
>the RSP, assuming that SF-foo has multiple instances.   Nothing in this
>second flavor of chain says that the same instance of SF-foo-* must be
>selected to satisfy SF-foo-first-behavior and SF-foo-second-behavior
>(which may not be required, but should be possible to force as such).
>
>I guess what I'm saying is that spiraling has a subtlety to it that isn't
>yet adequately addressed and that I don't have a specific proposal to
>solve it, either.
>
>   Ron
>
>
>-----Original Message-----
>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
>Sent: Thursday, February 26, 2015 11:21 AM
>To: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org
>Cc: Ben Wright (Ben.Wright@metaswitch.com)
>Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>
>If I may try to put it simply, I've always thought of it this way:
>--> Each node in the chain selects the context for processing and the
>next hop on the basis of BOTH path ID and Index, while decrementing the
>index for the next hop.
>
>That behavior supports spiraling.
>
>
>
>-Dave
>
>
>-----Original Message-----
>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
>Sent: Thursday, February 26, 2015 10:02 AM
>To: mohamed.boucadair@orange.com; sfc@ietf.org
>Cc: Ben Wright (Ben.Wright@metaswitch.com)
>Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>
>There are two different aspects of Spirals.
>
>One of the two aspects is enabling a packet that repeatedly arrives at
>the same SFF to get the correct services provided each time it arrives,
>and to go to the correct next SFF each time it arrives.  The Service Path
>Index, used by the SFF to select service functions and next SFF, provides
>that capability.
>
>The other aspect is how the Service Functions themselves handle spirals.
>  To a large degree, that depends upon the individual service function.
>  I normally assume that it would use packet context (as described in the
>text you quote) to determine what to do.
>
>Since I would prefer that service functions are independent of the
>underlying service function chaining infrastructure, and are not
>sensitive to how many functions are before or after them in the chain, I
>would personally prefer that they not use the path index for that.  I
>would recommend that if the packet does not carry enough context that the
>service function could and should use metadata to carry its needed state
>information.  But neither I personally nor the SFC Working Group get to
>tell folks how to build their service functions.  So they may come up
>with other methods for addressing their needs.  Which is also fine.
>
>Thus, I would not expect this document to discuss how service functions
>themselves handle revisiting.  But metadata clearly allows for a range of
>behaviors that will work.  And the path index handles the SFF needs
>relative to spirals, which is what we need to handle.
>
>Yours,
>Joel
>
>On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote:
>> Re-,
>>
>> Spiral is not mentioned in the draft, but SF loop is.
>>
>> I'm asking the question because I don't get from the draft how spirals
>>could work (that is a SF invoked several time in the context of the same
>>SFC).
>>
>> Before proposing text, I would like to understand first how it works.
>>If you can provide an example, this will be even great.
>>
>> Thank you.
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : jeudi 26
>>> f=E9vrier 2015 15:41 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Cc :
>>> Ben Wright (Ben.Wright@metaswitch.com) Objet : Re: [sfc]
>>> draft-quinn-sfc-nsh: Support of SF Spirals
>>>
>>> The SF Spirals requirement is one of the key drivers for the index.
>>> The index allows one to tell where one is in the spiral, and also to
>>> break a loop if one has a loop instead of a spiral.
>>>
>>> Is there text that we could add that would help make this clear,
>>> since your earlier question about the path index suggests that it is
>>> not as clear as it should be?
>>>
>>> Yours,
>>> Joel
>>>
>>> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote:
>>>> Hi Paul, all,
>>>>
>>>> There were a discussion in the mailing list
>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html)
>>>> that led to defining what is meant by SF Spirals: (below is provided
>>>> an excerpt from
>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where
>>>> the conclusions of that discussion were recorded)
>>>>
>>>> "   o  Service Function Spiral: denotes a Service Function Chain in
>>> which
>>>>
>>>>         data is handled by a Service Function, forwarded onwards,
>>>> and
>>>>
>>>>         arrives once again at that Service Function.
>>>>
>>>>         *  Note that some Service Functions support built-in
>>>> functions to
>>>>
>>>>            accommodate spirals; these service-specific functions may
>>>>
>>>>            require that the data received in a spiral should differ
>>>> in a
>>>>
>>>>            way that will result in a different processing decision
>>>> than
>>>>
>>>>            the original data.  This document does not make such
>>>>
>>>>            assumption.
>>>>
>>>>         *  A Service Function Chain may involve one or more Service
>>>>
>>>>            Function Spirals.
>>>>
>>>>         *  Unlike Service Function loop, spirals are not considered
>>>> as
>>>>
>>>>            errors."
>>>>
>>>> And this companion requirement:
>>>>
>>>> "               A.  Service Functions MAY be invoked multiple times in
>>>>
>>>>                      the same Service Function Chain (denoted as SF
>>>>
>>>>                      Spiral), but the solution MUST prevent infinite
>>>>
>>>>                      forwarding loops. =BB
>>>>
>>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is met.
>>>>
>>>> Can you please clarify whether this is supported and how?
>>>>
>>>> Thank you.
>>>>
>>>> Cheers,
>>>>
>>>> Med
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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 Thu Feb 26 08:46:56 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 89B7D1A1BD1 for ; Thu, 26 Feb 2015 08:46:55 -0800 (PST)
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 6Lo2-kAyl9ub for ; Thu, 26 Feb 2015 08:46:52 -0800 (PST)
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 A6C3E1A0211 for ; Thu, 26 Feb 2015 08:46:52 -0800 (PST)
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, 26 Feb 2015 08:46:52 -0800
From: Ron Parker 
To: "Jim Guichard (jguichar)" , Dave Dolson , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" 
Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
Thread-Index: AdBRyhUadMfMQp0TQVyP+AHUYniSlAASzvcAAABleoAAAFj2AAACvdgAABC+XSD//4AdAIAAhcqg
Date: Thu, 26 Feb 2015 16:46:51 +0000
Message-ID: 
References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3584.2080005@joelhalpern.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.203.66.100]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" 
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
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, 26 Feb 2015 16:46:55 -0000

Agree that metadata is one way to handle this, implying that SF-foo in my e=
xample knew that for this particular chain it was invoked in a spiral and t=
herefore its first invocation needed to insert metadata so that its subsequ=
ent invocations could do the right thing.

There is also an implication on RSP construction and binding -- the same in=
stance of SFF-foo likely needs to be selected at each position that it occu=
rs within the SFP.

   Ron


-----Original Message-----
From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20
Sent: Thursday, February 26, 2015 11:43 AM
To: Ron Parker; Dave Dolson; Joel M. Halpern; mohamed.boucadair@orange.com;=
 sfc@ietf.org
Cc: Ben Wright (Ben.Wright@metaswitch.com)
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals

Surely the responsibility of the SFC infrastructure is to deliver packets t=
o the SF where said SF =B3does it thing=B2. It seems to me that if you want=
 different behavior each time you visit a given SF then you need to provide=
 it context within the metadata so it can perform the right task.

On 2/26/15, 11:30 AM, "Ron Parker"  wrote:

>Hi, Dave.
>
>I agree that on the wire, this is the way it would work.
>
>But, when composing the chain, it seems like information would be=20
>lacking if a chain were expressed simply as {SF-foo, SF-bar, SF-foo, SF-fo=
obar}.
>  It is completely implicit that since SF-foo appears twice, it perhaps=20
>should perform some different duty when index =3D 0 vs when index =3D 2.
>
>At first, I thought that an alternative way to handle this would be to=20
>use multiple logical identities for SF-foo.  In this case, the chain=20
>above would be expressed as {SF-foo-first-behavior, SF-bar,
>SF-foo-second-behavior, SF-foobar}.   But, the problem here is selecting
>the RSP, assuming that SF-foo has multiple instances.   Nothing in this
>second flavor of chain says that the same instance of SF-foo-* must be=20
>selected to satisfy SF-foo-first-behavior and SF-foo-second-behavior=20
>(which may not be required, but should be possible to force as such).
>
>I guess what I'm saying is that spiraling has a subtlety to it that=20
>isn't yet adequately addressed and that I don't have a specific=20
>proposal to solve it, either.
>
>   Ron
>
>
>-----Original Message-----
>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
>Sent: Thursday, February 26, 2015 11:21 AM
>To: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org
>Cc: Ben Wright (Ben.Wright@metaswitch.com)
>Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>
>If I may try to put it simply, I've always thought of it this way:
>--> Each node in the chain selects the context for processing and the
>next hop on the basis of BOTH path ID and Index, while decrementing the=20
>index for the next hop.
>
>That behavior supports spiraling.
>
>
>
>-Dave
>
>
>-----Original Message-----
>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
>Sent: Thursday, February 26, 2015 10:02 AM
>To: mohamed.boucadair@orange.com; sfc@ietf.org
>Cc: Ben Wright (Ben.Wright@metaswitch.com)
>Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>
>There are two different aspects of Spirals.
>
>One of the two aspects is enabling a packet that repeatedly arrives at=20
>the same SFF to get the correct services provided each time it arrives,=20
>and to go to the correct next SFF each time it arrives.  The Service=20
>Path Index, used by the SFF to select service functions and next SFF,=20
>provides that capability.
>
>The other aspect is how the Service Functions themselves handle spirals.
>  To a large degree, that depends upon the individual service function.
>  I normally assume that it would use packet context (as described in=20
>the text you quote) to determine what to do.
>
>Since I would prefer that service functions are independent of the=20
>underlying service function chaining infrastructure, and are not=20
>sensitive to how many functions are before or after them in the chain,=20
>I would personally prefer that they not use the path index for that.  I=20
>would recommend that if the packet does not carry enough context that=20
>the service function could and should use metadata to carry its needed=20
>state information.  But neither I personally nor the SFC Working Group=20
>get to tell folks how to build their service functions.  So they may=20
>come up with other methods for addressing their needs.  Which is also fine=
.
>
>Thus, I would not expect this document to discuss how service functions=20
>themselves handle revisiting.  But metadata clearly allows for a range=20
>of behaviors that will work.  And the path index handles the SFF needs=20
>relative to spirals, which is what we need to handle.
>
>Yours,
>Joel
>
>On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote:
>> Re-,
>>
>> Spiral is not mentioned in the draft, but SF loop is.
>>
>> I'm asking the question because I don't get from the draft how=20
>>spirals could work (that is a SF invoked several time in the context=20
>>of the same SFC).
>>
>> Before proposing text, I would like to understand first how it works.
>>If you can provide an example, this will be even great.
>>
>> Thank you.
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : jeudi 26=20
>>> f=E9vrier 2015 15:41 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Cc :
>>> Ben Wright (Ben.Wright@metaswitch.com) Objet : Re: [sfc]
>>> draft-quinn-sfc-nsh: Support of SF Spirals
>>>
>>> The SF Spirals requirement is one of the key drivers for the index.
>>> The index allows one to tell where one is in the spiral, and also to=20
>>> break a loop if one has a loop instead of a spiral.
>>>
>>> Is there text that we could add that would help make this clear,=20
>>> since your earlier question about the path index suggests that it is=20
>>> not as clear as it should be?
>>>
>>> Yours,
>>> Joel
>>>
>>> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote:
>>>> Hi Paul, all,
>>>>
>>>> There were a discussion in the mailing list
>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html)
>>>> that led to defining what is meant by SF Spirals: (below is=20
>>>> provided an excerpt from
>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06=20
>>>> where the conclusions of that discussion were recorded)
>>>>
>>>> "   o  Service Function Spiral: denotes a Service Function Chain in
>>> which
>>>>
>>>>         data is handled by a Service Function, forwarded onwards,=20
>>>> and
>>>>
>>>>         arrives once again at that Service Function.
>>>>
>>>>         *  Note that some Service Functions support built-in=20
>>>> functions to
>>>>
>>>>            accommodate spirals; these service-specific functions=20
>>>> may
>>>>
>>>>            require that the data received in a spiral should differ=20
>>>> in a
>>>>
>>>>            way that will result in a different processing decision=20
>>>> than
>>>>
>>>>            the original data.  This document does not make such
>>>>
>>>>            assumption.
>>>>
>>>>         *  A Service Function Chain may involve one or more Service
>>>>
>>>>            Function Spirals.
>>>>
>>>>         *  Unlike Service Function loop, spirals are not considered=20
>>>> as
>>>>
>>>>            errors."
>>>>
>>>> And this companion requirement:
>>>>
>>>> "               A.  Service Functions MAY be invoked multiple times in
>>>>
>>>>                      the same Service Function Chain (denoted as SF
>>>>
>>>>                      Spiral), but the solution MUST prevent=20
>>>> infinite
>>>>
>>>>                      forwarding loops. =BB
>>>>
>>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is met.
>>>>
>>>> Can you please clarify whether this is supported and how?
>>>>
>>>> Thank you.
>>>>
>>>> Cheers,
>>>>
>>>> Med
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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 Thu Feb 26 08: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 CCE3B1A0171 for ; Thu, 26 Feb 2015 08:52:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Llp0-SewodSP for ; Thu, 26 Feb 2015 08:52:04 -0800 (PST)
Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE4E1A00F0 for ; Thu, 26 Feb 2015 08:52:04 -0800 (PST)
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 11:52:04 -0500
From: Dave Dolson 
To: Ron Parker , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" 
Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
Thread-Index: AdBRyhUadMfMQp0TQVyP+AHUYniSlAAMhaQAAABleoAAAFj2AAAJAG9w///QlQCAAFBcIA==
Date: Thu, 26 Feb 2015 16:52:02 +0000
Message-ID: 
References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3584.2080005@joelhalpern.com>  
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" 
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
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, 26 Feb 2015 16:52:07 -0000

Maybe naively, I thought the service functions would be provisioned with a =
table:

E.g., for element foo:
Path | Path Index | Next Hop  | Function
 123 |  4         |   SF-bar  | first behavior
 123 |  2         | SF-foobar | second behavior


The Function is clearly implementation specific. Maybe it points to a confi=
guration set or a policy set. I think completely out of scope here.

I suggest that this is not a problem for the wire protocol, rather for the =
configuration model (netconf or whatever).

It becomes very much vendor-specific if the behaviors are complex configura=
tions of specialized features.

If a person were manually configuring chains, I don't think they'd have a c=
onceptual problem, because they'd have a diagram they need to implement:
{SF-foo (first-behavior), SF-bar, SF-foo (second-behavior), SF-foobar}

If we wanted to standardize it, we could maybe make the Function simply a l=
abel that means something to the device--an indirection to a configuration =
set.

-Dave



-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker
Sent: Thursday, February 26, 2015 11:31 AM
To: Dave Dolson; Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.or=
g
Cc: Ben Wright (Ben.Wright@metaswitch.com)
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals

Hi, Dave.

I agree that on the wire, this is the way it would work.  =20

But, when composing the chain, it seems like information would be lacking i=
f a chain were expressed simply as {SF-foo, SF-bar, SF-foo, SF-foobar}.    =
It is completely implicit that since SF-foo appears twice, it perhaps shoul=
d perform some different duty when index =3D 0 vs when index =3D 2.   =20

At first, I thought that an alternative way to handle this would be to use =
multiple logical identities for SF-foo.  In this case, the chain above woul=
d be expressed as {SF-foo-first-behavior, SF-bar, SF-foo-second-behavior, S=
F-foobar}.   But, the problem here is selecting the RSP, assuming that SF-f=
oo has multiple instances.   Nothing in this second flavor of chain says th=
at the same instance of SF-foo-* must be selected to satisfy SF-foo-first-b=
ehavior and SF-foo-second-behavior (which may not be required, but should b=
e possible to force as such).

I guess what I'm saying is that spiraling has a subtlety to it that isn't y=
et adequately addressed and that I don't have a specific proposal to solve =
it, either.

   Ron


-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
Sent: Thursday, February 26, 2015 11:21 AM
To: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org
Cc: Ben Wright (Ben.Wright@metaswitch.com)
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals

If I may try to put it simply, I've always thought of it this way:
--> Each node in the chain selects the context for processing and the next =
hop on the basis of BOTH path ID and Index, while decrementing the index fo=
r the next hop.

That behavior supports spiraling.



-Dave


-----Original Message-----
From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
Sent: Thursday, February 26, 2015 10:02 AM
To: mohamed.boucadair@orange.com; sfc@ietf.org
Cc: Ben Wright (Ben.Wright@metaswitch.com)
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals

There are two different aspects of Spirals.

One of the two aspects is enabling a packet that repeatedly arrives at the =
same SFF to get the correct services provided each time it arrives, and to =
go to the correct next SFF each time it arrives.  The Service Path Index, u=
sed by the SFF to select service functions and next SFF, provides that capa=
bility.

The other aspect is how the Service Functions themselves handle spirals.=20
  To a large degree, that depends upon the individual service function.=20
  I normally assume that it would use packet context (as described in the t=
ext you quote) to determine what to do.

Since I would prefer that service functions are independent of the underlyi=
ng service function chaining infrastructure, and are not sensitive to how m=
any functions are before or after them in the chain, I would personally pre=
fer that they not use the path index for that.  I would recommend that if t=
he packet does not carry enough context that the service function could and=
 should use metadata to carry its needed state information.  But neither I =
personally nor the SFC Working Group get to tell folks how to build their s=
ervice functions.  So they may come up with other methods for addressing th=
eir needs.  Which is also fine.

Thus, I would not expect this document to discuss how service functions the=
mselves handle revisiting.  But metadata clearly allows for a range of beha=
viors that will work.  And the path index handles the SFF needs relative to=
 spirals, which is what we need to handle.

Yours,
Joel

On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote:
> Re-,
>
> Spiral is not mentioned in the draft, but SF loop is.
>
> I'm asking the question because I don't get from the draft how spirals co=
uld work (that is a SF invoked several time in the context of the same SFC)=
.
>
> Before proposing text, I would like to understand first how it works. If =
you can provide an example, this will be even great.
>
> Thank you.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : jeudi 26=20
>> f=E9vrier 2015 15:41 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Cc :=
=20
>> Ben Wright (Ben.Wright@metaswitch.com) Objet : Re: [sfc]=20
>> draft-quinn-sfc-nsh: Support of SF Spirals
>>
>> The SF Spirals requirement is one of the key drivers for the index. =20
>> The index allows one to tell where one is in the spiral, and also to=20
>> break a loop if one has a loop instead of a spiral.
>>
>> Is there text that we could add that would help make this clear,=20
>> since your earlier question about the path index suggests that it is=20
>> not as clear as it should be?
>>
>> Yours,
>> Joel
>>
>> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote:
>>> Hi Paul, all,
>>>
>>> There were a discussion in the mailing list
>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html)=20
>>> that led to defining what is meant by SF Spirals: (below is provided=20
>>> an excerpt from
>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where=20
>>> the conclusions of that discussion were recorded)
>>>
>>> "   o  Service Function Spiral: denotes a Service Function Chain in
>> which
>>>
>>>         data is handled by a Service Function, forwarded onwards,=20
>>> and
>>>
>>>         arrives once again at that Service Function.
>>>
>>>         *  Note that some Service Functions support built-in=20
>>> functions to
>>>
>>>            accommodate spirals; these service-specific functions may
>>>
>>>            require that the data received in a spiral should differ=20
>>> in a
>>>
>>>            way that will result in a different processing decision=20
>>> than
>>>
>>>            the original data.  This document does not make such
>>>
>>>            assumption.
>>>
>>>         *  A Service Function Chain may involve one or more Service
>>>
>>>            Function Spirals.
>>>
>>>         *  Unlike Service Function loop, spirals are not considered=20
>>> as
>>>
>>>            errors."
>>>
>>> And this companion requirement:
>>>
>>> "               A.  Service Functions MAY be invoked multiple times in
>>>
>>>                      the same Service Function Chain (denoted as SF
>>>
>>>                      Spiral), but the solution MUST prevent infinite
>>>
>>>                      forwarding loops. =BB
>>>
>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is met.
>>>
>>> Can you please clarify whether this is supported and how?
>>>
>>> Thank you.
>>>
>>> Cheers,
>>>
>>> Med
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 Thu Feb 26 08: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 8E5481A9086 for ; Thu, 26 Feb 2015 08:54:49 -0800 (PST)
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 79UewZslY299 for ; Thu, 26 Feb 2015 08:54:44 -0800 (PST)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 513F91A0218 for ; Thu, 26 Feb 2015 08:54:44 -0800 (PST)
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; Thu, 26 Feb 2015 11:54:43 -0500
From: Dave Dolson 
To: Ron Parker , "Jim Guichard (jguichar)" , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" 
Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
Thread-Index: AdBRyhUadMfMQp0TQVyP+AHUYniSlAAMhaQAAABleoAAAFj2AAAJAG9w///QlQCAAANmAIAAASuAgABQvpA=
Date: Thu, 26 Feb 2015 16:54:43 +0000
Message-ID: 
References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3584.2080005@joelhalpern.com>    
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" 
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
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, 26 Feb 2015 16:54:49 -0000

I think using metadata is more complicated than using the path Index.
You'd have to arrange for it to be set properly by neighbors. It just makes=
 it someone else's problem, which is a more difficult problem.

On the other hand, the Index is already guaranteed to be unique at each lin=
k in the chain.


-----Original Message-----
From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20
Sent: Thursday, February 26, 2015 11:47 AM
To: Jim Guichard (jguichar); Dave Dolson; Joel M. Halpern; mohamed.boucadai=
r@orange.com; sfc@ietf.org
Cc: Ben Wright (Ben.Wright@metaswitch.com)
Subject: RE: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals

Agree that metadata is one way to handle this, implying that SF-foo in my e=
xample knew that for this particular chain it was invoked in a spiral and t=
herefore its first invocation needed to insert metadata so that its subsequ=
ent invocations could do the right thing.

There is also an implication on RSP construction and binding -- the same in=
stance of SFF-foo likely needs to be selected at each position that it occu=
rs within the SFP.

   Ron


-----Original Message-----
From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20
Sent: Thursday, February 26, 2015 11:43 AM
To: Ron Parker; Dave Dolson; Joel M. Halpern; mohamed.boucadair@orange.com;=
 sfc@ietf.org
Cc: Ben Wright (Ben.Wright@metaswitch.com)
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals

Surely the responsibility of the SFC infrastructure is to deliver packets t=
o the SF where said SF =B3does it thing=B2. It seems to me that if you want=
 different behavior each time you visit a given SF then you need to provide=
 it context within the metadata so it can perform the right task.

On 2/26/15, 11:30 AM, "Ron Parker"  wrote:

>Hi, Dave.
>
>I agree that on the wire, this is the way it would work.
>
>But, when composing the chain, it seems like information would be=20
>lacking if a chain were expressed simply as {SF-foo, SF-bar, SF-foo, SF-fo=
obar}.
>  It is completely implicit that since SF-foo appears twice, it perhaps=20
>should perform some different duty when index =3D 0 vs when index =3D 2.
>
>At first, I thought that an alternative way to handle this would be to=20
>use multiple logical identities for SF-foo.  In this case, the chain=20
>above would be expressed as {SF-foo-first-behavior, SF-bar,
>SF-foo-second-behavior, SF-foobar}.   But, the problem here is selecting
>the RSP, assuming that SF-foo has multiple instances.   Nothing in this
>second flavor of chain says that the same instance of SF-foo-* must be=20
>selected to satisfy SF-foo-first-behavior and SF-foo-second-behavior=20
>(which may not be required, but should be possible to force as such).
>
>I guess what I'm saying is that spiraling has a subtlety to it that=20
>isn't yet adequately addressed and that I don't have a specific=20
>proposal to solve it, either.
>
>   Ron
>
>
>-----Original Message-----
>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
>Sent: Thursday, February 26, 2015 11:21 AM
>To: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org
>Cc: Ben Wright (Ben.Wright@metaswitch.com)
>Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>
>If I may try to put it simply, I've always thought of it this way:
>--> Each node in the chain selects the context for processing and the
>next hop on the basis of BOTH path ID and Index, while decrementing the=20
>index for the next hop.
>
>That behavior supports spiraling.
>
>
>
>-Dave
>
>
>-----Original Message-----
>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
>Sent: Thursday, February 26, 2015 10:02 AM
>To: mohamed.boucadair@orange.com; sfc@ietf.org
>Cc: Ben Wright (Ben.Wright@metaswitch.com)
>Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>
>There are two different aspects of Spirals.
>
>One of the two aspects is enabling a packet that repeatedly arrives at=20
>the same SFF to get the correct services provided each time it arrives,=20
>and to go to the correct next SFF each time it arrives.  The Service=20
>Path Index, used by the SFF to select service functions and next SFF,=20
>provides that capability.
>
>The other aspect is how the Service Functions themselves handle spirals.
>  To a large degree, that depends upon the individual service function.
>  I normally assume that it would use packet context (as described in=20
>the text you quote) to determine what to do.
>
>Since I would prefer that service functions are independent of the=20
>underlying service function chaining infrastructure, and are not=20
>sensitive to how many functions are before or after them in the chain,=20
>I would personally prefer that they not use the path index for that.  I=20
>would recommend that if the packet does not carry enough context that=20
>the service function could and should use metadata to carry its needed=20
>state information.  But neither I personally nor the SFC Working Group=20
>get to tell folks how to build their service functions.  So they may=20
>come up with other methods for addressing their needs.  Which is also fine=
.
>
>Thus, I would not expect this document to discuss how service functions=20
>themselves handle revisiting.  But metadata clearly allows for a range=20
>of behaviors that will work.  And the path index handles the SFF needs=20
>relative to spirals, which is what we need to handle.
>
>Yours,
>Joel
>
>On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote:
>> Re-,
>>
>> Spiral is not mentioned in the draft, but SF loop is.
>>
>> I'm asking the question because I don't get from the draft how=20
>>spirals could work (that is a SF invoked several time in the context=20
>>of the same SFC).
>>
>> Before proposing text, I would like to understand first how it works.
>>If you can provide an example, this will be even great.
>>
>> Thank you.
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : jeudi 26=20
>>> f=E9vrier 2015 15:41 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Cc :
>>> Ben Wright (Ben.Wright@metaswitch.com) Objet : Re: [sfc]
>>> draft-quinn-sfc-nsh: Support of SF Spirals
>>>
>>> The SF Spirals requirement is one of the key drivers for the index.
>>> The index allows one to tell where one is in the spiral, and also to=20
>>> break a loop if one has a loop instead of a spiral.
>>>
>>> Is there text that we could add that would help make this clear,=20
>>> since your earlier question about the path index suggests that it is=20
>>> not as clear as it should be?
>>>
>>> Yours,
>>> Joel
>>>
>>> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote:
>>>> Hi Paul, all,
>>>>
>>>> There were a discussion in the mailing list
>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html)
>>>> that led to defining what is meant by SF Spirals: (below is=20
>>>> provided an excerpt from
>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06=20
>>>> where the conclusions of that discussion were recorded)
>>>>
>>>> "   o  Service Function Spiral: denotes a Service Function Chain in
>>> which
>>>>
>>>>         data is handled by a Service Function, forwarded onwards,=20
>>>> and
>>>>
>>>>         arrives once again at that Service Function.
>>>>
>>>>         *  Note that some Service Functions support built-in=20
>>>> functions to
>>>>
>>>>            accommodate spirals; these service-specific functions=20
>>>> may
>>>>
>>>>            require that the data received in a spiral should differ=20
>>>> in a
>>>>
>>>>            way that will result in a different processing decision=20
>>>> than
>>>>
>>>>            the original data.  This document does not make such
>>>>
>>>>            assumption.
>>>>
>>>>         *  A Service Function Chain may involve one or more Service
>>>>
>>>>            Function Spirals.
>>>>
>>>>         *  Unlike Service Function loop, spirals are not considered=20
>>>> as
>>>>
>>>>            errors."
>>>>
>>>> And this companion requirement:
>>>>
>>>> "               A.  Service Functions MAY be invoked multiple times in
>>>>
>>>>                      the same Service Function Chain (denoted as SF
>>>>
>>>>                      Spiral), but the solution MUST prevent=20
>>>> infinite
>>>>
>>>>                      forwarding loops. =BB
>>>>
>>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is met.
>>>>
>>>> Can you please clarify whether this is supported and how?
>>>>
>>>> Thank you.
>>>>
>>>> Cheers,
>>>>
>>>> Med
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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 Thu Feb 26 08:59:26 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B991A6FF9 for ; Thu, 26 Feb 2015 08:59:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9nCzb-eKEep for ; Thu, 26 Feb 2015 08:59:21 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D2BD1A1A91 for ; Thu, 26 Feb 2015 08:59:17 -0800 (PST)
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 BTA42619; Thu, 26 Feb 2015 16:59:15 +0000 (GMT)
Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Feb 2015 16:59:14 +0000
Received: from SZXEMA503-MBX.china.huawei.com ([169.254.5.5]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Fri, 27 Feb 2015 00:59:10 +0800
From: Xingjun Chu 
To: "Jim Guichard (jguichar)" , Reinaldo Penno , "sfc-dev@lists.opendaylight.org" 
Thread-Topic: [sfc-dev] SFC ODL IETF-92 Hackton
Thread-Index: AQHQUd+9eO+LH+R8FkmKaWxebHK3oZ0DJzbg
Date: Thu, 26 Feb 2015 16:59:09 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.122.70.227]
Content-Type: multipart/alternative; boundary="_000_A80FD691ED8CBE458269B48D68F2E45E0B039092SZXEMA503MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Cc: "sfc@ietf.org" 
Subject: Re: [sfc] [sfc-dev] SFC ODL IETF-92 Hackton
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, 26 Feb 2015 16:59:24 -0000

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

Aha, thank you!  Jim

Cheers!
Xingjun

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar=
)
Sent: Thursday, February 26, 2015 11:18 AM
To: Xingjun Chu; Reinaldo Penno; sfc-dev@lists.opendaylight.org
Cc: sfc@ietf.org
Subject: Re: [sfc] [sfc-dev] SFC ODL IETF-92 Hackton

Hi Xingjun,

You must have missed Charles's other email that stated:

"We are still in the process of updating the event information and registra=
tion pages to include SFC. If you go to register in the meantime and do not=
 see SFC listed as a technology, you can enter "SFC" in the "Other" area".

From: Xingjun Chu >
Date: Thursday, February 26, 2015 at 11:14 AM
To: Reinaldo Penno >, "sfc-dev@=
lists.opendaylight.org" >
Cc: "sfc@ietf.org" >
Subject: Re: [sfc-dev] SFC ODL IETF-92 Hackton

I don't see SFC explicitly listed on the agenda as defined in the event lin=
k.

Regards
Xingjun

From: sfc-dev-bounces@lists.opendaylight.org [mailto:sfc-dev-bounces@lists.opendaylight.org] On Behalf =
Of Reinaldo Penno
Sent: Tuesday, February 24, 2015 4:46 PM
To: sfc-dev@lists.opendaylight.org; =
Charles Eckel (eckelcu)
Cc: sfc@ietf.org
Subject: [sfc-dev] SFC ODL IETF-92 Hackton


Event details:

https://developer.cisco.com/site/ietf-hackathon

Link to register: https://www.ietf.org/meeting/92/hackathon-signup.html

SFC Program:

Services Function Chaining in Opendaylight (Reinaldo Penno, Jim Guichard)



SFC ODL page: https://wiki.opendaylight.org/view/Service_Function_Chaining:=
Main



Strongly recommend watching the webex titled "Reinaldo SFC demo" at the bot=
tom of the page above.

*         Introduction to SFC architecture in Opendaylight

*         Architecture of SFC Agent and data plane

*         Work items will cover both control and data plane:

*         SFC Agent auto-provisioning (SF/SFF configuration-less deployment=
s) (Python)

o    SFC Agent Yang models (Yang)

*         SFC-OVS integration. (Java)

*         SFC/NSH Traceroute (Python, Standards work)

*         SFC Classifier (Python, Linux IPtables)

*         Netconf integration (Java)

*         Review of SFC Yang models and feedback into ODL (Yang, standards)

*         Implementation of Variable Length NSH packets (MD Type 02) in the=
 data plane (Python)



We welcome comments on the program and suggestions



Thanks,



Reinaldo



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









    

    Aha, thank you!  Jim=

    

     <=
/p>

    Cheers!=

    

    Xingjun=

    

     <=
/p>

    

    

    From: sfc [mai=
lto:sfc-bounces@ietf.org]
On Behalf Of Jim Guichard (jguichar)
    
Sent: Thursday, February 26, 2015 11:18 AM
    
To: Xingjun Chu; Reinaldo Penno; sfc-dev@lists.opendaylight.org
    
Cc: sfc@ietf.org
    
Subject: Re: [sfc] [sfc-dev] SFC ODL IETF-92 Hackton
    

    

    

     
    

    

    Hi Xingjun,
    

    

    

     

    

    

    You must have missed Charle=
s’s other email that stated:
    

    

    

     

    

    

    “We are still in the =
process of updating the event information and registration pages to include=
 SFC. If you go to register in the meantime and do not see SFC
 listed as a technology, you can enter “SFC” in the “Othe=
r” area”.
    

    

    

     

    

    

    From:
Xingjun Chu <Xingjun.Chu@huawei.com>
    
Date: Thursday, February 26, 2015 at 11:14 AM
    
To: Reinaldo Penno <rapenno@=
gmail.com>, "=
sfc-dev@lists.opendaylight.org" <sfc-dev@lists.opendaylight.org>
    
Cc: "sfc@ietf.org" <=
;sfc@ietf.org>
    
Subject: Re: [sfc-dev] SFC ODL IETF-92 Hackton
    

    

    

     

    

    

    

    I don’t see SFC exp=
licitly listed on the agenda as defined in the event link.

    

     
    

    Regards
    

    Xingjun
    

     
    

    

    

    From:
sfc-dev-bounces@l=
ists.opendaylight.org [mailto:sfc-dev-bounces@lists.opendaylight.org]
On Behalf Of Reinaldo Penno
    
Sent: Tuesday, February 24, 2015 4:46 PM
    
To: sfc-dev@lists.=
opendaylight.org; Charles Eckel (eckelcu)
    
Cc: sfc@ietf.org
    
Subject: [sfc-dev] SFC ODL IETF-92 Hackton
    

    

    

     =

    

    

    Event details: 
    

    

    https://developer.cisco.com/site/ietf-hackathon
    

    Link to register: https://www.ietf.org/meeting/92/hack=
athon-signup.html<=
/pre>

    SFC Program:
    

    

    Services Function Chainin=
g in Opendaylight (Reinaldo Penno, Jim Guichard)
    

    

    

     
    

    


    

     
    

    

    

    Strongly recommend&n=
bsp;watching the webex titled "Reinaldo SFC demo” at the bottom =
of the page above.

    

    

    

    =
· &n=
bsp;       Introduction to SFC architectur=
e in Opendaylight 
    

    =
· &n=
bsp;       Architecture of SFC Agent and d=
ata plane
    

    =
· &n=
bsp;       Work items will cover both control and=
 data plane:
    

    =
· &n=
bsp;       SFC Agent auto-provisioning (SF=
/SFF configuration-less deployments) (Python)
    

    =
o    <=
/span>SFC Agent Ya=
ng models (Yang)
    

    =
· &n=
bsp;       SFC-OVS integration. (Java)
    

    =
· &n=
bsp;       SFC/NSH Traceroute (Python, Sta=
ndards work)
    

    =
· &n=
bsp;       SFC Classifier (Python, Li=
nux IPtables)

    =
· &n=
bsp;       Netconf integration (Java)
    

    =
· &n=
bsp;       Review of SFC Yang models and f=
eedback into ODL (Yang, standards)<=
/o:p>
    

    =
· &n=
bsp;       Implementation of Variable Length=
 NSH packets (MD Type 02) in the data plane (Python)
    

    

    

    

     
    

    

    

    We welcome comments on the program and sugges=
tions
    

    

    

     
    

    

    

    Thanks,
    

    

    

     
    

    

    

    Reinaldo
    

    

    

     
    

    

    

    

    



--_000_A80FD691ED8CBE458269B48D68F2E45E0B039092SZXEMA503MBXchi_--


From nobody Thu Feb 26 09:00:57 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 7C0C41A8795 for ; Thu, 26 Feb 2015 09:00:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NvognOdv7aOL for ; Thu, 26 Feb 2015 09:00:53 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE891A9086 for ; Thu, 26 Feb 2015 09:00:47 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTA42720; Thu, 26 Feb 2015 17:00:46 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Feb 2015 17:00:46 +0000
Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.133]) by SJCEML703-CHM.china.huawei.com ([169.254.5.223]) with mapi id 14.03.0158.001;  Thu, 26 Feb 2015 09:00:41 -0800
From: Henry Fourie 
To: "Jim Guichard (jguichar)" , "sfc@ietf.org" 
Thread-Topic: WG call for adoption of draft-quinn-sfc-nsh
Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50DJ7RA
Date: Thu, 26 Feb 2015 17:00:40 +0000
Message-ID: <0F8583BBE82FA449A8B78417CC07559A091AB019@SJCEML701-CHM.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.212.145.59]
Content-Type: multipart/alternative; boundary="_000_0F8583BBE82FA449A8B78417CC07559A091AB019SJCEML701CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh
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, 26 Feb 2015 17:00:55 -0000

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

Support as a co-author.

-          Louis

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar=
)
Sent: Thursday, February 26, 2015 4:47 AM
To: sfc@ietf.org
Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh

Greetings WG:

The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft=
-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc=
-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined =
the NSH document so that the WG can focus on a single encapsulation documen=
t going forward. This new version of NSH includes an open items section bas=
ed on discussion between co-authors and members of the list. The WG will wo=
rk through this list (and any other issues that need to be added) over the =
next weeks. We appreciate and recognize the hard work of both the NSH and S=
CH authors in pushing the SFC encapsulation work forward.

With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n=
sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3=
/12/2015.

Please note that this is a call for adoption, and not a last call for conte=
nt of the document. Adopting a WG document simply means that the WG will fo=
cus its efforts on that particular draft going forward, and use that docume=
nt for resolving open issues and documenting the WG's decisions.

Please indicate whether you support adoption for not, and if not why. Issue=
s you have with the current document itself can also be raised, but they sh=
ould be raised in the context of what should be changed in the document goi=
ng forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that appl=
ies to this draft, in line with the IPR disclosure obligations for WG parti=
cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l=
isted as a document author please respond to this email (to the chairs) whe=
ther or not you are aware of any relevant IPR.

Jim & Thomas

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









    

    Support as a co-author.
    

    
-  &n=
bsp;      
Louis<=
/span>
    

     <=
/p>

    

    

    From: sfc [mai=
lto:sfc-bounces@ietf.org]
On Behalf Of Jim Guichard (jguichar)
    
Sent: Thursday, February 26, 2015 4:47 AM
    
To: sfc@ietf.org
    
Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh
    

    

    

     
    

    

    

    Greetings WG:
    

    

    

     =

    

    

    

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/dr=
aft-quinn-sfc-nsh/) has recently been
 reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draf=
t-zhang-sfc-sch/) have joined the NSH document so that the WG can focus=
 on a single encapsulation document
 going forward. This new version of NSH includes an open items secti=
on based on discussion between co-authors and members of the list. The WG w=
ill work through this list (and any other issues that need to be added) ove=
r the next weeks. We appreciate
 and recognize the hard work of both the NSH and SCH authors in pushing the=
 SFC encapsulation work forward.
    

    

    

     =

    

    

    

    With that said, the chairs are calling for WG adoption of draf=
t-quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 w=
eeks ending 3/12/2015.=

    

    

    

     =

    

    

    

    Please note that this is a call for adoption, and not a last call for cont=
ent of the document. Adopting a WG document simply means that the WG will f=
ocus its efforts on that particular
 draft going forward, and use that document for resolving open issues and d=
ocumenting the WG’s decisions.
    

    

    

     
    

    

    

    Please indicate whether you support adoption for not, and if not why. Issu=
es you have with the current document itself can also be raised, but they s=
hould be raised in the context of what
 should be changed in the document going forward, rather than a pre-conditi=
on for adoption. 
    

    

    

     
    

    

    

    Finally, now is also a good time to poll for knowledge of any IPR that app=
lies to this draft, in line with the IPR disclosure obligations for WG part=
icipants (see RFCs 3979, 4879, 3669
 and 5378 for more details). If you are listed as a document author please =
respond to this email (to the chairs) whether or not you are aware of any r=
elevant IPR.
    

    

    

     
    

    

    

    Jim & Thomas
    

    

    

    



--_000_0F8583BBE82FA449A8B78417CC07559A091AB019SJCEML701CHMchi_--


From nobody Thu Feb 26 09:18:28 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 B27C81A87E6 for ; Thu, 26 Feb 2015 09:18:26 -0800 (PST)
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 KTKgCliyN68B for ; Thu, 26 Feb 2015 09:18:18 -0800 (PST)
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 DB4721A87E4 for ; Thu, 26 Feb 2015 09:18:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9333; q=dns/txt; s=iport; t=1424971096; x=1426180696; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XG8QzN+sAB4OpOvMoSYfG05CVkPmkvLd5RwgPwcPqIc=; b=mQ4mxMEooSMrjE7swxEa2wIkTEq94PtPjHkfkmSKG+Q2+kaq6m/1yG0m aHqcrx0MXT5wpRZ+nc+3wE52a9JIqrayhPSri52Iz1WvweNy0SpY9Yy+O Z01/YMRdpYDy1j8zhnTHmvWGk8A5nt4I/4Jt7neOvrMu0KKvbXWraHKcs E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CSBQClVO9U/5FdJa1bgwJSWgTBeQqFcAKBJE0BAQEBAQF8hA8BAQEEAQEBJEcLDAQCAQgOAwQBAQEnBycLFAkIAgQBDQUJEogUDdcIAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sThAwQAgFPAgUGhCUFhW2EPYVFg2CFZYEbOYJli1KDPiODbm8BgUN/AQEB
X-IronPort-AV: E=Sophos;i="5.09,653,1418083200"; d="scan'208";a="127188279"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP; 26 Feb 2015 17:18:15 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t1QHIFQd003103 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Feb 2015 17:18:15 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.248]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 11:18:15 -0600
From: "Reinaldo Penno (repenno)" 
To: Dave Dolson , Ron Parker , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" 
Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
Thread-Index: AdBRyhUadMfMQp0TQVyP+AHUYniSlAAMhaQAAABleoAAAFj2AAAJAG9w///hWACAAAYEAP//gTYA
Date: Thu, 26 Feb 2015 17:18:15 +0000
Message-ID: 
References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3584.2080005@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.4.7.141117
x-originating-ip: [10.24.96.182]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" 
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
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, 26 Feb 2015 17:18:26 -0000

Agreed on all points. I thought I was missing something so before writing
this email I retested our implementation and it worked off the bat. The
RSP constructed has the the same (SFF, SF) tuple but different indexes.

The same SF is visited multiple times until the path ends.  If the SF
wants contextual info across visits than context headers are the way to
go.=20


On 2/26/15, 8:52 AM, "Dave Dolson"  wrote:

>Maybe naively, I thought the service functions would be provisioned with
>a table:
>
>E.g., for element foo:
>Path | Path Index | Next Hop  | Function
> 123 |  4         |   SF-bar  | first behavior
> 123 |  2         | SF-foobar | second behavior
>
>
>The Function is clearly implementation specific. Maybe it points to a
>configuration set or a policy set. I think completely out of scope here.
>
>I suggest that this is not a problem for the wire protocol, rather for
>the configuration model (netconf or whatever).
>
>It becomes very much vendor-specific if the behaviors are complex
>configurations of specialized features.
>
>If a person were manually configuring chains, I don't think they'd have a
>conceptual problem, because they'd have a diagram they need to implement:
>{SF-foo (first-behavior), SF-bar, SF-foo (second-behavior), SF-foobar}
>
>If we wanted to standardize it, we could maybe make the Function simply a
>label that means something to the device--an indirection to a
>configuration set.
>
>-Dave
>
>
>
>-----Original Message-----
>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker
>Sent: Thursday, February 26, 2015 11:31 AM
>To: Dave Dolson; Joel M. Halpern; mohamed.boucadair@orange.com;
>sfc@ietf.org
>Cc: Ben Wright (Ben.Wright@metaswitch.com)
>Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>
>Hi, Dave.
>
>I agree that on the wire, this is the way it would work.
>
>But, when composing the chain, it seems like information would be lacking
>if a chain were expressed simply as {SF-foo, SF-bar, SF-foo, SF-foobar}.
>  It is completely implicit that since SF-foo appears twice, it perhaps
>should perform some different duty when index =3D 0 vs when index =3D 2.
>
>At first, I thought that an alternative way to handle this would be to
>use multiple logical identities for SF-foo.  In this case, the chain
>above would be expressed as {SF-foo-first-behavior, SF-bar,
>SF-foo-second-behavior, SF-foobar}.   But, the problem here is selecting
>the RSP, assuming that SF-foo has multiple instances.   Nothing in this
>second flavor of chain says that the same instance of SF-foo-* must be
>selected to satisfy SF-foo-first-behavior and SF-foo-second-behavior
>(which may not be required, but should be possible to force as such).
>
>I guess what I'm saying is that spiraling has a subtlety to it that isn't
>yet adequately addressed and that I don't have a specific proposal to
>solve it, either.
>
>   Ron
>
>
>-----Original Message-----
>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
>Sent: Thursday, February 26, 2015 11:21 AM
>To: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org
>Cc: Ben Wright (Ben.Wright@metaswitch.com)
>Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>
>If I may try to put it simply, I've always thought of it this way:
>--> Each node in the chain selects the context for processing and the
>next hop on the basis of BOTH path ID and Index, while decrementing the
>index for the next hop.
>
>That behavior supports spiraling.
>
>
>
>-Dave
>
>
>-----Original Message-----
>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
>Sent: Thursday, February 26, 2015 10:02 AM
>To: mohamed.boucadair@orange.com; sfc@ietf.org
>Cc: Ben Wright (Ben.Wright@metaswitch.com)
>Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>
>There are two different aspects of Spirals.
>
>One of the two aspects is enabling a packet that repeatedly arrives at
>the same SFF to get the correct services provided each time it arrives,
>and to go to the correct next SFF each time it arrives.  The Service Path
>Index, used by the SFF to select service functions and next SFF, provides
>that capability.
>
>The other aspect is how the Service Functions themselves handle spirals.
>  To a large degree, that depends upon the individual service function.
>  I normally assume that it would use packet context (as described in the
>text you quote) to determine what to do.
>
>Since I would prefer that service functions are independent of the
>underlying service function chaining infrastructure, and are not
>sensitive to how many functions are before or after them in the chain, I
>would personally prefer that they not use the path index for that.  I
>would recommend that if the packet does not carry enough context that the
>service function could and should use metadata to carry its needed state
>information.  But neither I personally nor the SFC Working Group get to
>tell folks how to build their service functions.  So they may come up
>with other methods for addressing their needs.  Which is also fine.
>
>Thus, I would not expect this document to discuss how service functions
>themselves handle revisiting.  But metadata clearly allows for a range of
>behaviors that will work.  And the path index handles the SFF needs
>relative to spirals, which is what we need to handle.
>
>Yours,
>Joel
>
>On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote:
>> Re-,
>>
>> Spiral is not mentioned in the draft, but SF loop is.
>>
>> I'm asking the question because I don't get from the draft how spirals
>>could work (that is a SF invoked several time in the context of the same
>>SFC).
>>
>> Before proposing text, I would like to understand first how it works.
>>If you can provide an example, this will be even great.
>>
>> Thank you.
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : jeudi 26
>>> f=E9vrier 2015 15:41 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Cc :
>>> Ben Wright (Ben.Wright@metaswitch.com) Objet : Re: [sfc]
>>> draft-quinn-sfc-nsh: Support of SF Spirals
>>>
>>> The SF Spirals requirement is one of the key drivers for the index.
>>> The index allows one to tell where one is in the spiral, and also to
>>> break a loop if one has a loop instead of a spiral.
>>>
>>> Is there text that we could add that would help make this clear,
>>> since your earlier question about the path index suggests that it is
>>> not as clear as it should be?
>>>
>>> Yours,
>>> Joel
>>>
>>> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote:
>>>> Hi Paul, all,
>>>>
>>>> There were a discussion in the mailing list
>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html)
>>>> that led to defining what is meant by SF Spirals: (below is provided
>>>> an excerpt from
>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where
>>>> the conclusions of that discussion were recorded)
>>>>
>>>> "   o  Service Function Spiral: denotes a Service Function Chain in
>>> which
>>>>
>>>>         data is handled by a Service Function, forwarded onwards,
>>>> and
>>>>
>>>>         arrives once again at that Service Function.
>>>>
>>>>         *  Note that some Service Functions support built-in
>>>> functions to
>>>>
>>>>            accommodate spirals; these service-specific functions may
>>>>
>>>>            require that the data received in a spiral should differ
>>>> in a
>>>>
>>>>            way that will result in a different processing decision
>>>> than
>>>>
>>>>            the original data.  This document does not make such
>>>>
>>>>            assumption.
>>>>
>>>>         *  A Service Function Chain may involve one or more Service
>>>>
>>>>            Function Spirals.
>>>>
>>>>         *  Unlike Service Function loop, spirals are not considered
>>>> as
>>>>
>>>>            errors."
>>>>
>>>> And this companion requirement:
>>>>
>>>> "               A.  Service Functions MAY be invoked multiple times in
>>>>
>>>>                      the same Service Function Chain (denoted as SF
>>>>
>>>>                      Spiral), but the solution MUST prevent infinite
>>>>
>>>>                      forwarding loops. =BB
>>>>
>>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is met.
>>>>
>>>> Can you please clarify whether this is supported and how?
>>>>
>>>> Thank you.
>>>>
>>>> Cheers,
>>>>
>>>> Med
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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 Thu Feb 26 09:21: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 01A961A8891 for ; Thu, 26 Feb 2015 09:21:40 -0800 (PST)
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 I-CydU2r6pll for ; Thu, 26 Feb 2015 09:21:37 -0800 (PST)
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 437FE1A1A32 for ; Thu, 26 Feb 2015 09:21:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13404; q=dns/txt; s=iport; t=1424971297; x=1426180897; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aFiGKuZgGI/+jsXeKgse8R1MW6kNRJdGxAsJeVlDi8s=; b=GOV+lZQ2vj2dtMkXyJRit66ofpsszMGBjOPlEBI3rc50orj1a1AbYRAP ulcBN2btr+MA50V4NMkfGLJVkTLARKfGxG7o/yo+0PruIhVLQMLnx7Acv vb+Q2rFJGsAHobZ4ndtD/VVtG3BQUAXOTA3V9acGDt2sscGqE0JNKF4T8 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C9BQCWVe9U/5FdJa1bgwJSWgSDBb50CoVwAhyBCE0BAQEBAQF8hA8BAQEDAQEBASAEDToLDAQCAQgOAwQBAQECAiMDAgICJQsUAQgIAgQBDQUJEogMCA29LZloAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EhiXKEHQEBHAgQGwcCAgKCYoFDBYVtigKDYIVlgRs5gmWLUoM+I4ICHIFQbwGBCjl/AQEB
X-IronPort-AV: E=Sophos;i="5.09,653,1418083200"; d="scan'208";a="399463488"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP; 26 Feb 2015 17:21:36 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t1QHLZnt006640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Feb 2015 17:21:36 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.159]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 11:21:35 -0600
From: "Jim Guichard (jguichar)" 
To: Dave Dolson , Ron Parker , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" 
Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
Thread-Index: AdBRyhUadMfMQp0TQVyP+AHUYniSlAAOnhUAAABleoAAAFj2AAACvdgAAABVPAD//6+SAIAAVP+AgAACM4D//7OtgA==
Date: Thu, 26 Feb 2015 17:21:35 +0000
Message-ID: 
References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3584.2080005@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.4.7.141117
x-originating-ip: [10.98.43.180]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" 
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
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, 26 Feb 2015 17:21:40 -0000

SGkgRGF2ZSwNCg0KWWVzIG9mIGNvdXJzZSBhbmQgSSBkaWQgbm90IG1lYW4gdG8gaW1wbHkgdGhh
dCB0aGUgaW5kZXggaXMgbm90IHJlbGV2YW50Lg0KVGhlIHBvaW50IGlzIHRoYXQgdGhlIFNQSS9T
SSBpcyB1c2VkIHRvIHN0ZWVyIHRoZSB0cmFmZmljIGFuZCB0aGVuIGlmIGFuDQpTRiB3aXNoZXMg
dG8gZG8gc29tZXRoaW5nIGRpZmZlcmVudCBhdCBlYWNoIHNlcnZpY2UgaG9wIHRoZW4gdGhlIG1l
dGFkYXRhDQpjYW4gcHJvdmlkZSB0aGUgbmVjZXNzYXJ5IGNvbnRleHQuDQoNCk9uIDIvMjYvMTUs
IDExOjU0IEFNLCAiRGF2ZSBEb2xzb24iIDxkZG9sc29uQHNhbmR2aW5lLmNvbT4gd3JvdGU6DQoN
Cj5JIHRoaW5rIHVzaW5nIG1ldGFkYXRhIGlzIG1vcmUgY29tcGxpY2F0ZWQgdGhhbiB1c2luZyB0
aGUgcGF0aCBJbmRleC4NCj5Zb3UnZCBoYXZlIHRvIGFycmFuZ2UgZm9yIGl0IHRvIGJlIHNldCBw
cm9wZXJseSBieSBuZWlnaGJvcnMuIEl0IGp1c3QNCj5tYWtlcyBpdCBzb21lb25lIGVsc2UncyBw
cm9ibGVtLCB3aGljaCBpcyBhIG1vcmUgZGlmZmljdWx0IHByb2JsZW0uDQo+DQo+T24gdGhlIG90
aGVyIGhhbmQsIHRoZSBJbmRleCBpcyBhbHJlYWR5IGd1YXJhbnRlZWQgdG8gYmUgdW5pcXVlIGF0
IGVhY2gNCj5saW5rIGluIHRoZSBjaGFpbi4NCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KPkZyb206IFJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29y
a3MuY29tXQ0KPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAxMTo0NyBBTQ0KPlRv
OiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgRGF2ZSBEb2xzb247IEpvZWwgTS4gSGFscGVybjsN
Cj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcNCj5DYzogQmVuIFdy
aWdodCAoQmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbSkNCj5TdWJqZWN0OiBSRTogW3NmY10gZHJh
ZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzDQo+DQo+QWdyZWUgdGhhdCBt
ZXRhZGF0YSBpcyBvbmUgd2F5IHRvIGhhbmRsZSB0aGlzLCBpbXBseWluZyB0aGF0IFNGLWZvbyBp
biBteQ0KPmV4YW1wbGUga25ldyB0aGF0IGZvciB0aGlzIHBhcnRpY3VsYXIgY2hhaW4gaXQgd2Fz
IGludm9rZWQgaW4gYSBzcGlyYWwNCj5hbmQgdGhlcmVmb3JlIGl0cyBmaXJzdCBpbnZvY2F0aW9u
IG5lZWRlZCB0byBpbnNlcnQgbWV0YWRhdGEgc28gdGhhdCBpdHMNCj5zdWJzZXF1ZW50IGludm9j
YXRpb25zIGNvdWxkIGRvIHRoZSByaWdodCB0aGluZy4NCj4NCj5UaGVyZSBpcyBhbHNvIGFuIGlt
cGxpY2F0aW9uIG9uIFJTUCBjb25zdHJ1Y3Rpb24gYW5kIGJpbmRpbmcgLS0gdGhlIHNhbWUNCj5p
bnN0YW5jZSBvZiBTRkYtZm9vIGxpa2VseSBuZWVkcyB0byBiZSBzZWxlY3RlZCBhdCBlYWNoIHBv
c2l0aW9uIHRoYXQgaXQNCj5vY2N1cnMgd2l0aGluIHRoZSBTRlAuDQo+DQo+ICAgUm9uDQo+DQo+
DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBKaW0gR3VpY2hhcmQgKGpndWlj
aGFyKSBbbWFpbHRvOmpndWljaGFyQGNpc2NvLmNvbV0NCj5TZW50OiBUaHVyc2RheSwgRmVicnVh
cnkgMjYsIDIwMTUgMTE6NDMgQU0NCj5UbzogUm9uIFBhcmtlcjsgRGF2ZSBEb2xzb247IEpvZWwg
TS4gSGFscGVybjsNCj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcN
Cj5DYzogQmVuIFdyaWdodCAoQmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbSkNCj5TdWJqZWN0OiBS
ZTogW3NmY10gZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzDQo+DQo+
U3VyZWx5IHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgU0ZDIGluZnJhc3RydWN0dXJlIGlzIHRv
IGRlbGl2ZXIgcGFja2V0cw0KPnRvIHRoZSBTRiB3aGVyZSBzYWlkIFNGIMKzZG9lcyBpdCB0aGlu
Z8KyLiBJdCBzZWVtcyB0byBtZSB0aGF0IGlmIHlvdSB3YW50DQo+ZGlmZmVyZW50IGJlaGF2aW9y
IGVhY2ggdGltZSB5b3UgdmlzaXQgYSBnaXZlbiBTRiB0aGVuIHlvdSBuZWVkIHRvDQo+cHJvdmlk
ZSBpdCBjb250ZXh0IHdpdGhpbiB0aGUgbWV0YWRhdGEgc28gaXQgY2FuIHBlcmZvcm0gdGhlIHJp
Z2h0IHRhc2suDQo+DQo+T24gMi8yNi8xNSwgMTE6MzAgQU0sICJSb24gUGFya2VyIiA8Um9uX1Bh
cmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4NCj53cm90ZToNCj4NCj4+SGksIERhdmUuDQo+Pg0K
Pj5JIGFncmVlIHRoYXQgb24gdGhlIHdpcmUsIHRoaXMgaXMgdGhlIHdheSBpdCB3b3VsZCB3b3Jr
Lg0KPj4NCj4+QnV0LCB3aGVuIGNvbXBvc2luZyB0aGUgY2hhaW4sIGl0IHNlZW1zIGxpa2UgaW5m
b3JtYXRpb24gd291bGQgYmUNCj4+bGFja2luZyBpZiBhIGNoYWluIHdlcmUgZXhwcmVzc2VkIHNp
bXBseSBhcyB7U0YtZm9vLCBTRi1iYXIsIFNGLWZvbywNCj4+U0YtZm9vYmFyfS4NCj4+ICBJdCBp
cyBjb21wbGV0ZWx5IGltcGxpY2l0IHRoYXQgc2luY2UgU0YtZm9vIGFwcGVhcnMgdHdpY2UsIGl0
IHBlcmhhcHMNCj4+c2hvdWxkIHBlcmZvcm0gc29tZSBkaWZmZXJlbnQgZHV0eSB3aGVuIGluZGV4
ID0gMCB2cyB3aGVuIGluZGV4ID0gMi4NCj4+DQo+PkF0IGZpcnN0LCBJIHRob3VnaHQgdGhhdCBh
biBhbHRlcm5hdGl2ZSB3YXkgdG8gaGFuZGxlIHRoaXMgd291bGQgYmUgdG8NCj4+dXNlIG11bHRp
cGxlIGxvZ2ljYWwgaWRlbnRpdGllcyBmb3IgU0YtZm9vLiAgSW4gdGhpcyBjYXNlLCB0aGUgY2hh
aW4NCj4+YWJvdmUgd291bGQgYmUgZXhwcmVzc2VkIGFzIHtTRi1mb28tZmlyc3QtYmVoYXZpb3Is
IFNGLWJhciwNCj4+U0YtZm9vLXNlY29uZC1iZWhhdmlvciwgU0YtZm9vYmFyfS4gICBCdXQsIHRo
ZSBwcm9ibGVtIGhlcmUgaXMgc2VsZWN0aW5nDQo+PnRoZSBSU1AsIGFzc3VtaW5nIHRoYXQgU0Yt
Zm9vIGhhcyBtdWx0aXBsZSBpbnN0YW5jZXMuICAgTm90aGluZyBpbiB0aGlzDQo+PnNlY29uZCBm
bGF2b3Igb2YgY2hhaW4gc2F5cyB0aGF0IHRoZSBzYW1lIGluc3RhbmNlIG9mIFNGLWZvby0qIG11
c3QgYmUNCj4+c2VsZWN0ZWQgdG8gc2F0aXNmeSBTRi1mb28tZmlyc3QtYmVoYXZpb3IgYW5kIFNG
LWZvby1zZWNvbmQtYmVoYXZpb3INCj4+KHdoaWNoIG1heSBub3QgYmUgcmVxdWlyZWQsIGJ1dCBz
aG91bGQgYmUgcG9zc2libGUgdG8gZm9yY2UgYXMgc3VjaCkuDQo+Pg0KPj5JIGd1ZXNzIHdoYXQg
SSdtIHNheWluZyBpcyB0aGF0IHNwaXJhbGluZyBoYXMgYSBzdWJ0bGV0eSB0byBpdCB0aGF0DQo+
Pmlzbid0IHlldCBhZGVxdWF0ZWx5IGFkZHJlc3NlZCBhbmQgdGhhdCBJIGRvbid0IGhhdmUgYSBz
cGVjaWZpYw0KPj5wcm9wb3NhbCB0byBzb2x2ZSBpdCwgZWl0aGVyLg0KPj4NCj4+ICAgUm9uDQo+
Pg0KPj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogc2ZjIFttYWlsdG86
c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZlIERvbHNvbg0KPj5TZW50OiBU
aHVyc2RheSwgRmVicnVhcnkgMjYsIDIwMTUgMTE6MjEgQU0NCj4+VG86IEpvZWwgTS4gSGFscGVy
bjsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnDQo+PkNjOiBCZW4g
V3JpZ2h0IChCZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tKQ0KPj5TdWJqZWN0OiBSZTogW3NmY10g
ZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzDQo+Pg0KPj5JZiBJIG1h
eSB0cnkgdG8gcHV0IGl0IHNpbXBseSwgSSd2ZSBhbHdheXMgdGhvdWdodCBvZiBpdCB0aGlzIHdh
eToNCj4+LS0+IEVhY2ggbm9kZSBpbiB0aGUgY2hhaW4gc2VsZWN0cyB0aGUgY29udGV4dCBmb3Ig
cHJvY2Vzc2luZyBhbmQgdGhlDQo+Pm5leHQgaG9wIG9uIHRoZSBiYXNpcyBvZiBCT1RIIHBhdGgg
SUQgYW5kIEluZGV4LCB3aGlsZSBkZWNyZW1lbnRpbmcgdGhlDQo+PmluZGV4IGZvciB0aGUgbmV4
dCBob3AuDQo+Pg0KPj5UaGF0IGJlaGF2aW9yIHN1cHBvcnRzIHNwaXJhbGluZy4NCj4+DQo+Pg0K
Pj4NCj4+LURhdmUNCj4+DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9t
OiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvZWwgTS4g
SGFscGVybg0KPj5TZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjYsIDIwMTUgMTA6MDIgQU0NCj4+
VG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KPj5DYzogQmVu
IFdyaWdodCAoQmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbSkNCj4+U3ViamVjdDogUmU6IFtzZmNd
IGRyYWZ0LXF1aW5uLXNmYy1uc2g6IFN1cHBvcnQgb2YgU0YgU3BpcmFscw0KPj4NCj4+VGhlcmUg
YXJlIHR3byBkaWZmZXJlbnQgYXNwZWN0cyBvZiBTcGlyYWxzLg0KPj4NCj4+T25lIG9mIHRoZSB0
d28gYXNwZWN0cyBpcyBlbmFibGluZyBhIHBhY2tldCB0aGF0IHJlcGVhdGVkbHkgYXJyaXZlcyBh
dA0KPj50aGUgc2FtZSBTRkYgdG8gZ2V0IHRoZSBjb3JyZWN0IHNlcnZpY2VzIHByb3ZpZGVkIGVh
Y2ggdGltZSBpdCBhcnJpdmVzLA0KPj5hbmQgdG8gZ28gdG8gdGhlIGNvcnJlY3QgbmV4dCBTRkYg
ZWFjaCB0aW1lIGl0IGFycml2ZXMuICBUaGUgU2VydmljZQ0KPj5QYXRoIEluZGV4LCB1c2VkIGJ5
IHRoZSBTRkYgdG8gc2VsZWN0IHNlcnZpY2UgZnVuY3Rpb25zIGFuZCBuZXh0IFNGRiwNCj4+cHJv
dmlkZXMgdGhhdCBjYXBhYmlsaXR5Lg0KPj4NCj4+VGhlIG90aGVyIGFzcGVjdCBpcyBob3cgdGhl
IFNlcnZpY2UgRnVuY3Rpb25zIHRoZW1zZWx2ZXMgaGFuZGxlIHNwaXJhbHMuDQo+PiAgVG8gYSBs
YXJnZSBkZWdyZWUsIHRoYXQgZGVwZW5kcyB1cG9uIHRoZSBpbmRpdmlkdWFsIHNlcnZpY2UgZnVu
Y3Rpb24uDQo+PiAgSSBub3JtYWxseSBhc3N1bWUgdGhhdCBpdCB3b3VsZCB1c2UgcGFja2V0IGNv
bnRleHQgKGFzIGRlc2NyaWJlZCBpbg0KPj50aGUgdGV4dCB5b3UgcXVvdGUpIHRvIGRldGVybWlu
ZSB3aGF0IHRvIGRvLg0KPj4NCj4+U2luY2UgSSB3b3VsZCBwcmVmZXIgdGhhdCBzZXJ2aWNlIGZ1
bmN0aW9ucyBhcmUgaW5kZXBlbmRlbnQgb2YgdGhlDQo+PnVuZGVybHlpbmcgc2VydmljZSBmdW5j
dGlvbiBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZSwgYW5kIGFyZSBub3QNCj4+c2Vuc2l0aXZlIHRv
IGhvdyBtYW55IGZ1bmN0aW9ucyBhcmUgYmVmb3JlIG9yIGFmdGVyIHRoZW0gaW4gdGhlIGNoYWlu
LA0KPj5JIHdvdWxkIHBlcnNvbmFsbHkgcHJlZmVyIHRoYXQgdGhleSBub3QgdXNlIHRoZSBwYXRo
IGluZGV4IGZvciB0aGF0LiAgSQ0KPj53b3VsZCByZWNvbW1lbmQgdGhhdCBpZiB0aGUgcGFja2V0
IGRvZXMgbm90IGNhcnJ5IGVub3VnaCBjb250ZXh0IHRoYXQNCj4+dGhlIHNlcnZpY2UgZnVuY3Rp
b24gY291bGQgYW5kIHNob3VsZCB1c2UgbWV0YWRhdGEgdG8gY2FycnkgaXRzIG5lZWRlZA0KPj5z
dGF0ZSBpbmZvcm1hdGlvbi4gIEJ1dCBuZWl0aGVyIEkgcGVyc29uYWxseSBub3IgdGhlIFNGQyBX
b3JraW5nIEdyb3VwDQo+PmdldCB0byB0ZWxsIGZvbGtzIGhvdyB0byBidWlsZCB0aGVpciBzZXJ2
aWNlIGZ1bmN0aW9ucy4gIFNvIHRoZXkgbWF5DQo+PmNvbWUgdXAgd2l0aCBvdGhlciBtZXRob2Rz
IGZvciBhZGRyZXNzaW5nIHRoZWlyIG5lZWRzLiAgV2hpY2ggaXMgYWxzbw0KPj5maW5lLg0KPj4N
Cj4+VGh1cywgSSB3b3VsZCBub3QgZXhwZWN0IHRoaXMgZG9jdW1lbnQgdG8gZGlzY3VzcyBob3cg
c2VydmljZSBmdW5jdGlvbnMNCj4+dGhlbXNlbHZlcyBoYW5kbGUgcmV2aXNpdGluZy4gIEJ1dCBt
ZXRhZGF0YSBjbGVhcmx5IGFsbG93cyBmb3IgYSByYW5nZQ0KPj5vZiBiZWhhdmlvcnMgdGhhdCB3
aWxsIHdvcmsuICBBbmQgdGhlIHBhdGggaW5kZXggaGFuZGxlcyB0aGUgU0ZGIG5lZWRzDQo+PnJl
bGF0aXZlIHRvIHNwaXJhbHMsIHdoaWNoIGlzIHdoYXQgd2UgbmVlZCB0byBoYW5kbGUuDQo+Pg0K
Pj5Zb3VycywNCj4+Sm9lbA0KPj4NCj4+T24gMi8yNi8xNSA5OjUyIEFNLCBtb2hhbWVkLmJvdWNh
ZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPj4+IFJlLSwNCj4+Pg0KPj4+IFNwaXJhbCBpcyBub3Qg
bWVudGlvbmVkIGluIHRoZSBkcmFmdCwgYnV0IFNGIGxvb3AgaXMuDQo+Pj4NCj4+PiBJJ20gYXNr
aW5nIHRoZSBxdWVzdGlvbiBiZWNhdXNlIEkgZG9uJ3QgZ2V0IGZyb20gdGhlIGRyYWZ0IGhvdw0K
Pj4+c3BpcmFscyBjb3VsZCB3b3JrICh0aGF0IGlzIGEgU0YgaW52b2tlZCBzZXZlcmFsIHRpbWUg
aW4gdGhlIGNvbnRleHQNCj4+Pm9mIHRoZSBzYW1lIFNGQykuDQo+Pj4NCj4+PiBCZWZvcmUgcHJv
cG9zaW5nIHRleHQsIEkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIGZpcnN0IGhvdyBpdCB3b3Jr
cy4NCj4+PklmIHlvdSBjYW4gcHJvdmlkZSBhbiBleGFtcGxlLCB0aGlzIHdpbGwgYmUgZXZlbiBn
cmVhdC4NCj4+Pg0KPj4+IFRoYW5rIHlvdS4NCj4+Pg0KPj4+IENoZWVycywNCj4+PiBNZWQNCj4+
Pg0KPj4+PiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4+Pj4gRGUgOiBKb2VsIE0uIEhh
bHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXSBFbnZvecOpIDogamV1ZGkgMjYNCj4+
Pj4gZsOpdnJpZXIgMjAxNSAxNTo0MSDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IHNm
Y0BpZXRmLm9yZyBDYyA6DQo+Pj4+IEJlbiBXcmlnaHQgKEJlbi5XcmlnaHRAbWV0YXN3aXRjaC5j
b20pIE9iamV0IDogUmU6IFtzZmNdDQo+Pj4+IGRyYWZ0LXF1aW5uLXNmYy1uc2g6IFN1cHBvcnQg
b2YgU0YgU3BpcmFscw0KPj4+Pg0KPj4+PiBUaGUgU0YgU3BpcmFscyByZXF1aXJlbWVudCBpcyBv
bmUgb2YgdGhlIGtleSBkcml2ZXJzIGZvciB0aGUgaW5kZXguDQo+Pj4+IFRoZSBpbmRleCBhbGxv
d3Mgb25lIHRvIHRlbGwgd2hlcmUgb25lIGlzIGluIHRoZSBzcGlyYWwsIGFuZCBhbHNvIHRvDQo+
Pj4+IGJyZWFrIGEgbG9vcCBpZiBvbmUgaGFzIGEgbG9vcCBpbnN0ZWFkIG9mIGEgc3BpcmFsLg0K
Pj4+Pg0KPj4+PiBJcyB0aGVyZSB0ZXh0IHRoYXQgd2UgY291bGQgYWRkIHRoYXQgd291bGQgaGVs
cCBtYWtlIHRoaXMgY2xlYXIsDQo+Pj4+IHNpbmNlIHlvdXIgZWFybGllciBxdWVzdGlvbiBhYm91
dCB0aGUgcGF0aCBpbmRleCBzdWdnZXN0cyB0aGF0IGl0IGlzDQo+Pj4+IG5vdCBhcyBjbGVhciBh
cyBpdCBzaG91bGQgYmU/DQo+Pj4+DQo+Pj4+IFlvdXJzLA0KPj4+PiBKb2VsDQo+Pj4+DQo+Pj4+
IE9uIDIvMjYvMTUgODo0MiBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToN
Cj4+Pj4+IEhpIFBhdWwsIGFsbCwNCj4+Pj4+DQo+Pj4+PiBUaGVyZSB3ZXJlIGEgZGlzY3Vzc2lv
biBpbiB0aGUgbWFpbGluZyBsaXN0DQo+Pj4+PiAoaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy
Y2hpdmUvd2ViL3NmYy9jdXJyZW50L21zZzAxNzAxLmh0bWwpDQo+Pj4+PiB0aGF0IGxlZCB0byBk
ZWZpbmluZyB3aGF0IGlzIG1lYW50IGJ5IFNGIFNwaXJhbHM6IChiZWxvdyBpcw0KPj4+Pj4gcHJv
dmlkZWQgYW4gZXhjZXJwdCBmcm9tDQo+Pj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k
cmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wNg0KPj4+Pj4gd2hlcmUgdGhlIGNvbmNs
dXNpb25zIG9mIHRoYXQgZGlzY3Vzc2lvbiB3ZXJlIHJlY29yZGVkKQ0KPj4+Pj4NCj4+Pj4+ICIg
ICBvICBTZXJ2aWNlIEZ1bmN0aW9uIFNwaXJhbDogZGVub3RlcyBhIFNlcnZpY2UgRnVuY3Rpb24g
Q2hhaW4gaW4NCj4+Pj4gd2hpY2gNCj4+Pj4+DQo+Pj4+PiAgICAgICAgIGRhdGEgaXMgaGFuZGxl
ZCBieSBhIFNlcnZpY2UgRnVuY3Rpb24sIGZvcndhcmRlZCBvbndhcmRzLA0KPj4+Pj4gYW5kDQo+
Pj4+Pg0KPj4+Pj4gICAgICAgICBhcnJpdmVzIG9uY2UgYWdhaW4gYXQgdGhhdCBTZXJ2aWNlIEZ1
bmN0aW9uLg0KPj4+Pj4NCj4+Pj4+ICAgICAgICAgKiAgTm90ZSB0aGF0IHNvbWUgU2VydmljZSBG
dW5jdGlvbnMgc3VwcG9ydCBidWlsdC1pbg0KPj4+Pj4gZnVuY3Rpb25zIHRvDQo+Pj4+Pg0KPj4+
Pj4gICAgICAgICAgICBhY2NvbW1vZGF0ZSBzcGlyYWxzOyB0aGVzZSBzZXJ2aWNlLXNwZWNpZmlj
IGZ1bmN0aW9ucw0KPj4+Pj4gbWF5DQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAgICByZXF1aXJlIHRo
YXQgdGhlIGRhdGEgcmVjZWl2ZWQgaW4gYSBzcGlyYWwgc2hvdWxkIGRpZmZlcg0KPj4+Pj4gaW4g
YQ0KPj4+Pj4NCj4+Pj4+ICAgICAgICAgICAgd2F5IHRoYXQgd2lsbCByZXN1bHQgaW4gYSBkaWZm
ZXJlbnQgcHJvY2Vzc2luZyBkZWNpc2lvbg0KPj4+Pj4gdGhhbg0KPj4+Pj4NCj4+Pj4+ICAgICAg
ICAgICAgdGhlIG9yaWdpbmFsIGRhdGEuICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IG1ha2Ugc3Vj
aA0KPj4+Pj4NCj4+Pj4+ICAgICAgICAgICAgYXNzdW1wdGlvbi4NCj4+Pj4+DQo+Pj4+PiAgICAg
ICAgICogIEEgU2VydmljZSBGdW5jdGlvbiBDaGFpbiBtYXkgaW52b2x2ZSBvbmUgb3IgbW9yZSBT
ZXJ2aWNlDQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAgICBGdW5jdGlvbiBTcGlyYWxzLg0KPj4+Pj4N
Cj4+Pj4+ICAgICAgICAgKiAgVW5saWtlIFNlcnZpY2UgRnVuY3Rpb24gbG9vcCwgc3BpcmFscyBh
cmUgbm90IGNvbnNpZGVyZWQNCj4+Pj4+IGFzDQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAgICBlcnJv
cnMuIg0KPj4+Pj4NCj4+Pj4+IEFuZCB0aGlzIGNvbXBhbmlvbiByZXF1aXJlbWVudDoNCj4+Pj4+
DQo+Pj4+PiAiICAgICAgICAgICAgICAgQS4gIFNlcnZpY2UgRnVuY3Rpb25zIE1BWSBiZSBpbnZv
a2VkIG11bHRpcGxlIHRpbWVzDQo+Pj4+PmluDQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAgICAgICAg
ICAgICAgdGhlIHNhbWUgU2VydmljZSBGdW5jdGlvbiBDaGFpbiAoZGVub3RlZCBhcyBTRg0KPj4+
Pj4NCj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgIFNwaXJhbCksIGJ1dCB0aGUgc29sdXRpb24g
TVVTVCBwcmV2ZW50DQo+Pj4+PiBpbmZpbml0ZQ0KPj4+Pj4NCj4+Pj4+ICAgICAgICAgICAgICAg
ICAgICAgIGZvcndhcmRpbmcgbG9vcHMuIMK7DQo+Pj4+Pg0KPj4+Pj4gUmVhZGluZyB0aGUgY3Vy
cmVudCBkcmFmdC1xdWlubi1zZmMtbnNoLCBJIGRvbid0IHNlZSBob3cgdGhpcyBpcyBtZXQuDQo+
Pj4+Pg0KPj4+Pj4gQ2FuIHlvdSBwbGVhc2UgY2xhcmlmeSB3aGV0aGVyIHRoaXMgaXMgc3VwcG9y
dGVkIGFuZCBob3c/DQo+Pj4+Pg0KPj4+Pj4gVGhhbmsgeW91Lg0KPj4+Pj4NCj4+Pj4+IENoZWVy
cywNCj4+Pj4+DQo+Pj4+PiBNZWQNCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBzZmMgbWFpbGlu
ZyBsaXN0DQo+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vc2ZjDQo+Pj4+Pg0KPj4+DQo+Pg0KPj5fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5zZmMgbWFpbGluZyBsaXN0DQo+PnNmY0Bp
ZXRmLm9yZw0KPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4N
Cj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+c2Zj
IG1haWxpbmcgbGlzdA0KPj5zZmNAaWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9zZmMNCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+PnNmYyBtYWlsaW5nIGxpc3QNCj4+c2ZjQGlldGYub3JnDQo+Pmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQoNCg==


From nobody Thu Feb 26 09:30: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 DC8871A9105 for ; Thu, 26 Feb 2015 09:30:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgWCAQllqKa0 for ; Thu, 26 Feb 2015 09:30:05 -0800 (PST)
Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id F32ED1A874B for ; Thu, 26 Feb 2015 09:30:04 -0800 (PST)
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 12:30:04 -0500
From: Dave Dolson 
To: "Reinaldo Penno (repenno)" , Ron Parker , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" 
Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
Thread-Index: AdBRyhUadMfMQp0TQVyP+AHUYniSlAAMhaQAAABleoAAAFj2AAAJAG9w///QlQCAAFBcIP//vPuAgABSEAA=
Date: Thu, 26 Feb 2015 17:30:03 +0000
Message-ID: 
References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3584.2080005@joelhalpern.com>    
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" 
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
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, 26 Feb 2015 17:30:08 -0000

For the sake of argument, suppose I have a firewall SF, and I want to use=20
it more than once in a chain. (Maybe I want to book-end the chain with ingr=
ess
and egress rules.)

Do you agree it would be sufficient to use the Path Index to select which o=
f
the ingress or egress rule sets should be used?

I'm probably missing something; I don't understand how the context headers
define functionality. Maybe the device could communicate with itself=20
(e.g., the ingress portion sending a tag to the egress portion)
by sending state in the packet. Is that what you are mean by "contextual in=
fo" ?



-----Original Message-----
From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]=20
Sent: Thursday, February 26, 2015 12:18 PM
To: Dave Dolson; Ron Parker; Joel M. Halpern; mohamed.boucadair@orange.com;=
 sfc@ietf.org
Cc: Ben Wright (Ben.Wright@metaswitch.com)
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals

Agreed on all points. I thought I was missing something so before writing
this email I retested our implementation and it worked off the bat. The
RSP constructed has the the same (SFF, SF) tuple but different indexes.

The same SF is visited multiple times until the path ends.  If the SF
wants contextual info across visits than context headers are the way to
go.=20


On 2/26/15, 8:52 AM, "Dave Dolson"  wrote:

>Maybe naively, I thought the service functions would be provisioned with
>a table:
>
>E.g., for element foo:
>Path | Path Index | Next Hop  | Function
> 123 |  4         |   SF-bar  | first behavior
> 123 |  2         | SF-foobar | second behavior
>
>
>The Function is clearly implementation specific. Maybe it points to a
>configuration set or a policy set. I think completely out of scope here.
>
>I suggest that this is not a problem for the wire protocol, rather for
>the configuration model (netconf or whatever).
>
>It becomes very much vendor-specific if the behaviors are complex
>configurations of specialized features.
>
>If a person were manually configuring chains, I don't think they'd have a
>conceptual problem, because they'd have a diagram they need to implement:
>{SF-foo (first-behavior), SF-bar, SF-foo (second-behavior), SF-foobar}
>
>If we wanted to standardize it, we could maybe make the Function simply a
>label that means something to the device--an indirection to a
>configuration set.
>
>-Dave
>
>
>
>-----Original Message-----
>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker
>Sent: Thursday, February 26, 2015 11:31 AM
>To: Dave Dolson; Joel M. Halpern; mohamed.boucadair@orange.com;
>sfc@ietf.org
>Cc: Ben Wright (Ben.Wright@metaswitch.com)
>Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>
>Hi, Dave.
>
>I agree that on the wire, this is the way it would work.
>
>But, when composing the chain, it seems like information would be lacking
>if a chain were expressed simply as {SF-foo, SF-bar, SF-foo, SF-foobar}.
>  It is completely implicit that since SF-foo appears twice, it perhaps
>should perform some different duty when index =3D 0 vs when index =3D 2.
>
>At first, I thought that an alternative way to handle this would be to
>use multiple logical identities for SF-foo.  In this case, the chain
>above would be expressed as {SF-foo-first-behavior, SF-bar,
>SF-foo-second-behavior, SF-foobar}.   But, the problem here is selecting
>the RSP, assuming that SF-foo has multiple instances.   Nothing in this
>second flavor of chain says that the same instance of SF-foo-* must be
>selected to satisfy SF-foo-first-behavior and SF-foo-second-behavior
>(which may not be required, but should be possible to force as such).
>
>I guess what I'm saying is that spiraling has a subtlety to it that isn't
>yet adequately addressed and that I don't have a specific proposal to
>solve it, either.
>
>   Ron
>
>
>-----Original Message-----
>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
>Sent: Thursday, February 26, 2015 11:21 AM
>To: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org
>Cc: Ben Wright (Ben.Wright@metaswitch.com)
>Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>
>If I may try to put it simply, I've always thought of it this way:
>--> Each node in the chain selects the context for processing and the
>next hop on the basis of BOTH path ID and Index, while decrementing the
>index for the next hop.
>
>That behavior supports spiraling.
>
>
>
>-Dave
>
>
>-----Original Message-----
>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
>Sent: Thursday, February 26, 2015 10:02 AM
>To: mohamed.boucadair@orange.com; sfc@ietf.org
>Cc: Ben Wright (Ben.Wright@metaswitch.com)
>Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>
>There are two different aspects of Spirals.
>
>One of the two aspects is enabling a packet that repeatedly arrives at
>the same SFF to get the correct services provided each time it arrives,
>and to go to the correct next SFF each time it arrives.  The Service Path
>Index, used by the SFF to select service functions and next SFF, provides
>that capability.
>
>The other aspect is how the Service Functions themselves handle spirals.
>  To a large degree, that depends upon the individual service function.
>  I normally assume that it would use packet context (as described in the
>text you quote) to determine what to do.
>
>Since I would prefer that service functions are independent of the
>underlying service function chaining infrastructure, and are not
>sensitive to how many functions are before or after them in the chain, I
>would personally prefer that they not use the path index for that.  I
>would recommend that if the packet does not carry enough context that the
>service function could and should use metadata to carry its needed state
>information.  But neither I personally nor the SFC Working Group get to
>tell folks how to build their service functions.  So they may come up
>with other methods for addressing their needs.  Which is also fine.
>
>Thus, I would not expect this document to discuss how service functions
>themselves handle revisiting.  But metadata clearly allows for a range of
>behaviors that will work.  And the path index handles the SFF needs
>relative to spirals, which is what we need to handle.
>
>Yours,
>Joel
>
>On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote:
>> Re-,
>>
>> Spiral is not mentioned in the draft, but SF loop is.
>>
>> I'm asking the question because I don't get from the draft how spirals
>>could work (that is a SF invoked several time in the context of the same
>>SFC).
>>
>> Before proposing text, I would like to understand first how it works.
>>If you can provide an example, this will be even great.
>>
>> Thank you.
>>
>> Cheers,
>> Med
>>
>>> -----Message d'origine-----
>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : jeudi 26
>>> f=E9vrier 2015 15:41 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Cc :
>>> Ben Wright (Ben.Wright@metaswitch.com) Objet : Re: [sfc]
>>> draft-quinn-sfc-nsh: Support of SF Spirals
>>>
>>> The SF Spirals requirement is one of the key drivers for the index.
>>> The index allows one to tell where one is in the spiral, and also to
>>> break a loop if one has a loop instead of a spiral.
>>>
>>> Is there text that we could add that would help make this clear,
>>> since your earlier question about the path index suggests that it is
>>> not as clear as it should be?
>>>
>>> Yours,
>>> Joel
>>>
>>> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote:
>>>> Hi Paul, all,
>>>>
>>>> There were a discussion in the mailing list
>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html)
>>>> that led to defining what is meant by SF Spirals: (below is provided
>>>> an excerpt from
>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where
>>>> the conclusions of that discussion were recorded)
>>>>
>>>> "   o  Service Function Spiral: denotes a Service Function Chain in
>>> which
>>>>
>>>>         data is handled by a Service Function, forwarded onwards,
>>>> and
>>>>
>>>>         arrives once again at that Service Function.
>>>>
>>>>         *  Note that some Service Functions support built-in
>>>> functions to
>>>>
>>>>            accommodate spirals; these service-specific functions may
>>>>
>>>>            require that the data received in a spiral should differ
>>>> in a
>>>>
>>>>            way that will result in a different processing decision
>>>> than
>>>>
>>>>            the original data.  This document does not make such
>>>>
>>>>            assumption.
>>>>
>>>>         *  A Service Function Chain may involve one or more Service
>>>>
>>>>            Function Spirals.
>>>>
>>>>         *  Unlike Service Function loop, spirals are not considered
>>>> as
>>>>
>>>>            errors."
>>>>
>>>> And this companion requirement:
>>>>
>>>> "               A.  Service Functions MAY be invoked multiple times in
>>>>
>>>>                      the same Service Function Chain (denoted as SF
>>>>
>>>>                      Spiral), but the solution MUST prevent infinite
>>>>
>>>>                      forwarding loops. =BB
>>>>
>>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is met.
>>>>
>>>> Can you please clarify whether this is supported and how?
>>>>
>>>> Thank you.
>>>>
>>>> Cheers,
>>>>
>>>> Med
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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 Thu Feb 26 09:36: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 296531A023E for ; Thu, 26 Feb 2015 09:36:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 yFYsX4rg91uf for ; Thu, 26 Feb 2015 09:36:01 -0800 (PST)
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 893741A026F for ; Thu, 26 Feb 2015 09:36:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 6DC30240858; Thu, 26 Feb 2015 09:36:01 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net
Received: from Joels-MacBook-Pro.local (unknown [50.95.128.180]) (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 6A26C24090B; Thu, 26 Feb 2015 09:36:00 -0800 (PST)
Message-ID: <54EF596C.1080608@joelhalpern.com>
Date: Thu, 26 Feb 2015 12:35:40 -0500
From: "Joel M. Halpern" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Dave Dolson ,  "Reinaldo Penno (repenno)" , Ron Parker ,  "mohamed.boucadair@orange.com" , "sfc@ietf.org" 
References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3584.2080005@joelhalpern.com>     
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" 
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
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, 26 Feb 2015 17:36:04 -0000

Personally, I would prefer that the firewall use metadata rather than 
path-index.  My reasoning is that if functions get added before or after 
the firewall, operations would prefer not to have to change the 
configuration of the firewall SF itself.

Having said that, I don't see any way to stop you from using the path index.

Yours,
Joel

On 2/26/15 12:30 PM, Dave Dolson wrote:
> For the sake of argument, suppose I have a firewall SF, and I want to use
> it more than once in a chain. (Maybe I want to book-end the chain with ingress
> and egress rules.)
>
> Do you agree it would be sufficient to use the Path Index to select which of
> the ingress or egress rule sets should be used?
>
> I'm probably missing something; I don't understand how the context headers
> define functionality. Maybe the device could communicate with itself
> (e.g., the ingress portion sending a tag to the egress portion)
> by sending state in the packet. Is that what you are mean by "contextual info" ?
>
>
>
> -----Original Message-----
> From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
> Sent: Thursday, February 26, 2015 12:18 PM
> To: Dave Dolson; Ron Parker; Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org
> Cc: Ben Wright (Ben.Wright@metaswitch.com)
> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>
> Agreed on all points. I thought I was missing something so before writing
> this email I retested our implementation and it worked off the bat. The
> RSP constructed has the the same (SFF, SF) tuple but different indexes.
>
> The same SF is visited multiple times until the path ends.  If the SF
> wants contextual info across visits than context headers are the way to
> go.
>
>
> On 2/26/15, 8:52 AM, "Dave Dolson"  wrote:
>
>> Maybe naively, I thought the service functions would be provisioned with
>> a table:
>>
>> E.g., for element foo:
>> Path | Path Index | Next Hop  | Function
>> 123 |  4         |   SF-bar  | first behavior
>> 123 |  2         | SF-foobar | second behavior
>>
>>
>> The Function is clearly implementation specific. Maybe it points to a
>> configuration set or a policy set. I think completely out of scope here.
>>
>> I suggest that this is not a problem for the wire protocol, rather for
>> the configuration model (netconf or whatever).
>>
>> It becomes very much vendor-specific if the behaviors are complex
>> configurations of specialized features.
>>
>> If a person were manually configuring chains, I don't think they'd have a
>> conceptual problem, because they'd have a diagram they need to implement:
>> {SF-foo (first-behavior), SF-bar, SF-foo (second-behavior), SF-foobar}
>>
>> If we wanted to standardize it, we could maybe make the Function simply a
>> label that means something to the device--an indirection to a
>> configuration set.
>>
>> -Dave
>>
>>
>>
>> -----Original Message-----
>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker
>> Sent: Thursday, February 26, 2015 11:31 AM
>> To: Dave Dolson; Joel M. Halpern; mohamed.boucadair@orange.com;
>> sfc@ietf.org
>> Cc: Ben Wright (Ben.Wright@metaswitch.com)
>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>>
>> Hi, Dave.
>>
>> I agree that on the wire, this is the way it would work.
>>
>> But, when composing the chain, it seems like information would be lacking
>> if a chain were expressed simply as {SF-foo, SF-bar, SF-foo, SF-foobar}.
>>   It is completely implicit that since SF-foo appears twice, it perhaps
>> should perform some different duty when index = 0 vs when index = 2.
>>
>> At first, I thought that an alternative way to handle this would be to
>> use multiple logical identities for SF-foo.  In this case, the chain
>> above would be expressed as {SF-foo-first-behavior, SF-bar,
>> SF-foo-second-behavior, SF-foobar}.   But, the problem here is selecting
>> the RSP, assuming that SF-foo has multiple instances.   Nothing in this
>> second flavor of chain says that the same instance of SF-foo-* must be
>> selected to satisfy SF-foo-first-behavior and SF-foo-second-behavior
>> (which may not be required, but should be possible to force as such).
>>
>> I guess what I'm saying is that spiraling has a subtlety to it that isn't
>> yet adequately addressed and that I don't have a specific proposal to
>> solve it, either.
>>
>>    Ron
>>
>>
>> -----Original Message-----
>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
>> Sent: Thursday, February 26, 2015 11:21 AM
>> To: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org
>> Cc: Ben Wright (Ben.Wright@metaswitch.com)
>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>>
>> If I may try to put it simply, I've always thought of it this way:
>> --> Each node in the chain selects the context for processing and the
>> next hop on the basis of BOTH path ID and Index, while decrementing the
>> index for the next hop.
>>
>> That behavior supports spiraling.
>>
>>
>>
>> -Dave
>>
>>
>> -----Original Message-----
>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
>> Sent: Thursday, February 26, 2015 10:02 AM
>> To: mohamed.boucadair@orange.com; sfc@ietf.org
>> Cc: Ben Wright (Ben.Wright@metaswitch.com)
>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>>
>> There are two different aspects of Spirals.
>>
>> One of the two aspects is enabling a packet that repeatedly arrives at
>> the same SFF to get the correct services provided each time it arrives,
>> and to go to the correct next SFF each time it arrives.  The Service Path
>> Index, used by the SFF to select service functions and next SFF, provides
>> that capability.
>>
>> The other aspect is how the Service Functions themselves handle spirals.
>>   To a large degree, that depends upon the individual service function.
>>   I normally assume that it would use packet context (as described in the
>> text you quote) to determine what to do.
>>
>> Since I would prefer that service functions are independent of the
>> underlying service function chaining infrastructure, and are not
>> sensitive to how many functions are before or after them in the chain, I
>> would personally prefer that they not use the path index for that.  I
>> would recommend that if the packet does not carry enough context that the
>> service function could and should use metadata to carry its needed state
>> information.  But neither I personally nor the SFC Working Group get to
>> tell folks how to build their service functions.  So they may come up
>> with other methods for addressing their needs.  Which is also fine.
>>
>> Thus, I would not expect this document to discuss how service functions
>> themselves handle revisiting.  But metadata clearly allows for a range of
>> behaviors that will work.  And the path index handles the SFF needs
>> relative to spirals, which is what we need to handle.
>>
>> Yours,
>> Joel
>>
>> On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote:
>>> Re-,
>>>
>>> Spiral is not mentioned in the draft, but SF loop is.
>>>
>>> I'm asking the question because I don't get from the draft how spirals
>>> could work (that is a SF invoked several time in the context of the same
>>> SFC).
>>>
>>> Before proposing text, I would like to understand first how it works.
>>> If you can provide an example, this will be even great.
>>>
>>> Thank you.
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoyé : jeudi 26
>>>> février 2015 15:41 Ŕ : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Cc :
>>>> Ben Wright (Ben.Wright@metaswitch.com) Objet : Re: [sfc]
>>>> draft-quinn-sfc-nsh: Support of SF Spirals
>>>>
>>>> The SF Spirals requirement is one of the key drivers for the index.
>>>> The index allows one to tell where one is in the spiral, and also to
>>>> break a loop if one has a loop instead of a spiral.
>>>>
>>>> Is there text that we could add that would help make this clear,
>>>> since your earlier question about the path index suggests that it is
>>>> not as clear as it should be?
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote:
>>>>> Hi Paul, all,
>>>>>
>>>>> There were a discussion in the mailing list
>>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html)
>>>>> that led to defining what is meant by SF Spirals: (below is provided
>>>>> an excerpt from
>>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where
>>>>> the conclusions of that discussion were recorded)
>>>>>
>>>>> "   o  Service Function Spiral: denotes a Service Function Chain in
>>>> which
>>>>>
>>>>>          data is handled by a Service Function, forwarded onwards,
>>>>> and
>>>>>
>>>>>          arrives once again at that Service Function.
>>>>>
>>>>>          *  Note that some Service Functions support built-in
>>>>> functions to
>>>>>
>>>>>             accommodate spirals; these service-specific functions may
>>>>>
>>>>>             require that the data received in a spiral should differ
>>>>> in a
>>>>>
>>>>>             way that will result in a different processing decision
>>>>> than
>>>>>
>>>>>             the original data.  This document does not make such
>>>>>
>>>>>             assumption.
>>>>>
>>>>>          *  A Service Function Chain may involve one or more Service
>>>>>
>>>>>             Function Spirals.
>>>>>
>>>>>          *  Unlike Service Function loop, spirals are not considered
>>>>> as
>>>>>
>>>>>             errors."
>>>>>
>>>>> And this companion requirement:
>>>>>
>>>>> "               A.  Service Functions MAY be invoked multiple times in
>>>>>
>>>>>                       the same Service Function Chain (denoted as SF
>>>>>
>>>>>                       Spiral), but the solution MUST prevent infinite
>>>>>
>>>>>                       forwarding loops. »
>>>>>
>>>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is met.
>>>>>
>>>>> Can you please clarify whether this is supported and how?
>>>>>
>>>>> Thank you.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Med
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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 Thu Feb 26 09:38: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 085691AC39A for ; Thu, 26 Feb 2015 09:38:08 -0800 (PST)
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 n3bNkP6klRrO for ; Thu, 26 Feb 2015 09:38:01 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C90E1A92EA for ; Thu, 26 Feb 2015 09:38:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10941; q=dns/txt; s=iport; t=1424972282; x=1426181882; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rO404EXOnzuS6HbCVHXwjLGY/63mCrgKHbe2N9xTDW8=; b=lwfhC3Kb+lZcNXmgGv3/UVtDJ+o3vtKct+VvtxVbuv5C/WjJbJePWcWR vR775EkRjgm3UoM0L87SpINU5FAHHwK21rd/Jv/9X55qVs+43gr171/FU hzJf8eKB7S/Ypdr7ftXIuv34Z5a5kGA/38QnlemYykj/7MBbDS4L678ml A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CSBQC4WO9U/5RdJa1bgwJSWgTBeQqFcAKBJE0BAQEBAQF8hA8BAQEEAQEBJEcLDAQCAQgOAwQBAQEnBycLFAkIAgQBDQUJEogUDdcgAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sThAwQAgEcMwIFBoQlBYVthD2FRYNghWWBGzmCZYtSgz4jg25vAYFDfwEBAQ
X-IronPort-AV: E=Sophos;i="5.09,653,1418083200"; d="scan'208";a="399406462"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP; 26 Feb 2015 17:38:00 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t1QHc05o032121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Feb 2015 17:38:00 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.248]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 11:37:59 -0600
From: "Reinaldo Penno (repenno)" 
To: Dave Dolson , Ron Parker , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" 
Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
Thread-Index: AdBRyhUadMfMQp0TQVyP+AHUYniSlAAMhaQAAABleoAAAFj2AAAJAG9w///hWACAAAYEAP//gTYAgACJaoD//3wbgA==
Date: Thu, 26 Feb 2015 17:37:59 +0000
Message-ID: 
References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3584.2080005@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.4.7.141117
x-originating-ip: [10.24.96.182]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <15F80371286CB24A85BE1BECB30D1E11@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" 
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
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, 26 Feb 2015 17:38:08 -0000

On 2/26/15, 9:30 AM, "Dave Dolson"  wrote:

>For the sake of argument, suppose I have a firewall SF, and I want to use
>it more than once in a chain. (Maybe I want to book-end the chain with
>ingress
>and egress rules.)
>
>Do you agree it would be sufficient to use the Path Index to select which
>of
>the ingress or egress rule sets should be used?

[RP] Yes. But it is really up to the SF to decide what to do when it looks
up the SI.  From a SFF perspective the tuple SP/SI denotes a network
endpoint. If the SF uses internally a SI as a demux to map to different
policies or rules it is really an implementation detail.

>
>I'm probably missing something; I don't understand how the context headers
>define functionality. Maybe the device could communicate with itself
>(e.g., the ingress portion sending a tag to the egress portion)
>by sending state in the packet. Is that what you are mean by "contextual
>info" ?

[RP] Precisely.=20

>
>
>
>-----Original Message-----
>From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
>Sent: Thursday, February 26, 2015 12:18 PM
>To: Dave Dolson; Ron Parker; Joel M. Halpern;
>mohamed.boucadair@orange.com; sfc@ietf.org
>Cc: Ben Wright (Ben.Wright@metaswitch.com)
>Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>
>Agreed on all points. I thought I was missing something so before writing
>this email I retested our implementation and it worked off the bat. The
>RSP constructed has the the same (SFF, SF) tuple but different indexes.
>
>The same SF is visited multiple times until the path ends.  If the SF
>wants contextual info across visits than context headers are the way to
>go.=20
>
>
>On 2/26/15, 8:52 AM, "Dave Dolson"  wrote:
>
>>Maybe naively, I thought the service functions would be provisioned with
>>a table:
>>
>>E.g., for element foo:
>>Path | Path Index | Next Hop  | Function
>> 123 |  4         |   SF-bar  | first behavior
>> 123 |  2         | SF-foobar | second behavior
>>
>>
>>The Function is clearly implementation specific. Maybe it points to a
>>configuration set or a policy set. I think completely out of scope here.
>>
>>I suggest that this is not a problem for the wire protocol, rather for
>>the configuration model (netconf or whatever).
>>
>>It becomes very much vendor-specific if the behaviors are complex
>>configurations of specialized features.
>>
>>If a person were manually configuring chains, I don't think they'd have a
>>conceptual problem, because they'd have a diagram they need to implement:
>>{SF-foo (first-behavior), SF-bar, SF-foo (second-behavior), SF-foobar}
>>
>>If we wanted to standardize it, we could maybe make the Function simply a
>>label that means something to the device--an indirection to a
>>configuration set.
>>
>>-Dave
>>
>>
>>
>>-----Original Message-----
>>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker
>>Sent: Thursday, February 26, 2015 11:31 AM
>>To: Dave Dolson; Joel M. Halpern; mohamed.boucadair@orange.com;
>>sfc@ietf.org
>>Cc: Ben Wright (Ben.Wright@metaswitch.com)
>>Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>>
>>Hi, Dave.
>>
>>I agree that on the wire, this is the way it would work.
>>
>>But, when composing the chain, it seems like information would be lacking
>>if a chain were expressed simply as {SF-foo, SF-bar, SF-foo, SF-foobar}.
>>  It is completely implicit that since SF-foo appears twice, it perhaps
>>should perform some different duty when index =3D 0 vs when index =3D 2.
>>
>>At first, I thought that an alternative way to handle this would be to
>>use multiple logical identities for SF-foo.  In this case, the chain
>>above would be expressed as {SF-foo-first-behavior, SF-bar,
>>SF-foo-second-behavior, SF-foobar}.   But, the problem here is selecting
>>the RSP, assuming that SF-foo has multiple instances.   Nothing in this
>>second flavor of chain says that the same instance of SF-foo-* must be
>>selected to satisfy SF-foo-first-behavior and SF-foo-second-behavior
>>(which may not be required, but should be possible to force as such).
>>
>>I guess what I'm saying is that spiraling has a subtlety to it that isn't
>>yet adequately addressed and that I don't have a specific proposal to
>>solve it, either.
>>
>>   Ron
>>
>>
>>-----Original Message-----
>>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
>>Sent: Thursday, February 26, 2015 11:21 AM
>>To: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org
>>Cc: Ben Wright (Ben.Wright@metaswitch.com)
>>Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>>
>>If I may try to put it simply, I've always thought of it this way:
>>--> Each node in the chain selects the context for processing and the
>>next hop on the basis of BOTH path ID and Index, while decrementing the
>>index for the next hop.
>>
>>That behavior supports spiraling.
>>
>>
>>
>>-Dave
>>
>>
>>-----Original Message-----
>>From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
>>Sent: Thursday, February 26, 2015 10:02 AM
>>To: mohamed.boucadair@orange.com; sfc@ietf.org
>>Cc: Ben Wright (Ben.Wright@metaswitch.com)
>>Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>>
>>There are two different aspects of Spirals.
>>
>>One of the two aspects is enabling a packet that repeatedly arrives at
>>the same SFF to get the correct services provided each time it arrives,
>>and to go to the correct next SFF each time it arrives.  The Service Path
>>Index, used by the SFF to select service functions and next SFF, provides
>>that capability.
>>
>>The other aspect is how the Service Functions themselves handle spirals.
>>  To a large degree, that depends upon the individual service function.
>>  I normally assume that it would use packet context (as described in the
>>text you quote) to determine what to do.
>>
>>Since I would prefer that service functions are independent of the
>>underlying service function chaining infrastructure, and are not
>>sensitive to how many functions are before or after them in the chain, I
>>would personally prefer that they not use the path index for that.  I
>>would recommend that if the packet does not carry enough context that the
>>service function could and should use metadata to carry its needed state
>>information.  But neither I personally nor the SFC Working Group get to
>>tell folks how to build their service functions.  So they may come up
>>with other methods for addressing their needs.  Which is also fine.
>>
>>Thus, I would not expect this document to discuss how service functions
>>themselves handle revisiting.  But metadata clearly allows for a range of
>>behaviors that will work.  And the path index handles the SFF needs
>>relative to spirals, which is what we need to handle.
>>
>>Yours,
>>Joel
>>
>>On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote:
>>> Re-,
>>>
>>> Spiral is not mentioned in the draft, but SF loop is.
>>>
>>> I'm asking the question because I don't get from the draft how spirals
>>>could work (that is a SF invoked several time in the context of the same
>>>SFC).
>>>
>>> Before proposing text, I would like to understand first how it works.
>>>If you can provide an example, this will be even great.
>>>
>>> Thank you.
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : jeudi 26
>>>> f=E9vrier 2015 15:41 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Cc =
:
>>>> Ben Wright (Ben.Wright@metaswitch.com) Objet : Re: [sfc]
>>>> draft-quinn-sfc-nsh: Support of SF Spirals
>>>>
>>>> The SF Spirals requirement is one of the key drivers for the index.
>>>> The index allows one to tell where one is in the spiral, and also to
>>>> break a loop if one has a loop instead of a spiral.
>>>>
>>>> Is there text that we could add that would help make this clear,
>>>> since your earlier question about the path index suggests that it is
>>>> not as clear as it should be?
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote:
>>>>> Hi Paul, all,
>>>>>
>>>>> There were a discussion in the mailing list
>>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html)
>>>>> that led to defining what is meant by SF Spirals: (below is provided
>>>>> an excerpt from
>>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where
>>>>> the conclusions of that discussion were recorded)
>>>>>
>>>>> "   o  Service Function Spiral: denotes a Service Function Chain in
>>>> which
>>>>>
>>>>>         data is handled by a Service Function, forwarded onwards,
>>>>> and
>>>>>
>>>>>         arrives once again at that Service Function.
>>>>>
>>>>>         *  Note that some Service Functions support built-in
>>>>> functions to
>>>>>
>>>>>            accommodate spirals; these service-specific functions may
>>>>>
>>>>>            require that the data received in a spiral should differ
>>>>> in a
>>>>>
>>>>>            way that will result in a different processing decision
>>>>> than
>>>>>
>>>>>            the original data.  This document does not make such
>>>>>
>>>>>            assumption.
>>>>>
>>>>>         *  A Service Function Chain may involve one or more Service
>>>>>
>>>>>            Function Spirals.
>>>>>
>>>>>         *  Unlike Service Function loop, spirals are not considered
>>>>> as
>>>>>
>>>>>            errors."
>>>>>
>>>>> And this companion requirement:
>>>>>
>>>>> "               A.  Service Functions MAY be invoked multiple times
>>>>>in
>>>>>
>>>>>                      the same Service Function Chain (denoted as SF
>>>>>
>>>>>                      Spiral), but the solution MUST prevent infinite
>>>>>
>>>>>                      forwarding loops. =BB
>>>>>
>>>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is met.
>>>>>
>>>>> Can you please clarify whether this is supported and how?
>>>>>
>>>>> Thank you.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Med
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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 Thu Feb 26 10:14:25 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 A07B71A92B2 for ; Thu, 26 Feb 2015 10:14:24 -0800 (PST)
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 sNsI1KEAPmhe for ; Thu, 26 Feb 2015 10:14:21 -0800 (PST)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECAB1A90AD for ; Thu, 26 Feb 2015 10:14:21 -0800 (PST)
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; Thu, 26 Feb 2015 13:14:20 -0500
From: Dave Dolson 
To: "Joel M. Halpern" , "Reinaldo Penno (repenno)" , Ron Parker , "mohamed.boucadair@orange.com" , "sfc@ietf.org" 
Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
Thread-Index: AdBRyhUadMfMQp0TQVyP+AHUYniSlAAMhaQAAABleoAAAFj2AAAJAG9w///QlQCAAFBcIP//vPuAgABSEAD//7LOAIAASNWQ
Date: Thu, 26 Feb 2015 18:14:20 +0000
Message-ID: 
References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3584.2080005@joelhalpern.com>      <54EF596C.1080608@joelhalpern.com>
In-Reply-To: <54EF596C.1080608@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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" 
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
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, 26 Feb 2015 18:14:24 -0000

What are the mechanics of using meta-data?
Which element sets it, and how is it instructed to do so?


-----Original Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20
Sent: Thursday, February 26, 2015 12:36 PM
To: Dave Dolson; Reinaldo Penno (repenno); Ron Parker; mohamed.boucadair@or=
ange.com; sfc@ietf.org
Cc: Ben Wright (Ben.Wright@metaswitch.com)
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals

Personally, I would prefer that the firewall use metadata rather than=20
path-index.  My reasoning is that if functions get added before or after=20
the firewall, operations would prefer not to have to change the=20
configuration of the firewall SF itself.

Having said that, I don't see any way to stop you from using the path index=
.

Yours,
Joel

On 2/26/15 12:30 PM, Dave Dolson wrote:
> For the sake of argument, suppose I have a firewall SF, and I want to use
> it more than once in a chain. (Maybe I want to book-end the chain with in=
gress
> and egress rules.)
>
> Do you agree it would be sufficient to use the Path Index to select which=
 of
> the ingress or egress rule sets should be used?
>
> I'm probably missing something; I don't understand how the context header=
s
> define functionality. Maybe the device could communicate with itself
> (e.g., the ingress portion sending a tag to the egress portion)
> by sending state in the packet. Is that what you are mean by "contextual =
info" ?
>
>
>
> -----Original Message-----
> From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com]
> Sent: Thursday, February 26, 2015 12:18 PM
> To: Dave Dolson; Ron Parker; Joel M. Halpern; mohamed.boucadair@orange.co=
m; sfc@ietf.org
> Cc: Ben Wright (Ben.Wright@metaswitch.com)
> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>
> Agreed on all points. I thought I was missing something so before writing
> this email I retested our implementation and it worked off the bat. The
> RSP constructed has the the same (SFF, SF) tuple but different indexes.
>
> The same SF is visited multiple times until the path ends.  If the SF
> wants contextual info across visits than context headers are the way to
> go.
>
>
> On 2/26/15, 8:52 AM, "Dave Dolson"  wrote:
>
>> Maybe naively, I thought the service functions would be provisioned with
>> a table:
>>
>> E.g., for element foo:
>> Path | Path Index | Next Hop  | Function
>> 123 |  4         |   SF-bar  | first behavior
>> 123 |  2         | SF-foobar | second behavior
>>
>>
>> The Function is clearly implementation specific. Maybe it points to a
>> configuration set or a policy set. I think completely out of scope here.
>>
>> I suggest that this is not a problem for the wire protocol, rather for
>> the configuration model (netconf or whatever).
>>
>> It becomes very much vendor-specific if the behaviors are complex
>> configurations of specialized features.
>>
>> If a person were manually configuring chains, I don't think they'd have =
a
>> conceptual problem, because they'd have a diagram they need to implement=
:
>> {SF-foo (first-behavior), SF-bar, SF-foo (second-behavior), SF-foobar}
>>
>> If we wanted to standardize it, we could maybe make the Function simply =
a
>> label that means something to the device--an indirection to a
>> configuration set.
>>
>> -Dave
>>
>>
>>
>> -----Original Message-----
>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker
>> Sent: Thursday, February 26, 2015 11:31 AM
>> To: Dave Dolson; Joel M. Halpern; mohamed.boucadair@orange.com;
>> sfc@ietf.org
>> Cc: Ben Wright (Ben.Wright@metaswitch.com)
>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>>
>> Hi, Dave.
>>
>> I agree that on the wire, this is the way it would work.
>>
>> But, when composing the chain, it seems like information would be lackin=
g
>> if a chain were expressed simply as {SF-foo, SF-bar, SF-foo, SF-foobar}.
>>   It is completely implicit that since SF-foo appears twice, it perhaps
>> should perform some different duty when index =3D 0 vs when index =3D 2.
>>
>> At first, I thought that an alternative way to handle this would be to
>> use multiple logical identities for SF-foo.  In this case, the chain
>> above would be expressed as {SF-foo-first-behavior, SF-bar,
>> SF-foo-second-behavior, SF-foobar}.   But, the problem here is selecting
>> the RSP, assuming that SF-foo has multiple instances.   Nothing in this
>> second flavor of chain says that the same instance of SF-foo-* must be
>> selected to satisfy SF-foo-first-behavior and SF-foo-second-behavior
>> (which may not be required, but should be possible to force as such).
>>
>> I guess what I'm saying is that spiraling has a subtlety to it that isn'=
t
>> yet adequately addressed and that I don't have a specific proposal to
>> solve it, either.
>>
>>    Ron
>>
>>
>> -----Original Message-----
>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson
>> Sent: Thursday, February 26, 2015 11:21 AM
>> To: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org
>> Cc: Ben Wright (Ben.Wright@metaswitch.com)
>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>>
>> If I may try to put it simply, I've always thought of it this way:
>> --> Each node in the chain selects the context for processing and the
>> next hop on the basis of BOTH path ID and Index, while decrementing the
>> index for the next hop.
>>
>> That behavior supports spiraling.
>>
>>
>>
>> -Dave
>>
>>
>> -----Original Message-----
>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern
>> Sent: Thursday, February 26, 2015 10:02 AM
>> To: mohamed.boucadair@orange.com; sfc@ietf.org
>> Cc: Ben Wright (Ben.Wright@metaswitch.com)
>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
>>
>> There are two different aspects of Spirals.
>>
>> One of the two aspects is enabling a packet that repeatedly arrives at
>> the same SFF to get the correct services provided each time it arrives,
>> and to go to the correct next SFF each time it arrives.  The Service Pat=
h
>> Index, used by the SFF to select service functions and next SFF, provide=
s
>> that capability.
>>
>> The other aspect is how the Service Functions themselves handle spirals.
>>   To a large degree, that depends upon the individual service function.
>>   I normally assume that it would use packet context (as described in th=
e
>> text you quote) to determine what to do.
>>
>> Since I would prefer that service functions are independent of the
>> underlying service function chaining infrastructure, and are not
>> sensitive to how many functions are before or after them in the chain, I
>> would personally prefer that they not use the path index for that.  I
>> would recommend that if the packet does not carry enough context that th=
e
>> service function could and should use metadata to carry its needed state
>> information.  But neither I personally nor the SFC Working Group get to
>> tell folks how to build their service functions.  So they may come up
>> with other methods for addressing their needs.  Which is also fine.
>>
>> Thus, I would not expect this document to discuss how service functions
>> themselves handle revisiting.  But metadata clearly allows for a range o=
f
>> behaviors that will work.  And the path index handles the SFF needs
>> relative to spirals, which is what we need to handle.
>>
>> Yours,
>> Joel
>>
>> On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote:
>>> Re-,
>>>
>>> Spiral is not mentioned in the draft, but SF loop is.
>>>
>>> I'm asking the question because I don't get from the draft how spirals
>>> could work (that is a SF invoked several time in the context of the sam=
e
>>> SFC).
>>>
>>> Before proposing text, I would like to understand first how it works.
>>> If you can provide an example, this will be even great.
>>>
>>> Thank you.
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : jeudi 26
>>>> f=E9vrier 2015 15:41 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Cc =
:
>>>> Ben Wright (Ben.Wright@metaswitch.com) Objet : Re: [sfc]
>>>> draft-quinn-sfc-nsh: Support of SF Spirals
>>>>
>>>> The SF Spirals requirement is one of the key drivers for the index.
>>>> The index allows one to tell where one is in the spiral, and also to
>>>> break a loop if one has a loop instead of a spiral.
>>>>
>>>> Is there text that we could add that would help make this clear,
>>>> since your earlier question about the path index suggests that it is
>>>> not as clear as it should be?
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote:
>>>>> Hi Paul, all,
>>>>>
>>>>> There were a discussion in the mailing list
>>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html)
>>>>> that led to defining what is meant by SF Spirals: (below is provided
>>>>> an excerpt from
>>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where
>>>>> the conclusions of that discussion were recorded)
>>>>>
>>>>> "   o  Service Function Spiral: denotes a Service Function Chain in
>>>> which
>>>>>
>>>>>          data is handled by a Service Function, forwarded onwards,
>>>>> and
>>>>>
>>>>>          arrives once again at that Service Function.
>>>>>
>>>>>          *  Note that some Service Functions support built-in
>>>>> functions to
>>>>>
>>>>>             accommodate spirals; these service-specific functions may
>>>>>
>>>>>             require that the data received in a spiral should differ
>>>>> in a
>>>>>
>>>>>             way that will result in a different processing decision
>>>>> than
>>>>>
>>>>>             the original data.  This document does not make such
>>>>>
>>>>>             assumption.
>>>>>
>>>>>          *  A Service Function Chain may involve one or more Service
>>>>>
>>>>>             Function Spirals.
>>>>>
>>>>>          *  Unlike Service Function loop, spirals are not considered
>>>>> as
>>>>>
>>>>>             errors."
>>>>>
>>>>> And this companion requirement:
>>>>>
>>>>> "               A.  Service Functions MAY be invoked multiple times i=
n
>>>>>
>>>>>                       the same Service Function Chain (denoted as SF
>>>>>
>>>>>                       Spiral), but the solution MUST prevent infinite
>>>>>
>>>>>                       forwarding loops. =BB
>>>>>
>>>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is met.
>>>>>
>>>>> Can you please clarify whether this is supported and how?
>>>>>
>>>>> Thank you.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Med
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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 Thu Feb 26 10:15:55 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F901A90BF for ; Thu, 26 Feb 2015 10:15:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnCow1wDA81m for ; Thu, 26 Feb 2015 10:15:51 -0800 (PST)
Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B2061A90BD for ; Thu, 26 Feb 2015 10:15:51 -0800 (PST)
Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0224.002;  Thu, 26 Feb 2015 10:15:50 -0800
From: Ron Parker 
To: Henry Fourie , "Jim Guichard (jguichar)" , "sfc@ietf.org" 
Thread-Topic: WG call for adoption of draft-quinn-sfc-nsh
Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50DJ7RAgAAVJIA=
Date: Thu, 26 Feb 2015 18:15:50 +0000
Message-ID: 
References:  <0F8583BBE82FA449A8B78417CC07559A091AB019@SJCEML701-CHM.china.huawei.com>
In-Reply-To: <0F8583BBE82FA449A8B78417CC07559A091AB019@SJCEML701-CHM.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [50.203.66.100]
Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B2E83581BMBX021W3CA2exch_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh
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, 26 Feb 2015 18:15:54 -0000

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

Also support as co-author.

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Henry Fourie
Sent: Thursday, February 26, 2015 12:01 PM
To: Jim Guichard (jguichar); sfc@ietf.org
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh

Support as a co-author.

-        Louis

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar=
)
Sent: Thursday, February 26, 2015 4:47 AM
To: sfc@ietf.org
Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh

Greetings WG:

The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft=
-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc=
-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined =
the NSH document so that the WG can focus on a single encapsulation documen=
t going forward. This new version of NSH includes an open items section bas=
ed on discussion between co-authors and members of the list. The WG will wo=
rk through this list (and any other issues that need to be added) over the =
next weeks. We appreciate and recognize the hard work of both the NSH and S=
CH authors in pushing the SFC encapsulation work forward.

With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n=
sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3=
/12/2015.

Please note that this is a call for adoption, and not a last call for conte=
nt of the document. Adopting a WG document simply means that the WG will fo=
cus its efforts on that particular draft going forward, and use that docume=
nt for resolving open issues and documenting the WG's decisions.

Please indicate whether you support adoption for not, and if not why. Issue=
s you have with the current document itself can also be raised, but they sh=
ould be raised in the context of what should be changed in the document goi=
ng forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that appl=
ies to this draft, in line with the IPR disclosure obligations for WG parti=
cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l=
isted as a document author please respond to this email (to the chairs) whe=
ther or not you are aware of any relevant IPR.

Jim & Thomas

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









    

    Also support as co-author.=

    

    &nbs=
p;
    

    

    

    From: sfc [mailto:sfc-bounces@ietf.o=
rg]
On Behalf Of Henry Fourie
    
Sent: Thursday, February 26, 2015 12:01 PM
    
To: Jim Guichard (jguichar); sfc@ietf.org
    
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh<=
/o:p>
    

    

    

     
    

    Support as a co-author.
    

    
-    &n=
bsp;  
Louis
    

     
    

    

    

    From: sfc [mailto:sfc-bounces@ietf.org]
On Behalf Of Jim Guichard (jguichar)
    
Sent: Thursday, February 26, 2015 4:47 AM
    
To: sfc@ietf.org
    
Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh
    

    

    

     
    

    

    

    Greetings WG:
    

    

    

     =

    

    

    

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/dr=
aft-quinn-sfc-nsh/) has recently been
 reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draf=
t-zhang-sfc-sch/) have joined the NSH document so that the WG can focus=
 on a single encapsulation document
 going forward. This new version of NSH includes an open items secti=
on based on discussion between co-authors and members of the list. The WG w=
ill work through this list (and any other issues that need to be added) ove=
r the next weeks. We appreciate
 and recognize the hard work of both the NSH and SCH authors in pushing the=
 SFC encapsulation work forward.
    

    

    

     =

    

    

    

    With that said, the chairs are calling for WG adoption of draf=
t-quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 w=
eeks ending 3/12/2015.=

    

    

    

     =

    

    

    

    Please note that this is a call for adoption, and not a last call for cont=
ent of the document. Adopting a WG document simply means that the WG will f=
ocus its efforts on that particular
 draft going forward, and use that document for resolving open issues and d=
ocumenting the WG’s decisions.
    

    

    

     
    

    

    

    Please indicate whether you support adoption for not, and if not why. Issu=
es you have with the current document itself can also be raised, but they s=
hould be raised in the context of what
 should be changed in the document going forward, rather than a pre-conditi=
on for adoption. 
    

    

    

     
    

    

    

    Finally, now is also a good time to poll for knowledge of any IPR that app=
lies to this draft, in line with the IPR disclosure obligations for WG part=
icipants (see RFCs 3979, 4879, 3669
 and 5378 for more details). If you are listed as a document author please =
respond to this email (to the chairs) whether or not you are aware of any r=
elevant IPR.
    

    

    

     
    

    

    

    Jim & Thomas
    

    

    

    



--_000_CDF2F015F4429F458815ED2A6C2B6B0B2E83581BMBX021W3CA2exch_--


From nobody Thu Feb 26 10:20:22 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 AFE0A1A87C7 for ; Thu, 26 Feb 2015 10:20:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DJq0d8t-WlsT for ; Thu, 26 Feb 2015 10:20:12 -0800 (PST)
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 BEFE01A90BD for ; Thu, 26 Feb 2015 10:20:12 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C65EB1C055D; Thu, 26 Feb 2015 10:20:11 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from localhost (mobile-166-171-057-059.mycingular.net [166.171.57.59]) by mailb2.tigertech.net (Postfix) with ESMTPA id 3D4141C0D94; Thu, 26 Feb 2015 10:20:09 -0800 (PST)
Date: Thu, 26 Feb 2015 13:20:03 -0500
Message-ID: 
Importance: low
From: "Jmh.direct" 
To: ddolson@sandvine.com, jmh@joelhalpern.com, repenno@cisco.com, ron_parker@affirmednetworks.com, mohamed.boucadair@orange.com, sfc@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.android.email_159081965057974"
Archived-At: 
Cc: ben.wright@metaswitch.com
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
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, 26 Feb 2015 18:20:20 -0000

----_com.android.email_159081965057974
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

SW5zdHJ1Y3Rpb24gY29tZXMgZnJvbSB0aGUgc2V2aWNlIGZ1bmN0aW9uIGRlc2lnbi4gwqBTb21l
IGhlYWRlciBzdHJ1Y3R1cmVzIGF1Z21lbnQgdGhhdCB3aXRoIGNvbnRyb2wgbWFwcGluZyBpYmZv
cm1hdGlvbiB0byBpbmRpY2F0ZSB3aGljaCBtZXRhZGF0YSBmaWVsZCBoYXMgd2hpY2ggdXNlLgoK
R29yIFRMViBiYXNlZCBtZXRhZGF0IHdlIHByb2JhYmx5IGVhbnQgYSByZWdpc3RyeSB3aXRoIHZl
cnkgZWFzeSBlbnRyeSBjcmVhdGlvbi4KCllvdXJzLApKb2VsCgoKU2VudCBmcm9tIG15IFNhbXN1
bmcgc21hcnRwaG9uZSBvbiBBVCZUCgotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0t
ClN1YmplY3Q6IFJFOiBbc2ZjXSBkcmFmdC1xdWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNw
aXJhbHMgCkZyb206IERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5lLmNvbT4gClRvOiAiSm9l
bCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4sIlJlaW5hbGRvIFBlbm5vIChyZXBl
bm5vKSIgPHJlcGVubm9AY2lzY28uY29tPixSb24gUGFya2VyIDxSb25fUGFya2VyQGFmZmlybWVk
bmV0d29ya3MuY29tPiwibW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSIgPG1vaGFtZWQuYm91
Y2FkYWlyQG9yYW5nZS5jb20+LCJzZmNAaWV0Zi5vcmciIDxzZmNAaWV0Zi5vcmc+IApDQzogIkJl
biBXcmlnaHQgKEJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb20pIiA8QmVuLldyaWdodEBtZXRhc3dp
dGNoLmNvbT4gCgpXaGF0IGFyZSB0aGUgbWVjaGFuaWNzIG9mIHVzaW5nIG1ldGEtZGF0YT8KV2hp
Y2ggZWxlbWVudCBzZXRzIGl0LCBhbmQgaG93IGlzIGl0IGluc3RydWN0ZWQgdG8gZG8gc28/CgoK
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KRnJvbTogSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86
am1oQGpvZWxoYWxwZXJuLmNvbV0gClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAx
MjozNiBQTQpUbzogRGF2ZSBEb2xzb247IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgUm9uIFBh
cmtlcjsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnCkNjOiBCZW4g
V3JpZ2h0IChCZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tKQpTdWJqZWN0OiBSZTogW3NmY10gZHJh
ZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzCgpQZXJzb25hbGx5LCBJIHdv
dWxkIHByZWZlciB0aGF0IHRoZSBmaXJld2FsbCB1c2UgbWV0YWRhdGEgcmF0aGVyIHRoYW4gCnBh
dGgtaW5kZXguwqAgTXkgcmVhc29uaW5nIGlzIHRoYXQgaWYgZnVuY3Rpb25zIGdldCBhZGRlZCBi
ZWZvcmUgb3IgYWZ0ZXIgCnRoZSBmaXJld2FsbCwgb3BlcmF0aW9ucyB3b3VsZCBwcmVmZXIgbm90
IHRvIGhhdmUgdG8gY2hhbmdlIHRoZSAKY29uZmlndXJhdGlvbiBvZiB0aGUgZmlyZXdhbGwgU0Yg
aXRzZWxmLgoKSGF2aW5nIHNhaWQgdGhhdCwgSSBkb24ndCBzZWUgYW55IHdheSB0byBzdG9wIHlv
dSBmcm9tIHVzaW5nIHRoZSBwYXRoIGluZGV4LgoKWW91cnMsCkpvZWwKCk9uIDIvMjYvMTUgMTI6
MzAgUE0sIERhdmUgRG9sc29uIHdyb3RlOgo+IEZvciB0aGUgc2FrZSBvZiBhcmd1bWVudCwgc3Vw
cG9zZSBJIGhhdmUgYSBmaXJld2FsbCBTRiwgYW5kIEkgd2FudCB0byB1c2UKPiBpdCBtb3JlIHRo
YW4gb25jZSBpbiBhIGNoYWluLiAoTWF5YmUgSSB3YW50IHRvIGJvb2stZW5kIHRoZSBjaGFpbiB3
aXRoIGluZ3Jlc3MKPiBhbmQgZWdyZXNzIHJ1bGVzLikKPgo+IERvIHlvdSBhZ3JlZSBpdCB3b3Vs
ZCBiZSBzdWZmaWNpZW50IHRvIHVzZSB0aGUgUGF0aCBJbmRleCB0byBzZWxlY3Qgd2hpY2ggb2YK
PiB0aGUgaW5ncmVzcyBvciBlZ3Jlc3MgcnVsZSBzZXRzIHNob3VsZCBiZSB1c2VkPwo+Cj4gSSdt
IHByb2JhYmx5IG1pc3Npbmcgc29tZXRoaW5nOyBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRoZSBj
b250ZXh0IGhlYWRlcnMKPiBkZWZpbmUgZnVuY3Rpb25hbGl0eS4gTWF5YmUgdGhlIGRldmljZSBj
b3VsZCBjb21tdW5pY2F0ZSB3aXRoIGl0c2VsZgo+IChlLmcuLCB0aGUgaW5ncmVzcyBwb3J0aW9u
IHNlbmRpbmcgYSB0YWcgdG8gdGhlIGVncmVzcyBwb3J0aW9uKQo+IGJ5IHNlbmRpbmcgc3RhdGUg
aW4gdGhlIHBhY2tldC4gSXMgdGhhdCB3aGF0IHlvdSBhcmUgbWVhbiBieSAiY29udGV4dHVhbCBp
bmZvIiA/Cj4KPgo+Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPiBGcm9tOiBSZWluYWxk
byBQZW5ubyAocmVwZW5ubykgW21haWx0bzpyZXBlbm5vQGNpc2NvLmNvbV0KPiBTZW50OiBUaHVy
c2RheSwgRmVicnVhcnkgMjYsIDIwMTUgMTI6MTggUE0KPiBUbzogRGF2ZSBEb2xzb247IFJvbiBQ
YXJrZXI7IEpvZWwgTS4gSGFscGVybjsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2Zj
QGlldGYub3JnCj4gQ2M6IEJlbiBXcmlnaHQgKEJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb20pCj4g
U3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1uc2g6IFN1cHBvcnQgb2YgU0YgU3Bp
cmFscwo+Cj4gQWdyZWVkIG9uIGFsbCBwb2ludHMuIEkgdGhvdWdodCBJIHdhcyBtaXNzaW5nIHNv
bWV0aGluZyBzbyBiZWZvcmUgd3JpdGluZwo+IHRoaXMgZW1haWwgSSByZXRlc3RlZCBvdXIgaW1w
bGVtZW50YXRpb24gYW5kIGl0IHdvcmtlZCBvZmYgdGhlIGJhdC4gVGhlCj4gUlNQIGNvbnN0cnVj
dGVkIGhhcyB0aGUgdGhlIHNhbWUgKFNGRiwgU0YpIHR1cGxlIGJ1dCBkaWZmZXJlbnQgaW5kZXhl
cy4KPgo+IFRoZSBzYW1lIFNGIGlzIHZpc2l0ZWQgbXVsdGlwbGUgdGltZXMgdW50aWwgdGhlIHBh
dGggZW5kcy7CoCBJZiB0aGUgU0YKPiB3YW50cyBjb250ZXh0dWFsIGluZm8gYWNyb3NzIHZpc2l0
cyB0aGFuIGNvbnRleHQgaGVhZGVycyBhcmUgdGhlIHdheSB0bwo+IGdvLgo+Cj4KPiBPbiAyLzI2
LzE1LCA4OjUyIEFNLCAiRGF2ZSBEb2xzb24iIDxkZG9sc29uQHNhbmR2aW5lLmNvbT4gd3JvdGU6
Cj4KPj4gTWF5YmUgbmFpdmVseSwgSSB0aG91Z2h0IHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyB3b3Vs
ZCBiZSBwcm92aXNpb25lZCB3aXRoCj4+IGEgdGFibGU6Cj4+Cj4+IEUuZy4sIGZvciBlbGVtZW50
IGZvbzoKPj4gUGF0aCB8IFBhdGggSW5kZXggfCBOZXh0IEhvcMKgIHwgRnVuY3Rpb24KPj4gMTIz
IHzCoCA0wqDCoMKgwqDCoMKgwqDCoCB8wqDCoCBTRi1iYXLCoCB8IGZpcnN0IGJlaGF2aW9yCj4+
IDEyMyB8wqAgMsKgwqDCoMKgwqDCoMKgwqAgfCBTRi1mb29iYXIgfCBzZWNvbmQgYmVoYXZpb3IK
Pj4KPj4KPj4gVGhlIEZ1bmN0aW9uIGlzIGNsZWFybHkgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMu
IE1heWJlIGl0IHBvaW50cyB0byBhCj4+IGNvbmZpZ3VyYXRpb24gc2V0IG9yIGEgcG9saWN5IHNl
dC4gSSB0aGluayBjb21wbGV0ZWx5IG91dCBvZiBzY29wZSBoZXJlLgo+Pgo+PiBJIHN1Z2dlc3Qg
dGhhdCB0aGlzIGlzIG5vdCBhIHByb2JsZW0gZm9yIHRoZSB3aXJlIHByb3RvY29sLCByYXRoZXIg
Zm9yCj4+IHRoZSBjb25maWd1cmF0aW9uIG1vZGVsIChuZXRjb25mIG9yIHdoYXRldmVyKS4KPj4K
Pj4gSXQgYmVjb21lcyB2ZXJ5IG11Y2ggdmVuZG9yLXNwZWNpZmljIGlmIHRoZSBiZWhhdmlvcnMg
YXJlIGNvbXBsZXgKPj4gY29uZmlndXJhdGlvbnMgb2Ygc3BlY2lhbGl6ZWQgZmVhdHVyZXMuCj4+
Cj4+IElmIGEgcGVyc29uIHdlcmUgbWFudWFsbHkgY29uZmlndXJpbmcgY2hhaW5zLCBJIGRvbid0
IHRoaW5rIHRoZXknZCBoYXZlIGEKPj4gY29uY2VwdHVhbCBwcm9ibGVtLCBiZWNhdXNlIHRoZXkn
ZCBoYXZlIGEgZGlhZ3JhbSB0aGV5IG5lZWQgdG8gaW1wbGVtZW50Ogo+PiB7U0YtZm9vIChmaXJz
dC1iZWhhdmlvciksIFNGLWJhciwgU0YtZm9vIChzZWNvbmQtYmVoYXZpb3IpLCBTRi1mb29iYXJ9
Cj4+Cj4+IElmIHdlIHdhbnRlZCB0byBzdGFuZGFyZGl6ZSBpdCwgd2UgY291bGQgbWF5YmUgbWFr
ZSB0aGUgRnVuY3Rpb24gc2ltcGx5IGEKPj4gbGFiZWwgdGhhdCBtZWFucyBzb21ldGhpbmcgdG8g
dGhlIGRldmljZS0tYW4gaW5kaXJlY3Rpb24gdG8gYQo+PiBjb25maWd1cmF0aW9uIHNldC4KPj4K
Pj4gLURhdmUKPj4KPj4KPj4KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0KPj4gRnJvbTog
c2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb24gUGFya2Vy
Cj4+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAxMTozMSBBTQo+PiBUbzogRGF2
ZSBEb2xzb247IEpvZWwgTS4gSGFscGVybjsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsK
Pj4gc2ZjQGlldGYub3JnCj4+IENjOiBCZW4gV3JpZ2h0IChCZW4uV3JpZ2h0QG1ldGFzd2l0Y2gu
Y29tKQo+PiBTdWJqZWN0OiBSZTogW3NmY10gZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBv
ZiBTRiBTcGlyYWxzCj4+Cj4+IEhpLCBEYXZlLgo+Pgo+PiBJIGFncmVlIHRoYXQgb24gdGhlIHdp
cmUsIHRoaXMgaXMgdGhlIHdheSBpdCB3b3VsZCB3b3JrLgo+Pgo+PiBCdXQsIHdoZW4gY29tcG9z
aW5nIHRoZSBjaGFpbiwgaXQgc2VlbXMgbGlrZSBpbmZvcm1hdGlvbiB3b3VsZCBiZSBsYWNraW5n
Cj4+IGlmIGEgY2hhaW4gd2VyZSBleHByZXNzZWQgc2ltcGx5IGFzIHtTRi1mb28sIFNGLWJhciwg
U0YtZm9vLCBTRi1mb29iYXJ9Lgo+PsKgwqAgSXQgaXMgY29tcGxldGVseSBpbXBsaWNpdCB0aGF0
IHNpbmNlIFNGLWZvbyBhcHBlYXJzIHR3aWNlLCBpdCBwZXJoYXBzCj4+IHNob3VsZCBwZXJmb3Jt
IHNvbWUgZGlmZmVyZW50IGR1dHkgd2hlbiBpbmRleCA9IDAgdnMgd2hlbiBpbmRleCA9IDIuCj4+
Cj4+IEF0IGZpcnN0LCBJIHRob3VnaHQgdGhhdCBhbiBhbHRlcm5hdGl2ZSB3YXkgdG8gaGFuZGxl
IHRoaXMgd291bGQgYmUgdG8KPj4gdXNlIG11bHRpcGxlIGxvZ2ljYWwgaWRlbnRpdGllcyBmb3Ig
U0YtZm9vLsKgIEluIHRoaXMgY2FzZSwgdGhlIGNoYWluCj4+IGFib3ZlIHdvdWxkIGJlIGV4cHJl
c3NlZCBhcyB7U0YtZm9vLWZpcnN0LWJlaGF2aW9yLCBTRi1iYXIsCj4+IFNGLWZvby1zZWNvbmQt
YmVoYXZpb3IsIFNGLWZvb2Jhcn0uwqDCoCBCdXQsIHRoZSBwcm9ibGVtIGhlcmUgaXMgc2VsZWN0
aW5nCj4+IHRoZSBSU1AsIGFzc3VtaW5nIHRoYXQgU0YtZm9vIGhhcyBtdWx0aXBsZSBpbnN0YW5j
ZXMuwqDCoCBOb3RoaW5nIGluIHRoaXMKPj4gc2Vjb25kIGZsYXZvciBvZiBjaGFpbiBzYXlzIHRo
YXQgdGhlIHNhbWUgaW5zdGFuY2Ugb2YgU0YtZm9vLSogbXVzdCBiZQo+PiBzZWxlY3RlZCB0byBz
YXRpc2Z5IFNGLWZvby1maXJzdC1iZWhhdmlvciBhbmQgU0YtZm9vLXNlY29uZC1iZWhhdmlvcgo+
PiAod2hpY2ggbWF5IG5vdCBiZSByZXF1aXJlZCwgYnV0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBm
b3JjZSBhcyBzdWNoKS4KPj4KPj4gSSBndWVzcyB3aGF0IEknbSBzYXlpbmcgaXMgdGhhdCBzcGly
YWxpbmcgaGFzIGEgc3VidGxldHkgdG8gaXQgdGhhdCBpc24ndAo+PiB5ZXQgYWRlcXVhdGVseSBh
ZGRyZXNzZWQgYW5kIHRoYXQgSSBkb24ndCBoYXZlIGEgc3BlY2lmaWMgcHJvcG9zYWwgdG8KPj4g
c29sdmUgaXQsIGVpdGhlci4KPj4KPj7CoMKgwqAgUm9uCj4+Cj4+Cj4+IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tCj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBP
biBCZWhhbGYgT2YgRGF2ZSBEb2xzb24KPj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI2LCAy
MDE1IDExOjIxIEFNCj4+IFRvOiBKb2VsIE0uIEhhbHBlcm47IG1vaGFtZWQuYm91Y2FkYWlyQG9y
YW5nZS5jb207IHNmY0BpZXRmLm9yZwo+PiBDYzogQmVuIFdyaWdodCAoQmVuLldyaWdodEBtZXRh
c3dpdGNoLmNvbSkKPj4gU3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1uc2g6IFN1
cHBvcnQgb2YgU0YgU3BpcmFscwo+Pgo+PiBJZiBJIG1heSB0cnkgdG8gcHV0IGl0IHNpbXBseSwg
SSd2ZSBhbHdheXMgdGhvdWdodCBvZiBpdCB0aGlzIHdheToKPj4gLS0+IEVhY2ggbm9kZSBpbiB0
aGUgY2hhaW4gc2VsZWN0cyB0aGUgY29udGV4dCBmb3IgcHJvY2Vzc2luZyBhbmQgdGhlCj4+IG5l
eHQgaG9wIG9uIHRoZSBiYXNpcyBvZiBCT1RIIHBhdGggSUQgYW5kIEluZGV4LCB3aGlsZSBkZWNy
ZW1lbnRpbmcgdGhlCj4+IGluZGV4IGZvciB0aGUgbmV4dCBob3AuCj4+Cj4+IFRoYXQgYmVoYXZp
b3Igc3VwcG9ydHMgc3BpcmFsaW5nLgo+Pgo+Pgo+Pgo+PiAtRGF2ZQo+Pgo+Pgo+PiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQo+PiBGcm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRm
Lm9yZ10gT24gQmVoYWxmIE9mIEpvZWwgTS4gSGFscGVybgo+PiBTZW50OiBUaHVyc2RheSwgRmVi
cnVhcnkgMjYsIDIwMTUgMTA6MDIgQU0KPj4gVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j
b207IHNmY0BpZXRmLm9yZwo+PiBDYzogQmVuIFdyaWdodCAoQmVuLldyaWdodEBtZXRhc3dpdGNo
LmNvbSkKPj4gU3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1uc2g6IFN1cHBvcnQg
b2YgU0YgU3BpcmFscwo+Pgo+PiBUaGVyZSBhcmUgdHdvIGRpZmZlcmVudCBhc3BlY3RzIG9mIFNw
aXJhbHMuCj4+Cj4+IE9uZSBvZiB0aGUgdHdvIGFzcGVjdHMgaXMgZW5hYmxpbmcgYSBwYWNrZXQg
dGhhdCByZXBlYXRlZGx5IGFycml2ZXMgYXQKPj4gdGhlIHNhbWUgU0ZGIHRvIGdldCB0aGUgY29y
cmVjdCBzZXJ2aWNlcyBwcm92aWRlZCBlYWNoIHRpbWUgaXQgYXJyaXZlcywKPj4gYW5kIHRvIGdv
IHRvIHRoZSBjb3JyZWN0IG5leHQgU0ZGIGVhY2ggdGltZSBpdCBhcnJpdmVzLsKgIFRoZSBTZXJ2
aWNlIFBhdGgKPj4gSW5kZXgsIHVzZWQgYnkgdGhlIFNGRiB0byBzZWxlY3Qgc2VydmljZSBmdW5j
dGlvbnMgYW5kIG5leHQgU0ZGLCBwcm92aWRlcwo+PiB0aGF0IGNhcGFiaWxpdHkuCj4+Cj4+IFRo
ZSBvdGhlciBhc3BlY3QgaXMgaG93IHRoZSBTZXJ2aWNlIEZ1bmN0aW9ucyB0aGVtc2VsdmVzIGhh
bmRsZSBzcGlyYWxzLgo+PsKgwqAgVG8gYSBsYXJnZSBkZWdyZWUsIHRoYXQgZGVwZW5kcyB1cG9u
IHRoZSBpbmRpdmlkdWFsIHNlcnZpY2UgZnVuY3Rpb24uCj4+wqDCoCBJIG5vcm1hbGx5IGFzc3Vt
ZSB0aGF0IGl0IHdvdWxkIHVzZSBwYWNrZXQgY29udGV4dCAoYXMgZGVzY3JpYmVkIGluIHRoZQo+
PiB0ZXh0IHlvdSBxdW90ZSkgdG8gZGV0ZXJtaW5lIHdoYXQgdG8gZG8uCj4+Cj4+IFNpbmNlIEkg
d291bGQgcHJlZmVyIHRoYXQgc2VydmljZSBmdW5jdGlvbnMgYXJlIGluZGVwZW5kZW50IG9mIHRo
ZQo+PiB1bmRlcmx5aW5nIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgaW5mcmFzdHJ1Y3R1cmUs
IGFuZCBhcmUgbm90Cj4+IHNlbnNpdGl2ZSB0byBob3cgbWFueSBmdW5jdGlvbnMgYXJlIGJlZm9y
ZSBvciBhZnRlciB0aGVtIGluIHRoZSBjaGFpbiwgSQo+PiB3b3VsZCBwZXJzb25hbGx5IHByZWZl
ciB0aGF0IHRoZXkgbm90IHVzZSB0aGUgcGF0aCBpbmRleCBmb3IgdGhhdC7CoCBJCj4+IHdvdWxk
IHJlY29tbWVuZCB0aGF0IGlmIHRoZSBwYWNrZXQgZG9lcyBub3QgY2FycnkgZW5vdWdoIGNvbnRl
eHQgdGhhdCB0aGUKPj4gc2VydmljZSBmdW5jdGlvbiBjb3VsZCBhbmQgc2hvdWxkIHVzZSBtZXRh
ZGF0YSB0byBjYXJyeSBpdHMgbmVlZGVkIHN0YXRlCj4+IGluZm9ybWF0aW9uLsKgIEJ1dCBuZWl0
aGVyIEkgcGVyc29uYWxseSBub3IgdGhlIFNGQyBXb3JraW5nIEdyb3VwIGdldCB0bwo+PiB0ZWxs
IGZvbGtzIGhvdyB0byBidWlsZCB0aGVpciBzZXJ2aWNlIGZ1bmN0aW9ucy7CoCBTbyB0aGV5IG1h
eSBjb21lIHVwCj4+IHdpdGggb3RoZXIgbWV0aG9kcyBmb3IgYWRkcmVzc2luZyB0aGVpciBuZWVk
cy7CoCBXaGljaCBpcyBhbHNvIGZpbmUuCj4+Cj4+IFRodXMsIEkgd291bGQgbm90IGV4cGVjdCB0
aGlzIGRvY3VtZW50IHRvIGRpc2N1c3MgaG93IHNlcnZpY2UgZnVuY3Rpb25zCj4+IHRoZW1zZWx2
ZXMgaGFuZGxlIHJldmlzaXRpbmcuwqAgQnV0IG1ldGFkYXRhIGNsZWFybHkgYWxsb3dzIGZvciBh
IHJhbmdlIG9mCj4+IGJlaGF2aW9ycyB0aGF0IHdpbGwgd29yay7CoCBBbmQgdGhlIHBhdGggaW5k
ZXggaGFuZGxlcyB0aGUgU0ZGIG5lZWRzCj4+IHJlbGF0aXZlIHRvIHNwaXJhbHMsIHdoaWNoIGlz
IHdoYXQgd2UgbmVlZCB0byBoYW5kbGUuCj4+Cj4+IFlvdXJzLAo+PiBKb2VsCj4+Cj4+IE9uIDIv
MjYvMTUgOTo1MiBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToKPj4+IFJl
LSwKPj4+Cj4+PiBTcGlyYWwgaXMgbm90IG1lbnRpb25lZCBpbiB0aGUgZHJhZnQsIGJ1dCBTRiBs
b29wIGlzLgo+Pj4KPj4+IEknbSBhc2tpbmcgdGhlIHF1ZXN0aW9uIGJlY2F1c2UgSSBkb24ndCBn
ZXQgZnJvbSB0aGUgZHJhZnQgaG93IHNwaXJhbHMKPj4+IGNvdWxkIHdvcmsgKHRoYXQgaXMgYSBT
RiBpbnZva2VkIHNldmVyYWwgdGltZSBpbiB0aGUgY29udGV4dCBvZiB0aGUgc2FtZQo+Pj4gU0ZD
KS4KPj4+Cj4+PiBCZWZvcmUgcHJvcG9zaW5nIHRleHQsIEkgd291bGQgbGlrZSB0byB1bmRlcnN0
YW5kIGZpcnN0IGhvdyBpdCB3b3Jrcy4KPj4+IElmIHlvdSBjYW4gcHJvdmlkZSBhbiBleGFtcGxl
LCB0aGlzIHdpbGwgYmUgZXZlbiBncmVhdC4KPj4+Cj4+PiBUaGFuayB5b3UuCj4+Pgo+Pj4gQ2hl
ZXJzLAo+Pj4gTWVkCj4+Pgo+Pj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQo+Pj4+IERl
IDogSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0gRW52b3nDqSA6
IGpldWRpIDI2Cj4+Pj4gZsOpdnJpZXIgMjAxNSAxNTo0MSDDgCA6IEJPVUNBREFJUiBNb2hhbWVk
IElNVC9PTE47IHNmY0BpZXRmLm9yZyBDYyA6Cj4+Pj4gQmVuIFdyaWdodCAoQmVuLldyaWdodEBt
ZXRhc3dpdGNoLmNvbSkgT2JqZXQgOiBSZTogW3NmY10KPj4+PiBkcmFmdC1xdWlubi1zZmMtbnNo
OiBTdXBwb3J0IG9mIFNGIFNwaXJhbHNndDs+Pj4KPj4+PiBUaGUgU0YgU3BpcmFscyByZXF1aXJl
bWVudCBpcyBvbmUgb2YgdGhlIGtleSBkcml2ZXJzIGZvciB0aGUgaW5kZXguCj4+Pj4gVGhlIGlu
ZGV4IGFsbG93cyBvbmUgdG8gdGVsbCB3aGVyZSBvbmUgaXMgaW4gdGhlIHNwaXJhbCwgYW5kIGFs
c28gdG8KPj4+PiBicmVhayBhIGxvb3AgaWYgb25lIGhhcyBhIGxvb3AgaW5zdGVhZCBvZiBhIHNw
aXJhbC4KPj4+Pgo+Pj4+IElzIHRoZXJlIHRleHQgdGhhdCB3ZSBjb3VsZCBhZGQgdGhhdCB3b3Vs
ZCBoZWxwIG1ha2UgdGhpcyBjbGVhciwKPj4+PiBzaW5jZSB5b3VyIGVhcmxpZXIgcXVlc3Rpb24g
YWJvdXQgdGhlIHBhdGggaW5kZXggc3VnZ2VzdHMgdGhhdCBpdCBpcwo+Pj4+IG5vdCBhcyBjbGVh
ciBhcyBpdCBzaG91bGQgYmU/Cj4+Pj4KPj4+PiBZb3VycywKPj4+PiBKb2VsCj4+Pj4KPj4+PiBP
biAyLzI2LzE1IDg6NDIgQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6Cj4+
Pj4+IEhpIFBhdWwsIGFsbCwKPj4+Pj4KPj4+Pj4gVGhlcmUgd2VyZSBhIGRpc2N1c3Npb24gaW4g
dGhlIG1haWxpbmcgbGlzdAo+Pj4+PiAoaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv
d2ViL3NmYy9jdXJyZW50L21zZzAxNzAxLmh0bWwpCj4+Pj4+IHRoYXQgbGVkIHRvIGRlZmluaW5n
IHdoYXQgaXMgbWVhbnQgYnkgU0YgU3BpcmFsczogKGJlbG93IGlzIHByb3ZpZGVkCj4+Pj4+IGFu
IGV4Y2VycHQgZnJvbQo+Pj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3Vj
YWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wNiB3aGVyZQo+Pj4+PiB0aGUgY29uY2x1c2lvbnMgb2Yg
dGhhdCBkaXNjdXNzaW9uIHdlcmUgcmVjb3JkZWQpCj4+Pj4+Cj4+Pj4+ICLCoMKgIG/CoCBTZXJ2
aWNlIEZ1bmN0aW9uIFNwaXJhbDogZGVub3RlcyBhIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gaW4K
Pj4+PiB3aGljaAo+Pj4+Pgo+Pj4+PsKgwqDCoMKgwqDCoMKgwqDCoCBkYXRhIGlzIGhhbmRsZWQg
YnkgYSBTZXJ2aWNlIEZ1bmN0aW9uLCBmb3J3YXJkZWQgb253YXJkcywKPj4+Pj4gYW5kCj4+Pj4+
Cj4+Pj4+wqDCoMKgwqDCoMKgwqDCoMKgIGFycml2ZXMgb25jZSBhZ2FpbiBhdCB0aGF0IFNlcnZp
Y2UgRnVuY3Rpb24uCj4+Pj4+Cj4+Pj4+wqDCoMKgwqDCoMKgwqDCoMKgICrCoCBOb3RlIHRoYXQg
c29tZSBTZXJ2aWNlIEZ1bmN0aW9ucyBzdXBwb3J0IGJ1aWx0LWluCj4+Pj4+IGZ1bmN0aW9ucyB0
bwo+Pj4+Pgo+Pj4+PsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBhY2NvbW1vZGF0ZSBzcGlyYWxz
OyB0aGVzZSBzZXJ2aWNlLXNwZWNpZmljIGZ1bmN0aW9ucyBtYXkKPj4+Pj4KPj4+Pj7CoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqAgcmVxdWlyZSB0aGF0IHRoZSBkYXRhIHJlY2VpdmVkIGluIGEgc3Bp
cmFsIHNob3VsZCBkaWZmZXIKPj4+Pj4gaW4gYQo+Pj4+Pgo+Pj4+PsKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoCB3YXkgdGhhdCB3aWxsIHJlc3VsdCBpbiBhIGRpZmZlcmVudCBwcm9jZXNzaW5nIGRl
Y2lzaW9uCj4+Pj4+IHRoYW4KPj4+Pj4KPj4+Pj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgdGhl
IG9yaWdpbmFsIGRhdGEuwqAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBtYWtlIHN1Y2gKPj4+Pj4K
Pj4+Pj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYXNzdW1wdGlvbi4KPj4+Pj4KPj4+Pj7CoMKg
wqDCoMKgwqDCoMKgwqAgKsKgIEEgU2VydmljZSBGdW5jdGlvbiBDaGFpbiBtYXkgaW52b2x2ZSBv
bmUgb3IgbW9yZSBTZXJ2aWNlCj4+Pj4+Cj4+Pj4+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEZ1
bmN0aW9uIFNwaXJhbHMuCj4+Pj4+Cj4+Pj4+wqDCoMKgwqDCoMKgwqDCoMKgICrCoCBVbmxpa2Ug
U2VydmljZSBGdW5jdGlvbiBsb29wLCBzcGlyYWxzIGFyZSBub3QgY29uc2lkZXJlZAo+Pj4+PiBh
cwo+Pj4+Pgo+Pj4+PsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBlcnJvcnMuIgo+Pj4+Pgo+Pj4+
PiBBbmQgdGhpcyBjb21wYW5pb24gcmVxdWlyZW1lbnQ6Cj4+Pj4+Cj4+Pj4+ICLCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgIEEuwqAgU2VydmljZSBGdW5jdGlvbnMgTUFZIGJlIGludm9rZWQg
bXVsdGlwbGUgdGltZXMgaW4KPj4+Pj4KPj4+Pj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoCB0aGUgc2FtZSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluIChkZW5vdGVk
IGFzIFNGCj4+Pj4+Cj4+Pj4+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqAgU3BpcmFsKSwgYnV0IHRoZSBzb2x1dGlvbiBNVVNUIHByZXZlbnQgaW5maW5pdGUKPj4+
Pj4KPj4+Pj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBmb3J3
YXJkaW5nIGxvb3BzLiDCuwo+Pj4+Pgo+Pj4+PiBSZWFkaW5nIHRoZSBjdXJyZW50IGRyYWZ0LXF1
aW5uLXNmYy1uc2gsIEkgZG9uJ3Qgc2VlIGhvdyB0aGlzIGlzIG1ldC4KPj4+Pj4KPj4+Pj4gQ2Fu
IHlvdSBwbGVhc2UgY2xhcmlmeSB3aGV0aGVyIHRoaXMgaXMgc3VwcG9ydGVkIGFuZCBob3c/Cj4+
Pj4+Cj4+Pj4+IFRoYW5rIHlvdS4KPj4+Pj4KPj4+Pj4gQ2hlZXJzLAo+Pj4+Pgo+Pj4+PiBNZWQK
Pj4+Pj4KPj4+Pj4KPj4+Pj4KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KPj4+Pj4gc2ZjIG1haWxpbmcgbGlzdAo+Pj4+PiBzZmNAaWV0Zi5vcmcK
Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMKPj4+Pj4KPj4+
Cj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+
IHNmYyBtYWlsaW5nIGxpc3QKPj4gc2ZjQGlldGYub3JnCj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vc2ZjCj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fCj4+IHNmYyBtYWlsaW5nIGxpc3QKPj4gc2ZjQGlldGYub3JnCj4+
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjCj4+Cj4+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+IHNmYyBtYWlsaW5nIGxp
c3QKPj4gc2ZjQGlldGYub3JnCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vc2ZjCj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fCj4+IHNmYyBtYWlsaW5nIGxpc3QKPj4gc2ZjQGlldGYub3JnCj4+IGh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjCj4KPgo=

----_com.android.email_159081965057974
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT5JbnN0cnVjdGlvbiBjb21lcyBmcm9t
IHRoZSBzZXZpY2UgZnVuY3Rpb24gZGVzaWduLiAmbmJzcDtTb21lIGhlYWRlciBzdHJ1Y3R1cmVz
IGF1Z21lbnQgdGhhdCB3aXRoIGNvbnRyb2wgbWFwcGluZyBpYmZvcm1hdGlvbiB0byBpbmRpY2F0
ZSB3aGljaCBtZXRhZGF0YSBmaWVsZCBoYXMgd2hpY2ggdXNlLjxkaXY+PGJyPjwvZGl2PjxkaXY+
R29yIFRMViBiYXNlZCBtZXRhZGF0IHdlIHByb2JhYmx5IGVhbnQgYSByZWdpc3RyeSB3aXRoIHZl
cnkgZWFzeSBlbnRyeSBjcmVhdGlvbi48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PllvdXJzLDwv
ZGl2PjxkaXY+Sm9lbDxicj48YnI+PGJyPjxzcGFuIHN0eWxlPSJmb250LXNpemU6ODclIj5TZW50
IGZyb20gbXkgU2Ftc3VuZyBzbWFydHBob25lIG9uIEFUJmFtcDtUPC9zcGFuPiA8L2Rpdj48YnI+
PGJyPjxicj4tLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJyPlN1YmplY3Q6IFJF
OiBbc2ZjXSBkcmFmdC1xdWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHMgPGJyPkZy
b206IERhdmUgRG9sc29uICZsdDtkZG9sc29uQHNhbmR2aW5lLmNvbSZndDsgPGJyPlRvOiAiSm9l
bCBNLiBIYWxwZXJuIiAmbHQ7am1oQGpvZWxoYWxwZXJuLmNvbSZndDssIlJlaW5hbGRvIFBlbm5v
IChyZXBlbm5vKSIgJmx0O3JlcGVubm9AY2lzY28uY29tJmd0OyxSb24gUGFya2VyICZsdDtSb25f
UGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tJmd0OywibW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl
LmNvbSIgJmx0O21vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20mZ3Q7LCJzZmNAaWV0Zi5vcmci
ICZsdDtzZmNAaWV0Zi5vcmcmZ3Q7IDxicj5DQzogIkJlbiBXcmlnaHQgKEJlbi5XcmlnaHRAbWV0
YXN3aXRjaC5jb20pIiAmbHQ7QmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbSZndDsgPGJyPjxicj48
YnI+PGRpdiBzdHlsZT0id29yZC1icmVhazpicmVhay1hbGw7Ij5XaGF0IGFyZSB0aGUgbWVjaGFu
aWNzIG9mIHVzaW5nIG1ldGEtZGF0YT88YnI+V2hpY2ggZWxlbWVudCBzZXRzIGl0LCBhbmQgaG93
IGlzIGl0IGluc3RydWN0ZWQgdG8gZG8gc28/PGJyPjxicj48YnI+LS0tLS1PcmlnaW5hbCBNZXNz
YWdlLS0tLS08YnI+RnJvbTogSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJu
LmNvbV0gPGJyPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAxMjozNiBQTTxicj5U
bzogRGF2ZSBEb2xzb247IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgUm9uIFBhcmtlcjsgbW9o
YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnPGJyPkNjOiBCZW4gV3JpZ2h0
IChCZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tKTxicj5TdWJqZWN0OiBSZTogW3NmY10gZHJhZnQt
cXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzPGJyPjxicj5QZXJzb25hbGx5LCBJ
IHdvdWxkIHByZWZlciB0aGF0IHRoZSBmaXJld2FsbCB1c2UgbWV0YWRhdGEgcmF0aGVyIHRoYW4g
PGJyPnBhdGgtaW5kZXguJm5ic3A7IE15IHJlYXNvbmluZyBpcyB0aGF0IGlmIGZ1bmN0aW9ucyBn
ZXQgYWRkZWQgYmVmb3JlIG9yIGFmdGVyIDxicj50aGUgZmlyZXdhbGwsIG9wZXJhdGlvbnMgd291
bGQgcHJlZmVyIG5vdCB0byBoYXZlIHRvIGNoYW5nZSB0aGUgPGJyPmNvbmZpZ3VyYXRpb24gb2Yg
dGhlIGZpcmV3YWxsIFNGIGl0c2VsZi48YnI+PGJyPkhhdmluZyBzYWlkIHRoYXQsIEkgZG9uJ3Qg
c2VlIGFueSB3YXkgdG8gc3RvcCB5b3UgZnJvbSB1c2luZyB0aGUgcGF0aCBpbmRleC48YnI+PGJy
PllvdXJzLDxicj5Kb2VsPGJyPjxicj5PbiAyLzI2LzE1IDEyOjMwIFBNLCBEYXZlIERvbHNvbiB3
cm90ZTo8YnI+Jmd0OyBGb3IgdGhlIHNha2Ugb2YgYXJndW1lbnQsIHN1cHBvc2UgSSBoYXZlIGEg
ZmlyZXdhbGwgU0YsIGFuZCBJIHdhbnQgdG8gdXNlPGJyPiZndDsgaXQgbW9yZSB0aGFuIG9uY2Ug
aW4gYSBjaGFpbi4gKE1heWJlIEkgd2FudCB0byBib29rLWVuZCB0aGUgY2hhaW4gd2l0aCBpbmdy
ZXNzPGJyPiZndDsgYW5kIGVncmVzcyBydWxlcy4pPGJyPiZndDs8YnI+Jmd0OyBEbyB5b3UgYWdy
ZWUgaXQgd291bGQgYmUgc3VmZmljaWVudCB0byB1c2UgdGhlIFBhdGggSW5kZXggdG8gc2VsZWN0
IHdoaWNoIG9mPGJyPiZndDsgdGhlIGluZ3Jlc3Mgb3IgZWdyZXNzIHJ1bGUgc2V0cyBzaG91bGQg
YmUgdXNlZD88YnI+Jmd0Ozxicj4mZ3Q7IEknbSBwcm9iYWJseSBtaXNzaW5nIHNvbWV0aGluZzsg
SSBkb24ndCB1bmRlcnN0YW5kIGhvdyB0aGUgY29udGV4dCBoZWFkZXJzPGJyPiZndDsgZGVmaW5l
IGZ1bmN0aW9uYWxpdHkuIE1heWJlIHRoZSBkZXZpY2UgY291bGQgY29tbXVuaWNhdGUgd2l0aCBp
dHNlbGY8YnI+Jmd0OyAoZS5nLiwgdGhlIGluZ3Jlc3MgcG9ydGlvbiBzZW5kaW5nIGEgdGFnIHRv
IHRoZSBlZ3Jlc3MgcG9ydGlvbik8YnI+Jmd0OyBieSBzZW5kaW5nIHN0YXRlIGluIHRoZSBwYWNr
ZXQuIElzIHRoYXQgd2hhdCB5b3UgYXJlIG1lYW4gYnkgImNvbnRleHR1YWwgaW5mbyIgPzxicj4m
Z3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy
PiZndDsgRnJvbTogUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pIFttYWlsdG86cmVwZW5ub0BjaXNj
by5jb21dPGJyPiZndDsgU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE1IDEyOjE4IFBN
PGJyPiZndDsgVG86IERhdmUgRG9sc29uOyBSb24gUGFya2VyOyBKb2VsIE0uIEhhbHBlcm47IG1v
aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZzxicj4mZ3Q7IENjOiBCZW4g
V3JpZ2h0IChCZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tKTxicj4mZ3Q7IFN1YmplY3Q6IFJlOiBb
c2ZjXSBkcmFmdC1xdWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHM8YnI+Jmd0Ozxi
cj4mZ3Q7IEFncmVlZCBvbiBhbGwgcG9pbnRzLiBJIHRob3VnaHQgSSB3YXMgbWlzc2luZyBzb21l
dGhpbmcgc28gYmVmb3JlIHdyaXRpbmc8YnI+Jmd0OyB0aGlzIGVtYWlsIEkgcmV0ZXN0ZWQgb3Vy
IGltcGxlbWVudGF0aW9uIGFuZCBpdCB3b3JrZWQgb2ZmIHRoZSBiYXQuIFRoZTxicj4mZ3Q7IFJT
UCBjb25zdHJ1Y3RlZCBoYXMgdGhlIHRoZSBzYW1lIChTRkYsIFNGKSB0dXBsZSBidXQgZGlmZmVy
ZW50IGluZGV4ZXMuPGJyPiZndDs8YnI+Jmd0OyBUaGUgc2FtZSBTRiBpcyB2aXNpdGVkIG11bHRp
cGxlIHRpbWVzIHVudGlsIHRoZSBwYXRoIGVuZHMuJm5ic3A7IElmIHRoZSBTRjxicj4mZ3Q7IHdh
bnRzIGNvbnRleHR1YWwgaW5mbyBhY3Jvc3MgdmlzaXRzIHRoYW4gY29udGV4dCBoZWFkZXJzIGFy
ZSB0aGUgd2F5IHRvPGJyPiZndDsgZ28uPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IE9uIDIvMjYv
MTUsIDg6NTIgQU0sICJEYXZlIERvbHNvbiIgJmx0O2Rkb2xzb25Ac2FuZHZpbmUuY29tJmd0OyB3
cm90ZTo8YnI+Jmd0Ozxicj4mZ3Q7Jmd0OyBNYXliZSBuYWl2ZWx5LCBJIHRob3VnaHQgdGhlIHNl
cnZpY2UgZnVuY3Rpb25zIHdvdWxkIGJlIHByb3Zpc2lvbmVkIHdpdGg8YnI+Jmd0OyZndDsgYSB0
YWJsZTo8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgRS5nLiwgZm9yIGVsZW1lbnQgZm9vOjxicj4m
Z3Q7Jmd0OyBQYXRoIHwgUGF0aCBJbmRleCB8IE5leHQgSG9wJm5ic3A7IHwgRnVuY3Rpb248YnI+
Jmd0OyZndDsgMTIzIHwmbmJzcDsgNCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IFNGLWJhciZuYnNwOyB8IGZpcnN0IGJlaGF2aW9y
PGJyPiZndDsmZ3Q7IDEyMyB8Jm5ic3A7IDImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgfCBTRi1mb29iYXIgfCBzZWNvbmQgYmVoYXZpb3I8YnI+Jmd0OyZn
dDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgVGhlIEZ1bmN0aW9uIGlzIGNsZWFybHkgaW1wbGVt
ZW50YXRpb24gc3BlY2lmaWMuIE1heWJlIGl0IHBvaW50cyB0byBhPGJyPiZndDsmZ3Q7IGNvbmZp
Z3VyYXRpb24gc2V0IG9yIGEgcG9saWN5IHNldC4gSSB0aGluayBjb21wbGV0ZWx5IG91dCBvZiBz
Y29wZSBoZXJlLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBJIHN1Z2dlc3QgdGhhdCB0aGlzIGlz
IG5vdCBhIHByb2JsZW0gZm9yIHRoZSB3aXJlIHByb3RvY29sLCByYXRoZXIgZm9yPGJyPiZndDsm
Z3Q7IHRoZSBjb25maWd1cmF0aW9uIG1vZGVsIChuZXRjb25mIG9yIHdoYXRldmVyKS48YnI+Jmd0
OyZndDs8YnI+Jmd0OyZndDsgSXQgYmVjb21lcyB2ZXJ5IG11Y2ggdmVuZG9yLXNwZWNpZmljIGlm
IHRoZSBiZWhhdmlvcnMgYXJlIGNvbXBsZXg8YnI+Jmd0OyZndDsgY29uZmlndXJhdGlvbnMgb2Yg
c3BlY2lhbGl6ZWQgZmVhdHVyZXMuPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IElmIGEgcGVyc29u
IHdlcmUgbWFudWFsbHkgY29uZmlndXJpbmcgY2hhaW5zLCBJIGRvbid0IHRoaW5rIHRoZXknZCBo
YXZlIGE8YnI+Jmd0OyZndDsgY29uY2VwdHVhbCBwcm9ibGVtLCBiZWNhdXNlIHRoZXknZCBoYXZl
IGEgZGlhZ3JhbSB0aGV5IG5lZWQgdG8gaW1wbGVtZW50Ojxicj4mZ3Q7Jmd0OyB7U0YtZm9vIChm
aXJzdC1iZWhhdmlvciksIFNGLWJhciwgU0YtZm9vIChzZWNvbmQtYmVoYXZpb3IpLCBTRi1mb29i
YXJ9PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IElmIHdlIHdhbnRlZCB0byBzdGFuZGFyZGl6ZSBp
dCwgd2UgY291bGQgbWF5YmUgbWFrZSB0aGUgRnVuY3Rpb24gc2ltcGx5IGE8YnI+Jmd0OyZndDsg
bGFiZWwgdGhhdCBtZWFucyBzb21ldGhpbmcgdG8gdGhlIGRldmljZS0tYW4gaW5kaXJlY3Rpb24g
dG8gYTxicj4mZ3Q7Jmd0OyBjb25maWd1cmF0aW9uIHNldC48YnI+Jmd0OyZndDs8YnI+Jmd0OyZn
dDsgLURhdmU8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsg
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0OyZndDsgRnJvbTogc2ZjIFttYWlsdG86
c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb24gUGFya2VyPGJyPiZndDsmZ3Q7
IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAxMTozMSBBTTxicj4mZ3Q7Jmd0OyBU
bzogRGF2ZSBEb2xzb247IEpvZWwgTS4gSGFscGVybjsgbW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl
LmNvbTs8YnI+Jmd0OyZndDsgc2ZjQGlldGYub3JnPGJyPiZndDsmZ3Q7IENjOiBCZW4gV3JpZ2h0
IChCZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tKTxicj4mZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3Nm
Y10gZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzPGJyPiZndDsmZ3Q7
PGJyPiZndDsmZ3Q7IEhpLCBEYXZlLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBJIGFncmVlIHRo
YXQgb24gdGhlIHdpcmUsIHRoaXMgaXMgdGhlIHdheSBpdCB3b3VsZCB3b3JrLjxicj4mZ3Q7Jmd0
Ozxicj4mZ3Q7Jmd0OyBCdXQsIHdoZW4gY29tcG9zaW5nIHRoZSBjaGFpbiwgaXQgc2VlbXMgbGlr
ZSBpbmZvcm1hdGlvbiB3b3VsZCBiZSBsYWNraW5nPGJyPiZndDsmZ3Q7IGlmIGEgY2hhaW4gd2Vy
ZSBleHByZXNzZWQgc2ltcGx5IGFzIHtTRi1mb28sIFNGLWJhciwgU0YtZm9vLCBTRi1mb29iYXJ9
Ljxicj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBJdCBpcyBjb21wbGV0ZWx5IGltcGxpY2l0IHRoYXQg
c2luY2UgU0YtZm9vIGFwcGVhcnMgdHdpY2UsIGl0IHBlcmhhcHM8YnI+Jmd0OyZndDsgc2hvdWxk
IHBlcmZvcm0gc29tZSBkaWZmZXJlbnQgZHV0eSB3aGVuIGluZGV4ID0gMCB2cyB3aGVuIGluZGV4
ID0gMi48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgQXQgZmlyc3QsIEkgdGhvdWdodCB0aGF0IGFu
IGFsdGVybmF0aXZlIHdheSB0byBoYW5kbGUgdGhpcyB3b3VsZCBiZSB0bzxicj4mZ3Q7Jmd0OyB1
c2UgbXVsdGlwbGUgbG9naWNhbCBpZGVudGl0aWVzIGZvciBTRi1mb28uJm5ic3A7IEluIHRoaXMg
Y2FzZSwgdGhlIGNoYWluPGJyPiZndDsmZ3Q7IGFib3ZlIHdvdWxkIGJlIGV4cHJlc3NlZCBhcyB7
U0YtZm9vLWZpcnN0LWJlaGF2aW9yLCBTRi1iYXIsPGJyPiZndDsmZ3Q7IFNGLWZvby1zZWNvbmQt
YmVoYXZpb3IsIFNGLWZvb2Jhcn0uJm5ic3A7Jm5ic3A7IEJ1dCwgdGhlIHByb2JsZW0gaGVyZSBp
cyBzZWxlY3Rpbmc8YnI+Jmd0OyZndDsgdGhlIFJTUCwgYXNzdW1pbmcgdGhhdCBTRi1mb28gaGFz
IG11bHRpcGxlIGluc3RhbmNlcy4mbmJzcDsmbmJzcDsgTm90aGluZyBpbiB0aGlzPGJyPiZndDsm
Z3Q7IHNlY29uZCBmbGF2b3Igb2YgY2hhaW4gc2F5cyB0aGF0IHRoZSBzYW1lIGluc3RhbmNlIG9m
IFNGLWZvby0qIG11c3QgYmU8YnI+Jmd0OyZndDsgc2VsZWN0ZWQgdG8gc2F0aXNmeSBTRi1mb28t
Zmlyc3QtYmVoYXZpb3IgYW5kIFNGLWZvby1zZWNvbmQtYmVoYXZpb3I8YnI+Jmd0OyZndDsgKHdo
aWNoIG1heSBub3QgYmUgcmVxdWlyZWQsIGJ1dCBzaG91bGQgYmUgcG9zc2libGUgdG8gZm9yY2Ug
YXMgc3VjaCkuPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IEkgZ3Vlc3Mgd2hhdCBJJ20gc2F5aW5n
IGlzIHRoYXQgc3BpcmFsaW5nIGhhcyBhIHN1YnRsZXR5IHRvIGl0IHRoYXQgaXNuJ3Q8YnI+Jmd0
OyZndDsgeWV0IGFkZXF1YXRlbHkgYWRkcmVzc2VkIGFuZCB0aGF0IEkgZG9uJ3QgaGF2ZSBhIHNw
ZWNpZmljIHByb3Bvc2FsIHRvPGJyPiZndDsmZ3Q7IHNvbHZlIGl0LCBlaXRoZXIuPGJyPiZndDsm
Z3Q7PGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvbjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7
Jmd0Ozxicj4mZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4mZ3Q7Jmd0OyBG
cm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmUg
RG9sc29uPGJyPiZndDsmZ3Q7IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAxMToy
MSBBTTxicj4mZ3Q7Jmd0OyBUbzogSm9lbCBNLiBIYWxwZXJuOyBtb2hhbWVkLmJvdWNhZGFpckBv
cmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmc8YnI+Jmd0OyZndDsgQ2M6IEJlbiBXcmlnaHQgKEJlbi5X
cmlnaHRAbWV0YXN3aXRjaC5jb20pPGJyPiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBkcmFm
dC1xdWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHM8YnI+Jmd0OyZndDs8YnI+Jmd0
OyZndDsgSWYgSSBtYXkgdHJ5IHRvIHB1dCBpdCBzaW1wbHksIEkndmUgYWx3YXlzIHRob3VnaHQg
b2YgaXQgdGhpcyB3YXk6PGJyPiZndDsmZ3Q7IC0tJmd0OyBFYWNoIG5vZGUgaW4gdGhlIGNoYWlu
IHNlbGVjdHMgdGhlIGNvbnRleHQgZm9yIHByb2Nlc3NpbmcgYW5kIHRoZTxicj4mZ3Q7Jmd0OyBu
ZXh0IGhvcCBvbiB0aGUgYmFzaXMgb2YgQk9USCBwYXRoIElEIGFuZCBJbmRleCwgd2hpbGUgZGVj
cmVtZW50aW5nIHRoZTxicj4mZ3Q7Jmd0OyBpbmRleCBmb3IgdGhlIG5leHQgaG9wLjxicj4mZ3Q7
Jmd0Ozxicj4mZ3Q7Jmd0OyBUaGF0IGJlaGF2aW9yIHN1cHBvcnRzIHNwaXJhbGluZy48YnI+Jmd0
OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgLURhdmU8YnI+Jmd0OyZn
dDs8YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+
Jmd0OyZndDsgRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs
ZiBPZiBKb2VsIE0uIEhhbHBlcm48YnI+Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5
IDI2LCAyMDE1IDEwOjAyIEFNPGJyPiZndDsmZ3Q7IFRvOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFu
Z2UuY29tOyBzZmNAaWV0Zi5vcmc8YnI+Jmd0OyZndDsgQ2M6IEJlbiBXcmlnaHQgKEJlbi5Xcmln
aHRAbWV0YXN3aXRjaC5jb20pPGJyPiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBkcmFmdC1x
dWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHM8YnI+Jmd0OyZndDs8YnI+Jmd0OyZn
dDsgVGhlcmUgYXJlIHR3byBkaWZmZXJlbnQgYXNwZWN0cyBvZiBTcGlyYWxzLjxicj4mZ3Q7Jmd0
Ozxicj4mZ3Q7Jmd0OyBPbmUgb2YgdGhlIHR3byBhc3BlY3RzIGlzIGVuYWJsaW5nIGEgcGFja2V0
IHRoYXQgcmVwZWF0ZWRseSBhcnJpdmVzIGF0PGJyPiZndDsmZ3Q7IHRoZSBzYW1lIFNGRiB0byBn
ZXQgdGhlIGNvcnJlY3Qgc2VydmljZXMgcHJvdmlkZWQgZWFjaCB0aW1lIGl0IGFycml2ZXMsPGJy
PiZndDsmZ3Q7IGFuZCB0byBnbyB0byB0aGUgY29ycmVjdCBuZXh0IFNGRiBlYWNoIHRpbWUgaXQg
YXJyaXZlcy4mbmJzcDsgVGhlIFNlcnZpY2UgUGF0aDxicj4mZ3Q7Jmd0OyBJbmRleCwgdXNlZCBi
eSB0aGUgU0ZGIHRvIHNlbGVjdCBzZXJ2aWNlIGZ1bmN0aW9ucyBhbmQgbmV4dCBTRkYsIHByb3Zp
ZGVzPGJyPiZndDsmZ3Q7IHRoYXQgY2FwYWJpbGl0eS48YnI+Jmd0OyZndDs8YnI+Jmd0OyZndDsg
VGhlIG90aGVyIGFzcGVjdCBpcyBob3cgdGhlIFNlcnZpY2UgRnVuY3Rpb25zIHRoZW1zZWx2ZXMg
aGFuZGxlIHNwaXJhbHMuPGJyPiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IFRvIGEgbGFyZ2UgZGVncmVl
LCB0aGF0IGRlcGVuZHMgdXBvbiB0aGUgaW5kaXZpZHVhbCBzZXJ2aWNlIGZ1bmN0aW9uLjxicj4m
Z3Q7Jmd0OyZuYnNwOyZuYnNwOyBJIG5vcm1hbGx5IGFzc3VtZSB0aGF0IGl0IHdvdWxkIHVzZSBw
YWNrZXQgY29udGV4dCAoYXMgZGVzY3JpYmVkIGluIHRoZTxicj4mZ3Q7Jmd0OyB0ZXh0IHlvdSBx
dW90ZSkgdG8gZGV0ZXJtaW5lIHdoYXQgdG8gZG8uPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IFNp
bmNlIEkgd291bGQgcHJlZmVyIHRoYXQgc2VydmljZSBmdW5jdGlvbnMgYXJlIGluZGVwZW5kZW50
IG9mIHRoZTxicj4mZ3Q7Jmd0OyB1bmRlcmx5aW5nIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcg
aW5mcmFzdHJ1Y3R1cmUsIGFuZCBhcmUgbm90PGJyPiZndDsmZ3Q7IHNlbnNpdGl2ZSB0byBob3cg
bWFueSBmdW5jdGlvbnMgYXJlIGJlZm9yZSBvciBhZnRlciB0aGVtIGluIHRoZSBjaGFpbiwgSTxi
cj4mZ3Q7Jmd0OyB3b3VsZCBwZXJzb25hbGx5IHByZWZlciB0aGF0IHRoZXkgbm90IHVzZSB0aGUg
cGF0aCBpbmRleCBmb3IgdGhhdC4mbmJzcDsgSTxicj4mZ3Q7Jmd0OyB3b3VsZCByZWNvbW1lbmQg
dGhhdCBpZiB0aGUgcGFja2V0IGRvZXMgbm90IGNhcnJ5IGVub3VnaCBjb250ZXh0IHRoYXQgdGhl
PGJyPiZndDsmZ3Q7IHNlcnZpY2UgZnVuY3Rpb24gY291bGQgYW5kIHNob3VsZCB1c2UgbWV0YWRh
dGEgdG8gY2FycnkgaXRzIG5lZWRlZCBzdGF0ZTxicj4mZ3Q7Jmd0OyBpbmZvcm1hdGlvbi4mbmJz
cDsgQnV0IG5laXRoZXIgSSBwZXJzb25hbGx5IG5vciB0aGUgU0ZDIFdvcmtpbmcgR3JvdXAgZ2V0
IHRvPGJyPiZndDsmZ3Q7IHRlbGwgZm9sa3MgaG93IHRvIGJ1aWxkIHRoZWlyIHNlcnZpY2UgZnVu
Y3Rpb25zLiZuYnNwOyBTbyB0aGV5IG1heSBjb21lIHVwPGJyPiZndDsmZ3Q7IHdpdGggb3RoZXIg
bWV0aG9kcyBmb3IgYWRkcmVzc2luZyB0aGVpciBuZWVkcy4mbmJzcDsgV2hpY2ggaXMgYWxzbyBm
aW5lLjxicj4mZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyBUaHVzLCBJIHdvdWxkIG5vdCBleHBlY3QgdGhp
cyBkb2N1bWVudCB0byBkaXNjdXNzIGhvdyBzZXJ2aWNlIGZ1bmN0aW9uczxicj4mZ3Q7Jmd0OyB0
aGVtc2VsdmVzIGhhbmRsZSByZXZpc2l0aW5nLiZuYnNwOyBCdXQgbWV0YWRhdGEgY2xlYXJseSBh
bGxvd3MgZm9yIGEgcmFuZ2Ugb2Y8YnI+Jmd0OyZndDsgYmVoYXZpb3JzIHRoYXQgd2lsbCB3b3Jr
LiZuYnNwOyBBbmQgdGhlIHBhdGggaW5kZXggaGFuZGxlcyB0aGUgU0ZGIG5lZWRzPGJyPiZndDsm
Z3Q7IHJlbGF0aXZlIHRvIHNwaXJhbHMsIHdoaWNoIGlzIHdoYXQgd2UgbmVlZCB0byBoYW5kbGUu
PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IFlvdXJzLDxicj4mZ3Q7Jmd0OyBKb2VsPGJyPiZndDsm
Z3Q7PGJyPiZndDsmZ3Q7IE9uIDIvMjYvMTUgOTo1MiBBTSwgbW9oYW1lZC5ib3VjYWRhaXJAb3Jh
bmdlLmNvbSB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7IFJlLSw8YnI+Jmd0OyZndDsmZ3Q7PGJyPiZn
dDsmZ3Q7Jmd0OyBTcGlyYWwgaXMgbm90IG1lbnRpb25lZCBpbiB0aGUgZHJhZnQsIGJ1dCBTRiBs
b29wIGlzLjxicj4mZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7IEknbSBhc2tpbmcgdGhlIHF1
ZXN0aW9uIGJlY2F1c2UgSSBkb24ndCBnZXQgZnJvbSB0aGUgZHJhZnQgaG93IHNwaXJhbHM8YnI+
Jmd0OyZndDsmZ3Q7IGNvdWxkIHdvcmsgKHRoYXQgaXMgYSBTRiBpbnZva2VkIHNldmVyYWwgdGlt
ZSBpbiB0aGUgY29udGV4dCBvZiB0aGUgc2FtZTxicj4mZ3Q7Jmd0OyZndDsgU0ZDKS48YnI+Jmd0
OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBCZWZvcmUgcHJvcG9zaW5nIHRleHQsIEkgd291bGQg
bGlrZSB0byB1bmRlcnN0YW5kIGZpcnN0IGhvdyBpdCB3b3Jrcy48YnI+Jmd0OyZndDsmZ3Q7IElm
IHlvdSBjYW4gcHJvdmlkZSBhbiBleGFtcGxlLCB0aGlzIHdpbGwgYmUgZXZlbiBncmVhdC48YnI+
Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyBUaGFuayB5b3UuPGJyPiZndDsmZ3Q7Jmd0Ozxi
cj4mZ3Q7Jmd0OyZndDsgQ2hlZXJzLDxicj4mZ3Q7Jmd0OyZndDsgTWVkPGJyPiZndDsmZ3Q7Jmd0
Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxicj4mZ3Q7
Jmd0OyZndDsmZ3Q7IERlIDogSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am1oQGpvZWxoYWxwZXJu
LmNvbV0gRW52b3nDqSA6IGpldWRpIDI2PGJyPiZndDsmZ3Q7Jmd0OyZndDsgZsOpdnJpZXIgMjAx
NSAxNTo0MSDDgCA6IEJPVUNBREFJUiBNb2hhbWVkIElNVC9PTE47IHNmY0BpZXRmLm9yZyBDYyA6
PGJyPiZndDsmZ3Q7Jmd0OyZndDsgQmVuIFdyaWdodCAoQmVuLldyaWdodEBtZXRhc3dpdGNoLmNv
bSkgT2JqZXQgOiBSZTogW3NmY108YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBkcmFmdC1xdWlubi1zZmMt
bnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHNndDsmZ3Q7Jmd0OyZndDs8L2Rpdj4mZ3Q7Jmd0OyZn
dDsmZ3Q7IFRoZSBTRiBTcGlyYWxzIHJlcXVpcmVtZW50IGlzIG9uZSBvZiB0aGUga2V5IGRyaXZl
cnMgZm9yIHRoZSBpbmRleC48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgaW5kZXggYWxsb3dzIG9u
ZSB0byB0ZWxsIHdoZXJlIG9uZSBpcyBpbiB0aGUgc3BpcmFsLCBhbmQgYWxzbyB0bzxicj4mZ3Q7
Jmd0OyZndDsmZ3Q7IGJyZWFrIGEgbG9vcCBpZiBvbmUgaGFzIGEgbG9vcCBpbnN0ZWFkIG9mIGEg
c3BpcmFsLjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsgSXMgdGhlcmUg
dGV4dCB0aGF0IHdlIGNvdWxkIGFkZCB0aGF0IHdvdWxkIGhlbHAgbWFrZSB0aGlzIGNsZWFyLDxi
cj4mZ3Q7Jmd0OyZndDsmZ3Q7IHNpbmNlIHlvdXIgZWFybGllciBxdWVzdGlvbiBhYm91dCB0aGUg
cGF0aCBpbmRleCBzdWdnZXN0cyB0aGF0IGl0IGlzPGJyPiZndDsmZ3Q7Jmd0OyZndDsgbm90IGFz
IGNsZWFyIGFzIGl0IHNob3VsZCBiZT88YnI+Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZn
dDsmZ3Q7IFlvdXJzLDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IEpvZWw8YnI+Jmd0OyZndDsmZ3Q7Jmd0
Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDIvMjYvMTUgODo0MiBBTSwgbW9oYW1lZC5ib3VjYWRh
aXJAb3JhbmdlLmNvbSB3cm90ZTo8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSGkgUGF1bCwgYWxs
LDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGVyZSB3
ZXJlIGEgZGlzY3Vzc2lvbiBpbiB0aGUgbWFpbGluZyBsaXN0PGJyPiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2ZjL2N1cnJlbnQvbXNn
MDE3MDEuaHRtbCk8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCBsZWQgdG8gZGVmaW5pbmcg
d2hhdCBpcyBtZWFudCBieSBTRiBTcGlyYWxzOiAoYmVsb3cgaXMgcHJvdmlkZWQ8YnI+Jmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgYW4gZXhjZXJwdCBmcm9tPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGh0
dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRz
LTA2IHdoZXJlPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBjb25jbHVzaW9ucyBvZiB0aGF0
IGRpc2N1c3Npb24gd2VyZSByZWNvcmRlZCk8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0
OyZndDsmZ3Q7Jmd0OyZndDsgIiZuYnNwOyZuYnNwOyBvJm5ic3A7IFNlcnZpY2UgRnVuY3Rpb24g
U3BpcmFsOiBkZW5vdGVzIGEgU2VydmljZSBGdW5jdGlvbiBDaGFpbiBpbjxicj4mZ3Q7Jmd0OyZn
dDsmZ3Q7IHdoaWNoPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IGRhdGEgaXMgaGFuZGxlZCBieSBhIFNlcnZpY2UgRnVuY3Rpb24sIGZvcndhcmRlZCBvbndhcmRz
LDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbmQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgYXJyaXZlcyBvbmNlIGFnYWluIGF0IHRoYXQgU2VydmljZSBGdW5j
dGlvbi48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNw
OyBOb3RlIHRoYXQgc29tZSBTZXJ2aWNlIEZ1bmN0aW9ucyBzdXBwb3J0IGJ1aWx0LWluPGJyPiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZ1bmN0aW9ucyB0bzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi
cj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhY2NvbW1vZGF0ZSBzcGlyYWxz
OyB0aGVzZSBzZXJ2aWNlLXNwZWNpZmljIGZ1bmN0aW9ucyBtYXk8YnI+Jmd0OyZndDsmZ3Q7Jmd0
OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVxdWlyZSB0aGF0
IHRoZSBkYXRhIHJlY2VpdmVkIGluIGEgc3BpcmFsIHNob3VsZCBkaWZmZXI8YnI+Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsgaW4gYTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3YXkgdGhhdCB3aWxsIHJlc3VsdCBpbiBhIGRpZmZlcmVu
dCBwcm9jZXNzaW5nIGRlY2lzaW9uPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYW48YnI+Jmd0
OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
dGhlIG9yaWdpbmFsIGRhdGEuJm5ic3A7IFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgbWFrZSBzdWNo
PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IGFzc3VtcHRpb24uPGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7ICombmJzcDsgQSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluIG1heSBpbnZvbHZlIG9uZSBv
ciBtb3JlIFNlcnZpY2U8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0
OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgRnVuY3Rpb24gU3BpcmFscy48YnI+Jmd0OyZndDsmZ3Q7Jmd0
OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZuYnNwOyBVbmxpa2UgU2VydmljZSBGdW5jdGlv
biBsb29wLCBzcGlyYWxzIGFyZSBub3QgY29uc2lkZXJlZDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyBhczxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBlcnJvcnMuIjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyBBbmQgdGhpcyBjb21wYW5pb24gcmVxdWlyZW1lbnQ6PGJyPiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICImbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgQS4mbmJzcDsgU2VydmljZSBGdW5jdGlvbnMgTUFZIGJlIGludm9rZWQgbXVsdGlwbGUg
dGltZXMgaW48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgdGhlIHNhbWUgU2VydmljZSBGdW5jdGlvbiBDaGFpbiAoZGVub3Rl
ZCBhcyBTRjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBTcGlyYWwpLCBidXQgdGhlIHNvbHV0aW9uIE1VU1QgcHJldmVudCBp
bmZpbml0ZTxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBmb3J3YXJkaW5nIGxvb3BzLiDCuzxicj4mZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSZWFkaW5nIHRoZSBjdXJyZW50IGRyYWZ0LXF1
aW5uLXNmYy1uc2gsIEkgZG9uJ3Qgc2VlIGhvdyB0aGlzIGlzIG1ldC48YnI+Jmd0OyZndDsmZ3Q7
Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2FuIHlvdSBwbGVhc2UgY2xhcmlmeSB3
aGV0aGVyIHRoaXMgaXMgc3VwcG9ydGVkIGFuZCBob3c/PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
PGJyPiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rIHlvdS48YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZn
dDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2hlZXJzLDxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
Ozxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBNZWQ8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+
Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+Jmd0OyZndDsm
Z3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X188YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2ZjIG1haWxpbmcgbGlzdDxicj4mZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyBzZmNAaWV0Zi5vcmc8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8YnI+Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8
YnI+Jmd0OyZndDsmZ3Q7PGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxp
c3Q8YnI+Jmd0OyZndDsgc2ZjQGlldGYub3JnPGJyPiZndDsmZ3Q7IGh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsmZ3Q7IHNmYyBt
YWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsgc2ZjQGlldGYub3JnPGJyPiZndDsmZ3Q7IGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPGJyPiZndDsmZ3Q7PGJyPiZndDsmZ3Q7
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsm
Z3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsgc2ZjQGlldGYub3JnPGJyPiZndDsmZ3Q7
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPGJyPiZndDsmZ3Q7PGJy
PiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
PGJyPiZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyZndDsgc2ZjQGlldGYub3JnPGJy
PiZndDsmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPGJyPiZn
dDs8YnI+Jmd0Ozxicj4gPC9ib2R5Pg==

----_com.android.email_159081965057974--





From nobody Thu Feb 26 10:32: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 73F5A1AC3AD for ; Thu, 26 Feb 2015 10:32:39 -0800 (PST)
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 W8Vsj4z9T07L for ; Thu, 26 Feb 2015 10:32:37 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E231AC3AB for ; Thu, 26 Feb 2015 10:32:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7239; q=dns/txt; s=iport; t=1424975557; x=1426185157; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=csrnwPOdZ/IwShJofKshruBvpj5UE/ffFpCoZGamnS0=; b=IzFYWKMYynr6uHU8HKvP4aHdiNNZ5PNPi85dV0KJS7DWNnRijj02Poja DOH/YES3CoM/i+1ljyCYjQbbFOUlwyxNTjPo5xW2SPwW08QExryrDhcRf Uuo5bGRTQwHf3eA1bpJCKPZjg4ZLRjIaCKMYsY/sQRy1WTqKZSx0gMgUC U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DjBwB5Zu9U/4kNJK1bgj9DUk4MBLJIjQw8gWkBCYVwAoEkTQEBAQEBAXyEEAEBBAEBARpRCxACAQg/BycLFBECBA4FiC8N1wEBAQEBAQEBAQEBAQEBAQEBAQEBAQEXixOEDBEBTAQGAYMXgRQFj2+DYIVlAYEaOYJljxAjggIcgVBvgQs5fwEBAQ
X-IronPort-AV: E=Sophos;i="5.09,654,1418083200";  d="scan'208,217";a="399403369"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP; 26 Feb 2015 18:32:32 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t1QIWVu9008816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Feb 2015 18:32:31 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.138]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 12:32:31 -0600
From: "Carlos Pignataro (cpignata)" 
To: "Jim Guichard (jguichar)" 
Thread-Topic: [sfc] WG call for adoption of draft-quinn-sfc-nsh
Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50DpjmA
Date: Thu, 26 Feb 2015 18:32:30 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.131.12.103]
Content-Type: multipart/alternative; boundary="_000_EA9D82BC83FF45CBA791882DA10DC4EBciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "sfc@ietf.org" 
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh
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, 26 Feb 2015 18:32:39 -0000

--_000_EA9D82BC83FF45CBA791882DA10DC4EBciscocom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I support WG adoption of this document.

Thanks,

=97 Carlos.

On Feb 26, 2015, at 7:47 AM, Jim Guichard (jguichar) > wrote:

Greetings WG:

The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft=
-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc=
-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined =
the NSH document so that the WG can focus on a single encapsulation documen=
t going forward. This new version of NSH includes an open items section bas=
ed on discussion between co-authors and members of the list. The WG will wo=
rk through this list (and any other issues that need to be added) over the =
next weeks. We appreciate and recognize the hard work of both the NSH and S=
CH authors in pushing the SFC encapsulation work forward.

With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n=
sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3=
/12/2015.

Please note that this is a call for adoption, and not a last call for conte=
nt of the document. Adopting a WG document simply means that the WG will fo=
cus its efforts on that particular draft going forward, and use that docume=
nt for resolving open issues and documenting the WG=92s decisions.

Please indicate whether you support adoption for not, and if not why. Issue=
s you have with the current document itself can also be raised, but they sh=
ould be raised in the context of what should be changed in the document goi=
ng forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that appl=
ies to this draft, in line with the IPR disclosure obligations for WG parti=
cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l=
isted as a document author please respond to this email (to the chairs) whe=
ther or not you are aware of any relevant IPR.

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


--_000_EA9D82BC83FF45CBA791882DA10DC4EBciscocom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <01602A734F914644B398E0DA3F37719A@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable






I support WG adoption of this document.


    

    

    Thanks,
    


    

    

    =97 Carlos.
    


    

    

    

    On Feb 26, 2015, at 7:47 AM, Jim Guichard (jguichar) <jguichar@cisco.com> w=
rote:
    

    

    

    

    

    Greetings WG:
    


    

    

    The document draft-quinn-sfc-nsh-07 (https://datatracker.iet=
f.org/doc/draft-quinn-sfc-nsh/) has recently
 been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.i=
etf.org/doc/draft-zhang-sfc-sch/) have joined the NSH document so that =
the WG can focus on a single encapsulation
 document going forward. This new version of NSH includes an =
open items
section based on discussion between co-authors and members of the list.=
 The WG will work through this list (and any other issues that need to be a=
dded) over the next weeks. We appreciate and recognize the hard work of bot=
h the NSH and SCH authors in pushing
 the SFC encapsulation work forward.
    


    

    

    With that said, the chairs are calling for WG adoption of dra=
ft-quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 =
weeks ending 3/12/2015.
    


    

    

    Please note that this is=
 a call for adoption, and not a last call for content of the document. Adop=
ting a WG document simply means that the WG will focus its efforts on that =
particular draft going forward, and use
 that document for resolving open issues and documenting the WG=92s decisio=
ns.
    


    

    

    Please indicate whether =
you support adoption for not, and if not why. Issues you have with the curr=
ent document itself can also be raised, but they should be raised in the co=
ntext of what should be changed in the
 document going forward, rather than a pre-condition for adoption. 
    


    

    

    Finally, now is also a g=
ood time to poll for knowledge of any IPR that applies to this draft, in li=
ne with the IPR disclosure obligations for WG participants (see RFCs 3979, =
4879, 3669 and 5378 for more details).
 If you are listed as a document author please respond to this email (to th=
e chairs) whether or not you are aware of any relevant IPR.
    

    


    

    

    Jim & Thomas
    

    

    

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

    

    

    

    

    

    



--_000_EA9D82BC83FF45CBA791882DA10DC4EBciscocom_--


From nobody Thu Feb 26 10:33:56 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 EB6321A92B2 for ; Thu, 26 Feb 2015 10:33:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tsqReubFVgB for ; Thu, 26 Feb 2015 10:33:51 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED8311AC3B0 for ; Thu, 26 Feb 2015 10:33:49 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTA48487; Thu, 26 Feb 2015 18:33:48 +0000 (GMT)
Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Feb 2015 18:33:47 +0000
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Thu, 26 Feb 2015 10:33:44 -0800
From: Linda Dunbar 
To: Ron Parker , Joel Halpern , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" 
Thread-Topic: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05
Thread-Index: AdBRG3N71HhtcFa0RsuzFw1dT6iegwAAMTdQAABKvqAAABrE4AABrb3gADKL8WA=
Date: Thu, 26 Feb 2015 18:33:43 +0000
Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645EE3CC3@dfweml701-chm>
References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> 
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.210]
Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645EE3CC3dfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05
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, 26 Feb 2015 18:33:56 -0000

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

I think Ron's suggested wording for SFC is much more straight forward than =
the current SFC definition on the sfc-architecture-05.

draft-ietf-sfc-architecture-05 has:
Service Function Chain (SFC): A service function chain defines an
ordered set of abstract service functions (SFs) and ordering
constraints that must be applied to packets and/or frames and/or
flows selected as a result of classification. An example of an
abstract service function is "a firewall". The implied order
may not be a linear progression as the architecture allows for
SFCs that copy to more than one branch, and also allows for
cases where there is flexibility in the order in which service
functions need to be applied. The term service chain is often
used as shorthand for service function chain.

Isn't the wording of  "an ordered set of abstract service functions (SFs) t=
hat must be applied to packets and/or frames and/or flows" already sufficie=
nt enough to describe the ordering constraints?

Why need the extra wording of "..and ordering constraints"?

"...selected as a result of classification" should be more like ".. selecte=
d based on a specific matching criteria".


I suggest using the following wording:

"A service function chain defines an ordered set of abstract service functi=
ons (SFs)
that must be applied to packets and/or frames and/or flows that meet the sp=
ecific matching criteria."


It is implementation specific to have a classification node inspecting pack=
ets and attaching different SFC-IDs based on the "Service Chain matching Cr=
iteria" in the header to make it easier for subsequent nodes.

Linda


From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Wednesday, February 25, 2015 12:02 PM
To: Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf=
t-ietf-sfc-architecture-05

I think the key concept here is that of a 3 level hierarchy of SFC, SFP, RS=
P.   I don't think that comes out clearly in the current description, espec=
ially when RSP references Service Function Chain rather than Service Functi=
on Path.   The way I think of it:


*        SFC - specify the sequence of service function types that need to =
be visited

*        SFP - specify the sequence of service function types that need to =
be visited, but also optionally specify instance selection constraining pol=
icies for some or all of the types

*        RSP - specify the exact sequence of service function instances tha=
t need to be visited (with the understanding that an instance may optionall=
y perform its own internal load balancing)

Thanks.

   Ron


From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern
Sent: Wednesday, February 25, 2015 12:11 PM
To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Service P=
ath (RSP) in draft-ietf-sfc-architecture-05

Sorry.  A packet is technically using a service function path.  It is doing=
 so if the information in the SFC defined header indicates that the packet =
is to forwarded along that service function path.  Thus, the assignment / u=
sage can be determined from examining the packet.  The RSP itself requires =
a rather omniscient observer perspective to determine, but does exist conce=
ptually.

Yours,
Joel

From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
Sent: Wednesday, February 25, 2015 12:08 PM
To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf=
t-ietf-sfc-architecture-05

Joel,

What does it mean by saying packets "using" a service chain?

How does packets  "use" a service chain? I am confused.

Linda

From: Joel Halpern [mailto:joel.halpern@ericsson.com]
Sent: Wednesday, February 25, 2015 10:59 AM
To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf=
t-ietf-sfc-architecture-05

I don't think adding another word to the term will help comprehension, and =
it will complicate usage.  So I would prefer not to do that.

As for the other change, packets don't belong to a service chain.  They may=
 be using a service chain.  They may be assigned by a classifier to a servi=
ce chain, but they don't "belong" to the chain as I understand the words.

Yours,
Joel

From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
Sent: Wednesday, February 25, 2015 11:52 AM
To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
Subject: wording Suggestion for the Rendered Service Path (RSP) in draft-ie=
tf-sfc-architecture-05

Joel and Carlos,

The current definition of RSP is:

Rendered Service Path (RSP): The Service Function Path is a
constrained specification of where packets using a certain
service chain must go. While it may be so constrained as to
identify the exact locations, it can also be less specific.
Packets themselves are of course transmitted from and to
specific places in the network, visiting a specific sequence of
SFFs and SFs. This sequence of actual visits by a packet to
specific SFFs and SFs in the network is known as the Rendered
Service Path (RSP). This definition is included here for use by
later documents, such as when solutions may need to discuss the
actual sequence of locations the packets visit.


Some suggestions:

-        I would think it is more accurate to call it "Rendered Service Fun=
ction Path (RSFP)".

-        Why do you say "packets using a certain service chain"? It is more=
 accurate to say "packets belonging to a certain service function chain".


Here is my suggested wording for RSP (or RSFP):


-        The sequence of actual SFFs and SFs in the network traversed by pa=
ckets belonging to a specific Service Function Chain is known as the Render=
ed Service Function Path (RSFP).

Cheers,

Linda Dunbar


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









    

    I think Ron’s su=
ggested wording for SFC is much more straight forward than the current SFC =
definition on the sfc-architecture-05.

    

     
    

    draft-ietf-sfc-architecture-05 has: 
    

    Service Function Chain (SFC=
): A service function chain defines an
    

    ordered set of abstract ser=
vice functions (SFs) and ordering
    

    constraints that must be ap=
plied to packets and/or frames and/or
    

    flows selected as a result =
of classification. An example of an
    

    abstract service function i=
s "a firewall". The implied order
    

    may not be a linear progres=
sion as the architecture allows for
    

    SFCs that copy to more than=
 one branch, and also allows for
    

    cases where there is flexib=
ility in the order in which service
    

    functions need to be applie=
d. The term service chain is often
    

    used as shorthand for servi=
ce function chain.
    

     
    

    Isn’t the wordin=
g of  “an ordered set of abstract service functions (SFs) that must be applied =
to packets and/or frames and/or flows&=
#8221;
 already sufficient enough to describe the ordering constraints? 
    

     
    

    Why need the extra wor=
ding of 
“..and ordering =
constraints”?

    

     
    

    “...selected as a result of cla=
ssification” should be more like=
 “.. selected based on a specific matching criteria”.

    

     
    

     
    

    I suggest using the fo=
llowing wording:
    

     
    

    “A service function c=
hain defines an ordered set of abstract service functions (SFs)

    

    that must be applied to pac=
kets and/or frames and/or flows that meet the specific matching criteria.&#=
8221;
    

     
    

     
    

    It is implementation s=
pecific to have a classification node inspecting packets and attaching diff=
erent SFC-IDs based on the “Service Chain matching Criteria” in=
 the header to make it easier for subsequent nodes.

    

     
    

    Linda
    

     
    

     
    

    

    

    From: Ron Park=
er [mailto:Ron_Parker@affirmednetworks.com]

    
Sent: Wednesday, February 25, 2015 12:02 PM
    
To: Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); sfc@iet=
f.org
    
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) =
in draft-ietf-sfc-architecture-05
    

    

    

     
    

    I think the key concep=
t here is that of a 3 level hierarchy of SFC, SFP, RSP.   I don&#=
8217;t think that comes out clearly in the current description, especially =
when RSP references Service Function Chain rather than
 Service Function Path.   The way I think of it:
    

     
    

    ·SFC – specify the sequence of se=
rvice function types that need to be visited
    

    ·SFP – specify the sequence of se=
rvice function types that need to be visited, but also optionally specify i=
nstance selection constraining policies for some or all of the types
    

    ·RSP – specify the exact sequence=
 of service function instances that need to be visited (with the understand=
ing that an instance may optionally perform its own internal load balancing=
)
    

     
    

    Thanks.
    

     
    

       Ron<=
/o:p>
    

     
    

     
    

    

    

    From: sfc [mailto:sfc-bounces@ietf.org]
On Behalf Of Joel Halpern
    
Sent: Wednesday, February 25, 2015 12:11 PM
    
To: Linda Dunbar; Carlos Pignataro (cpignata); 
sfc@ietf.org
    
Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Se=
rvice Path (RSP) in draft-ietf-sfc-architecture-05
    

    

    

     
    

    Sorry.  A packet =
is technically using a service function path.  It is doing so if the i=
nformation in the SFC defined header indicates that the packet is to forwar=
ded along that service function path.  Thus, the
 assignment / usage can be determined from examining the packet.  The =
RSP itself requires a rather omniscient observer perspective to determine, =
but does exist conceptually.
    

     
    

    Yours,
    

    Joel=

    

     
    

    

    

    From: Linda Du=
nbar [mailto:linda.dunbar@huawei=
.com]

    
Sent: Wednesday, February 25, 2015 12:08 PM
    
To: Joel Halpern; Carlos Pignataro (cpignata); 
sfc@ietf.org
    
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) =
in draft-ietf-sfc-architecture-05
    

    

    

     
    

    Joel, 
    

     
    

    What does it mean by s=
aying packets “using” a service chain?

    

     
    

    How does packets  =
;“use” a service chain? I am confused.

    

     
    

    Linda
    

     
    

    

    

    From: Joel Hal=
pern
[mailto:joel.halpern@=
ericsson.com]

    
Sent: Wednesday, February 25, 2015 10:59 AM
    
To: Linda Dunbar; Carlos Pignataro (cpignata); 
sfc@ietf.org
    
Subject: RE: wording Suggestion for the Rendered Service Path (RSP) =
in draft-ietf-sfc-architecture-05
    

    

    

     
    

    I don’t think ad=
ding another word to the term will help comprehension, and it will complica=
te usage.  So I would prefer not to do that.
    

     
    

    As for the other chang=
e, packets don’t belong to a service chain.  They may be using a=
 service chain.  They may be assigned by a classifier to a service cha=
in, but they don’t “belong” to the chain as I understand
 the words.
    

     
    

    Yours,
    

    Joel=

    

     
    

    

    

    From: Linda Du=
nbar [mailto:linda.dunbar@huawei=
.com]

    
Sent: Wednesday, February 25, 2015 11:52 AM
    
To: Joel Halpern; Carlos Pignataro (cpignata); 
sfc@ietf.org
    
Subject: wording Suggestion for the Rendered Service Path (RSP) in d=
raft-ietf-sfc-architecture-05
    

    

    

     
    

    Joel and Carlos, 
    

     
    

    The current definition of RSP is:
    

     
    

    Rendered Service Path (RSP)=
: The Service Function Path is a
    

    constrained specification o=
f where packets using a certain
    

    service chain must go. Whil=
e it may be so constrained as to
    

    identify the exact location=
s, it can also be less specific.
    

    Packets themselves are of c=
ourse transmitted from and to
    

    specific places in the netw=
ork, visiting a specific sequence of
    

    SFFs and SFs. This sequence=
 of actual visits by a packet to
    

    specific SFFs and SFs in th=
e network is known as the Rendered
    

    Service Path (RSP). This de=
finition is included here for use by
    

    later documents, such as wh=
en solutions may need to discuss the
    

    actual sequence of location=
s the packets visit.
    

     
    

     
    

    Some suggestions:
    

    -=
       
I would think it is more accurate to call it “Rendered Service=
 Function Path (RSFP)”.

    

    -=
       
Why do you say “packets using a certain service chain”? =
It is more accurate to say “packets belonging to a certain service fu=
nction chain”.

    

     
    

     
    

    Here is my suggested wording for RSP (or RSFP):=

    

     
    

    -=
       
The sequence of actual SFFs and SFs in the network traversed by pack=
ets belonging to a specific Service Function Chain is known as the Rendered=
 Service Function Path (RSFP).

    

     
    

    Cheers, 
    

     
    

    Linda Dunbar
    

     
    

    



--_000_4A95BA014132FF49AE685FAB4B9F17F645EE3CC3dfweml701chm_--


From nobody Thu Feb 26 10:37: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 477A01AC3B8 for ; Thu, 26 Feb 2015 10:37:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.309
X-Spam-Level: 
X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGa03SFhiugz for ; Thu, 26 Feb 2015 10:37:02 -0800 (PST)
Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8549C1AC3BE for ; Thu, 26 Feb 2015 10:37:01 -0800 (PST)
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 13:37:00 -0500
From: Dave Dolson 
To: Jmh.direct , "jmh@joelhalpern.com" , "repenno@cisco.com" , "ron_parker@affirmednetworks.com" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" 
Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
Thread-Index: AQHQUfDWdMfMQp0TQVyP+AHUYniSlJ0DQURg
Date: Thu, 26 Feb 2015 18:36:58 +0000
Message-ID: 
References: 
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_E8355113905631478EFF04F5AA706E9830B55B03wtlexchp2sandvi_"
MIME-Version: 1.0
Archived-At: 
Cc: "ben.wright@metaswitch.com" 
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
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, 26 Feb 2015 18:37:06 -0000

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

U3VyZSwgYnV0IGdvaW5nIGZyb20gdGhlIGdlbmVyaWMgdG8gdGhlIHNwZWNpZmljLCB0YWtlIG15
IGV4YW1wbGUgb2YgdGhlIGZpcmV3YWxsIHdpdGggZGlmZmVyZW50IHNldHMgb2YgcnVsZXMgZGVw
ZW5kaW5nIG9uIGxvY2F0aW9uIGluIHRoZSBjaGFpbi4NCknigJltIGhlYXJpbmcgdGhhdCBtZXRh
LWRhdGEgY2FuIGJlIHVzZWQgYnkgdGhlIGZpcmV3YWxsIHRvIHNlbGVjdCB3aGljaCBydWxlIHNl
dCB0byBhcHBseSwgbWVhbmluZyB0aGUgbWV0YS1kYXRhIGlzIGluc3BlY3RlZCB1cG9uIHBhY2tl
dCBhcnJpdmFsIGFuZCB1c2VkIHRvIHNlbGVjdCB0aGUgcnVsZSBzZXQuDQooSXMgdGhhdCB3aGF0
IGZvbGtzIG1lYW50IHRvIHNheT8pDQoNClNvIHdoaWNoIGVsZW1lbnRzIHNldCB0aGUgbWV0YS1k
YXRhIGZvciB0aGUgZmlyZXdhbGwgdG8gdXNlPw0KQW5kIHdoaWNoIHJ1bGVzIGRldGVybWluZSB0
aGUgbWV0YS1kYXRhIHZhbHVlcyB0byBiZSBhcHBsaWVkIGJ5IHRob3NlIGVsZW1lbnRzPw0KDQoN
Ci1EYXZlDQoNCg0KRnJvbTogSm1oLmRpcmVjdCBbbWFpbHRvOmptaC5kaXJlY3RAam9lbGhhbHBl
cm4uY29tXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE1IDE6MjAgUE0NClRvOiBE
YXZlIERvbHNvbjsgam1oQGpvZWxoYWxwZXJuLmNvbTsgcmVwZW5ub0BjaXNjby5jb207IHJvbl9w
YXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb207IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207
IHNmY0BpZXRmLm9yZw0KQ2M6IGJlbi53cmlnaHRAbWV0YXN3aXRjaC5jb20NClN1YmplY3Q6IFJF
OiBbc2ZjXSBkcmFmdC1xdWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHMNCkltcG9y
dGFuY2U6IExvdw0KDQpJbnN0cnVjdGlvbiBjb21lcyBmcm9tIHRoZSBzZXZpY2UgZnVuY3Rpb24g
ZGVzaWduLiAgU29tZSBoZWFkZXIgc3RydWN0dXJlcyBhdWdtZW50IHRoYXQgd2l0aCBjb250cm9s
IG1hcHBpbmcgaWJmb3JtYXRpb24gdG8gaW5kaWNhdGUgd2hpY2ggbWV0YWRhdGEgZmllbGQgaGFz
IHdoaWNoIHVzZS4NCg0KR29yIFRMViBiYXNlZCBtZXRhZGF0IHdlIHByb2JhYmx5IGVhbnQgYSBy
ZWdpc3RyeSB3aXRoIHZlcnkgZWFzeSBlbnRyeSBjcmVhdGlvbi4NCg0KWW91cnMsDQpKb2VsDQoN
Cg0KU2VudCBmcm9tIG15IFNhbXN1bmcgc21hcnRwaG9uZSBvbiBBVCZUDQoNCg0KDQotLS0tLS0t
LSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0OiBSRTogW3NmY10gZHJhZnQtcXVp
bm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzDQpGcm9tOiBEYXZlIERvbHNvbiA8ZGRv
bHNvbkBzYW5kdmluZS5jb208bWFpbHRvOmRkb2xzb25Ac2FuZHZpbmUuY29tPj4NClRvOiAiSm9l
bCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbTxtYWlsdG86am1oQGpvZWxoYWxwZXJu
LmNvbT4+LCJSZWluYWxkbyBQZW5ubyAocmVwZW5ubykiIDxyZXBlbm5vQGNpc2NvLmNvbTxtYWls
dG86cmVwZW5ub0BjaXNjby5jb20+PixSb24gUGFya2VyIDxSb25fUGFya2VyQGFmZmlybWVkbmV0
d29ya3MuY29tPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPj4sIm1vaGFt
ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j
b20+IiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRh
aXJAb3JhbmdlLmNvbT4+LCJzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4iIDxzZmNA
aWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4+DQpDQzogIkJlbiBXcmlnaHQgKEJlbi5Xcmln
aHRAbWV0YXN3aXRjaC5jb208bWFpbHRvOkJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb20+KSIgPEJl
bi5XcmlnaHRAbWV0YXN3aXRjaC5jb208bWFpbHRvOkJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb20+
Pg0KDQpXaGF0IGFyZSB0aGUgbWVjaGFuaWNzIG9mIHVzaW5nIG1ldGEtZGF0YT8NCldoaWNoIGVs
ZW1lbnQgc2V0cyBpdCwgYW5kIGhvdyBpcyBpdCBpbnN0cnVjdGVkIHRvIGRvIHNvPw0KDQoNCi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpq
bWhAam9lbGhhbHBlcm4uY29tXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE1IDEy
OjM2IFBNDQpUbzogRGF2ZSBEb2xzb247IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgUm9uIFBh
cmtlcjsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRh
aXJAb3JhbmdlLmNvbT47IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0KQ2M6IEJl
biBXcmlnaHQgKEJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb208bWFpbHRvOkJlbi5XcmlnaHRAbWV0
YXN3aXRjaC5jb20+KQ0KU3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1uc2g6IFN1
cHBvcnQgb2YgU0YgU3BpcmFscw0KDQpQZXJzb25hbGx5LCBJIHdvdWxkIHByZWZlciB0aGF0IHRo
ZSBmaXJld2FsbCB1c2UgbWV0YWRhdGEgcmF0aGVyIHRoYW4NCnBhdGgtaW5kZXguICBNeSByZWFz
b25pbmcgaXMgdGhhdCBpZiBmdW5jdGlvbnMgZ2V0IGFkZGVkIGJlZm9yZSBvciBhZnRlcg0KdGhl
IGZpcmV3YWxsLCBvcGVyYXRpb25zIHdvdWxkIHByZWZlciBub3QgdG8gaGF2ZSB0byBjaGFuZ2Ug
dGhlDQpjb25maWd1cmF0aW9uIG9mIHRoZSBmaXJld2FsbCBTRiBpdHNlbGYuDQoNCkhhdmluZyBz
YWlkIHRoYXQsIEkgZG9uJ3Qgc2VlIGFueSB3YXkgdG8gc3RvcCB5b3UgZnJvbSB1c2luZyB0aGUg
cGF0aCBpbmRleC4NCg0KWW91cnMsDQpKb2VsDQoNCk9uIDIvMjYvMTUgMTI6MzAgUE0sIERhdmUg
RG9sc29uIHdyb3RlOg0KPiBGb3IgdGhlIHNha2Ugb2YgYXJndW1lbnQsIHN1cHBvc2UgSSBoYXZl
IGEgZmlyZXdhbGwgU0YsIGFuZCBJIHdhbnQgdG8gdXNlDQo+IGl0IG1vcmUgdGhhbiBvbmNlIGlu
IGEgY2hhaW4uIChNYXliZSBJIHdhbnQgdG8gYm9vay1lbmQgdGhlIGNoYWluIHdpdGggaW5ncmVz
cw0KPiBhbmQgZWdyZXNzIHJ1bGVzLikNCj4NCj4gRG8geW91IGFncmVlIGl0IHdvdWxkIGJlIHN1
ZmZpY2llbnQgdG8gdXNlIHRoZSBQYXRoIEluZGV4IHRvIHNlbGVjdCB3aGljaCBvZg0KPiB0aGUg
aW5ncmVzcyBvciBlZ3Jlc3MgcnVsZSBzZXRzIHNob3VsZCBiZSB1c2VkPw0KPg0KPiBJJ20gcHJv
YmFibHkgbWlzc2luZyBzb21ldGhpbmc7IEkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgdGhlIGNvbnRl
eHQgaGVhZGVycw0KPiBkZWZpbmUgZnVuY3Rpb25hbGl0eS4gTWF5YmUgdGhlIGRldmljZSBjb3Vs
ZCBjb21tdW5pY2F0ZSB3aXRoIGl0c2VsZg0KPiAoZS5nLiwgdGhlIGluZ3Jlc3MgcG9ydGlvbiBz
ZW5kaW5nIGEgdGFnIHRvIHRoZSBlZ3Jlc3MgcG9ydGlvbikNCj4gYnkgc2VuZGluZyBzdGF0ZSBp
biB0aGUgcGFja2V0LiBJcyB0aGF0IHdoYXQgeW91IGFyZSBtZWFuIGJ5ICJjb250ZXh0dWFsIGlu
Zm8iID8NCj4NCj4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUmVp
bmFsZG8gUGVubm8gKHJlcGVubm8pIFttYWlsdG86cmVwZW5ub0BjaXNjby5jb21dDQo+IFNlbnQ6
IFRodXJzZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAxMjoxOCBQTQ0KPiBUbzogRGF2ZSBEb2xzb247
IFJvbiBQYXJrZXI7IEpvZWwgTS4gSGFscGVybjsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv
bTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT47IHNmY0BpZXRmLm9yZzxtYWls
dG86c2ZjQGlldGYub3JnPg0KPiBDYzogQmVuIFdyaWdodCAoQmVuLldyaWdodEBtZXRhc3dpdGNo
LmNvbTxtYWlsdG86QmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbT4pDQo+IFN1YmplY3Q6IFJlOiBb
c2ZjXSBkcmFmdC1xdWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHMNCj4NCj4gQWdy
ZWVkIG9uIGFsbCBwb2ludHMuIEkgdGhvdWdodCBJIHdhcyBtaXNzaW5nIHNvbWV0aGluZyBzbyBi
ZWZvcmUgd3JpdGluZw0KPiB0aGlzIGVtYWlsIEkgcmV0ZXN0ZWQgb3VyIGltcGxlbWVudGF0aW9u
IGFuZCBpdCB3b3JrZWQgb2ZmIHRoZSBiYXQuIFRoZQ0KPiBSU1AgY29uc3RydWN0ZWQgaGFzIHRo
ZSB0aGUgc2FtZSAoU0ZGLCBTRikgdHVwbGUgYnV0IGRpZmZlcmVudCBpbmRleGVzLg0KPg0KPiBU
aGUgc2FtZSBTRiBpcyB2aXNpdGVkIG11bHRpcGxlIHRpbWVzIHVudGlsIHRoZSBwYXRoIGVuZHMu
ICBJZiB0aGUgU0YNCj4gd2FudHMgY29udGV4dHVhbCBpbmZvIGFjcm9zcyB2aXNpdHMgdGhhbiBj
b250ZXh0IGhlYWRlcnMgYXJlIHRoZSB3YXkgdG8NCj4gZ28uDQo+DQo+DQo+IE9uIDIvMjYvMTUs
IDg6NTIgQU0sICJEYXZlIERvbHNvbiIgPGRkb2xzb25Ac2FuZHZpbmUuY29tPG1haWx0bzpkZG9s
c29uQHNhbmR2aW5lLmNvbT4+IHdyb3RlOg0KPg0KPj4gTWF5YmUgbmFpdmVseSwgSSB0aG91Z2h0
IHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyB3b3VsZCBiZSBwcm92aXNpb25lZCB3aXRoDQo+PiBhIHRh
YmxlOg0KPj4NCj4+IEUuZy4sIGZvciBlbGVtZW50IGZvbzoNCj4+IFBhdGggfCBQYXRoIEluZGV4
IHwgTmV4dCBIb3AgIHwgRnVuY3Rpb24NCj4+IDEyMyB8ICA0ICAgICAgICAgfCAgIFNGLWJhciAg
fCBmaXJzdCBiZWhhdmlvcg0KPj4gMTIzIHwgIDIgICAgICAgICB8IFNGLWZvb2JhciB8IHNlY29u
ZCBiZWhhdmlvcg0KPj4NCj4+DQo+PiBUaGUgRnVuY3Rpb24gaXMgY2xlYXJseSBpbXBsZW1lbnRh
dGlvbiBzcGVjaWZpYy4gTWF5YmUgaXQgcG9pbnRzIHRvIGENCj4+IGNvbmZpZ3VyYXRpb24gc2V0
IG9yIGEgcG9saWN5IHNldC4gSSB0aGluayBjb21wbGV0ZWx5IG91dCBvZiBzY29wZSBoZXJlLg0K
Pj4NCj4+IEkgc3VnZ2VzdCB0aGF0IHRoaXMgaXMgbm90IGEgcHJvYmxlbSBmb3IgdGhlIHdpcmUg
cHJvdG9jb2wsIHJhdGhlciBmb3INCj4+IHRoZSBjb25maWd1cmF0aW9uIG1vZGVsIChuZXRjb25m
IG9yIHdoYXRldmVyKS4NCj4+DQo+PiBJdCBiZWNvbWVzIHZlcnkgbXVjaCB2ZW5kb3Itc3BlY2lm
aWMgaWYgdGhlIGJlaGF2aW9ycyBhcmUgY29tcGxleA0KPj4gY29uZmlndXJhdGlvbnMgb2Ygc3Bl
Y2lhbGl6ZWQgZmVhdHVyZXMuDQo+Pg0KPj4gSWYgYSBwZXJzb24gd2VyZSBtYW51YWxseSBjb25m
aWd1cmluZyBjaGFpbnMsIEkgZG9uJ3QgdGhpbmsgdGhleSdkIGhhdmUgYQ0KPj4gY29uY2VwdHVh
bCBwcm9ibGVtLCBiZWNhdXNlIHRoZXknZCBoYXZlIGEgZGlhZ3JhbSB0aGV5IG5lZWQgdG8gaW1w
bGVtZW50Og0KPj4ge1NGLWZvbyAoZmlyc3QtYmVoYXZpb3IpLCBTRi1iYXIsIFNGLWZvbyAoc2Vj
b25kLWJlaGF2aW9yKSwgU0YtZm9vYmFyfQ0KPj4NCj4+IElmIHdlIHdhbnRlZCB0byBzdGFuZGFy
ZGl6ZSBpdCwgd2UgY291bGQgbWF5YmUgbWFrZSB0aGUgRnVuY3Rpb24gc2ltcGx5IGENCj4+IGxh
YmVsIHRoYXQgbWVhbnMgc29tZXRoaW5nIHRvIHRoZSBkZXZpY2UtLWFuIGluZGlyZWN0aW9uIHRv
IGENCj4+IGNvbmZpZ3VyYXRpb24gc2V0Lg0KPj4NCj4+IC1EYXZlDQo+Pg0KPj4NCj4+DQo+PiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5j
ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb24gUGFya2VyDQo+PiBTZW50OiBUaHVyc2RheSwg
RmVicnVhcnkgMjYsIDIwMTUgMTE6MzEgQU0NCj4+IFRvOiBEYXZlIERvbHNvbjsgSm9lbCBNLiBI
YWxwZXJuOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNh
ZGFpckBvcmFuZ2UuY29tPjsNCj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGlldGYub3JnPg0K
Pj4gQ2M6IEJlbiBXcmlnaHQgKEJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb208bWFpbHRvOkJlbi5X
cmlnaHRAbWV0YXN3aXRjaC5jb20+KQ0KPj4gU3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LXF1aW5u
LXNmYy1uc2g6IFN1cHBvcnQgb2YgU0YgU3BpcmFscw0KPj4NCj4+IEhpLCBEYXZlLg0KPj4NCj4+
IEkgYWdyZWUgdGhhdCBvbiB0aGUgd2lyZSwgdGhpcyBpcyB0aGUgd2F5IGl0IHdvdWxkIHdvcmsu
DQo+Pg0KPj4gQnV0LCB3aGVuIGNvbXBvc2luZyB0aGUgY2hhaW4sIGl0IHNlZW1zIGxpa2UgaW5m
b3JtYXRpb24gd291bGQgYmUgbGFja2luZw0KPj4gaWYgYSBjaGFpbiB3ZXJlIGV4cHJlc3NlZCBz
aW1wbHkgYXMge1NGLWZvbywgU0YtYmFyLCBTRi1mb28sIFNGLWZvb2Jhcn0uDQo+PiAgIEl0IGlz
IGNvbXBsZXRlbHkgaW1wbGljaXQgdGhhdCBzaW5jZSBTRi1mb28gYXBwZWFycyB0d2ljZSwgaXQg
cGVyaGFwcw0KPj4gc2hvdWxkIHBlcmZvcm0gc29tZSBkaWZmZXJlbnQgZHV0eSB3aGVuIGluZGV4
ID0gMCB2cyB3aGVuIGluZGV4ID0gMi4NCj4+DQo+PiBBdCBmaXJzdCwgSSB0aG91Z2h0IHRoYXQg
YW4gYWx0ZXJuYXRpdmUgd2F5IHRvIGhhbmRsZSB0aGlzIHdvdWxkIGJlIHRvDQo+PiB1c2UgbXVs
dGlwbGUgbG9naWNhbCBpZGVudGl0aWVzIGZvciBTRi1mb28uICBJbiB0aGlzIGNhc2UsIHRoZSBj
aGFpbg0KPj4gYWJvdmUgd291bGQgYmUgZXhwcmVzc2VkIGFzIHtTRi1mb28tZmlyc3QtYmVoYXZp
b3IsIFNGLWJhciwNCj4+IFNGLWZvby1zZWNvbmQtYmVoYXZpb3IsIFNGLWZvb2Jhcn0uICAgQnV0
LCB0aGUgcHJvYmxlbSBoZXJlIGlzIHNlbGVjdGluZw0KPj4gdGhlIFJTUCwgYXNzdW1pbmcgdGhh
dCBTRi1mb28gaGFzIG11bHRpcGxlIGluc3RhbmNlcy4gICBOb3RoaW5nIGluIHRoaXMNCj4+IHNl
Y29uZCBmbGF2b3Igb2YgY2hhaW4gc2F5cyB0aGF0IHRoZSBzYW1lIGluc3RhbmNlIG9mIFNGLWZv
by0qIG11c3QgYmUNCj4+IHNlbGVjdGVkIHRvIHNhdGlzZnkgU0YtZm9vLWZpcnN0LWJlaGF2aW9y
IGFuZCBTRi1mb28tc2Vjb25kLWJlaGF2aW9yDQo+PiAod2hpY2ggbWF5IG5vdCBiZSByZXF1aXJl
ZCwgYnV0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBmb3JjZSBhcyBzdWNoKS4NCj4+DQo+PiBJIGd1
ZXNzIHdoYXQgSSdtIHNheWluZyBpcyB0aGF0IHNwaXJhbGluZyBoYXMgYSBzdWJ0bGV0eSB0byBp
dCB0aGF0IGlzbid0DQo+PiB5ZXQgYWRlcXVhdGVseSBhZGRyZXNzZWQgYW5kIHRoYXQgSSBkb24n
dCBoYXZlIGEgc3BlY2lmaWMgcHJvcG9zYWwgdG8NCj4+IHNvbHZlIGl0LCBlaXRoZXIuDQo+Pg0K
Pj4gICAgUm9uDQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t
OiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmUgRG9s
c29uDQo+PiBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjYsIDIwMTUgMTE6MjEgQU0NCj4+IFRv
OiBKb2VsIE0uIEhhbHBlcm47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1v
aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRm
Lm9yZz4NCj4+IENjOiBCZW4gV3JpZ2h0IChCZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tPG1haWx0
bzpCZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tPikNCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBkcmFm
dC1xdWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHMNCj4+DQo+PiBJZiBJIG1heSB0
cnkgdG8gcHV0IGl0IHNpbXBseSwgSSd2ZSBhbHdheXMgdGhvdWdodCBvZiBpdCB0aGlzIHdheToN
Cj4+IC0tPiBFYWNoIG5vZGUgaW4gdGhlIGNoYWluIHNlbGVjdHMgdGhlIGNvbnRleHQgZm9yIHBy
b2Nlc3NpbmcgYW5kIHRoZQ0KPj4gbmV4dCBob3Agb24gdGhlIGJhc2lzIG9mIEJPVEggcGF0aCBJ
RCBhbmQgSW5kZXgsIHdoaWxlIGRlY3JlbWVudGluZyB0aGUNCj4+IGluZGV4IGZvciB0aGUgbmV4
dCBob3AuDQo+Pg0KPj4gVGhhdCBiZWhhdmlvciBzdXBwb3J0cyBzcGlyYWxpbmcuDQo+Pg0KPj4N
Cj4+DQo+PiAtRGF2ZQ0KPj4NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g
RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2Vs
IE0uIEhhbHBlcm4NCj4+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAxMDowMiBB
TQ0KPj4gVG86IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208bWFpbHRvOm1vaGFtZWQuYm91
Y2FkYWlyQG9yYW5nZS5jb20+OyBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+
IENjOiBCZW4gV3JpZ2h0IChCZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tPG1haWx0bzpCZW4uV3Jp
Z2h0QG1ldGFzd2l0Y2guY29tPikNCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBkcmFmdC1xdWlubi1z
ZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHMNCj4+DQo+PiBUaGVyZSBhcmUgdHdvIGRpZmZl
cmVudCBhc3BlY3RzIG9mIFNwaXJhbHMuDQo+Pg0KPj4gT25lIG9mIHRoZSB0d28gYXNwZWN0cyBp
cyBlbmFibGluZyBhIHBhY2tldCB0aGF0IHJlcGVhdGVkbHkgYXJyaXZlcyBhdA0KPj4gdGhlIHNh
bWUgU0ZGIHRvIGdldCB0aGUgY29ycmVjdCBzZXJ2aWNlcyBwcm92aWRlZCBlYWNoIHRpbWUgaXQg
YXJyaXZlcywNCj4+IGFuZCB0byBnbyB0byB0aGUgY29ycmVjdCBuZXh0IFNGRiBlYWNoIHRpbWUg
aXQgYXJyaXZlcy4gIFRoZSBTZXJ2aWNlIFBhdGgNCj4+IEluZGV4LCB1c2VkIGJ5IHRoZSBTRkYg
dG8gc2VsZWN0IHNlcnZpY2UgZnVuY3Rpb25zIGFuZCBuZXh0IFNGRiwgcHJvdmlkZXMNCj4+IHRo
YXQgY2FwYWJpbGl0eS4NCj4+DQo+PiBUaGUgb3RoZXIgYXNwZWN0IGlzIGhvdyB0aGUgU2Vydmlj
ZSBGdW5jdGlvbnMgdGhlbXNlbHZlcyBoYW5kbGUgc3BpcmFscy4NCj4+ICAgVG8gYSBsYXJnZSBk
ZWdyZWUsIHRoYXQgZGVwZW5kcyB1cG9uIHRoZSBpbmRpdmlkdWFsIHNlcnZpY2UgZnVuY3Rpb24u
DQo+PiAgIEkgbm9ybWFsbHkgYXNzdW1lIHRoYXQgaXQgd291bGQgdXNlIHBhY2tldCBjb250ZXh0
IChhcyBkZXNjcmliZWQgaW4gdGhlDQo+PiB0ZXh0IHlvdSBxdW90ZSkgdG8gZGV0ZXJtaW5lIHdo
YXQgdG8gZG8uDQo+Pg0KPj4gU2luY2UgSSB3b3VsZCBwcmVmZXIgdGhhdCBzZXJ2aWNlIGZ1bmN0
aW9ucyBhcmUgaW5kZXBlbmRlbnQgb2YgdGhlDQo+PiB1bmRlcmx5aW5nIHNlcnZpY2UgZnVuY3Rp
b24gY2hhaW5pbmcgaW5mcmFzdHJ1Y3R1cmUsIGFuZCBhcmUgbm90DQo+PiBzZW5zaXRpdmUgdG8g
aG93IG1hbnkgZnVuY3Rpb25zIGFyZSBiZWZvcmUgb3IgYWZ0ZXIgdGhlbSBpbiB0aGUgY2hhaW4s
IEkNCj4+IHdvdWxkIHBlcnNvbmFsbHkgcHJlZmVyIHRoYXQgdGhleSBub3QgdXNlIHRoZSBwYXRo
IGluZGV4IGZvciB0aGF0LiAgSQ0KPj4gd291bGQgcmVjb21tZW5kIHRoYXQgaWYgdGhlIHBhY2tl
dCBkb2VzIG5vdCBjYXJyeSBlbm91Z2ggY29udGV4dCB0aGF0IHRoZQ0KPj4gc2VydmljZSBmdW5j
dGlvbiBjb3VsZCBhbmQgc2hvdWxkIHVzZSBtZXRhZGF0YSB0byBjYXJyeSBpdHMgbmVlZGVkIHN0
YXRlDQo+PiBpbmZvcm1hdGlvbi4gIEJ1dCBuZWl0aGVyIEkgcGVyc29uYWxseSBub3IgdGhlIFNG
QyBXb3JraW5nIEdyb3VwIGdldCB0bw0KPj4gdGVsbCBmb2xrcyBob3cgdG8gYnVpbGQgdGhlaXIg
c2VydmljZSBmdW5jdGlvbnMuICBTbyB0aGV5IG1heSBjb21lIHVwDQo+PiB3aXRoIG90aGVyIG1l
dGhvZHMgZm9yIGFkZHJlc3NpbmcgdGhlaXIgbmVlZHMuICBXaGljaCBpcyBhbHNvIGZpbmUuDQo+
Pg0KPj4gVGh1cywgSSB3b3VsZCBub3QgZXhwZWN0IHRoaXMgZG9jdW1lbnQgdG8gZGlzY3VzcyBo
b3cgc2VydmljZSBmdW5jdGlvbnMNCj4+IHRoZW1zZWx2ZXMgaGFuZGxlIHJldmlzaXRpbmcuICBC
dXQgbWV0YWRhdGEgY2xlYXJseSBhbGxvd3MgZm9yIGEgcmFuZ2Ugb2YNCj4+IGJlaGF2aW9ycyB0
aGF0IHdpbGwgd29yay4gIEFuZCB0aGUgcGF0aCBpbmRleCBoYW5kbGVzIHRoZSBTRkYgbmVlZHMN
Cj4+IHJlbGF0aXZlIHRvIHNwaXJhbHMsIHdoaWNoIGlzIHdoYXQgd2UgbmVlZCB0byBoYW5kbGUu
DQo+Pg0KPj4gWW91cnMsDQo+PiBKb2VsDQo+Pg0KPj4gT24gMi8yNi8xNSA5OjUyIEFNLCBtb2hh
bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu
Y29tPiB3cm90ZToNCj4+PiBSZS0sDQo+Pj4NCj4+PiBTcGlyYWwgaXMgbm90IG1lbnRpb25lZCBp
biB0aGUgZHJhZnQsIGJ1dCBTRiBsb29wIGlzLg0KPj4+DQo+Pj4gSSdtIGFza2luZyB0aGUgcXVl
c3Rpb24gYmVjYXVzZSBJIGRvbid0IGdldCBmcm9tIHRoZSBkcmFmdCBob3cgc3BpcmFscw0KPj4+
IGNvdWxkIHdvcmsgKHRoYXQgaXMgYSBTRiBpbnZva2VkIHNldmVyYWwgdGltZSBpbiB0aGUgY29u
dGV4dCBvZiB0aGUgc2FtZQ0KPj4+IFNGQykuDQo+Pj4NCj4+PiBCZWZvcmUgcHJvcG9zaW5nIHRl
eHQsIEkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIGZpcnN0IGhvdyBpdCB3b3Jrcy4NCj4+PiBJ
ZiB5b3UgY2FuIHByb3ZpZGUgYW4gZXhhbXBsZSwgdGhpcyB3aWxsIGJlIGV2ZW4gZ3JlYXQuDQo+
Pj4NCj4+PiBUaGFuayB5b3UuDQo+Pj4NCj4+PiBDaGVlcnMsDQo+Pj4gTWVkDQo+Pj4NCj4+Pj4g
LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+Pj4+IERlIDogSm9lbCBNLiBIYWxwZXJuIFtt
YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0gRW52b3nDqSA6IGpldWRpIDI2DQo+Pj4+IGbDqXZy
aWVyIDIwMTUgMTU6NDEgw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTVQvT0xOOyBzZmNAaWV0Zi5v
cmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4gQ2MgOg0KPj4+PiBCZW4gV3JpZ2h0IChCZW4uV3JpZ2h0
QG1ldGFzd2l0Y2guY29tPG1haWx0bzpCZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tPikgT2JqZXQg
OiBSZTogW3NmY10NCj4+Pj4gZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGly
YWxzZ3Q7Pj4+DQo+Pj4+IFRoZSBTRiBTcGlyYWxzIHJlcXVpcmVtZW50IGlzIG9uZSBvZiB0aGUg
a2V5IGRyaXZlcnMgZm9yIHRoZSBpbmRleC4NCj4+Pj4gVGhlIGluZGV4IGFsbG93cyBvbmUgdG8g
dGVsbCB3aGVyZSBvbmUgaXMgaW4gdGhlIHNwaXJhbCwgYW5kIGFsc28gdG8NCj4+Pj4gYnJlYWsg
YSBsb29wIGlmIG9uZSBoYXMgYSBsb29wIGluc3RlYWQgb2YgYSBzcGlyYWwuDQo+Pj4+DQo+Pj4+
IElzIHRoZXJlIHRleHQgdGhhdCB3ZSBjb3VsZCBhZGQgdGhhdCB3b3VsZCBoZWxwIG1ha2UgdGhp
cyBjbGVhciwNCj4+Pj4gc2luY2UgeW91ciBlYXJsaWVyIHF1ZXN0aW9uIGFib3V0IHRoZSBwYXRo
IGluZGV4IHN1Z2dlc3RzIHRoYXQgaXQgaXMNCj4+Pj4gbm90IGFzIGNsZWFyIGFzIGl0IHNob3Vs
ZCBiZT8NCj4+Pj4NCj4+Pj4gWW91cnMsDQo+Pj4+IEpvZWwNCj4+Pj4NCj4+Pj4gT24gMi8yNi8x
NSA4OjQyIEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPG1haWx0bzptb2hhbWVkLmJv
dWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCj4+Pj4+IEhpIFBhdWwsIGFsbCwNCj4+Pj4+DQo+
Pj4+PiBUaGVyZSB3ZXJlIGEgZGlzY3Vzc2lvbiBpbiB0aGUgbWFpbGluZyBsaXN0DQo+Pj4+PiAo
aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NmYy9jdXJyZW50L21zZzAxNzAx
Lmh0bWwpDQo+Pj4+PiB0aGF0IGxlZCB0byBkZWZpbmluZyB3aGF0IGlzIG1lYW50IGJ5IFNGIFNw
aXJhbHM6IChiZWxvdyBpcyBwcm92aWRlZA0KPj4+Pj4gYW4gZXhjZXJwdCBmcm9tDQo+Pj4+PiBo
dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50
cy0wNiB3aGVyZQ0KPj4+Pj4gdGhlIGNvbmNsdXNpb25zIG9mIHRoYXQgZGlzY3Vzc2lvbiB3ZXJl
IHJlY29yZGVkKQ0KPj4+Pj4NCj4+Pj4+ICIgICBvICBTZXJ2aWNlIEZ1bmN0aW9uIFNwaXJhbDog
ZGVub3RlcyBhIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gaW4NCj4+Pj4gd2hpY2gNCj4+Pj4+DQo+
Pj4+PiAgICAgICAgICBkYXRhIGlzIGhhbmRsZWQgYnkgYSBTZXJ2aWNlIEZ1bmN0aW9uLCBmb3J3
YXJkZWQgb253YXJkcywNCj4+Pj4+IGFuZA0KPj4+Pj4NCj4+Pj4+ICAgICAgICAgIGFycml2ZXMg
b25jZSBhZ2FpbiBhdCB0aGF0IFNlcnZpY2UgRnVuY3Rpb24uDQo+Pj4+Pg0KPj4+Pj4gICAgICAg
ICAgKiAgTm90ZSB0aGF0IHNvbWUgU2VydmljZSBGdW5jdGlvbnMgc3VwcG9ydCBidWlsdC1pbg0K
Pj4+Pj4gZnVuY3Rpb25zIHRvDQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAgICAgYWNjb21tb2RhdGUg
c3BpcmFsczsgdGhlc2Ugc2VydmljZS1zcGVjaWZpYyBmdW5jdGlvbnMgbWF5DQo+Pj4+Pg0KPj4+
Pj4gICAgICAgICAgICAgcmVxdWlyZSB0aGF0IHRoZSBkYXRhIHJlY2VpdmVkIGluIGEgc3BpcmFs
IHNob3VsZCBkaWZmZXINCj4+Pj4+IGluIGENCj4+Pj4+DQo+Pj4+PiAgICAgICAgICAgICB3YXkg
dGhhdCB3aWxsIHJlc3VsdCBpbiBhIGRpZmZlcmVudCBwcm9jZXNzaW5nIGRlY2lzaW9uDQo+Pj4+
PiB0aGFuDQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAgICAgdGhlIG9yaWdpbmFsIGRhdGEuICBUaGlz
IGRvY3VtZW50IGRvZXMgbm90IG1ha2Ugc3VjaA0KPj4+Pj4NCj4+Pj4+ICAgICAgICAgICAgIGFz
c3VtcHRpb24uDQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAgKiAgQSBTZXJ2aWNlIEZ1bmN0aW9uIENo
YWluIG1heSBpbnZvbHZlIG9uZSBvciBtb3JlIFNlcnZpY2UNCj4+Pj4+DQo+Pj4+PiAgICAgICAg
ICAgICBGdW5jdGlvbiBTcGlyYWxzLg0KPj4+Pj4NCj4+Pj4+ICAgICAgICAgICogIFVubGlrZSBT
ZXJ2aWNlIEZ1bmN0aW9uIGxvb3AsIHNwaXJhbHMgYXJlIG5vdCBjb25zaWRlcmVkDQo+Pj4+PiBh
cw0KPj4+Pj4NCj4+Pj4+ICAgICAgICAgICAgIGVycm9ycy4iDQo+Pj4+Pg0KPj4+Pj4gQW5kIHRo
aXMgY29tcGFuaW9uIHJlcXVpcmVtZW50Og0KPj4+Pj4NCj4+Pj4+ICIgICAgICAgICAgICAgICBB
LiAgU2VydmljZSBGdW5jdGlvbnMgTUFZIGJlIGludm9rZWQgbXVsdGlwbGUgdGltZXMgaW4NCj4+
Pj4+DQo+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAgdGhlIHNhbWUgU2VydmljZSBGdW5jdGlv
biBDaGFpbiAoZGVub3RlZCBhcyBTRg0KPj4+Pj4NCj4+Pj4+ICAgICAgICAgICAgICAgICAgICAg
ICBTcGlyYWwpLCBidXQgdGhlIHNvbHV0aW9uIE1VU1QgcHJldmVudCBpbmZpbml0ZQ0KPj4+Pj4N
Cj4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICBmb3J3YXJkaW5nIGxvb3BzLiDCuw0KPj4+Pj4N
Cj4+Pj4+IFJlYWRpbmcgdGhlIGN1cnJlbnQgZHJhZnQtcXVpbm4tc2ZjLW5zaCwgSSBkb24ndCBz
ZWUgaG93IHRoaXMgaXMgbWV0Lg0KPj4+Pj4NCj4+Pj4+IENhbiB5b3UgcGxlYXNlIGNsYXJpZnkg
d2hldGhlciB0aGlzIGlzIHN1cHBvcnRlZCBhbmQgaG93Pw0KPj4+Pj4NCj4+Pj4+IFRoYW5rIHlv
dS4NCj4+Pj4+DQo+Pj4+PiBDaGVlcnMsDQo+Pj4+Pg0KPj4+Pj4gTWVkDQo+Pj4+Pg0KPj4+Pj4N
Cj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4gc2ZjQGlldGYub3JnPG1haWx0bzpz
ZmNAaWV0Zi5vcmc+DQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3NmYw0KPj4+Pj4NCj4+Pg0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQo+PiBzZmMgbWFpbGluZyBsaXN0DQo+PiBzZmNAaWV0Zi5vcmc8bWFp
bHRvOnNmY0BpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vc2ZjDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+IHNmY0BpZXRmLm9yZzxtYWlsdG86c2ZjQGll
dGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+
DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g
c2ZjIG1haWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYub3JnPG1haWx0bzpzZmNAaWV0Zi5vcmc+DQo+
PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCj4+IF9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBzZmMgbWFpbGlu
ZyBsaXN0DQo+PiBzZmNAaWV0Zi5vcmc8bWFpbHRvOnNmY0BpZXRmLm9yZz4NCj4+IGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+DQo+DQo=

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2
IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs
aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t
Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv
bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy
aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv
QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp
bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28t
c3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwi
c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u
YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj
MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K
CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu
MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x
DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4
bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94
bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2
OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw
ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs
aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG
NDk3RCI+U3VyZSwgYnV0IGdvaW5nIGZyb20gdGhlIGdlbmVyaWMgdG8gdGhlIHNwZWNpZmljLCB0
YWtlIG15IGV4YW1wbGUgb2YgdGhlIGZpcmV3YWxsIHdpdGggZGlmZmVyZW50IHNldHMgb2YgcnVs
ZXMgZGVwZW5kaW5nIG9uIGxvY2F0aW9uIGluIHRoZSBjaGFpbi48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+SeKAmW0gaGVhcmluZyB0aGF0IG1ldGEtZGF0YSBjYW4gYmUgdXNlZCBieSB0
aGUgZmlyZXdhbGwgdG8gc2VsZWN0IHdoaWNoIHJ1bGUgc2V0IHRvIGFwcGx5LCBtZWFuaW5nIHRo
ZSBtZXRhLWRhdGEgaXMgaW5zcGVjdGVkIHVwb24gcGFja2V0IGFycml2YWwgYW5kIHVzZWQgdG8N
CiBzZWxlY3QgdGhlIHJ1bGUgc2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4oSXMg
dGhhdCB3aGF0IGZvbGtzIG1lYW50IHRvIHNheT8pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyB3aGljaCBlbGVtZW50
cyBzZXQgdGhlIG1ldGEtZGF0YSBmb3IgdGhlIGZpcmV3YWxsIHRvIHVzZT88bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+QW5kIHdoaWNoIHJ1bGVzIGRldGVybWluZSB0aGUgbWV0YS1kYXRh
IHZhbHVlcyB0byBiZSBhcHBsaWVkIGJ5IHRob3NlIGVsZW1lbnRzPzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi1EYXZlPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy
LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z
cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU
YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEptaC5kaXJlY3QgW21haWx0bzpq
bWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg
RmVicnVhcnkgMjYsIDIwMTUgMToyMCBQTTxicj4NCjxiPlRvOjwvYj4gRGF2ZSBEb2xzb247IGpt
aEBqb2VsaGFscGVybi5jb207IHJlcGVubm9AY2lzY28uY29tOyByb25fcGFya2VyQGFmZmlybWVk
bmV0d29ya3MuY29tOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmc8
YnI+DQo8Yj5DYzo8L2I+IGJlbi53cmlnaHRAbWV0YXN3aXRjaC5jb208YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gUkU6IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1uc2g6IFN1cHBvcnQgb2YgU0YgU3BpcmFs
czxicj4NCjxiPkltcG9ydGFuY2U6PC9iPiBMb3c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5JbnN0cnVjdGlvbiBjb21lcyBmcm9tIHRoZSBzZXZpY2UgZnVu
Y3Rpb24gZGVzaWduLiAmbmJzcDtTb21lIGhlYWRlciBzdHJ1Y3R1cmVzIGF1Z21lbnQgdGhhdCB3
aXRoIGNvbnRyb2wgbWFwcGluZyBpYmZvcm1hdGlvbiB0byBpbmRpY2F0ZSB3aGljaCBtZXRhZGF0
YSBmaWVsZCBoYXMgd2hpY2ggdXNlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+R29yIFRMViBiYXNlZCBtZXRhZGF0IHdlIHByb2JhYmx5IGVhbnQgYSByZWdp
c3RyeSB3aXRoIHZlcnkgZWFzeSBlbnRyeSBjcmVhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91cnMsPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2VsPGJyPg0KPGJyPg0KPGJyPg0K
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPlNlbnQgZnJvbSBteSBTYW1zdW5nIHNtYXJ0
cGhvbmUgb24gQVQmYW1wO1Q8L3NwYW4+IDxvOnA+DQo8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0K
PGJyPg0KLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTxicj4NClN1YmplY3Q6IFJF
OiBbc2ZjXSBkcmFmdC1xdWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHMgPGJyPg0K
RnJvbTogRGF2ZSBEb2xzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNv
bSI+ZGRvbHNvbkBzYW5kdmluZS5jb208L2E+Jmd0Ow0KPGJyPg0KVG86ICZxdW90O0pvZWwgTS4g
SGFscGVybiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPmpt
aEBqb2VsaGFscGVybi5jb208L2E+Jmd0OywmcXVvdDtSZWluYWxkbyBQZW5ubyAocmVwZW5ubykm
cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyZXBlbm5vQGNpc2NvLmNvbSI+cmVwZW5ub0BjaXNj
by5jb208L2E+Jmd0OyxSb24gUGFya2VyICZsdDs8YSBocmVmPSJtYWlsdG86Um9uX1BhcmtlckBh
ZmZpcm1lZG5ldHdvcmtzLmNvbSI+Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTwvYT4m
Z3Q7LCZxdW90OzxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj5t
b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWls
dG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl
LmNvbTwvYT4mZ3Q7LCZxdW90OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRm
Lm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRm
Lm9yZzwvYT4mZ3Q7DQo8YnI+DQpDQzogJnF1b3Q7QmVuIFdyaWdodCAoPGEgaHJlZj0ibWFpbHRv
OkJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb20iPkJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb208L2E+
KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb20iPkJl
bi5XcmlnaHRAbWV0YXN3aXRjaC5jb208L2E+Jmd0Ow0KPGJyPg0KPGJyPg0KPG86cD48L286cD48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWst
YWxsIj5XaGF0IGFyZSB0aGUgbWVjaGFuaWNzIG9mIHVzaW5nIG1ldGEtZGF0YT88YnI+DQpXaGlj
aCBlbGVtZW50IHNldHMgaXQsIGFuZCBob3cgaXMgaXQgaW5zdHJ1Y3RlZCB0byBkbyBzbz88YnI+
DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IEpvZWwg
TS4gSGFscGVybiBbPGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPm1haWx0bzpq
bWhAam9lbGhhbHBlcm4uY29tPC9hPl0NCjxicj4NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAy
NiwgMjAxNSAxMjozNiBQTTxicj4NClRvOiBEYXZlIERvbHNvbjsgUmVpbmFsZG8gUGVubm8gKHJl
cGVubm8pOyBSb24gUGFya2VyOyA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jh
bmdlLmNvbSI+DQptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsgPGEgaHJlZj0ibWFp
bHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCkNjOiBCZW4gV3JpZ2h0ICg8
YSBocmVmPSJtYWlsdG86QmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbSI+QmVuLldyaWdodEBtZXRh
c3dpdGNoLmNvbTwvYT4pPGJyPg0KU3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1u
c2g6IFN1cHBvcnQgb2YgU0YgU3BpcmFsczxicj4NCjxicj4NClBlcnNvbmFsbHksIEkgd291bGQg
cHJlZmVyIHRoYXQgdGhlIGZpcmV3YWxsIHVzZSBtZXRhZGF0YSByYXRoZXIgdGhhbiA8YnI+DQpw
YXRoLWluZGV4LiZuYnNwOyBNeSByZWFzb25pbmcgaXMgdGhhdCBpZiBmdW5jdGlvbnMgZ2V0IGFk
ZGVkIGJlZm9yZSBvciBhZnRlciA8YnI+DQp0aGUgZmlyZXdhbGwsIG9wZXJhdGlvbnMgd291bGQg
cHJlZmVyIG5vdCB0byBoYXZlIHRvIGNoYW5nZSB0aGUgPGJyPg0KY29uZmlndXJhdGlvbiBvZiB0
aGUgZmlyZXdhbGwgU0YgaXRzZWxmLjxicj4NCjxicj4NCkhhdmluZyBzYWlkIHRoYXQsIEkgZG9u
J3Qgc2VlIGFueSB3YXkgdG8gc3RvcCB5b3UgZnJvbSB1c2luZyB0aGUgcGF0aCBpbmRleC48YnI+
DQo8YnI+DQpZb3Vycyw8YnI+DQpKb2VsPGJyPg0KPGJyPg0KT24gMi8yNi8xNSAxMjozMCBQTSwg
RGF2ZSBEb2xzb24gd3JvdGU6PGJyPg0KJmd0OyBGb3IgdGhlIHNha2Ugb2YgYXJndW1lbnQsIHN1
cHBvc2UgSSBoYXZlIGEgZmlyZXdhbGwgU0YsIGFuZCBJIHdhbnQgdG8gdXNlPGJyPg0KJmd0OyBp
dCBtb3JlIHRoYW4gb25jZSBpbiBhIGNoYWluLiAoTWF5YmUgSSB3YW50IHRvIGJvb2stZW5kIHRo
ZSBjaGFpbiB3aXRoIGluZ3Jlc3M8YnI+DQomZ3Q7IGFuZCBlZ3Jlc3MgcnVsZXMuKTxicj4NCiZn
dDs8YnI+DQomZ3Q7IERvIHlvdSBhZ3JlZSBpdCB3b3VsZCBiZSBzdWZmaWNpZW50IHRvIHVzZSB0
aGUgUGF0aCBJbmRleCB0byBzZWxlY3Qgd2hpY2ggb2Y8YnI+DQomZ3Q7IHRoZSBpbmdyZXNzIG9y
IGVncmVzcyBydWxlIHNldHMgc2hvdWxkIGJlIHVzZWQ/PGJyPg0KJmd0Ozxicj4NCiZndDsgSSdt
IHByb2JhYmx5IG1pc3Npbmcgc29tZXRoaW5nOyBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRoZSBj
b250ZXh0IGhlYWRlcnM8YnI+DQomZ3Q7IGRlZmluZSBmdW5jdGlvbmFsaXR5LiBNYXliZSB0aGUg
ZGV2aWNlIGNvdWxkIGNvbW11bmljYXRlIHdpdGggaXRzZWxmPGJyPg0KJmd0OyAoZS5nLiwgdGhl
IGluZ3Jlc3MgcG9ydGlvbiBzZW5kaW5nIGEgdGFnIHRvIHRoZSBlZ3Jlc3MgcG9ydGlvbik8YnI+
DQomZ3Q7IGJ5IHNlbmRpbmcgc3RhdGUgaW4gdGhlIHBhY2tldC4gSXMgdGhhdCB3aGF0IHlvdSBh
cmUgbWVhbiBieSAmcXVvdDtjb250ZXh0dWFsIGluZm8mcXVvdDsgPzxicj4NCiZndDs8YnI+DQom
Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQom
Z3Q7IEZyb206IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKSBbPGEgaHJlZj0ibWFpbHRvOnJlcGVu
bm9AY2lzY28uY29tIj5tYWlsdG86cmVwZW5ub0BjaXNjby5jb208L2E+XTxicj4NCiZndDsgU2Vu
dDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE1IDEyOjE4IFBNPGJyPg0KJmd0OyBUbzogRGF2
ZSBEb2xzb247IFJvbiBQYXJrZXI7IEpvZWwgTS4gSGFscGVybjsgPGEgaHJlZj0ibWFpbHRvOm1v
aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPg0KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv
bTwvYT47IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+
DQomZ3Q7IENjOiBCZW4gV3JpZ2h0ICg8YSBocmVmPSJtYWlsdG86QmVuLldyaWdodEBtZXRhc3dp
dGNoLmNvbSI+QmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbTwvYT4pPGJyPg0KJmd0OyBTdWJqZWN0
OiBSZTogW3NmY10gZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzPGJy
Pg0KJmd0Ozxicj4NCiZndDsgQWdyZWVkIG9uIGFsbCBwb2ludHMuIEkgdGhvdWdodCBJIHdhcyBt
aXNzaW5nIHNvbWV0aGluZyBzbyBiZWZvcmUgd3JpdGluZzxicj4NCiZndDsgdGhpcyBlbWFpbCBJ
IHJldGVzdGVkIG91ciBpbXBsZW1lbnRhdGlvbiBhbmQgaXQgd29ya2VkIG9mZiB0aGUgYmF0LiBU
aGU8YnI+DQomZ3Q7IFJTUCBjb25zdHJ1Y3RlZCBoYXMgdGhlIHRoZSBzYW1lIChTRkYsIFNGKSB0
dXBsZSBidXQgZGlmZmVyZW50IGluZGV4ZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIHNhbWUg
U0YgaXMgdmlzaXRlZCBtdWx0aXBsZSB0aW1lcyB1bnRpbCB0aGUgcGF0aCBlbmRzLiZuYnNwOyBJ
ZiB0aGUgU0Y8YnI+DQomZ3Q7IHdhbnRzIGNvbnRleHR1YWwgaW5mbyBhY3Jvc3MgdmlzaXRzIHRo
YW4gY29udGV4dCBoZWFkZXJzIGFyZSB0aGUgd2F5IHRvPGJyPg0KJmd0OyBnby48YnI+DQomZ3Q7
PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gMi8yNi8xNSwgODo1MiBBTSwgJnF1b3Q7RGF2ZSBEb2xz
b24mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkZG9sc29uQHNhbmR2aW5lLmNvbSI+ZGRvbHNv
bkBzYW5kdmluZS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDsgTWF5
YmUgbmFpdmVseSwgSSB0aG91Z2h0IHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyB3b3VsZCBiZSBwcm92
aXNpb25lZCB3aXRoPGJyPg0KJmd0OyZndDsgYSB0YWJsZTo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7IEUuZy4sIGZvciBlbGVtZW50IGZvbzo8YnI+DQomZ3Q7Jmd0OyBQYXRoIHwgUGF0aCBJ
bmRleCB8IE5leHQgSG9wJm5ic3A7IHwgRnVuY3Rpb248YnI+DQomZ3Q7Jmd0OyAxMjMgfCZuYnNw
OyA0Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJz
cDsmbmJzcDsgU0YtYmFyJm5ic3A7IHwgZmlyc3QgYmVoYXZpb3I8YnI+DQomZ3Q7Jmd0OyAxMjMg
fCZuYnNwOyAyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHwgU0YtZm9vYmFyIHwgc2Vjb25kIGJlaGF2aW9yPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0
Ozxicj4NCiZndDsmZ3Q7IFRoZSBGdW5jdGlvbiBpcyBjbGVhcmx5IGltcGxlbWVudGF0aW9uIHNw
ZWNpZmljLiBNYXliZSBpdCBwb2ludHMgdG8gYTxicj4NCiZndDsmZ3Q7IGNvbmZpZ3VyYXRpb24g
c2V0IG9yIGEgcG9saWN5IHNldC4gSSB0aGluayBjb21wbGV0ZWx5IG91dCBvZiBzY29wZSBoZXJl
Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSBzdWdnZXN0IHRoYXQgdGhpcyBpcyBub3Qg
YSBwcm9ibGVtIGZvciB0aGUgd2lyZSBwcm90b2NvbCwgcmF0aGVyIGZvcjxicj4NCiZndDsmZ3Q7
IHRoZSBjb25maWd1cmF0aW9uIG1vZGVsIChuZXRjb25mIG9yIHdoYXRldmVyKS48YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7IEl0IGJlY29tZXMgdmVyeSBtdWNoIHZlbmRvci1zcGVjaWZpYyBp
ZiB0aGUgYmVoYXZpb3JzIGFyZSBjb21wbGV4PGJyPg0KJmd0OyZndDsgY29uZmlndXJhdGlvbnMg
b2Ygc3BlY2lhbGl6ZWQgZmVhdHVyZXMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJZiBh
IHBlcnNvbiB3ZXJlIG1hbnVhbGx5IGNvbmZpZ3VyaW5nIGNoYWlucywgSSBkb24ndCB0aGluayB0
aGV5J2QgaGF2ZSBhPGJyPg0KJmd0OyZndDsgY29uY2VwdHVhbCBwcm9ibGVtLCBiZWNhdXNlIHRo
ZXknZCBoYXZlIGEgZGlhZ3JhbSB0aGV5IG5lZWQgdG8gaW1wbGVtZW50Ojxicj4NCiZndDsmZ3Q7
IHtTRi1mb28gKGZpcnN0LWJlaGF2aW9yKSwgU0YtYmFyLCBTRi1mb28gKHNlY29uZC1iZWhhdmlv
ciksIFNGLWZvb2Jhcn08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IElmIHdlIHdhbnRlZCB0
byBzdGFuZGFyZGl6ZSBpdCwgd2UgY291bGQgbWF5YmUgbWFrZSB0aGUgRnVuY3Rpb24gc2ltcGx5
IGE8YnI+DQomZ3Q7Jmd0OyBsYWJlbCB0aGF0IG1lYW5zIHNvbWV0aGluZyB0byB0aGUgZGV2aWNl
LS1hbiBpbmRpcmVjdGlvbiB0byBhPGJyPg0KJmd0OyZndDsgY29uZmlndXJhdGlvbiBzZXQuPGJy
Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtRGF2ZTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t
PGJyPg0KJmd0OyZndDsgRnJvbTogc2ZjIFs8YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0
Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBSb24g
UGFya2VyPGJyPg0KJmd0OyZndDsgU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE1IDEx
OjMxIEFNPGJyPg0KJmd0OyZndDsgVG86IERhdmUgRG9sc29uOyBKb2VsIE0uIEhhbHBlcm47IDxh
IGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj4NCm1vaGFtZWQuYm91
Y2FkYWlyQG9yYW5nZS5jb208L2E+Ozxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNA
aWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyBDYzogQmVuIFdyaWdodCAo
PGEgaHJlZj0ibWFpbHRvOkJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb20iPkJlbi5XcmlnaHRAbWV0
YXN3aXRjaC5jb208L2E+KTxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBkcmFmdC1x
dWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHM8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7IEhpLCBEYXZlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSBhZ3JlZSB0aGF0
IG9uIHRoZSB3aXJlLCB0aGlzIGlzIHRoZSB3YXkgaXQgd291bGQgd29yay48YnI+DQomZ3Q7Jmd0
Ozxicj4NCiZndDsmZ3Q7IEJ1dCwgd2hlbiBjb21wb3NpbmcgdGhlIGNoYWluLCBpdCBzZWVtcyBs
aWtlIGluZm9ybWF0aW9uIHdvdWxkIGJlIGxhY2tpbmc8YnI+DQomZ3Q7Jmd0OyBpZiBhIGNoYWlu
IHdlcmUgZXhwcmVzc2VkIHNpbXBseSBhcyB7U0YtZm9vLCBTRi1iYXIsIFNGLWZvbywgU0YtZm9v
YmFyfS48YnI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyBJdCBpcyBjb21wbGV0ZWx5IGltcGxpY2l0
IHRoYXQgc2luY2UgU0YtZm9vIGFwcGVhcnMgdHdpY2UsIGl0IHBlcmhhcHM8YnI+DQomZ3Q7Jmd0
OyBzaG91bGQgcGVyZm9ybSBzb21lIGRpZmZlcmVudCBkdXR5IHdoZW4gaW5kZXggPSAwIHZzIHdo
ZW4gaW5kZXggPSAyLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQXQgZmlyc3QsIEkgdGhv
dWdodCB0aGF0IGFuIGFsdGVybmF0aXZlIHdheSB0byBoYW5kbGUgdGhpcyB3b3VsZCBiZSB0bzxi
cj4NCiZndDsmZ3Q7IHVzZSBtdWx0aXBsZSBsb2dpY2FsIGlkZW50aXRpZXMgZm9yIFNGLWZvby4m
bmJzcDsgSW4gdGhpcyBjYXNlLCB0aGUgY2hhaW48YnI+DQomZ3Q7Jmd0OyBhYm92ZSB3b3VsZCBi
ZSBleHByZXNzZWQgYXMge1NGLWZvby1maXJzdC1iZWhhdmlvciwgU0YtYmFyLDxicj4NCiZndDsm
Z3Q7IFNGLWZvby1zZWNvbmQtYmVoYXZpb3IsIFNGLWZvb2Jhcn0uJm5ic3A7Jm5ic3A7IEJ1dCwg
dGhlIHByb2JsZW0gaGVyZSBpcyBzZWxlY3Rpbmc8YnI+DQomZ3Q7Jmd0OyB0aGUgUlNQLCBhc3N1
bWluZyB0aGF0IFNGLWZvbyBoYXMgbXVsdGlwbGUgaW5zdGFuY2VzLiZuYnNwOyZuYnNwOyBOb3Ro
aW5nIGluIHRoaXM8YnI+DQomZ3Q7Jmd0OyBzZWNvbmQgZmxhdm9yIG9mIGNoYWluIHNheXMgdGhh
dCB0aGUgc2FtZSBpbnN0YW5jZSBvZiBTRi1mb28tKiBtdXN0IGJlPGJyPg0KJmd0OyZndDsgc2Vs
ZWN0ZWQgdG8gc2F0aXNmeSBTRi1mb28tZmlyc3QtYmVoYXZpb3IgYW5kIFNGLWZvby1zZWNvbmQt
YmVoYXZpb3I8YnI+DQomZ3Q7Jmd0OyAod2hpY2ggbWF5IG5vdCBiZSByZXF1aXJlZCwgYnV0IHNo
b3VsZCBiZSBwb3NzaWJsZSB0byBmb3JjZSBhcyBzdWNoKS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7IEkgZ3Vlc3Mgd2hhdCBJJ20gc2F5aW5nIGlzIHRoYXQgc3BpcmFsaW5nIGhhcyBhIHN1
YnRsZXR5IHRvIGl0IHRoYXQgaXNuJ3Q8YnI+DQomZ3Q7Jmd0OyB5ZXQgYWRlcXVhdGVseSBhZGRy
ZXNzZWQgYW5kIHRoYXQgSSBkb24ndCBoYXZlIGEgc3BlY2lmaWMgcHJvcG9zYWwgdG88YnI+DQom
Z3Q7Jmd0OyBzb2x2ZSBpdCwgZWl0aGVyLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmbmJz
cDsmbmJzcDsmbmJzcDsgUm9uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsgRnJvbTogc2ZjIFs8
YSBocmVmPSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0Bp
ZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBEYXZlIERvbHNvbjxicj4NCiZndDsmZ3Q7IFNlbnQ6
IFRodXJzZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAxMToyMSBBTTxicj4NCiZndDsmZ3Q7IFRvOiBK
b2VsIE0uIEhhbHBlcm47IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu
Y29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpz
ZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyBDYzogQmVuIFdyaWdo
dCAoPGEgaHJlZj0ibWFpbHRvOkJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb20iPkJlbi5XcmlnaHRA
bWV0YXN3aXRjaC5jb208L2E+KTxicj4NCiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc2ZjXSBkcmFm
dC1xdWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHM8YnI+DQomZ3Q7Jmd0Ozxicj4N
CiZndDsmZ3Q7IElmIEkgbWF5IHRyeSB0byBwdXQgaXQgc2ltcGx5LCBJJ3ZlIGFsd2F5cyB0aG91
Z2h0IG9mIGl0IHRoaXMgd2F5Ojxicj4NCiZndDsmZ3Q7IC0tJmd0OyBFYWNoIG5vZGUgaW4gdGhl
IGNoYWluIHNlbGVjdHMgdGhlIGNvbnRleHQgZm9yIHByb2Nlc3NpbmcgYW5kIHRoZTxicj4NCiZn
dDsmZ3Q7IG5leHQgaG9wIG9uIHRoZSBiYXNpcyBvZiBCT1RIIHBhdGggSUQgYW5kIEluZGV4LCB3
aGlsZSBkZWNyZW1lbnRpbmcgdGhlPGJyPg0KJmd0OyZndDsgaW5kZXggZm9yIHRoZSBuZXh0IGhv
cC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYXQgYmVoYXZpb3Igc3VwcG9ydHMgc3Bp
cmFsaW5nLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7IC1EYXZlPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsgRnJvbTogc2ZjIFs8YSBocmVm
PSJtYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9y
ZzwvYT5dIE9uIEJlaGFsZiBPZiBKb2VsIE0uIEhhbHBlcm48YnI+DQomZ3Q7Jmd0OyBTZW50OiBU
aHVyc2RheSwgRmVicnVhcnkgMjYsIDIwMTUgMTA6MDIgQU08YnI+DQomZ3Q7Jmd0OyBUbzogPGEg
aHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2Fk
YWlyQG9yYW5nZS5jb208L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGll
dGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IENjOiBCZW4gV3JpZ2h0ICg8YSBocmVmPSJtYWlsdG86
QmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbSI+QmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbTwvYT4p
PGJyPg0KJmd0OyZndDsgU3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1uc2g6IFN1
cHBvcnQgb2YgU0YgU3BpcmFsczxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlcmUgYXJl
IHR3byBkaWZmZXJlbnQgYXNwZWN0cyBvZiBTcGlyYWxzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0
OyZndDsgT25lIG9mIHRoZSB0d28gYXNwZWN0cyBpcyBlbmFibGluZyBhIHBhY2tldCB0aGF0IHJl
cGVhdGVkbHkgYXJyaXZlcyBhdDxicj4NCiZndDsmZ3Q7IHRoZSBzYW1lIFNGRiB0byBnZXQgdGhl
IGNvcnJlY3Qgc2VydmljZXMgcHJvdmlkZWQgZWFjaCB0aW1lIGl0IGFycml2ZXMsPGJyPg0KJmd0
OyZndDsgYW5kIHRvIGdvIHRvIHRoZSBjb3JyZWN0IG5leHQgU0ZGIGVhY2ggdGltZSBpdCBhcnJp
dmVzLiZuYnNwOyBUaGUgU2VydmljZSBQYXRoPGJyPg0KJmd0OyZndDsgSW5kZXgsIHVzZWQgYnkg
dGhlIFNGRiB0byBzZWxlY3Qgc2VydmljZSBmdW5jdGlvbnMgYW5kIG5leHQgU0ZGLCBwcm92aWRl
czxicj4NCiZndDsmZ3Q7IHRoYXQgY2FwYWJpbGl0eS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7IFRoZSBvdGhlciBhc3BlY3QgaXMgaG93IHRoZSBTZXJ2aWNlIEZ1bmN0aW9ucyB0aGVtc2Vs
dmVzIGhhbmRsZSBzcGlyYWxzLjxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IFRvIGEgbGFyZ2Ug
ZGVncmVlLCB0aGF0IGRlcGVuZHMgdXBvbiB0aGUgaW5kaXZpZHVhbCBzZXJ2aWNlIGZ1bmN0aW9u
Ljxicj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IEkgbm9ybWFsbHkgYXNzdW1lIHRoYXQgaXQgd291
bGQgdXNlIHBhY2tldCBjb250ZXh0IChhcyBkZXNjcmliZWQgaW4gdGhlPGJyPg0KJmd0OyZndDsg
dGV4dCB5b3UgcXVvdGUpIHRvIGRldGVybWluZSB3aGF0IHRvIGRvLjxicj4NCiZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsgU2luY2UgSSB3b3VsZCBwcmVmZXIgdGhhdCBzZXJ2aWNlIGZ1bmN0aW9ucyBh
cmUgaW5kZXBlbmRlbnQgb2YgdGhlPGJyPg0KJmd0OyZndDsgdW5kZXJseWluZyBzZXJ2aWNlIGZ1
bmN0aW9uIGNoYWluaW5nIGluZnJhc3RydWN0dXJlLCBhbmQgYXJlIG5vdDxicj4NCiZndDsmZ3Q7
IHNlbnNpdGl2ZSB0byBob3cgbWFueSBmdW5jdGlvbnMgYXJlIGJlZm9yZSBvciBhZnRlciB0aGVt
IGluIHRoZSBjaGFpbiwgSTxicj4NCiZndDsmZ3Q7IHdvdWxkIHBlcnNvbmFsbHkgcHJlZmVyIHRo
YXQgdGhleSBub3QgdXNlIHRoZSBwYXRoIGluZGV4IGZvciB0aGF0LiZuYnNwOyBJPGJyPg0KJmd0
OyZndDsgd291bGQgcmVjb21tZW5kIHRoYXQgaWYgdGhlIHBhY2tldCBkb2VzIG5vdCBjYXJyeSBl
bm91Z2ggY29udGV4dCB0aGF0IHRoZTxicj4NCiZndDsmZ3Q7IHNlcnZpY2UgZnVuY3Rpb24gY291
bGQgYW5kIHNob3VsZCB1c2UgbWV0YWRhdGEgdG8gY2FycnkgaXRzIG5lZWRlZCBzdGF0ZTxicj4N
CiZndDsmZ3Q7IGluZm9ybWF0aW9uLiZuYnNwOyBCdXQgbmVpdGhlciBJIHBlcnNvbmFsbHkgbm9y
IHRoZSBTRkMgV29ya2luZyBHcm91cCBnZXQgdG88YnI+DQomZ3Q7Jmd0OyB0ZWxsIGZvbGtzIGhv
dyB0byBidWlsZCB0aGVpciBzZXJ2aWNlIGZ1bmN0aW9ucy4mbmJzcDsgU28gdGhleSBtYXkgY29t
ZSB1cDxicj4NCiZndDsmZ3Q7IHdpdGggb3RoZXIgbWV0aG9kcyBmb3IgYWRkcmVzc2luZyB0aGVp
ciBuZWVkcy4mbmJzcDsgV2hpY2ggaXMgYWxzbyBmaW5lLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0
OyZndDsgVGh1cywgSSB3b3VsZCBub3QgZXhwZWN0IHRoaXMgZG9jdW1lbnQgdG8gZGlzY3VzcyBo
b3cgc2VydmljZSBmdW5jdGlvbnM8YnI+DQomZ3Q7Jmd0OyB0aGVtc2VsdmVzIGhhbmRsZSByZXZp
c2l0aW5nLiZuYnNwOyBCdXQgbWV0YWRhdGEgY2xlYXJseSBhbGxvd3MgZm9yIGEgcmFuZ2Ugb2Y8
YnI+DQomZ3Q7Jmd0OyBiZWhhdmlvcnMgdGhhdCB3aWxsIHdvcmsuJm5ic3A7IEFuZCB0aGUgcGF0
aCBpbmRleCBoYW5kbGVzIHRoZSBTRkYgbmVlZHM8YnI+DQomZ3Q7Jmd0OyByZWxhdGl2ZSB0byBz
cGlyYWxzLCB3aGljaCBpcyB3aGF0IHdlIG5lZWQgdG8gaGFuZGxlLjxicj4NCiZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsgWW91cnMsPGJyPg0KJmd0OyZndDsgSm9lbDxicj4NCiZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsgT24gMi8yNi8xNSA5OjUyIEFNLCA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3Vj
YWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4gd3JvdGU6
PGJyPg0KJmd0OyZndDsmZ3Q7IFJlLSw8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn
dDsgU3BpcmFsIGlzIG5vdCBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0LCBidXQgU0YgbG9vcCBpcy48
YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgSSdtIGFza2luZyB0aGUgcXVlc3Rp
b24gYmVjYXVzZSBJIGRvbid0IGdldCBmcm9tIHRoZSBkcmFmdCBob3cgc3BpcmFsczxicj4NCiZn
dDsmZ3Q7Jmd0OyBjb3VsZCB3b3JrICh0aGF0IGlzIGEgU0YgaW52b2tlZCBzZXZlcmFsIHRpbWUg
aW4gdGhlIGNvbnRleHQgb2YgdGhlIHNhbWU8YnI+DQomZ3Q7Jmd0OyZndDsgU0ZDKS48YnI+DQom
Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgQmVmb3JlIHByb3Bvc2luZyB0ZXh0LCBJIHdv
dWxkIGxpa2UgdG8gdW5kZXJzdGFuZCBmaXJzdCBob3cgaXQgd29ya3MuPGJyPg0KJmd0OyZndDsm
Z3Q7IElmIHlvdSBjYW4gcHJvdmlkZSBhbiBleGFtcGxlLCB0aGlzIHdpbGwgYmUgZXZlbiBncmVh
dC48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgVGhhbmsgeW91Ljxicj4NCiZn
dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBDaGVlcnMsPGJyPg0KJmd0OyZndDsmZ3Q7IE1l
ZDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1NZXNzYWdlIGQn
b3JpZ2luZS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBEZSA6IEpvZWwgTS4gSGFscGVybiBb
PGEgaHJlZj0ibWFpbHRvOmptaEBqb2VsaGFscGVybi5jb20iPm1haWx0bzpqbWhAam9lbGhhbHBl
cm4uY29tPC9hPl0gRW52b3nDqSA6IGpldWRpIDI2PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBmw6l2
cmllciAyMDE1IDE1OjQxIMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgPGEgaHJlZj0i
bWFpbHRvOnNmY0BpZXRmLm9yZyI+DQpzZmNAaWV0Zi5vcmc8L2E+IENjIDo8YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7IEJlbiBXcmlnaHQgKDxhIGhyZWY9Im1haWx0bzpCZW4uV3JpZ2h0QG1ldGFzd2l0
Y2guY29tIj5CZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tPC9hPikgT2JqZXQgOiBSZTogW3NmY108
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGRyYWZ0LXF1aW5uLXNmYy1uc2g6IFN1cHBvcnQgb2YgU0Yg
U3BpcmFsc2d0OyZndDsmZ3Q7Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBTRiBTcGlyYWxzIHJlcXVpcmVtZW50IGlz
IG9uZSBvZiB0aGUga2V5IGRyaXZlcnMgZm9yIHRoZSBpbmRleC48YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7IFRoZSBpbmRleCBhbGxvd3Mgb25lIHRvIHRlbGwgd2hlcmUgb25lIGlzIGluIHRoZSBzcGly
YWwsIGFuZCBhbHNvIHRvPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBicmVhayBhIGxvb3AgaWYgb25l
IGhhcyBhIGxvb3AgaW5zdGVhZCBvZiBhIHNwaXJhbC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyBJcyB0aGVyZSB0ZXh0IHRoYXQgd2UgY291bGQgYWRkIHRoYXQg
d291bGQgaGVscCBtYWtlIHRoaXMgY2xlYXIsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBzaW5jZSB5
b3VyIGVhcmxpZXIgcXVlc3Rpb24gYWJvdXQgdGhlIHBhdGggaW5kZXggc3VnZ2VzdHMgdGhhdCBp
dCBpczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgbm90IGFzIGNsZWFyIGFzIGl0IHNob3VsZCBiZT88
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBZb3Vycyw8YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7IEpvZWw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyBPbiAyLzI2LzE1IDg6NDIgQU0sIDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNh
ZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiB3cm90ZTo8
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIaSBQYXVsLCBhbGwsPGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGVyZSB3ZXJlIGEgZGlzY3Vzc2lv
biBpbiB0aGUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgKDxhIGhyZWY9
Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zZmMvY3VycmVudC9tc2cwMTcw
MS5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2ZjL2N1cnJlbnQv
bXNnMDE3MDEuaHRtbDwvYT4pPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCBsZWQgdG8g
ZGVmaW5pbmcgd2hhdCBpcyBtZWFudCBieSBTRiBTcGlyYWxzOiAoYmVsb3cgaXMgcHJvdmlkZWQ8
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbiBleGNlcnB0IGZyb208YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3Vj
YWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wNiI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh
ZnQtYm91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDY8L2E+IHdoZXJlPGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyZndDsgdGhlIGNvbmNsdXNpb25zIG9mIHRoYXQgZGlzY3Vzc2lvbiB3ZXJlIHJlY29y
ZGVkKTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg
JnF1b3Q7Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgU2VydmljZSBGdW5jdGlvbiBTcGlyYWw6IGRlbm90
ZXMgYSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluIGluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyB3aGlj
aDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGF0YSBp
cyBoYW5kbGVkIGJ5IGEgU2VydmljZSBGdW5jdGlvbiwgZm9yd2FyZGVkIG9ud2FyZHMsPGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgYW5kPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBhcnJpdmVzIG9uY2UgYWdhaW4gYXQgdGhhdCBTZXJ2aWNlIEZ1bmN0
aW9uLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiZu
YnNwOyBOb3RlIHRoYXQgc29tZSBTZXJ2aWNlIEZ1bmN0aW9ucyBzdXBwb3J0IGJ1aWx0LWluPGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZnVuY3Rpb25zIHRvPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhY2NvbW1vZGF0
ZSBzcGlyYWxzOyB0aGVzZSBzZXJ2aWNlLXNwZWNpZmljIGZ1bmN0aW9ucyBtYXk8YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IHJlcXVpcmUgdGhhdCB0aGUgZGF0YSByZWNlaXZlZCBpbiBhIHNwaXJhbCBzaG91bGQgZGlmZmVy
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW4gYTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2F5IHRoYXQgd2lsbCBy
ZXN1bHQgaW4gYSBkaWZmZXJlbnQgcHJvY2Vzc2luZyBkZWNpc2lvbjxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7IHRoYW48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBvcmlnaW5hbCBkYXRhLiZuYnNwOyBUaGlzIGRv
Y3VtZW50IGRvZXMgbm90IG1ha2Ugc3VjaDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXNzdW1wdGlvbi48YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsgQSBTZXJ2aWNl
IEZ1bmN0aW9uIENoYWluIG1heSBpbnZvbHZlIG9uZSBvciBtb3JlIFNlcnZpY2U8YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IEZ1bmN0aW9uIFNwaXJhbHMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyAqJm5ic3A7IFVubGlrZSBTZXJ2aWNlIEZ1bmN0aW9uIGxvb3AsIHNwaXJhbHMg
YXJlIG5vdCBjb25zaWRlcmVkPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXM8YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
IGVycm9ycy4mcXVvdDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7IEFuZCB0aGlzIGNvbXBhbmlvbiByZXF1aXJlbWVudDo8YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZxdW90OyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyBBLiZuYnNwOyBTZXJ2aWNlIEZ1bmN0aW9ucyBNQVkgYmUgaW52b2tlZCBt
dWx0aXBsZSB0aW1lcyBpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlIHNhbWUgU2VydmljZSBGdW5jdGlvbiBD
aGFpbiAoZGVub3RlZCBhcyBTRjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU3BpcmFsKSwgYnV0IHRoZSBzb2x1dGlv
biBNVVNUIHByZXZlbnQgaW5maW5pdGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvcndhcmRpbmcgbG9vcHMuIMK7
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBSZWFk
aW5nIHRoZSBjdXJyZW50IGRyYWZ0LXF1aW5uLXNmYy1uc2gsIEkgZG9uJ3Qgc2VlIGhvdyB0aGlz
IGlzIG1ldC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7IENhbiB5b3UgcGxlYXNlIGNsYXJpZnkgd2hldGhlciB0aGlzIGlzIHN1cHBvcnRlZCBhbmQg
aG93Pzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg
VGhhbmsgeW91Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyZndDsgQ2hlZXJzLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyZndDsgTWVkPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn
dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nm
YzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsg
PGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsm
Z3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5o
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7Jmd0
Ozxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fPGJyPg0KJmd0OyZndDsgc2ZjIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhy
ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyA8
YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPg0KJmd0OyZndDs8YnI+
DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xzxicj4NCiZndDsmZ3Q7IHNmYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJt
YWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgPGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0
OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+
DQomZ3Q7Jmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRv
OnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYzwvYT48YnI+DQomZ3Q7PGJyPg0KJmd0OzxvOnA+PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_E8355113905631478EFF04F5AA706E9830B55B03wtlexchp2sandvi_--


From nobody Thu Feb 26 10:37:20 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682AC1AC3D8 for ; Thu, 26 Feb 2015 10:37:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level: 
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpTsp8x-UiE1 for ; Thu, 26 Feb 2015 10:37:11 -0800 (PST)
Received: from mail-gw2-out.broadcom.com (mail-gw2-out.broadcom.com [216.31.210.63]) by ietfa.amsl.com (Postfix) with ESMTP id 291E31AC3CC for ; Thu, 26 Feb 2015 10:37:11 -0800 (PST)
X-IronPort-AV: E=Sophos; i="5.09,654,1418112000"; d="scan'208,217"; a="58111690"
Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 26 Feb 2015 11:19:20 -0800
Received: from SJEXCHCAS03.corp.ad.broadcom.com (10.16.203.8) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 26 Feb 2015 10:37:08 -0800
Received: from SJEXCHMB12.corp.ad.broadcom.com ([fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS03.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0174.001; Thu, 26 Feb 2015 10:37:08 -0800
From: Rajeev Manur 
To: "Carlos Pignataro (cpignata)" , "Jim Guichard (jguichar)" 
Thread-Topic: [sfc] WG call for adoption of draft-quinn-sfc-nsh
Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50DpjmA//+bpdA=
Date: Thu, 26 Feb 2015 18:37:08 +0000
Message-ID: <1E714095C88C9D408749A723A59CF6ED31EF37E3@SJEXCHMB12.corp.ad.broadcom.com>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.16.203.100]
Content-Type: multipart/alternative; boundary="_000_1E714095C88C9D408749A723A59CF6ED31EF37E3SJEXCHMB12corpa_"
MIME-Version: 1.0
Archived-At: 
Cc: "sfc@ietf.org" 
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh
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, 26 Feb 2015 18:37:17 -0000

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

Support as co-author.

Thanks!
--Rajeev


From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Carlos Pignataro (cpig=
nata)
Sent: Thursday, February 26, 2015 10:32 AM
To: Jim Guichard (jguichar)
Cc: sfc@ietf.org
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh

I support WG adoption of this document.

Thanks,

- Carlos.

On Feb 26, 2015, at 7:47 AM, Jim Guichard (jguichar) > wrote:

Greetings WG:

The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft=
-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc=
-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined =
the NSH document so that the WG can focus on a single encapsulation documen=
t going forward. This new version of NSH includes an open items section bas=
ed on discussion between co-authors and members of the list. The WG will wo=
rk through this list (and any other issues that need to be added) over the =
next weeks. We appreciate and recognize the hard work of both the NSH and S=
CH authors in pushing the SFC encapsulation work forward.

With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n=
sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3=
/12/2015.

Please note that this is a call for adoption, and not a last call for conte=
nt of the document. Adopting a WG document simply means that the WG will fo=
cus its efforts on that particular draft going forward, and use that docume=
nt for resolving open issues and documenting the WG's decisions.

Please indicate whether you support adoption for not, and if not why. Issue=
s you have with the current document itself can also be raised, but they sh=
ould be raised in the context of what should be changed in the document goi=
ng forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that appl=
ies to this draft, in line with the IPR disclosure obligations for WG parti=
cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l=
isted as a document author please respond to this email (to the chairs) whe=
ther or not you are aware of any relevant IPR.

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


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









    

    Support 
as co-author.
    

     
    

    Thanks!
    
--Rajeev
    

     
    

     
    

    

    

    From: sfc [mai=
lto:sfc-bounces@ietf.org]
On Behalf Of Carlos Pignataro (cpignata)
    
Sent: Thursday, February 26, 2015 10:32 AM
    
To: Jim Guichard (jguichar)
    
Cc: sfc@ietf.org
    
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh<=
/o:p>
    

    

    

     
    

    I support WG adoption of this document. <=
/p>

    

     
    

    

    

    Thanks,
    

    

    

     
    

    

    

    — Carlos.
    

    

     
    

    

    

    

    On Feb 26, 2015, at 7:47 AM, Jim Guichard (jguichar)=
 <jguichar@cisco.com> wrote=
:
    

    

     
    

    

    

    

    

    Greetings WG:
    

    

    

     
    

    

    

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft-quinn-sf=
c-nsh/) has recently been reissued.
 The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sf=
c-sch/) have joined the NSH document so that the WG can focus on a sing=
le encapsulation document going forward.
 This new version of NSH includes an open items section based on dis=
cussion between co-authors and members of the list. The WG will work throug=
h this list (and any other issues that need to be added) over the next week=
s. We appreciate and recognize the
 hard work of both the NSH and SCH authors in pushing the SFC encapsulation=
 work forward.
    

    

    

     
    

    

    

    With that said, the chairs are calling for WG adoption of draft-quinn-sfc-=
nsh-07 as a WG document. The call for adoption will run for 2 weeks ending =
3/12/2015.
    

    

    

     
    

    

    

    Please note tha=
t this is a call for adoption, and not a last call for content of the docum=
ent. Adopting a WG document simply means that the WG will focus its efforts=
 on that particular draft going forward,
 and use that document for resolving open issues and documenting the WGR=
17;s decisions.
    

    

    

     
    

    

    

    Please indicate=
 whether you support adoption for not, and if not why. Issues you have with=
 the current document itself can also be raised, but they should be raised =
in the context of what should be changed
 in the document going forward, rather than a pre-condition for adoption.&n=
bsp;
    

    

    

     
    

    

    

    Finally, now is=
 also a good time to poll for knowledge of any IPR that applies to this dra=
ft, in line with the IPR disclosure obligations for WG participants (see RF=
Cs 3979, 4879, 3669 and 5378 for more
 details). If you are listed as a document author please respond to this em=
ail (to the chairs) whether or not you are aware of any relevant IPR.
    

    

    

     
    

    

    

    Jim & Thomas
    

    

    

    

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

    

    

    

     
    

    

    

    



--_000_1E714095C88C9D408749A723A59CF6ED31EF37E3SJEXCHMB12corpa_--


From nobody Thu Feb 26 10:50: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 EDBFB1A0111 for ; Thu, 26 Feb 2015 10:50:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level: 
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 op9CSe44kznr for ; Thu, 26 Feb 2015 10:50:47 -0800 (PST)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9631A0015 for ; Thu, 26 Feb 2015 10:50:47 -0800 (PST)
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, 26 Feb 2015 13:50:46 -0500
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, 26 Feb 2015 13:50:46 -0500
From: Dave Dolson 
To: "Jim Guichard (jguichar)" , "sfc@ietf.org" 
Thread-Topic: WG call for adoption of draft-quinn-sfc-nsh
Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50DRtzw
Date: Thu, 26 Feb 2015 18:50:45 +0000
Message-ID: 
References: 
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_E8355113905631478EFF04F5AA706E9830B55B53wtlexchp2sandvi_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh
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, 26 Feb 2015 18:50:50 -0000

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

I support adoption.


From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar=
)
Sent: Thursday, February 26, 2015 7:47 AM
To: sfc@ietf.org
Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh

Greetings WG:

The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft=
-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc=
-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined =
the NSH document so that the WG can focus on a single encapsulation documen=
t going forward. This new version of NSH includes an open items section bas=
ed on discussion between co-authors and members of the list. The WG will wo=
rk through this list (and any other issues that need to be added) over the =
next weeks. We appreciate and recognize the hard work of both the NSH and S=
CH authors in pushing the SFC encapsulation work forward.

With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n=
sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3=
/12/2015.

Please note that this is a call for adoption, and not a last call for conte=
nt of the document. Adopting a WG document simply means that the WG will fo=
cus its efforts on that particular draft going forward, and use that docume=
nt for resolving open issues and documenting the WG's decisions.

Please indicate whether you support adoption for not, and if not why. Issue=
s you have with the current document itself can also be raised, but they sh=
ould be raised in the context of what should be changed in the document goi=
ng forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that appl=
ies to this draft, in line with the IPR disclosure obligations for WG parti=
cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l=
isted as a document author please respond to this email (to the chairs) whe=
ther or not you are aware of any relevant IPR.

Jim & Thomas

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









    

    I support adoption.<=
/o:p>
    

     <=
/p>

     <=
/p>

    

    

    From: sfc [mai=
lto:sfc-bounces@ietf.org]
On Behalf Of Jim Guichard (jguichar)
    
Sent: Thursday, February 26, 2015 7:47 AM
    
To: sfc@ietf.org
    
Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh
    

    

    

     
    

    

    

    Greetings WG:
    

    

    

     =

    

    

    

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/dr=
aft-quinn-sfc-nsh/) has recently been
 reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draf=
t-zhang-sfc-sch/) have joined the NSH document so that the WG can focus=
 on a single encapsulation document
 going forward. This new version of NSH includes an open items secti=
on based on discussion between co-authors and members of the list. The WG w=
ill work through this list (and any other issues that need to be added) ove=
r the next weeks. We appreciate
 and recognize the hard work of both the NSH and SCH authors in pushing the=
 SFC encapsulation work forward.
    

    

    

     =

    

    

    

    With that said, the chairs are calling for WG adoption of draf=
t-quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 w=
eeks ending 3/12/2015.=

    

    

    

     =

    

    

    

    Please note that this is a call for adoption, and not a last call for cont=
ent of the document. Adopting a WG document simply means that the WG will f=
ocus its efforts on that particular
 draft going forward, and use that document for resolving open issues and d=
ocumenting the WG’s decisions.
    

    

    

     
    

    

    

    Please indicate whether you support adoption for not, and if not why. Issu=
es you have with the current document itself can also be raised, but they s=
hould be raised in the context of what
 should be changed in the document going forward, rather than a pre-conditi=
on for adoption. 
    

    

    

     
    

    

    

    Finally, now is also a good time to poll for knowledge of any IPR that app=
lies to this draft, in line with the IPR disclosure obligations for WG part=
icipants (see RFCs 3979, 4879, 3669
 and 5378 for more details). If you are listed as a document author please =
respond to this email (to the chairs) whether or not you are aware of any r=
elevant IPR.
    

    

    

     
    

    

    

    Jim & Thomas
    

    

    

    



--_000_E8355113905631478EFF04F5AA706E9830B55B53wtlexchp2sandvi_--


From nobody Thu Feb 26 10:57:19 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D0B1A1A59 for ; Thu, 26 Feb 2015 10:57:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmbLjLMgGktm for ; Thu, 26 Feb 2015 10:57:15 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6ACE1A1A3C for ; Thu, 26 Feb 2015 10:57:14 -0800 (PST)
Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id DF1F63F1286B1; Thu, 26 Feb 2015 18:57:07 +0000 (GMT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id t1QIv6AC003905 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Feb 2015 13:57:10 -0500
Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.112]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 13:56:54 -0500
From: "Dolganow, Andrew (Andrew)" 
To: Guichard Jim 
Thread-Topic: [sfc] WG call for adoption of draft-quinn-sfc-nsh
Thread-Index: AQHQUeBzIn8pIGy5yE+x2adva5EB3J0DSDhX
Date: Thu, 26 Feb 2015 18:56:53 +0000
Message-ID: <98EEF036-6D81-4030-84D3-BFB17F2C33BA@alcatel-lucent.com>
References: , 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: multipart/alternative; boundary="_000_98EEF0366D81403084D3BFB17F2C33BAalcatellucentcom_"
MIME-Version: 1.0
Archived-At: 
Cc: "sfc@ietf.org" 
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh
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, 26 Feb 2015 18:57:17 -0000

--_000_98EEF0366D81403084D3BFB17F2C33BAalcatellucentcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Support

Andrew

Sent from my iPhone


On Feb 26, 2015:7:47 AM, at 7:47 AM, Jim Guichard (jguichar) > wrote:

Greetings WG:

The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft=
-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc=
-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined =
the NSH document so that the WG can focus on a single encapsulation documen=
t going forward. This new version of NSH includes an open items section bas=
ed on discussion between co-authors and members of the list. The WG will wo=
rk through this list (and any other issues that need to be added) over the =
next weeks. We appreciate and recognize the hard work of both the NSH and S=
CH authors in pushing the SFC encapsulation work forward.

With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n=
sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3=
/12/2015.

Please note that this is a call for adoption, and not a last call for conte=
nt of the document. Adopting a WG document simply means that the WG will fo=
cus its efforts on that particular draft going forward, and use that docume=
nt for resolving open issues and documenting the WG=92s decisions.

Please indicate whether you support adoption for not, and if not why. Issue=
s you have with the current document itself can also be raised, but they sh=
ould be raised in the context of what should be changed in the document goi=
ng forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that appl=
ies to this draft, in line with the IPR disclosure obligations for WG parti=
cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l=
isted as a document author please respond to this email (to the chairs) whe=
ther or not you are aware of any relevant IPR.

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


--_000_98EEF0366D81403084D3BFB17F2C33BAalcatellucentcom_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable







    Support
    

    
Andrew


    

    

    Sent from my iPhone
    

    


    

    

    

    

    

    

    

    

    On Feb 26, 2015:7:47 AM, at 7:47 AM, Jim Guichard (jguichar=
) <jguichar@cisco.com> wrote:
    

    

    

    

    

    Greetings WG:
    


    

    

    The document draft-quinn-sfc-nsh-07 (https://datatracker.iet=
f.org/doc/draft-quinn-sfc-nsh/) has recently
 been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.i=
etf.org/doc/draft-zhang-sfc-sch/) have joined the NSH document so that =
the WG can focus on a single encapsulation
 document going forward. This new version of NSH includes an =
open items
section based on discussion between co-authors and members of the list.=
 The WG will work through this list (and any other issues that need to be a=
dded) over the next weeks. We appreciate and recognize the hard work of bot=
h the NSH and SCH authors in pushing
 the SFC encapsulation work forward.
    


    

    

    With that said, the chairs are calling for WG adoption of dra=
ft-quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 =
weeks ending 3/12/2015.
    


    

    

    Please note that this is a call for adoption, and not a=
 last call for content of the document. Adopting a WG document simply means=
 that the WG will focus its efforts on that
 particular draft going forward, and use that document for resolving open i=
ssues and documenting the WG=92s decisions.
    


    

    

    Please indicate whether you support adoption for not, a=
nd if not why. Issues you have with the current document itself can also be=
 raised, but they should be raised in the
 context of what should be changed in the document going forward, rather th=
an a pre-condition for adoption. 
    


    

    

    Finally, now is also a good time to poll for knowledge =
of any IPR that applies to this draft, in line with the IPR disclosure obli=
gations for WG participants (see RFCs 3979,
 4879, 3669 and 5378 for more details). If you are listed as a document aut=
hor please respond to this email (to the chairs) whether or not you are awa=
re of any relevant IPR.
    

    


    

    

    Jim & Thomas
    

    

    

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

    

    

    

    

    

    

    


    

    

    



--_000_98EEF0366D81403084D3BFB17F2C33BAalcatellucentcom_--


From nobody Thu Feb 26 11:05:04 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 233781A1A14 for ; Thu, 26 Feb 2015 11:05:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Level: 
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 DlPTGOEjC3G3 for ; Thu, 26 Feb 2015 11:04:59 -0800 (PST)
Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C53F51A1AA3 for ; Thu, 26 Feb 2015 11:04:54 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 96F731BC5993; Thu, 26 Feb 2015 11:04:54 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net
Received: from localhost (mobile-166-171-057-059.mycingular.net [166.171.57.59]) by mailc2.tigertech.net (Postfix) with ESMTPA id 68A9C1BC59A4; Thu, 26 Feb 2015 11:04:45 -0800 (PST)
Date: Thu, 26 Feb 2015 14:04:40 -0500
Message-ID: 
Importance: low
From: "Jmh.direct" 
To: ddolson@sandvine.com, jmh@joelhalpern.com, repenno@cisco.com, ron_parker@affirmednetworks.com, mohamed.boucadair@orange.com, sfc@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.android.email_160550734879705"
Archived-At: 
Cc: ben.wright@metaswitch.com
Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals
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, 26 Feb 2015 19:05:04 -0000

----_com.android.email_160550734879705
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

VGhlIGZpcmVhd2FsbCBzZXRzIHRoZSBtZXRhZGF0YSBmb3IgdGdlIGZpcmV3YWxsIHRvIHVzZS4g
wqBUaGUgYWJzZW5jZSBvZiB0aGUgbWV0YWRhdGEgc2VydmVzIGFzIHRoZSBpbmRpY2F0b3IgdGhh
dCB0aGlzIGlzIHRoZSBmaXJzdCB0aW1lLiDCoFJ1bGVzIGZvciB0aGlzIHNvcnQgb2YgdGhpbmcg
YXJlIHNldCAvIGFncmVlZCBieSB0aGVzZXJ2aWNlIGZ1bmN0aW9ucy4gwqBUaGF0IGlzIG91dCBv
ZiBzY29wZSBmb3IgdGhlIHdvcmtpbmcgZ3JvdXAgYnV0IHdlZWsgY2FuIHByb3ZpZGUgYSByZWdp
c3RyeSB0byBoZWxwLgoKQ29udHJvbCBpcyBwcm9iYWJseSBieSBhcHBsaWNhdGlvbiBwcm92aXNp
b25pbmcgb3Igb3RoZXIgY29udHJvbCBwcm90b2NvbHMuIMKgV2UgbWlnaHQgd2FudCB0byB3b3Jr
IG9uIHRoYXQgc3BhY2Ugb25jZSB3ZSBmaW5pc2ggb3VyIGRlbGl2ZXJhYmxlcy4KCllvdXJzLApK
b2VsCgoKU2VudCBmcm9tIG15IFNhbXN1bmcgc21hcnRwaG9uZSBvbiBBVCZUCgotLS0tLS0tLSBP
cmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tClN1YmplY3Q6IFJFOiBbc2ZjXSBkcmFmdC1xdWlubi1z
ZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHMgCkZyb206IERhdmUgRG9sc29uIDxkZG9sc29u
QHNhbmR2aW5lLmNvbT4gClRvOiAiSm1oLmRpcmVjdCIgPGptaC5kaXJlY3RAam9lbGhhbHBlcm4u
Y29tPiwiam1oQGpvZWxoYWxwZXJuLmNvbSIgPGptaEBqb2VsaGFscGVybi5jb20+LCJyZXBlbm5v
QGNpc2NvLmNvbSIgPHJlcGVubm9AY2lzY28uY29tPiwicm9uX3BhcmtlckBhZmZpcm1lZG5ldHdv
cmtzLmNvbSIgPHJvbl9wYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+LCJtb2hhbWVkLmJvdWNh
ZGFpckBvcmFuZ2UuY29tIiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4sInNmY0BpZXRm
Lm9yZyIgPHNmY0BpZXRmLm9yZz4gCkNDOiAiYmVuLndyaWdodEBtZXRhc3dpdGNoLmNvbSIgPGJl
bi53cmlnaHRAbWV0YXN3aXRjaC5jb20+IAoKU3VyZSwgYnV0IGdvaW5nIGZyb20gdGhlIGdlbmVy
aWMgdG8gdGhlIHNwZWNpZmljLCB0YWtlIG15IGV4YW1wbGUgb2YgdGhlIGZpcmV3YWxsIHdpdGgg
ZGlmZmVyZW50IHNldHMgb2YgcnVsZXMgZGVwZW5kaW5nIG9uIGxvY2F0aW9uIGluIHRoZSBjaGFp
bi4KCknigJltIGhlYXJpbmcgdGhhdCBtZXRhLWRhdGEgY2FuIGJlIHVzZWQgYnkgdGhlIGZpcmV3
YWxsIHRvIHNlbGVjdCB3aGljaCBydWxlIHNldCB0byBhcHBseSwgbWVhbmluZyB0aGUgbWV0YS1k
YXRhIGlzIGluc3BlY3RlZCB1cG9uIHBhY2tldCBhcnJpdmFsIGFuZCB1c2VkIHRvIHNlbGVjdCB0
aGUgcnVsZSBzZXQuCgooSXMgdGhhdCB3aGF0IGZvbGtzIG1lYW50IHRvIHNheT8pCgrCoAoKU28g
d2hpY2ggZWxlbWVudHMgc2V0IHRoZSBtZXRhLWRhdGEgZm9yIHRoZSBmaXJld2FsbCB0byB1c2U/
CgpBbmQgd2hpY2ggcnVsZXMgZGV0ZXJtaW5lIHRoZSBtZXRhLWRhdGEgdmFsdWVzIHRvIGJlIGFw
cGxpZWQgYnkgdGhvc2UgZWxlbWVudHM/CgrCoAoKwqAKCi1EYXZlCgrCoAoKwqAKCkZyb206IEpt
aC5kaXJlY3QgW21haWx0bzpqbWguZGlyZWN0QGpvZWxoYWxwZXJuLmNvbV0gClNlbnQ6IFRodXJz
ZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAxOjIwIFBNClRvOiBEYXZlIERvbHNvbjsgam1oQGpvZWxo
YWxwZXJuLmNvbTsgcmVwZW5ub0BjaXNjby5jb207IHJvbl9wYXJrZXJAYWZmaXJtZWRuZXR3b3Jr
cy5jb207IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZwpDYzogYmVu
LndyaWdodEBtZXRhc3dpdGNoLmNvbQpTdWJqZWN0OiBSRTogW3NmY10gZHJhZnQtcXVpbm4tc2Zj
LW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzCkltcG9ydGFuY2U6IExvdwoKwqAKCkluc3RydWN0
aW9uIGNvbWVzIGZyb20gdGhlIHNldmljZSBmdW5jdGlvbiBkZXNpZ24uIMKgU29tZSBoZWFkZXIg
c3RydWN0dXJlcyBhdWdtZW50IHRoYXQgd2l0aCBjb250cm9sIG1hcHBpbmcgaWJmb3JtYXRpb24g
dG8gaW5kaWNhdGUgd2hpY2ggbWV0YWRhdGEgZmllbGQgaGFzIHdoaWNoIHVzZS4KCsKgCgpHb3Ig
VExWIGJhc2VkIG1ldGFkYXQgd2UgcHJvYmFibHkgZWFudCBhIHJlZ2lzdHJ5IHdpdGggdmVyeSBl
YXN5IGVudHJ5IGNyZWF0aW9uLgoKwqAKCllvdXJzLAoKSm9lbAoKClNlbnQgZnJvbSBteSBTYW1z
dW5nIHNtYXJ0cGhvbmUgb24gQVQmVAoKCgoKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0t
LS0tLQpTdWJqZWN0OiBSRTogW3NmY10gZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBT
RiBTcGlyYWxzIApGcm9tOiBEYXZlIERvbHNvbiA8ZGRvbHNvbkBzYW5kdmluZS5jb20+IApUbzog
IkpvZWwgTS4gSGFscGVybiIgPGptaEBqb2VsaGFscGVybi5jb20+LCJSZWluYWxkbyBQZW5ubyAo
cmVwZW5ubykiIDxyZXBlbm5vQGNpc2NvLmNvbT4sUm9uIFBhcmtlciA8Um9uX1BhcmtlckBhZmZp
cm1lZG5ldHdvcmtzLmNvbT4sIm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20iIDxtb2hhbWVk
LmJvdWNhZGFpckBvcmFuZ2UuY29tPiwic2ZjQGlldGYub3JnIiA8c2ZjQGlldGYub3JnPiAKQ0M6
ICJCZW4gV3JpZ2h0IChCZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tKSIgPEJlbi5XcmlnaHRAbWV0
YXN3aXRjaC5jb20+IAoKCldoYXQgYXJlIHRoZSBtZWNoYW5pY3Mgb2YgdXNpbmcgbWV0YS1kYXRh
PwpXaGljaCBlbGVtZW50IHNldHMgaXQsIGFuZCBob3cgaXMgaXQgaW5zdHJ1Y3RlZCB0byBkbyBz
bz8KCgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21h
aWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXSAKU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI2LCAy
MDE1IDEyOjM2IFBNClRvOiBEYXZlIERvbHNvbjsgUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pOyBS
b24gUGFya2VyOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcKQ2M6
IEJlbiBXcmlnaHQgKEJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb20pClN1YmplY3Q6IFJlOiBbc2Zj
XSBkcmFmdC1xdWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHMKClBlcnNvbmFsbHks
IEkgd291bGQgcHJlZmVyIHRoYXQgdGhlIGZpcmV3YWxsIHVzZSBtZXRhZGF0YSByYXRoZXIgdGhh
biAKcGF0aC1pbmRleC7CoCBNeSByZWFzb25pbmcgaXMgdGhhdCBpZiBmdW5jdGlvbnMgZ2V0IGFk
ZGVkIGJlZm9yZSBvciBhZnRlciAKdGhlIGZpcmV3YWxsLCBvcGVyYXRpb25zIHdvdWxkIHByZWZl
ciBub3QgdG8gaGF2ZSB0byBjaGFuZ2UgdGhlIApjb25maWd1cmF0aW9uIG9mIHRoZSBmaXJld2Fs
bCBTRiBpdHNlbGYuCgpIYXZpbmcgc2FpZCB0aGF0LCBJIGRvbid0IHNlZSBhbnkgd2F5IHRvIHN0
b3AgeW91IGZyb20gdXNpbmcgdGhlIHBhdGggaW5kZXguCgpZb3VycywKSm9lbAoKT24gMi8yNi8x
NSAxMjozMCBQTSwgRGF2ZSBEb2xzb24gd3JvdGU6Cj4gRm9yIHRoZSBzYWtlIG9mIGFyZ3VtZW50
LCBzdXBwb3NlIEkgaGF2ZSBhIGZpcmV3YWxsIFNGLCBhbmQgSSB3YW50IHRvIHVzZQo+IGl0IG1v
cmUgdGhhbiBvbmNlIGluIGEgY2hhaW4uIChNYXliZSBJIHdhbnQgdG8gYm9vay1lbmQgdGhlIGNo
YWluIHdpdGggaW5ncmVzcwo+IGFuZCBlZ3Jlc3MgcnVsZXMuKQo+Cj4gRG8geW91IGFncmVlIGl0
IHdvdWxkIGJlIHN1ZmZpY2llbnQgdG8gdXNlIHRoZSBQYXRoIEluZGV4IHRvIHNlbGVjdCB3aGlj
aCBvZgo+IHRoZSBpbmdyZXNzIG9yIGVncmVzcyBydWxlIHNldHMgc2hvdWxkIGJlIHVzZWQ/Cj4K
PiBJJ20gcHJvYmFibHkgbWlzc2luZyBzb21ldGhpbmc7IEkgZG9uJ3QgdW5kZXJzdGFuZCBob3cg
dGhlIGNvbnRleHQgaGVhZGVycwo+IGRlZmluZSBmdW5jdGlvbmFsaXR5LiBNYXliZSB0aGUgZGV2
aWNlIGNvdWxkIGNvbW11bmljYXRlIHdpdGggaXRzZWxmCj4gKGUuZy4sIHRoZSBpbmdyZXNzIHBv
cnRpb24gc2VuZGluZyBhIHRhZyB0byB0aGUgZWdyZXNzIHBvcnRpb24pCj4gYnkgc2VuZGluZyBz
dGF0ZSBpbiB0aGUgcGFja2V0LiBJcyB0aGF0IHdoYXQgeW91IGFyZSBtZWFuIGJ5ICJjb250ZXh0
dWFsIGluZm8iID8KPgo+Cj4KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206IFJl
aW5hbGRvIFBlbm5vIChyZXBlbm5vKSBbbWFpbHRvOnJlcGVubm9AY2lzY28uY29tXQo+IFNlbnQ6
IFRodXJzZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAxMjoxOCBQTQo+IFRvOiBEYXZlIERvbHNvbjsg
Um9uIFBhcmtlcjsgSm9lbCBNLiBIYWxwZXJuOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t
OyBzZmNAaWV0Zi5vcmcKPiBDYzogQmVuIFdyaWdodCAoQmVuLldyaWdodEBtZXRhc3dpdGNoLmNv
bSkKPiBTdWJqZWN0OiBSZTogW3NmY10gZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBT
RiBTcGlyYWxzCj4KPiBBZ3JlZWQgb24gYWxsIHBvaW50cy4gSSB0aG91Z2h0IEkgd2FzIG1pc3Np
bmcgc29tZXRoaW5nIHNvIGJlZm9yZSB3cml0aW5nCj4gdGhpcyBlbWFpbCBJIHJldGVzdGVkIG91
ciBpbXBsZW1lbnRhdGlvbiBhbmQgaXQgd29ya2VkIG9mZiB0aGUgYmF0LiBUaGUKPiBSU1AgY29u
c3RydWN0ZWQgaGFzIHRoZSB0aGUgc2FtZSAoU0ZGLCBTRikgdHVwbGUgYnV0IGRpZmZlcmVudCBp
bmRleGVzLgo+Cj4gVGhlIHNhbWUgU0YgaXMgdmlzaXRlZCBtdWx0aXBsZSB0aW1lcyB1bnRpbCB0
aGUgcGF0aCBlbmRzLsKgIElmIHRoZSBTRgo+IHdhbnRzIGNvbnRleHR1YWwgaW5mbyBhY3Jvc3Mg
dmlzaXRzIHRoYW4gY29udGV4dCBoZWFkZXJzIGFyZSB0aGUgd2F5IHRvCj4gZ28uCj4KPgo+IE9u
IDIvMjYvMTUsIDg6NTIgQU0sICJEYXZlIERvbHNvbiIgPGRkb2xzb25Ac2FuZHZpbmUuY29tPiB3
cm90ZToKPgo+PiBNYXliZSBuYWl2ZWx5LCBJIHRob3VnaHQgdGhlIHNlcnZpY2UgZnVuY3Rpb25z
IHdvdWxkIGJlIHByb3Zpc2lvbmVkIHdpdGgKPj4gYSB0YWJsZToKPj4KPj4gRS5nLiwgZm9yIGVs
ZW1lbnQgZm9vOgo+PiBQYXRoIHwgUGF0aCBJbmRleCB8IE5leHQgSG9wwqAgfCBGdW5jdGlvbgo+
PiAxMjMgfMKgIDTCoMKgwqDCoMKgwqDCoMKgIHzCoMKgIFNGLWJhcsKgIHwgZmlyc3QgYmVoYXZp
b3IKPj4gMTIzIHzCoCAywqDCoMKgwqDCoMKgwqDCoCB8IFNGLWZvb2JhciB8IHNlY29uZCBiZWhh
dmlvcgo+Pgo+Pgo+PiBUaGUgRnVuY3Rpb24gaXMgY2xlYXJseSBpbXBsZW1lbnRhdGlvbiBzcGVj
aWZpYy4gTWF5YmUgaXQgcG9pbnRzIHRvIGEKPj4gY29uZmlndXJhdGlvbiBzZXQgb3IgYSBwb2xp
Y3kgc2V0LiBJIHRoaW5rIGNvbXBsZXRlbHkgb3V0IG9mIHNjb3BlIGhlcmUuCj4+Cj4+IEkgc3Vn
Z2VzdCB0aGF0IHRoaXMgaXMgbm90IGEgcHJvYmxlbSBmb3IgdGhlIHdpcmUgcHJvdG9jb2wsIHJh
dGhlciBmb3IKPj4gdGhlIGNvbmZpZ3VyYXRpb24gbW9kZWwgKG5ldGNvbmYgb3Igd2hhdGV2ZXIp
Lgo+Pgo+PiBJdCBiZWNvbWVzIHZlcnkgbXVjaCB2ZW5kb3Itc3BlY2lmaWMgaWYgdGhlIGJlaGF2
aW9ycyBhcmUgY29tcGxleAo+PiBjb25maWd1cmF0aW9ucyBvZiBzcGVjaWFsaXplZCBmZWF0dXJl
cy4KPj4KPj4gSWYgYSBwZXJzb24gd2VyZSBtYW51YWxseSBjb25maWd1cmluZyBjaGFpbnMsIEkg
ZG9uJ3QgdGhpbmsgdGhleSdkIGhhdmUgYQo+PiBjb25jZXB0dWFsIHByb2JsZW0sIGJlY2F1c2Ug
dGhleSdkIGhhdmUgYSBkaWFncmFtIHRoZXkgbmVlZCB0byBpbXBsZW1lbnQ6Cj4+IHtTRi1mb28g
KGZpcnN0LWJlaGF2aW9yKSwgU0YtYmFyLCBTRi1mb28gKHNlY29uZC1iZWhhdmlvciksIFNGLWZv
b2Jhcn0KPj4KPj4gSWYgd2Ugd2FudGVkIHRvIHN0YW5kYXJkaXplIGl0LCB3ZSBjb3VsZCBtYXli
ZSBtYWtlIHRoZSBGdW5jdGlvbiBzaW1wbHkgYQo+PiBsYWJlbCB0aGF0IG1lYW5zIHNvbWV0aGlu
ZyB0byB0aGUgZGV2aWNlLS1hbiBpbmRpcmVjdGlvbiB0byBhCj4+IGNvbmZpZ3VyYXRpb24gc2V0
Lgo+Pgo+PiAtRGF2ZQo+Pgo+Pgo+Pgo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+PiBG
cm9tOiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbiBQ
YXJrZXIKPj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE1IDExOjMxIEFNCj4+IFRv
OiBEYXZlIERvbHNvbjsgSm9lbCBNLiBIYWxwZXJuOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2Uu
Y29tOwo+PiBzZmNAaWV0Zi5vcmcKPj4gQ2M6IEJlbiBXcmlnaHQgKEJlbi5XcmlnaHRAbWV0YXN3
aXRjaC5jb20pCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBkcmFmdC1xdWlubi1zZmMtbnNoOiBTdXBw
b3J0IG9mIFNGIFNwaXJhbHMKPj4KPj4gSGksIERhdmUuCj4+Cj4+IEkgYWdyZWUgdGhhdCBvbiB0
aGUgd2lyZSwgdGhpcyBpcyB0aGUgd2F5IGl0IHdvdWxkIHdvcmsuCj4+Cj4+IEJ1dCwgd2hlbiBj
b21wb3NpbmcgdGhlIGNoYWluLCBpdCBzZWVtcyBsaWtlIGluZm9ybWF0aW9uIHdvdWxkIGJlIGxh
Y2tpbmcKPj4gaWYgYSBjaGFpbiB3ZXJlIGV4cHJlc3NlZCBzaW1wbHkgYXMge1NGLWZvbywgU0Yt
YmFyLCBTRi1mb28sIFNGLWZvb2Jhcn0uCj4+wqDCoCBJdCBpcyBjb21wbGV0ZWx5IGltcGxpY2l0
IHRoYXQgc2luY2UgU0YtZm9vIGFwcGVhcnMgdHdpY2UsIGl0IHBlcmhhcHMKPj4gc2hvdWxkIHBl
cmZvcm0gc29tZSBkaWZmZXJlbnQgZHV0eSB3aGVuIGluZGV4ID0gMCB2cyB3aGVuIGluZGV4ID0g
Mi4KPj4KPj4gQXQgZmlyc3QsIEkgdGhvdWdodCB0aGF0IGFuIGFsdGVybmF0aXZlIHdheSB0byBo
YW5kbGUgdGhpcyB3b3VsZCBiZSB0bwo+PiB1c2UgbXVsdGlwbGUgbG9naWNhbCBpZGVudGl0aWVz
IGZvciBTRi1mb28uwqAgSW4gdGhpcyBjYXNlLCB0aGUgY2hhaW4KPj4gYWJvdmUgd291bGQgYmUg
ZXhwcmVzc2VkIGFzIHtTRi1mb28tZmlyc3QtYmVoYXZpb3IsIFNGLWJhciwKPj4gU0YtZm9vLXNl
Y29uZC1iZWhhdmlvciwgU0YtZm9vYmFyfS7CoMKgIEJ1dCwgdGhlIHByb2JsZW0gaGVyZSBpcyBz
ZWxlY3RpbmcKPj4gdGhlIFJTUCwgYXNzdW1pbmcgdGhhdCBTRi1mb28gaGFzIG11bHRpcGxlIGlu
c3RhbmNlcy7CoMKgIE5vdGhpbmcgaW4gdGhpcwo+PiBzZWNvbmQgZmxhdm9yIG9mIGNoYWluIHNh
eXMgdGhhdCB0aGUgc2FtZSBpbnN0YW5jZSBvZiBTRi1mb28tKiBtdXN0IGJlCj4+IHNlbGVjdGVk
IHRvIHNhdGlzZnkgU0YtZm9vLWZpcnN0LWJlaGF2aW9yIGFuZCBTRi1mb28tc2Vjb25kLWJlaGF2
aW9yCj4+ICh3aGljaCBtYXkgbm90IGJlIHJlcXVpcmVkLCBidXQgc2hvdWxkIGJlIHBvc3NpYmxl
IHRvIGZvcmNlIGFzIHN1Y2gpLgo+Pgo+PiBJIGd1ZXNzIHdoYXQgSSdtIHNheWluZyBpcyB0aGF0
IHNwaXJhbGluZyBoYXMgYSBzdWJ0bGV0eSB0byBpdCB0aGF0IGlzbid0Cj4+IHlldCBhZGVxdWF0
ZWx5IGFkZHJlc3NlZCBhbmQgdGhhdCBJIGRvbid0IGhhdmUgYSBzcGVjaWZpYyBwcm9wb3NhbCB0
bwo+PiBzb2x2ZSBpdCwgZWl0aGVyLgo+Pgo+PsKgwqDCoCBSb24KPj4KPj4KPj4gLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0KPj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5v
cmddIE9uIEJlaGFsZiBPZiBEYXZlIERvbHNvbgo+PiBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkg
MjYsIDIwMTUgMTE6MjEgQU0KPj4gVG86IEpvZWwgTS4gSGFscGVybjsgbW9oYW1lZC5ib3VjYWRh
aXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnCj4+IENjOiBCZW4gV3JpZ2h0IChCZW4uV3JpZ2h0
QG1ldGFzd2l0Y2guY29tKQo+PiBTdWJqZWN0OiBSZTogW3NmY10gZHJhZnQtcXVpbm4tc2ZjLW5z
aDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzCj4+Cj4+IElmIEkgbWF5IHRyeSB0byBwdXQgaXQgc2lt
cGx5LCBJJ3ZlIGFsd2F5cyB0aG91Z2h0IG9mIGl0IHRoaXMgd2F5Ogo+PiAtLT4gRWFjaCBub2Rl
IGluIHRoZSBjaGFpbiBzZWxlY3RzIHRoZSBjb250ZXh0IGZvciBwcm9jZXNzaW5nIGFuZCB0aGUK
Pj4gbmV4dCBob3Agb24gdGhlIGJhc2lzIG9mIEJPVEggcGF0aCBJRCBhbmQgSW5kZXgsIHdoaWxl
IGRlY3JlbWVudGluZyB0aGUKPj4gaW5kZXggZm9yIHRoZSBuZXh0IGhvcC4KPj4KPj4gVGhhdCBi
ZWhhdmlvciBzdXBwb3J0cyBzcGlyYWxpbmcuCj4+Cj4+Cj4+Cj4+IC1EYXZlCj4+Cj4+Cj4+IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCj4+IEZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2Vz
QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJuCj4+IFNlbnQ6IFRodXJzZGF5
LCBGZWJydWFyeSAyNiwgMjAxNSAxMDowMiBBTQo+PiBUbzogbW9oYW1lZC5ib3VjYWRhaXJAb3Jh
bmdlLmNvbTsgc2ZjQGlldGYub3JnCj4+IENjOiBCZW4gV3JpZ2h0IChCZW4uV3JpZ2h0QG1ldGFz
d2l0Y2guY29tKQo+PiBTdWJqZWN0OiBSZTogW3NmY10gZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3Vw
cG9ydCBvZiBTRiBTcGlyYWxzCj4+Cj4+IFRoZXJlIGFyZSB0d28gZGlmZmVyZW50IGFzcGVjdHMg
b2YgU3BpcmFscy4KPj4KPj4gT25lIG9mIHRoZSB0d28gYXNwZWN0cyBpcyBlbmFibGluZyBhIHBh
Y2tldCB0aGF0IHJlcGVhdGVkbHkgYXJyaXZlcyBhdAo+PiB0aGUgc2FtZSBTRkYgdG8gZ2V0IHRo
ZSBjb3JyZWN0IHNlcnZpY2VzIHByb3ZpZGVkIGVhY2ggdGltZSBpdCBhcnJpdmVzLAo+PiBhbmQg
dG8gZ28gdG8gdGhlIGNvcnJlY3QgbmV4dCBTRkYgZWFjaCB0aW1lIGl0IGFycml2ZXMuwqAgVGhl
IFNlcnZpY2UgUGF0aAo+PiBJbmRleCwgdXNlZCBieSB0aGUgU0ZGIHRvIHNlbGVjdCBzZXJ2aWNl
IGZ1bmN0aW9ucyBhbmQgbmV4dCBTRkYsIHByb3ZpZGVzCj4+IHRoYXQgY2FwYWJpbGl0eS4KPj4K
Pj4gVGhlIG90aGVyIGFzcGVjdCBpcyBob3cgdGhlIFNlcnZpY2UgRnVuY3Rpb25zIHRoZW1zZWx2
ZXMgaGFuZGxlIHNwaXJhbHMuCj4+wqDCoCBUbyBhIGxhcmdlIGRlZ3JlZSwgdGhhdCBkZXBlbmRz
IHVwb24gdGhlIGluZGl2aWR1YWwgc2VydmljZSBmdW5jdGlvbi4KPj7CoMKgIEkgbm9ybWFsbHkg
YXNzdW1lIHRoYXQgaXQgd291bGQgdXNlIHBhY2tldCBjb250ZXh0IChhcyBkZXNjcmliZWQgaW4g
dGhlCj4+IHRleHQgeW91IHF1b3RlKSB0byBkZXRlcm1pbmUgd2hhdCB0byBkby4KPj4KPj4gU2lu
Y2UgSSB3b3VsZCBwcmVmZXIgdGhhdCBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUgaW5kZXBlbmRlbnQg
b2YgdGhlCj4+IHVuZGVybHlpbmcgc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBpbmZyYXN0cnVj
dHVyZSwgYW5kIGFyZSBub3QKPj4gc2Vuc2l0aXZlIHRvIGhvdyBtYW55IGZ1bmN0aW9ucyBhcmUg
YmVmb3JlIG9yIGFmdGVyIHRoZW0gaW4gdGhlIGNoYWluLCBJCj4+IHdvdWxkIHBlcnNvbmFsbHkg
cHJlZmVyIHRoYXQgdGhleSBub3QgdXNlIHRoZSBwYXRoIGluZGV4IGZvciB0aGF0LsKgIEkKPj4g
d291bGQgcmVjb21tZW5kIHRoYXQgaWYgdGhlIHBhY2tldCBkb2VzIG5vdCBjYXJyeSBlbm91Z2gg
Y29udGV4dCB0aGF0IHRoZQo+PiBzZXJ2aWNlIGZ1bmN0aW9uIGNvdWxkIGFuZCBzaG91bGQgdXNl
IG1ldGFkYXRhIHRvIGNhcnJ5IGl0cyBuZWVkZWQgc3RhdGUKPj4gaW5mb3JtYXRpb24uwqAgQnV0
IG5laXRoZXIgSSBwZXJzb25hbGx5IG5vciB0aGUgU0ZDIFdvcmtpbmcgR3JvdXAgZ2V0IHRvCj4+
IHRlbGwgZm9sa3MgaG93IHRvIGJ1aWxkIHRoZWlyIHNlcnZpY2UgZnVuY3Rpb25zLsKgIFNvIHRo
ZXkgbWF5IGNvbWUgdXAKPj4gd2l0aCBvdGhlciBtZXRob2RzIGZvciBhZGRyZXNzaW5nIHRoZWly
IG5lZWRzLsKgIFdoaWNoIGlzIGFsc28gZmluZS4KPj4KPj4gVGh1cywgSSB3b3VsZCBub3QgZXhw
ZWN0IHRoaXMgZG9jdW1lbnQgdG8gZGlzY3VzcyBob3cgc2VydmljZSBmdW5jdGlvbnMKPj4gdGhl
bXNlbHZlcyBoYW5kbGUgcmV2aXNpdGluZy7CoCBCdXQgbWV0YWRhdGEgY2xlYXJseSBhbGxvd3Mg
Zm9yIGEgcmFuZ2Ugb2YKPj4gYmVoYXZpb3JzIHRoYXQgd2lsbCB3b3JrLsKgIEFuZCB0aGUgcGF0
aCBpbmRleCBoYW5kbGVzIHRoZSBTRkYgbmVlZHMKPj4gcmVsYXRpdmUgdG8gc3BpcmFscywgd2hp
Y2ggaXMgd2hhdCB3ZSBuZWVkIHRvIGhhbmRsZS4KPj4KPj4gWW91cnMsCj4+IEpvZWwKPj4KPj4g
T24gMi8yNi8xNSA5OjUyIEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOgo+
Pj4gUmUtLAo+Pj4KPj4+IFNwaXJhbCBpcyBub3QgbWVudGlvbmVkIGluIHRoZSBkcmFmdCwgYnV0
IFNGIGxvb3AgaXMuCj4+Pgo+Pj4gSSdtIGFza2luZyB0aGUgcXVlc3Rpb24gYmVjYXVzZSBJIGRv
bid0IGdldCBmcm9tIHRoZSBkcmFmdCBob3cgc3BpcmFscwo+Pj4gY291bGQgd29yayAodGhhdCBp
cyBhIFNGIGludm9rZWQgc2V2ZXJhbCB0aW1lIGluIHRoZSBjb250ZXh0IG9mIHRoZSBzYW1lCj4+
PiBTRkMpLgo+Pj4KPj4+IEJlZm9yZSBwcm9wb3NpbmcgdGV4dCwgSSB3b3VsZCBsaWtlIHRvIHVu
ZGVyc3RhbmQgZmlyc3QgaG93IGl0IHdvcmtzLgo+Pj4gSWYgeW91IGNhbiBwcm92aWRlIGFuIGV4
YW1wbGUsIHRoaXMgd2lsbCBiZSBldmVuIGdyZWF0Lgo+Pj4KPj4+IFRoYW5rIHlvdS4KPj4+Cj4+
PiBDaGVlcnMsCj4+PiBNZWQKPj4+Cj4+Pj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tCj4+
Pj4gRGUgOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9lbGhhbHBlcm4uY29tXSBFbnZv
ecOpIDogamV1ZGkgMjYKPj4+PiBmw6l2cmllciAyMDE1IDE1OjQxIMOAIDogQk9VQ0FEQUlSIE1v
aGFtZWQgSU1UL09MTjsgc2ZjQGlldGYub3JnIENjIDoKPj4+PiBCZW4gV3JpZ2h0IChCZW4uV3Jp
Z2h0QG1ldGFzd2l0Y2guY29tKSBPYmpldCA6IFJlOiBbc2ZjXQo+Pj4+IGRyYWZ0LXF1aW5uLXNm
Yy1uc2g6IFN1cHBvcnQgb2YgU0YgU3BpcmFsc2d0Oz4+PgoKPj4+PiBUaGUgU0YgU3BpcmFscyBy
ZXF1aXJlbWVudCBpcyBvbmUgb2YgdGhlIGtleSBkcml2ZXJzIGZvciB0aGUgaW5kZXguCj4+Pj4g
VGhlIGluZGV4IGFsbG93cyBvbmUgdG8gdGVsbCB3aGVyZSBvbmUgaXMgaW4gdGhlIHNwaXJhbCwg
YW5kIGFsc28gdG8KPj4+PiBicmVhayBhIGxvb3AgaWYgb25lIGhhcyBhIGxvb3AgaW5zdGVhZCBv
ZiBhIHNwaXJhbC4KPj4+Pgo+Pj4+IElzIHRoZXJlIHRleHQgdGhhdCB3ZSBjb3VsZCBhZGQgdGhh
dCB3b3VsZCBoZWxwIG1ha2UgdGhpcyBjbGVhciwKPj4+PiBzaW5jZSB5b3VyIGVhcmxpZXIgcXVl
c3Rpb24gYWJvdXQgdGhlIHBhdGggaW5kZXggc3VnZ2VzdHMgdGhhdCBpdCBpcwo+Pj4+IG5vdCBh
cyBjbGVhciBhcyBpdCBzaG91bGQgYmU/Cj4+Pj4KPj4+PiBZb3VycywKPj4+PiBKb2VsCj4+Pj4K
Pj4+PiBPbiAyLzI2LzE1IDg6NDIgQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3Jv
dGU6Cj4+Pj4+IEhpIFBhdWwsIGFsbCwKPj4+Pj4KPj4+Pj4gVGhlcmUgd2VyZSBhIGRpc2N1c3Np
b24gaW4gdGhlIG1haWxpbmcgbGlzdAo+Pj4+PiAoaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy
Y2hpdmUvd2ViL3NmYy9jdXJyZW50L21zZzAxNzAxLmh0bWwpCj4+Pj4+IHRoYXQgbGVkIHRvIGRl
ZmluaW5nIHdoYXQgaXMgbWVhbnQgYnkgU0YgU3BpcmFsczogKGJlbG93IGlzIHByb3ZpZGVkCj4+
Pj4+IGFuIGV4Y2VycHQgZnJvbQo+Pj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm
dC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wNiB3aGVyZQo+Pj4+PiB0aGUgY29uY2x1c2lv
bnMgb2YgdGhhdCBkaXNjdXNzaW9uIHdlcmUgcmVjb3JkZWQpCj4+Pj4+Cj4+Pj4+ICLCoMKgIG/C
oCBTZXJ2aWNlIEZ1bmN0aW9uIFNwaXJhbDogZGVub3RlcyBhIFNlcnZpY2UgRnVuY3Rpb24gQ2hh
aW4gaW4KPj4+PiB3aGljaAo+Pj4+Pgo+Pj4+PsKgwqDCoMKgwqDCoMKgwqDCoCBkYXRhIGlzIGhh
bmRsZWQgYnkgYSBTZXJ2aWNlIEZ1bmN0aW9uLCBmb3J3YXJkZWQgb253YXJkcywKPj4+Pj4gYW5k
Cj4+Pj4+Cj4+Pj4+wqDCoMKgwqDCoMKgwqDCoMKgIGFycml2ZXMgb25jZSBhZ2FpbiBhdCB0aGF0
IFNlcnZpY2UgRnVuY3Rpb24uCj4+Pj4+Cj4+Pj4+wqDCoMKgwqDCoMKgwqDCoMKgICrCoCBOb3Rl
IHRoYXQgc29tZSBTZXJ2aWNlIEZ1bmN0aW9ucyBzdXBwb3J0IGJ1aWx0LWluCj4+Pj4+IGZ1bmN0
aW9ucyB0bwo+Pj4+Pgo+Pj4+PsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBhY2NvbW1vZGF0ZSBz
cGlyYWxzOyB0aGVzZSBzZXJ2aWNlLXNwZWNpZmljIGZ1bmN0aW9ucyBtYXkKPj4+Pj4KPj4+Pj7C
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgcmVxdWlyZSB0aGF0IHRoZSBkYXRhIHJlY2VpdmVkIGlu
IGEgc3BpcmFsIHNob3VsZCBkaWZmZXIKPj4+Pj4gaW4gYQo+Pj4+Pgo+Pj4+PsKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoCB3YXkgdGhhdCB3aWxsIHJlc3VsdCBpbiBhIGRpZmZlcmVudCBwcm9jZXNz
aW5nIGRlY2lzaW9uCj4+Pj4+IHRoYW4KPj4+Pj4KPj4+Pj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqAgdGhlIG9yaWdpbmFsIGRhdGEuwqAgVGhpcyBkb2N1bWVudCBkb2VzIG5vdCBtYWtlIHN1Y2gK
Pj4+Pj4KPj4+Pj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgYXNzdW1wdGlvbi4KPj4+Pj4KPj4+
Pj7CoMKgwqDCoMKgwqDCoMKgwqAgKsKgIEEgU2VydmljZSBGdW5jdGlvbiBDaGFpbiBtYXkgaW52
b2x2ZSBvbmUgb3IgbW9yZSBTZXJ2aWNlCj4+Pj4+Cj4+Pj4+wqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgIEZ1bmN0aW9uIFNwaXJhbHMuCj4+Pj4+Cj4+Pj4+wqDCoMKgwqDCoMKgwqDCoMKgICrCoCBV
bmxpa2UgU2VydmljZSBGdW5jdGlvbiBsb29wLCBzcGlyYWxzIGFyZSBub3QgY29uc2lkZXJlZAo+
Pj4+PiBhcwo+Pj4+Pgo+Pj4+PsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBlcnJvcnMuIgo+Pj4+
Pgo+Pj4+PiBBbmQgdGhpcyBjb21wYW5pb24gcmVxdWlyZW1lbnQ6Cj4+Pj4+Cj4+Pj4+ICLCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIEEuwqAgU2VydmljZSBGdW5jdGlvbnMgTUFZIGJlIGlu
dm9rZWQgbXVsdGlwbGUgdGltZXMgaW4KPj4+Pj4KPj4+Pj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB0aGUgc2FtZSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluIChk
ZW5vdGVkIGFzIFNGCj4+Pj4+Cj4+Pj4+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqAgU3BpcmFsKSwgYnV0IHRoZSBzb2x1dGlvbiBNVVNUIHByZXZlbnQgaW5maW5p
dGUKPj4+Pj4KPj4+Pj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oCBmb3J3YXJkaW5nIGxvb3BzLiDCuwo+Pj4+Pgo+Pj4+PiBSZWFkaW5nIHRoZSBjdXJyZW50IGRy
YWZ0LXF1aW5uLXNmYy1uc2gsIEkgZG9uJ3Qgc2VlIGhvdyB0aGlzIGlzIG1ldC4KPj4+Pj4KPj4+
Pj4gQ2FuIHlvdSBwbGVhc2UgY2xhcmlmeSB3aGV0aGVyIHRoaXMgaXMgc3VwcG9ydGVkIGFuZCBo
b3c/Cj4+Pj4+Cj4+Pj4+IFRoYW5rIHlvdS4KPj4+Pj4KPj4+Pj4gQ2hlZXJzLAo+Pj4+Pgo+Pj4+
PiBNZWQKPj4+Pj4KPj4+Pj4KPj4+Pj4KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KPj4+Pj4gc2ZjIG1haWxpbmcgbGlzdAo+Pj4+PiBzZmNAaWV0
Zi5vcmcKPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMKPj4+
Pj4KPj4+Cj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fCj4+IHNmYyBtYWlsaW5nIGxpc3QKPj4gc2ZjQGlldGYub3JnCj4+IGh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjCj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fCj4+IHNmYyBtYWlsaW5nIGxpc3QKPj4gc2ZjQGlldGYu
b3JnCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjCj4+Cj4+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4+IHNmYyBtYWls
aW5nIGxpc3QKPj4gc2ZjQGlldGYub3JnCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vc2ZjCj4+Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fCj4+IHNmYyBtYWlsaW5nIGxpc3QKPj4gc2ZjQGlldGYub3JnCj4+IGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjCj4KPg==

----_com.android.email_160550734879705
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0
L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT5UaGUgZmlyZWF3YWxsIHNldHMgdGhl
IG1ldGFkYXRhIGZvciB0Z2UgZmlyZXdhbGwgdG8gdXNlLiAmbmJzcDtUaGUgYWJzZW5jZSBvZiB0
aGUgbWV0YWRhdGEgc2VydmVzIGFzIHRoZSBpbmRpY2F0b3IgdGhhdCB0aGlzIGlzIHRoZSBmaXJz
dCB0aW1lLiAmbmJzcDtSdWxlcyBmb3IgdGhpcyBzb3J0IG9mIHRoaW5nIGFyZSBzZXQgLyBhZ3Jl
ZWQgYnkgdGhlc2VydmljZSBmdW5jdGlvbnMuICZuYnNwO1RoYXQgaXMgb3V0IG9mIHNjb3BlIGZv
ciB0aGUgd29ya2luZyBncm91cCBidXQgd2VlayBjYW4gcHJvdmlkZSBhIHJlZ2lzdHJ5IHRvIGhl
bHAuPGRpdj48YnI+PC9kaXY+PGRpdj5Db250cm9sIGlzIHByb2JhYmx5IGJ5IGFwcGxpY2F0aW9u
IHByb3Zpc2lvbmluZyBvciBvdGhlciBjb250cm9sIHByb3RvY29scy4gJm5ic3A7V2UgbWlnaHQg
d2FudCB0byB3b3JrIG9uIHRoYXQgc3BhY2Ugb25jZSB3ZSBmaW5pc2ggb3VyIGRlbGl2ZXJhYmxl
cy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PllvdXJzLDwvZGl2PjxkaXY+Sm9lbDxicj48YnI+
PGJyPjxzcGFuIHN0eWxlPSJmb250LXNpemU6ODclIj5TZW50IGZyb20gbXkgU2Ftc3VuZyBzbWFy
dHBob25lIG9uIEFUJmFtcDtUPC9zcGFuPiA8L2Rpdj48YnI+PGJyPjxicj4tLS0tLS0tLSBPcmln
aW5hbCBtZXNzYWdlIC0tLS0tLS0tPGJyPlN1YmplY3Q6IFJFOiBbc2ZjXSBkcmFmdC1xdWlubi1z
ZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHMgPGJyPkZyb206IERhdmUgRG9sc29uICZsdDtk
ZG9sc29uQHNhbmR2aW5lLmNvbSZndDsgPGJyPlRvOiAiSm1oLmRpcmVjdCIgJmx0O2ptaC5kaXJl
Y3RAam9lbGhhbHBlcm4uY29tJmd0Oywiam1oQGpvZWxoYWxwZXJuLmNvbSIgJmx0O2ptaEBqb2Vs
aGFscGVybi5jb20mZ3Q7LCJyZXBlbm5vQGNpc2NvLmNvbSIgJmx0O3JlcGVubm9AY2lzY28uY29t
Jmd0Oywicm9uX3BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbSIgJmx0O3Jvbl9wYXJrZXJAYWZm
aXJtZWRuZXR3b3Jrcy5jb20mZ3Q7LCJtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiAmbHQ7
bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSZndDssInNmY0BpZXRmLm9yZyIgJmx0O3NmY0Bp
ZXRmLm9yZyZndDsgPGJyPkNDOiAiYmVuLndyaWdodEBtZXRhc3dpdGNoLmNvbSIgJmx0O2Jlbi53
cmlnaHRAbWV0YXN3aXRjaC5jb20mZ3Q7IDxicj48YnI+PGJyPjxkaXYgY2xhc3M9IldvcmRTZWN0
aW9uMSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj
b2xvcjojMUY0OTdEIj5TdXJlLCBidXQgZ29pbmcgZnJvbSB0aGUgZ2VuZXJpYyB0byB0aGUgc3Bl
Y2lmaWMsIHRha2UgbXkgZXhhbXBsZSBvZiB0aGUgZmlyZXdhbGwgd2l0aCBkaWZmZXJlbnQgc2V0
cyBvZiBydWxlcyBkZXBlbmRpbmcgb24gbG9jYXRpb24gaW4gdGhlIGNoYWluLjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJltIGhlYXJpbmcgdGhhdCBtZXRhLWRhdGEgY2FuIGJlIHVz
ZWQgYnkgdGhlIGZpcmV3YWxsIHRvIHNlbGVjdCB3aGljaCBydWxlIHNldCB0byBhcHBseSwgbWVh
bmluZyB0aGUgbWV0YS1kYXRhIGlzIGluc3BlY3RlZCB1cG9uIHBhY2tldCBhcnJpdmFsIGFuZCB1
c2VkIHRvCiBzZWxlY3QgdGhlIHJ1bGUgc2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi
PihJcyB0aGF0IHdoYXQgZm9sa3MgbWVhbnQgdG8gc2F5Pyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyB3aGljaCBlbGVt
ZW50cyBzZXQgdGhlIG1ldGEtZGF0YSBmb3IgdGhlIGZpcmV3YWxsIHRvIHVzZT88bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj5BbmQgd2hpY2ggcnVsZXMgZGV0ZXJtaW5lIHRoZSBtZXRhLWRh
dGEgdmFsdWVzIHRvIGJlIGFwcGxpZWQgYnkgdGhvc2UgZWxlbWVudHM/PG86cD48L286cD48L3Nw
YW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LURhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv
bzpwPjwvc3Bhbj48L3A+CjxkaXY+CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6
c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv
Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm
cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEptaC5kaXJlY3QgW21haWx0bzpqbWguZGly
ZWN0QGpvZWxoYWxwZXJuLmNvbV0KPGJyPgo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5
IDI2LCAyMDE1IDE6MjAgUE08YnI+CjxiPlRvOjwvYj4gRGF2ZSBEb2xzb247IGptaEBqb2VsaGFs
cGVybi5jb207IHJlcGVubm9AY2lzY28uY29tOyByb25fcGFya2VyQGFmZmlybWVkbmV0d29ya3Mu
Y29tOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmc8YnI+CjxiPkNj
OjwvYj4gYmVuLndyaWdodEBtZXRhc3dpdGNoLmNvbTxicj4KPGI+U3ViamVjdDo8L2I+IFJFOiBb
c2ZjXSBkcmFmdC1xdWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHM8YnI+CjxiPklt
cG9ydGFuY2U6PC9iPiBMb3c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjwvZGl2Pgo8L2Rpdj4KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkluc3RydWN0aW9uIGNvbWVzIGZyb20gdGhlIHNldmljZSBmdW5jdGlvbiBkZXNpZ24uICZu
YnNwO1NvbWUgaGVhZGVyIHN0cnVjdHVyZXMgYXVnbWVudCB0aGF0IHdpdGggY29udHJvbCBtYXBw
aW5nIGliZm9ybWF0aW9uIHRvIGluZGljYXRlIHdoaWNoIG1ldGFkYXRhIGZpZWxkIGhhcyB3aGlj
aCB1c2UuPG86cD48L286cD48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R29yIFRMViBi
YXNlZCBtZXRhZGF0IHdlIHByb2JhYmx5IGVhbnQgYSByZWdpc3RyeSB3aXRoIHZlcnkgZWFzeSBl
bnRyeSBjcmVhdGlvbi48bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+WW91cnMsPG86cD48L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5Kb2VsPGJyPgo8YnI+Cjxicj4KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPlNl
bnQgZnJvbSBteSBTYW1zdW5nIHNtYXJ0cGhvbmUgb24gQVQmYW1wO1Q8L3NwYW4+IDxvOnA+Cjwv
bzpwPjwvcD4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t
OjEyLjBwdCI+PGJyPgo8YnI+Cjxicj4KLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0t
LTxicj4KU3ViamVjdDogUkU6IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1uc2g6IFN1cHBvcnQgb2Yg
U0YgU3BpcmFscyA8YnI+CkZyb206IERhdmUgRG9sc29uICZsdDs8YSBocmVmPSJtYWlsdG86ZGRv
bHNvbkBzYW5kdmluZS5jb20iPmRkb2xzb25Ac2FuZHZpbmUuY29tPC9hPiZndDsKPGJyPgpUbzog
IkpvZWwgTS4gSGFscGVybiIgJmx0OzxhIGhyZWY9Im1haWx0bzpqbWhAam9lbGhhbHBlcm4uY29t
Ij5qbWhAam9lbGhhbHBlcm4uY29tPC9hPiZndDssIlJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKSIg
Jmx0OzxhIGhyZWY9Im1haWx0bzpyZXBlbm5vQGNpc2NvLmNvbSI+cmVwZW5ub0BjaXNjby5jb208
L2E+Jmd0OyxSb24gUGFya2VyICZsdDs8YSBocmVmPSJtYWlsdG86Um9uX1BhcmtlckBhZmZpcm1l
ZG5ldHdvcmtzLmNvbSI+Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbTwvYT4mZ3Q7LCI8
YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3Vj
YWRhaXJAb3JhbmdlLmNvbTwvYT4iCiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2Fk
YWlyQG9yYW5nZS5jb20iPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb208L2E+Jmd0OywiPGEg
aHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPiIgJmx0OzxhIGhyZWY9
Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT4mZ3Q7Cjxicj4KQ0M6ICJCZW4g
V3JpZ2h0ICg8YSBocmVmPSJtYWlsdG86QmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbSI+QmVuLldy
aWdodEBtZXRhc3dpdGNoLmNvbTwvYT4pIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkJlbi5XcmlnaHRA
bWV0YXN3aXRjaC5jb20iPkJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb208L2E+Jmd0Owo8YnI+Cjxi
cj4KPG86cD48L286cD48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ3b3Jk
LWJyZWFrOmJyZWFrLWFsbCI+V2hhdCBhcmUgdGhlIG1lY2hhbmljcyBvZiB1c2luZyBtZXRhLWRh
dGE/PGJyPgpXaGljaCBlbGVtZW50IHNldHMgaXQsIGFuZCBob3cgaXMgaXQgaW5zdHJ1Y3RlZCB0
byBkbyBzbz88YnI+Cjxicj4KPGJyPgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4KRnJv
bTogSm9lbCBNLiBIYWxwZXJuIFs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbSI+
bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb208L2E+XQo8YnI+ClNlbnQ6IFRodXJzZGF5LCBGZWJy
dWFyeSAyNiwgMjAxNSAxMjozNiBQTTxicj4KVG86IERhdmUgRG9sc29uOyBSZWluYWxkbyBQZW5u
byAocmVwZW5ubyk7IFJvbiBQYXJrZXI7IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFp
ckBvcmFuZ2UuY29tIj4KbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9
Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+CkNjOiBCZW4gV3JpZ2h0
ICg8YSBocmVmPSJtYWlsdG86QmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbSI+QmVuLldyaWdodEBt
ZXRhc3dpdGNoLmNvbTwvYT4pPGJyPgpTdWJqZWN0OiBSZTogW3NmY10gZHJhZnQtcXVpbm4tc2Zj
LW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzPGJyPgo8YnI+ClBlcnNvbmFsbHksIEkgd291bGQg
cHJlZmVyIHRoYXQgdGhlIGZpcmV3YWxsIHVzZSBtZXRhZGF0YSByYXRoZXIgdGhhbiA8YnI+CnBh
dGgtaW5kZXguJm5ic3A7IE15IHJlYXNvbmluZyBpcyB0aGF0IGlmIGZ1bmN0aW9ucyBnZXQgYWRk
ZWQgYmVmb3JlIG9yIGFmdGVyIDxicj4KdGhlIGZpcmV3YWxsLCBvcGVyYXRpb25zIHdvdWxkIHBy
ZWZlciBub3QgdG8gaGF2ZSB0byBjaGFuZ2UgdGhlIDxicj4KY29uZmlndXJhdGlvbiBvZiB0aGUg
ZmlyZXdhbGwgU0YgaXRzZWxmLjxicj4KPGJyPgpIYXZpbmcgc2FpZCB0aGF0LCBJIGRvbid0IHNl
ZSBhbnkgd2F5IHRvIHN0b3AgeW91IGZyb20gdXNpbmcgdGhlIHBhdGggaW5kZXguPGJyPgo8YnI+
CllvdXJzLDxicj4KSm9lbDxicj4KPGJyPgpPbiAyLzI2LzE1IDEyOjMwIFBNLCBEYXZlIERvbHNv
biB3cm90ZTo8YnI+CiZndDsgRm9yIHRoZSBzYWtlIG9mIGFyZ3VtZW50LCBzdXBwb3NlIEkgaGF2
ZSBhIGZpcmV3YWxsIFNGLCBhbmQgSSB3YW50IHRvIHVzZTxicj4KJmd0OyBpdCBtb3JlIHRoYW4g
b25jZSBpbiBhIGNoYWluLiAoTWF5YmUgSSB3YW50IHRvIGJvb2stZW5kIHRoZSBjaGFpbiB3aXRo
IGluZ3Jlc3M8YnI+CiZndDsgYW5kIGVncmVzcyBydWxlcy4pPGJyPgomZ3Q7PGJyPgomZ3Q7IERv
IHlvdSBhZ3JlZSBpdCB3b3VsZCBiZSBzdWZmaWNpZW50IHRvIHVzZSB0aGUgUGF0aCBJbmRleCB0
byBzZWxlY3Qgd2hpY2ggb2Y8YnI+CiZndDsgdGhlIGluZ3Jlc3Mgb3IgZWdyZXNzIHJ1bGUgc2V0
cyBzaG91bGQgYmUgdXNlZD88YnI+CiZndDs8YnI+CiZndDsgSSdtIHByb2JhYmx5IG1pc3Npbmcg
c29tZXRoaW5nOyBJIGRvbid0IHVuZGVyc3RhbmQgaG93IHRoZSBjb250ZXh0IGhlYWRlcnM8YnI+
CiZndDsgZGVmaW5lIGZ1bmN0aW9uYWxpdHkuIE1heWJlIHRoZSBkZXZpY2UgY291bGQgY29tbXVu
aWNhdGUgd2l0aCBpdHNlbGY8YnI+CiZndDsgKGUuZy4sIHRoZSBpbmdyZXNzIHBvcnRpb24gc2Vu
ZGluZyBhIHRhZyB0byB0aGUgZWdyZXNzIHBvcnRpb24pPGJyPgomZ3Q7IGJ5IHNlbmRpbmcgc3Rh
dGUgaW4gdGhlIHBhY2tldC4gSXMgdGhhdCB3aGF0IHlvdSBhcmUgbWVhbiBieSAiY29udGV4dHVh
bCBpbmZvIiA/PGJyPgomZ3Q7PGJyPgomZ3Q7PGJyPgomZ3Q7PGJyPgomZ3Q7IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tPGJyPgomZ3Q7IEZyb206IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKSBb
PGEgaHJlZj0ibWFpbHRvOnJlcGVubm9AY2lzY28uY29tIj5tYWlsdG86cmVwZW5ub0BjaXNjby5j
b208L2E+XTxicj4KJmd0OyBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjYsIDIwMTUgMTI6MTgg
UE08YnI+CiZndDsgVG86IERhdmUgRG9sc29uOyBSb24gUGFya2VyOyBKb2VsIE0uIEhhbHBlcm47
IDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIj4KbW9oYW1lZC5i
b3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNm
Y0BpZXRmLm9yZzwvYT48YnI+CiZndDsgQ2M6IEJlbiBXcmlnaHQgKDxhIGhyZWY9Im1haWx0bzpC
ZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tIj5CZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tPC9hPik8
YnI+CiZndDsgU3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1uc2g6IFN1cHBvcnQg
b2YgU0YgU3BpcmFsczxicj4KJmd0Ozxicj4KJmd0OyBBZ3JlZWQgb24gYWxsIHBvaW50cy4gSSB0
aG91Z2h0IEkgd2FzIG1pc3Npbmcgc29tZXRoaW5nIHNvIGJlZm9yZSB3cml0aW5nPGJyPgomZ3Q7
IHRoaXMgZW1haWwgSSByZXRlc3RlZCBvdXIgaW1wbGVtZW50YXRpb24gYW5kIGl0IHdvcmtlZCBv
ZmYgdGhlIGJhdC4gVGhlPGJyPgomZ3Q7IFJTUCBjb25zdHJ1Y3RlZCBoYXMgdGhlIHRoZSBzYW1l
IChTRkYsIFNGKSB0dXBsZSBidXQgZGlmZmVyZW50IGluZGV4ZXMuPGJyPgomZ3Q7PGJyPgomZ3Q7
IFRoZSBzYW1lIFNGIGlzIHZpc2l0ZWQgbXVsdGlwbGUgdGltZXMgdW50aWwgdGhlIHBhdGggZW5k
cy4mbmJzcDsgSWYgdGhlIFNGPGJyPgomZ3Q7IHdhbnRzIGNvbnRleHR1YWwgaW5mbyBhY3Jvc3Mg
dmlzaXRzIHRoYW4gY29udGV4dCBoZWFkZXJzIGFyZSB0aGUgd2F5IHRvPGJyPgomZ3Q7IGdvLjxi
cj4KJmd0Ozxicj4KJmd0Ozxicj4KJmd0OyBPbiAyLzI2LzE1LCA4OjUyIEFNLCAiRGF2ZSBEb2xz
b24iICZsdDs8YSBocmVmPSJtYWlsdG86ZGRvbHNvbkBzYW5kdmluZS5jb20iPmRkb2xzb25Ac2Fu
ZHZpbmUuY29tPC9hPiZndDsgd3JvdGU6PGJyPgomZ3Q7PGJyPgomZ3Q7Jmd0OyBNYXliZSBuYWl2
ZWx5LCBJIHRob3VnaHQgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIHdvdWxkIGJlIHByb3Zpc2lvbmVk
IHdpdGg8YnI+CiZndDsmZ3Q7IGEgdGFibGU6PGJyPgomZ3Q7Jmd0Ozxicj4KJmd0OyZndDsgRS5n
LiwgZm9yIGVsZW1lbnQgZm9vOjxicj4KJmd0OyZndDsgUGF0aCB8IFBhdGggSW5kZXggfCBOZXh0
IEhvcCZuYnNwOyB8IEZ1bmN0aW9uPGJyPgomZ3Q7Jmd0OyAxMjMgfCZuYnNwOyA0Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgU0Yt
YmFyJm5ic3A7IHwgZmlyc3QgYmVoYXZpb3I8YnI+CiZndDsmZ3Q7IDEyMyB8Jm5ic3A7IDImbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCBTRi1mb29iYXIg
fCBzZWNvbmQgYmVoYXZpb3I8YnI+CiZndDsmZ3Q7PGJyPgomZ3Q7Jmd0Ozxicj4KJmd0OyZndDsg
VGhlIEZ1bmN0aW9uIGlzIGNsZWFybHkgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuIE1heWJlIGl0
IHBvaW50cyB0byBhPGJyPgomZ3Q7Jmd0OyBjb25maWd1cmF0aW9uIHNldCBvciBhIHBvbGljeSBz
ZXQuIEkgdGhpbmsgY29tcGxldGVseSBvdXQgb2Ygc2NvcGUgaGVyZS48YnI+CiZndDsmZ3Q7PGJy
PgomZ3Q7Jmd0OyBJIHN1Z2dlc3QgdGhhdCB0aGlzIGlzIG5vdCBhIHByb2JsZW0gZm9yIHRoZSB3
aXJlIHByb3RvY29sLCByYXRoZXIgZm9yPGJyPgomZ3Q7Jmd0OyB0aGUgY29uZmlndXJhdGlvbiBt
b2RlbCAobmV0Y29uZiBvciB3aGF0ZXZlcikuPGJyPgomZ3Q7Jmd0Ozxicj4KJmd0OyZndDsgSXQg
YmVjb21lcyB2ZXJ5IG11Y2ggdmVuZG9yLXNwZWNpZmljIGlmIHRoZSBiZWhhdmlvcnMgYXJlIGNv
bXBsZXg8YnI+CiZndDsmZ3Q7IGNvbmZpZ3VyYXRpb25zIG9mIHNwZWNpYWxpemVkIGZlYXR1cmVz
Ljxicj4KJmd0OyZndDs8YnI+CiZndDsmZ3Q7IElmIGEgcGVyc29uIHdlcmUgbWFudWFsbHkgY29u
ZmlndXJpbmcgY2hhaW5zLCBJIGRvbid0IHRoaW5rIHRoZXknZCBoYXZlIGE8YnI+CiZndDsmZ3Q7
IGNvbmNlcHR1YWwgcHJvYmxlbSwgYmVjYXVzZSB0aGV5J2QgaGF2ZSBhIGRpYWdyYW0gdGhleSBu
ZWVkIHRvIGltcGxlbWVudDo8YnI+CiZndDsmZ3Q7IHtTRi1mb28gKGZpcnN0LWJlaGF2aW9yKSwg
U0YtYmFyLCBTRi1mb28gKHNlY29uZC1iZWhhdmlvciksIFNGLWZvb2Jhcn08YnI+CiZndDsmZ3Q7
PGJyPgomZ3Q7Jmd0OyBJZiB3ZSB3YW50ZWQgdG8gc3RhbmRhcmRpemUgaXQsIHdlIGNvdWxkIG1h
eWJlIG1ha2UgdGhlIEZ1bmN0aW9uIHNpbXBseSBhPGJyPgomZ3Q7Jmd0OyBsYWJlbCB0aGF0IG1l
YW5zIHNvbWV0aGluZyB0byB0aGUgZGV2aWNlLS1hbiBpbmRpcmVjdGlvbiB0byBhPGJyPgomZ3Q7
Jmd0OyBjb25maWd1cmF0aW9uIHNldC48YnI+CiZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyAtRGF2ZTxi
cj4KJmd0OyZndDs8YnI+CiZndDsmZ3Q7PGJyPgomZ3Q7Jmd0Ozxicj4KJmd0OyZndDsgLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+CiZndDsmZ3Q7IEZyb206IHNmYyBbPGEgaHJlZj0ibWFp
bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+
XSBPbiBCZWhhbGYgT2YgUm9uIFBhcmtlcjxicj4KJmd0OyZndDsgU2VudDogVGh1cnNkYXksIEZl
YnJ1YXJ5IDI2LCAyMDE1IDExOjMxIEFNPGJyPgomZ3Q7Jmd0OyBUbzogRGF2ZSBEb2xzb247IEpv
ZWwgTS4gSGFscGVybjsgPGEgaHJlZj0ibWFpbHRvOm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5j
b20iPgptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPjs8YnI+CiZndDsmZ3Q7IDxhIGhy
ZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+CiZndDsmZ3Q7IENj
OiBCZW4gV3JpZ2h0ICg8YSBocmVmPSJtYWlsdG86QmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbSI+
QmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbTwvYT4pPGJyPgomZ3Q7Jmd0OyBTdWJqZWN0OiBSZTog
W3NmY10gZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzPGJyPgomZ3Q7
Jmd0Ozxicj4KJmd0OyZndDsgSGksIERhdmUuPGJyPgomZ3Q7Jmd0Ozxicj4KJmd0OyZndDsgSSBh
Z3JlZSB0aGF0IG9uIHRoZSB3aXJlLCB0aGlzIGlzIHRoZSB3YXkgaXQgd291bGQgd29yay48YnI+
CiZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyBCdXQsIHdoZW4gY29tcG9zaW5nIHRoZSBjaGFpbiwgaXQg
c2VlbXMgbGlrZSBpbmZvcm1hdGlvbiB3b3VsZCBiZSBsYWNraW5nPGJyPgomZ3Q7Jmd0OyBpZiBh
IGNoYWluIHdlcmUgZXhwcmVzc2VkIHNpbXBseSBhcyB7U0YtZm9vLCBTRi1iYXIsIFNGLWZvbywg
U0YtZm9vYmFyfS48YnI+CiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IEl0IGlzIGNvbXBsZXRlbHkgaW1w
bGljaXQgdGhhdCBzaW5jZSBTRi1mb28gYXBwZWFycyB0d2ljZSwgaXQgcGVyaGFwczxicj4KJmd0
OyZndDsgc2hvdWxkIHBlcmZvcm0gc29tZSBkaWZmZXJlbnQgZHV0eSB3aGVuIGluZGV4ID0gMCB2
cyB3aGVuIGluZGV4ID0gMi48YnI+CiZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyBBdCBmaXJzdCwgSSB0
aG91Z2h0IHRoYXQgYW4gYWx0ZXJuYXRpdmUgd2F5IHRvIGhhbmRsZSB0aGlzIHdvdWxkIGJlIHRv
PGJyPgomZ3Q7Jmd0OyB1c2UgbXVsdGlwbGUgbG9naWNhbCBpZGVudGl0aWVzIGZvciBTRi1mb28u
Jm5ic3A7IEluIHRoaXMgY2FzZSwgdGhlIGNoYWluPGJyPgomZ3Q7Jmd0OyBhYm92ZSB3b3VsZCBi
ZSBleHByZXNzZWQgYXMge1NGLWZvby1maXJzdC1iZWhhdmlvciwgU0YtYmFyLDxicj4KJmd0OyZn
dDsgU0YtZm9vLXNlY29uZC1iZWhhdmlvciwgU0YtZm9vYmFyfS4mbmJzcDsmbmJzcDsgQnV0LCB0
aGUgcHJvYmxlbSBoZXJlIGlzIHNlbGVjdGluZzxicj4KJmd0OyZndDsgdGhlIFJTUCwgYXNzdW1p
bmcgdGhhdCBTRi1mb28gaGFzIG11bHRpcGxlIGluc3RhbmNlcy4mbmJzcDsmbmJzcDsgTm90aGlu
ZyBpbiB0aGlzPGJyPgomZ3Q7Jmd0OyBzZWNvbmQgZmxhdm9yIG9mIGNoYWluIHNheXMgdGhhdCB0
aGUgc2FtZSBpbnN0YW5jZSBvZiBTRi1mb28tKiBtdXN0IGJlPGJyPgomZ3Q7Jmd0OyBzZWxlY3Rl
ZCB0byBzYXRpc2Z5IFNGLWZvby1maXJzdC1iZWhhdmlvciBhbmQgU0YtZm9vLXNlY29uZC1iZWhh
dmlvcjxicj4KJmd0OyZndDsgKHdoaWNoIG1heSBub3QgYmUgcmVxdWlyZWQsIGJ1dCBzaG91bGQg
YmUgcG9zc2libGUgdG8gZm9yY2UgYXMgc3VjaCkuPGJyPgomZ3Q7Jmd0Ozxicj4KJmd0OyZndDsg
SSBndWVzcyB3aGF0IEknbSBzYXlpbmcgaXMgdGhhdCBzcGlyYWxpbmcgaGFzIGEgc3VidGxldHkg
dG8gaXQgdGhhdCBpc24ndDxicj4KJmd0OyZndDsgeWV0IGFkZXF1YXRlbHkgYWRkcmVzc2VkIGFu
ZCB0aGF0IEkgZG9uJ3QgaGF2ZSBhIHNwZWNpZmljIHByb3Bvc2FsIHRvPGJyPgomZ3Q7Jmd0OyBz
b2x2ZSBpdCwgZWl0aGVyLjxicj4KJmd0OyZndDs8YnI+CiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IFJvbjxicj4KJmd0OyZndDs8YnI+CiZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyAtLS0tLU9yaWdp
bmFsIE1lc3NhZ2UtLS0tLTxicj4KJmd0OyZndDsgRnJvbTogc2ZjIFs8YSBocmVmPSJtYWlsdG86
c2ZjLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9u
IEJlaGFsZiBPZiBEYXZlIERvbHNvbjxicj4KJmd0OyZndDsgU2VudDogVGh1cnNkYXksIEZlYnJ1
YXJ5IDI2LCAyMDE1IDExOjIxIEFNPGJyPgomZ3Q7Jmd0OyBUbzogSm9lbCBNLiBIYWxwZXJuOyA8
YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbSI+bW9oYW1lZC5ib3Vj
YWRhaXJAb3JhbmdlLmNvbTwvYT47CjxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0Bp
ZXRmLm9yZzwvYT48YnI+CiZndDsmZ3Q7IENjOiBCZW4gV3JpZ2h0ICg8YSBocmVmPSJtYWlsdG86
QmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbSI+QmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbTwvYT4p
PGJyPgomZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10gZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3Vw
cG9ydCBvZiBTRiBTcGlyYWxzPGJyPgomZ3Q7Jmd0Ozxicj4KJmd0OyZndDsgSWYgSSBtYXkgdHJ5
IHRvIHB1dCBpdCBzaW1wbHksIEkndmUgYWx3YXlzIHRob3VnaHQgb2YgaXQgdGhpcyB3YXk6PGJy
PgomZ3Q7Jmd0OyAtLSZndDsgRWFjaCBub2RlIGluIHRoZSBjaGFpbiBzZWxlY3RzIHRoZSBjb250
ZXh0IGZvciBwcm9jZXNzaW5nIGFuZCB0aGU8YnI+CiZndDsmZ3Q7IG5leHQgaG9wIG9uIHRoZSBi
YXNpcyBvZiBCT1RIIHBhdGggSUQgYW5kIEluZGV4LCB3aGlsZSBkZWNyZW1lbnRpbmcgdGhlPGJy
PgomZ3Q7Jmd0OyBpbmRleCBmb3IgdGhlIG5leHQgaG9wLjxicj4KJmd0OyZndDs8YnI+CiZndDsm
Z3Q7IFRoYXQgYmVoYXZpb3Igc3VwcG9ydHMgc3BpcmFsaW5nLjxicj4KJmd0OyZndDs8YnI+CiZn
dDsmZ3Q7PGJyPgomZ3Q7Jmd0Ozxicj4KJmd0OyZndDsgLURhdmU8YnI+CiZndDsmZ3Q7PGJyPgom
Z3Q7Jmd0Ozxicj4KJmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+CiZndDsm
Z3Q7IEZyb206IHNmYyBbPGEgaHJlZj0ibWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnIj5tYWls
dG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgSm9lbCBNLiBIYWxwZXJu
PGJyPgomZ3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjYsIDIwMTUgMTA6MDIgQU08
YnI+CiZndDsmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3Jhbmdl
LmNvbSI+bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT47CjxhIGhyZWY9Im1haWx0bzpz
ZmNAaWV0Zi5vcmciPnNmY0BpZXRmLm9yZzwvYT48YnI+CiZndDsmZ3Q7IENjOiBCZW4gV3JpZ2h0
ICg8YSBocmVmPSJtYWlsdG86QmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbSI+QmVuLldyaWdodEBt
ZXRhc3dpdGNoLmNvbTwvYT4pPGJyPgomZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NmY10gZHJhZnQt
cXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzPGJyPgomZ3Q7Jmd0Ozxicj4KJmd0
OyZndDsgVGhlcmUgYXJlIHR3byBkaWZmZXJlbnQgYXNwZWN0cyBvZiBTcGlyYWxzLjxicj4KJmd0
OyZndDs8YnI+CiZndDsmZ3Q7IE9uZSBvZiB0aGUgdHdvIGFzcGVjdHMgaXMgZW5hYmxpbmcgYSBw
YWNrZXQgdGhhdCByZXBlYXRlZGx5IGFycml2ZXMgYXQ8YnI+CiZndDsmZ3Q7IHRoZSBzYW1lIFNG
RiB0byBnZXQgdGhlIGNvcnJlY3Qgc2VydmljZXMgcHJvdmlkZWQgZWFjaCB0aW1lIGl0IGFycml2
ZXMsPGJyPgomZ3Q7Jmd0OyBhbmQgdG8gZ28gdG8gdGhlIGNvcnJlY3QgbmV4dCBTRkYgZWFjaCB0
aW1lIGl0IGFycml2ZXMuJm5ic3A7IFRoZSBTZXJ2aWNlIFBhdGg8YnI+CiZndDsmZ3Q7IEluZGV4
LCB1c2VkIGJ5IHRoZSBTRkYgdG8gc2VsZWN0IHNlcnZpY2UgZnVuY3Rpb25zIGFuZCBuZXh0IFNG
RiwgcHJvdmlkZXM8YnI+CiZndDsmZ3Q7IHRoYXQgY2FwYWJpbGl0eS48YnI+CiZndDsmZ3Q7PGJy
PgomZ3Q7Jmd0OyBUaGUgb3RoZXIgYXNwZWN0IGlzIGhvdyB0aGUgU2VydmljZSBGdW5jdGlvbnMg
dGhlbXNlbHZlcyBoYW5kbGUgc3BpcmFscy48YnI+CiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7IFRvIGEg
bGFyZ2UgZGVncmVlLCB0aGF0IGRlcGVuZHMgdXBvbiB0aGUgaW5kaXZpZHVhbCBzZXJ2aWNlIGZ1
bmN0aW9uLjxicj4KJmd0OyZndDsmbmJzcDsmbmJzcDsgSSBub3JtYWxseSBhc3N1bWUgdGhhdCBp
dCB3b3VsZCB1c2UgcGFja2V0IGNvbnRleHQgKGFzIGRlc2NyaWJlZCBpbiB0aGU8YnI+CiZndDsm
Z3Q7IHRleHQgeW91IHF1b3RlKSB0byBkZXRlcm1pbmUgd2hhdCB0byBkby48YnI+CiZndDsmZ3Q7
PGJyPgomZ3Q7Jmd0OyBTaW5jZSBJIHdvdWxkIHByZWZlciB0aGF0IHNlcnZpY2UgZnVuY3Rpb25z
IGFyZSBpbmRlcGVuZGVudCBvZiB0aGU8YnI+CiZndDsmZ3Q7IHVuZGVybHlpbmcgc2VydmljZSBm
dW5jdGlvbiBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZSwgYW5kIGFyZSBub3Q8YnI+CiZndDsmZ3Q7
IHNlbnNpdGl2ZSB0byBob3cgbWFueSBmdW5jdGlvbnMgYXJlIGJlZm9yZSBvciBhZnRlciB0aGVt
IGluIHRoZSBjaGFpbiwgSTxicj4KJmd0OyZndDsgd291bGQgcGVyc29uYWxseSBwcmVmZXIgdGhh
dCB0aGV5IG5vdCB1c2UgdGhlIHBhdGggaW5kZXggZm9yIHRoYXQuJm5ic3A7IEk8YnI+CiZndDsm
Z3Q7IHdvdWxkIHJlY29tbWVuZCB0aGF0IGlmIHRoZSBwYWNrZXQgZG9lcyBub3QgY2FycnkgZW5v
dWdoIGNvbnRleHQgdGhhdCB0aGU8YnI+CiZndDsmZ3Q7IHNlcnZpY2UgZnVuY3Rpb24gY291bGQg
YW5kIHNob3VsZCB1c2UgbWV0YWRhdGEgdG8gY2FycnkgaXRzIG5lZWRlZCBzdGF0ZTxicj4KJmd0
OyZndDsgaW5mb3JtYXRpb24uJm5ic3A7IEJ1dCBuZWl0aGVyIEkgcGVyc29uYWxseSBub3IgdGhl
IFNGQyBXb3JraW5nIEdyb3VwIGdldCB0bzxicj4KJmd0OyZndDsgdGVsbCBmb2xrcyBob3cgdG8g
YnVpbGQgdGhlaXIgc2VydmljZSBmdW5jdGlvbnMuJm5ic3A7IFNvIHRoZXkgbWF5IGNvbWUgdXA8
YnI+CiZndDsmZ3Q7IHdpdGggb3RoZXIgbWV0aG9kcyBmb3IgYWRkcmVzc2luZyB0aGVpciBuZWVk
cy4mbmJzcDsgV2hpY2ggaXMgYWxzbyBmaW5lLjxicj4KJmd0OyZndDs8YnI+CiZndDsmZ3Q7IFRo
dXMsIEkgd291bGQgbm90IGV4cGVjdCB0aGlzIGRvY3VtZW50IHRvIGRpc2N1c3MgaG93IHNlcnZp
Y2UgZnVuY3Rpb25zPGJyPgomZ3Q7Jmd0OyB0aGVtc2VsdmVzIGhhbmRsZSByZXZpc2l0aW5nLiZu
YnNwOyBCdXQgbWV0YWRhdGEgY2xlYXJseSBhbGxvd3MgZm9yIGEgcmFuZ2Ugb2Y8YnI+CiZndDsm
Z3Q7IGJlaGF2aW9ycyB0aGF0IHdpbGwgd29yay4mbmJzcDsgQW5kIHRoZSBwYXRoIGluZGV4IGhh
bmRsZXMgdGhlIFNGRiBuZWVkczxicj4KJmd0OyZndDsgcmVsYXRpdmUgdG8gc3BpcmFscywgd2hp
Y2ggaXMgd2hhdCB3ZSBuZWVkIHRvIGhhbmRsZS48YnI+CiZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyBZ
b3Vycyw8YnI+CiZndDsmZ3Q7IEpvZWw8YnI+CiZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyBPbiAyLzI2
LzE1IDk6NTIgQU0sIDxhIGhyZWY9Im1haWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t
Ij5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiB3cm90ZTo8YnI+CiZndDsmZ3Q7Jmd0
OyBSZS0sPGJyPgomZ3Q7Jmd0OyZndDs8YnI+CiZndDsmZ3Q7Jmd0OyBTcGlyYWwgaXMgbm90IG1l
bnRpb25lZCBpbiB0aGUgZHJhZnQsIGJ1dCBTRiBsb29wIGlzLjxicj4KJmd0OyZndDsmZ3Q7PGJy
PgomZ3Q7Jmd0OyZndDsgSSdtIGFza2luZyB0aGUgcXVlc3Rpb24gYmVjYXVzZSBJIGRvbid0IGdl
dCBmcm9tIHRoZSBkcmFmdCBob3cgc3BpcmFsczxicj4KJmd0OyZndDsmZ3Q7IGNvdWxkIHdvcmsg
KHRoYXQgaXMgYSBTRiBpbnZva2VkIHNldmVyYWwgdGltZSBpbiB0aGUgY29udGV4dCBvZiB0aGUg
c2FtZTxicj4KJmd0OyZndDsmZ3Q7IFNGQykuPGJyPgomZ3Q7Jmd0OyZndDs8YnI+CiZndDsmZ3Q7
Jmd0OyBCZWZvcmUgcHJvcG9zaW5nIHRleHQsIEkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIGZp
cnN0IGhvdyBpdCB3b3Jrcy48YnI+CiZndDsmZ3Q7Jmd0OyBJZiB5b3UgY2FuIHByb3ZpZGUgYW4g
ZXhhbXBsZSwgdGhpcyB3aWxsIGJlIGV2ZW4gZ3JlYXQuPGJyPgomZ3Q7Jmd0OyZndDs8YnI+CiZn
dDsmZ3Q7Jmd0OyBUaGFuayB5b3UuPGJyPgomZ3Q7Jmd0OyZndDs8YnI+CiZndDsmZ3Q7Jmd0OyBD
aGVlcnMsPGJyPgomZ3Q7Jmd0OyZndDsgTWVkPGJyPgomZ3Q7Jmd0OyZndDs8YnI+CiZndDsmZ3Q7
Jmd0OyZndDsgLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tPGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7
IERlIDogSm9lbCBNLiBIYWxwZXJuIFs8YSBocmVmPSJtYWlsdG86am1oQGpvZWxoYWxwZXJuLmNv
bSI+bWFpbHRvOmptaEBqb2VsaGFscGVybi5jb208L2E+XSBFbnZvecOpIDogamV1ZGkgMjY8YnI+
CiZndDsmZ3Q7Jmd0OyZndDsgZsOpdnJpZXIgMjAxNSAxNTo0MSDDgCA6IEJPVUNBREFJUiBNb2hh
bWVkIElNVC9PTE47IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPgpzZmNAaWV0Zi5vcmc8
L2E+IENjIDo8YnI+CiZndDsmZ3Q7Jmd0OyZndDsgQmVuIFdyaWdodCAoPGEgaHJlZj0ibWFpbHRv
OkJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb20iPkJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb208L2E+
KSBPYmpldCA6IFJlOiBbc2ZjXTxicj4KJmd0OyZndDsmZ3Q7Jmd0OyBkcmFmdC1xdWlubi1zZmMt
bnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHNndDsmZ3Q7Jmd0OyZndDs8bzpwPjwvbzpwPjwvcD4K
PC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmZ3Q7Jmd0OyZndDsgVGhlIFNGIFNwaXJh
bHMgcmVxdWlyZW1lbnQgaXMgb25lIG9mIHRoZSBrZXkgZHJpdmVycyBmb3IgdGhlIGluZGV4Ljxi
cj4KJmd0OyZndDsmZ3Q7Jmd0OyBUaGUgaW5kZXggYWxsb3dzIG9uZSB0byB0ZWxsIHdoZXJlIG9u
ZSBpcyBpbiB0aGUgc3BpcmFsLCBhbmQgYWxzbyB0bzxicj4KJmd0OyZndDsmZ3Q7Jmd0OyBicmVh
ayBhIGxvb3AgaWYgb25lIGhhcyBhIGxvb3AgaW5zdGVhZCBvZiBhIHNwaXJhbC48YnI+CiZndDsm
Z3Q7Jmd0OyZndDs8YnI+CiZndDsmZ3Q7Jmd0OyZndDsgSXMgdGhlcmUgdGV4dCB0aGF0IHdlIGNv
dWxkIGFkZCB0aGF0IHdvdWxkIGhlbHAgbWFrZSB0aGlzIGNsZWFyLDxicj4KJmd0OyZndDsmZ3Q7
Jmd0OyBzaW5jZSB5b3VyIGVhcmxpZXIgcXVlc3Rpb24gYWJvdXQgdGhlIHBhdGggaW5kZXggc3Vn
Z2VzdHMgdGhhdCBpdCBpczxicj4KJmd0OyZndDsmZ3Q7Jmd0OyBub3QgYXMgY2xlYXIgYXMgaXQg
c2hvdWxkIGJlPzxicj4KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4KJmd0OyZndDsmZ3Q7Jmd0OyBZb3Vy
cyw8YnI+CiZndDsmZ3Q7Jmd0OyZndDsgSm9lbDxicj4KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4KJmd0
OyZndDsmZ3Q7Jmd0OyBPbiAyLzI2LzE1IDg6NDIgQU0sIDxhIGhyZWY9Im1haWx0bzptb2hhbWVk
LmJvdWNhZGFpckBvcmFuZ2UuY29tIj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPC9hPiB3
cm90ZTo8YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhpIFBhdWwsIGFsbCw8YnI+CiZndDsmZ3Q7
Jmd0OyZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGVyZSB3ZXJlIGEgZGlzY3Vz
c2lvbiBpbiB0aGUgbWFpbGluZyBsaXN0PGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAoPGEgaHJl
Zj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NmYy9jdXJyZW50L21zZzAx
NzAxLmh0bWwiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zZmMvY3VycmVu
dC9tc2cwMTcwMS5odG1sPC9hPik8YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQgbGVkIHRv
IGRlZmluaW5nIHdoYXQgaXMgbWVhbnQgYnkgU0YgU3BpcmFsczogKGJlbG93IGlzIHByb3ZpZGVk
PGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbiBleGNlcnB0IGZyb208YnI+CiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNh
ZGFpci1zZmMtcmVxdWlyZW1lbnRzLTA2Ij5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm
dC1ib3VjYWRhaXItc2ZjLXJlcXVpcmVtZW50cy0wNjwvYT4gd2hlcmU8YnI+CiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7IHRoZSBjb25jbHVzaW9ucyBvZiB0aGF0IGRpc2N1c3Npb24gd2VyZSByZWNvcmRl
ZCk8YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAiJm5i
c3A7Jm5ic3A7IG8mbmJzcDsgU2VydmljZSBGdW5jdGlvbiBTcGlyYWw6IGRlbm90ZXMgYSBTZXJ2
aWNlIEZ1bmN0aW9uIENoYWluIGluPGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7IHdoaWNoPGJyPgomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZGF0YSBpcyBoYW5kbGVkIGJ5
IGEgU2VydmljZSBGdW5jdGlvbiwgZm9yd2FyZGVkIG9ud2FyZHMsPGJyPgomZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyBhbmQ8YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyBhcnJpdmVzIG9uY2UgYWdhaW4gYXQgdGhhdCBTZXJ2aWNlIEZ1bmN0aW9uLjxicj4KJmd0OyZn
dDsmZ3Q7Jmd0OyZndDs8YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICombmJzcDsgTm90ZSB0aGF0IHNv
bWUgU2VydmljZSBGdW5jdGlvbnMgc3VwcG9ydCBidWlsdC1pbjxicj4KJmd0OyZndDsmZ3Q7Jmd0
OyZndDsgZnVuY3Rpb25zIHRvPGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4KJmd0OyZndDsm
Z3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWNjb21tb2RhdGUgc3BpcmFsczsgdGhlc2Ugc2Vy
dmljZS1zcGVjaWZpYyBmdW5jdGlvbnMgbWF5PGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVxdWlyZSB0aGF0IHRoZSBkYXRh
IHJlY2VpdmVkIGluIGEgc3BpcmFsIHNob3VsZCBkaWZmZXI8YnI+CiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7IGluIGE8YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyB3YXkgdGhhdCB3aWxsIHJlc3VsdCBpbiBhIGRpZmZlcmVudCBwcm9j
ZXNzaW5nIGRlY2lzaW9uPGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGFuPGJyPgomZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0Ozxicj4KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhl
IG9yaWdpbmFsIGRhdGEuJm5ic3A7IFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgbWFrZSBzdWNoPGJy
PgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgYXNzdW1wdGlvbi48YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyAqJm5ic3A7IEEgU2VydmljZSBGdW5jdGlvbiBDaGFpbiBtYXkgaW52b2x2ZSBvbmUg
b3IgbW9yZSBTZXJ2aWNlPGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4KJmd0OyZndDsmZ3Q7
Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRnVuY3Rpb24gU3BpcmFscy48YnI+CiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqJm5ic3A7IFVubGlrZSBTZXJ2aWNlIEZ1
bmN0aW9uIGxvb3AsIHNwaXJhbHMgYXJlIG5vdCBjb25zaWRlcmVkPGJyPgomZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyBhczxicj4KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+CiZndDsmZ3Q7Jmd0OyZndDsm
Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IGVycm9ycy4iPGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQW5kIHRoaXMgY29tcGFuaW9uIHJlcXVpcmVtZW50Ojxicj4K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICImbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgQS4mbmJzcDsgU2VydmljZSBGdW5jdGlvbnMgTUFZIGJlIGludm9r
ZWQgbXVsdGlwbGUgdGltZXMgaW48YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPgomZ3Q7Jmd0
OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgc2FtZSBTZXJ2aWNlIEZ1bmN0aW9u
IENoYWluIChkZW5vdGVkIGFzIFNGPGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4KJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU3BpcmFsKSwgYnV0IHRoZSBzb2x1dGlv
biBNVVNUIHByZXZlbnQgaW5maW5pdGU8YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPgomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBmb3J3YXJkaW5nIGxvb3BzLiDCuzxi
cj4KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlYWRpbmcg
dGhlIGN1cnJlbnQgZHJhZnQtcXVpbm4tc2ZjLW5zaCwgSSBkb24ndCBzZWUgaG93IHRoaXMgaXMg
bWV0Ljxicj4KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENh
biB5b3UgcGxlYXNlIGNsYXJpZnkgd2hldGhlciB0aGlzIGlzIHN1cHBvcnRlZCBhbmQgaG93Pzxi
cj4KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rIHlv
dS48YnI+CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDaGVl
cnMsPGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgTWVk
PGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+CiZn
dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KJmd0OyZndDsmZ3Q7Jmd0OyZn
dDsgc2ZjIG1haWxpbmcgbGlzdDxicj4KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFp
bHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9hPjxicj4KJmd0OyZndDsmZ3Q7Jmd0OyZn
dDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxicj4KJmd0OyZndDsm
Z3Q7Jmd0OyZndDs8YnI+CiZndDsmZ3Q7Jmd0Ozxicj4KJmd0OyZndDs8YnI+CiZndDsmZ3Q7IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPgomZ3Q7Jmd0
OyBzZmMgbWFpbGluZyBsaXN0PGJyPgomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYu
b3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPgomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h
bi9saXN0aW5mby9zZmM8L2E+PGJyPgomZ3Q7Jmd0Ozxicj4KJmd0OyZndDsgX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+CiZndDsmZ3Q7IHNmYyBtYWls
aW5nIGxpc3Q8YnI+CiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzZmNAaWV0Zi5vcmciPnNmY0Bp
ZXRmLm9yZzwvYT48YnI+CiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vc2ZjIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L3NmYzwvYT48YnI+CiZndDsmZ3Q7PGJyPgomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4KJmd0OyZndDsgc2ZjIG1haWxpbmcgbGlzdDxi
cj4KJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNmY0BpZXRmLm9yZyI+c2ZjQGlldGYub3JnPC9h
Pjxicj4KJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9zZmMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjPC9hPjxi
cj4KJmd0OyZndDs8YnI+CiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPGJyPgomZ3Q7Jmd0OyBzZmMgbWFpbGluZyBsaXN0PGJyPgomZ3Q7Jmd0
OyA8YSBocmVmPSJtYWlsdG86c2ZjQGlldGYub3JnIj5zZmNAaWV0Zi5vcmc8L2E+PGJyPgomZ3Q7
Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYyI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmM8L2E+PGJyPgomZ3Q7PGJy
PgomZ3Q7PG86cD48L286cD48L3A+CjwvZGl2PgoKIDwvYm9keT4=

----_com.android.email_160550734879705--



From nobody Thu Feb 26 11:15:19 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C42A1A1ABB for ; Thu, 26 Feb 2015 11:15:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0-ZBXKYpIGc for ; Thu, 26 Feb 2015 11:15:08 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8BD41A1A29 for ; Thu, 26 Feb 2015 11:15:07 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPR07108; Thu, 26 Feb 2015 19:15:06 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Feb 2015 19:15:05 +0000
Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.133]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0158.001;  Thu, 26 Feb 2015 11:15:02 -0800
From: Cathy Zhang 
To: "Jim Guichard (jguichar)" , "sfc@ietf.org" 
Thread-Topic: WG call for adoption of draft-quinn-sfc-nsh
Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50DTThQ
Date: Thu, 26 Feb 2015 19:15:01 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.212.145.87]
Content-Type: multipart/alternative; boundary="_000_A2C96F6779E6A041BC7023CC207FC9942166D8B0SJCEML701CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh
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, 26 Feb 2015 19:15:13 -0000

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

Support as a co-author.

Cathy

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar=
)
Sent: Thursday, February 26, 2015 4:47 AM
To: sfc@ietf.org
Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh

Greetings WG:

The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft=
-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc=
-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined =
the NSH document so that the WG can focus on a single encapsulation documen=
t going forward. This new version of NSH includes an open items section bas=
ed on discussion between co-authors and members of the list. The WG will wo=
rk through this list (and any other issues that need to be added) over the =
next weeks. We appreciate and recognize the hard work of both the NSH and S=
CH authors in pushing the SFC encapsulation work forward.

With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n=
sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3=
/12/2015.

Please note that this is a call for adoption, and not a last call for conte=
nt of the document. Adopting a WG document simply means that the WG will fo=
cus its efforts on that particular draft going forward, and use that docume=
nt for resolving open issues and documenting the WG's decisions.

Please indicate whether you support adoption for not, and if not why. Issue=
s you have with the current document itself can also be raised, but they sh=
ould be raised in the context of what should be changed in the document goi=
ng forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that appl=
ies to this draft, in line with the IPR disclosure obligations for WG parti=
cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l=
isted as a document author please respond to this email (to the chairs) whe=
ther or not you are aware of any relevant IPR.

Jim & Thomas

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









    

    Support as a co-author.
    

     <=
/p>

    Cathy

     <=
/p>

    

    

    From: sfc [mai=
lto:sfc-bounces@ietf.org]
On Behalf Of Jim Guichard (jguichar)
    
Sent: Thursday, February 26, 2015 4:47 AM
    
To: sfc@ietf.org
    
Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh
    

    

    

     
    

    

    

    Greetings WG:
    

    

    

     =

    

    

    

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/dr=
aft-quinn-sfc-nsh/) has recently been
 reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draf=
t-zhang-sfc-sch/) have joined the NSH document so that the WG can focus=
 on a single encapsulation document
 going forward. This new version of NSH includes an open items secti=
on based on discussion between co-authors and members of the list. The WG w=
ill work through this list (and any other issues that need to be added) ove=
r the next weeks. We appreciate
 and recognize the hard work of both the NSH and SCH authors in pushing the=
 SFC encapsulation work forward.
    

    

    

     =

    

    

    

    With that said, the chairs are calling for WG adoption of draf=
t-quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 w=
eeks ending 3/12/2015.=

    

    

    

     =

    

    

    

    Please note that this is a call for adoption, and not a last call for cont=
ent of the document. Adopting a WG document simply means that the WG will f=
ocus its efforts on that particular
 draft going forward, and use that document for resolving open issues and d=
ocumenting the WG’s decisions.
    

    

    

     
    

    

    

    Please indicate whether you support adoption for not, and if not why. Issu=
es you have with the current document itself can also be raised, but they s=
hould be raised in the context of what
 should be changed in the document going forward, rather than a pre-conditi=
on for adoption. 
    

    

    

     
    

    

    

    Finally, now is also a good time to poll for knowledge of any IPR that app=
lies to this draft, in line with the IPR disclosure obligations for WG part=
icipants (see RFCs 3979, 4879, 3669
 and 5378 for more details). If you are listed as a document author please =
respond to this email (to the chairs) whether or not you are aware of any r=
elevant IPR.
    

    

    

     
    

    

    

    Jim & Thomas
    

    

    

    



--_000_A2C96F6779E6A041BC7023CC207FC9942166D8B0SJCEML701CHMchi_--


From nobody Thu Feb 26 11:20:50 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D2DD1A049C for ; Thu, 26 Feb 2015 11:20:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZueydtXdNYbf for ; Thu, 26 Feb 2015 11:20:47 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290E61A037D for ; Thu, 26 Feb 2015 11:20:47 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 33135635F7D0F; Thu, 26 Feb 2015 19:20:42 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t1QJKieI012904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Feb 2015 20:20:45 +0100
Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.17]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 20:20:44 +0100
From: "Henderickx, Wim (Wim)" 
To: "Dolganow, Andrew (Andrew)" , "Guichard Jim" 
Thread-Topic: [sfc] WG call for adoption of draft-quinn-sfc-nsh
Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50DDHSAgAArO4CAABdnAA==
Date: Thu, 26 Feb 2015 19:20:43 +0000
Message-ID: 
References:   <98EEF036-6D81-4030-84D3-BFB17F2C33BA@alcatel-lucent.com>
In-Reply-To: <98EEF036-6D81-4030-84D3-BFB17F2C33BA@alcatel-lucent.com>
Accept-Language: nl-BE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_D115309312B5B3wimhenderickxalcatellucentcom_"
MIME-Version: 1.0
Archived-At: 
Cc: "sfc@ietf.org" 
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh
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, 26 Feb 2015 19:20:49 -0000

--_000_D115309312B5B3wimhenderickxalcatellucentcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

support

From: , Andrew Dolganow >
Date: Thursday 26 February 2015 19:56
To: Jim Guichard >
Cc: "sfc@ietf.org" >
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh

Support

Andrew

Sent from my iPhone


On Feb 26, 2015:7:47 AM, at 7:47 AM, Jim Guichard (jguichar) > wrote:

Greetings WG:

The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft=
-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc=
-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined =
the NSH document so that the WG can focus on a single encapsulation documen=
t going forward. This new version of NSH includes an open items section bas=
ed on discussion between co-authors and members of the list. The WG will wo=
rk through this list (and any other issues that need to be added) over the =
next weeks. We appreciate and recognize the hard work of both the NSH and S=
CH authors in pushing the SFC encapsulation work forward.

With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n=
sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3=
/12/2015.

Please note that this is a call for adoption, and not a last call for conte=
nt of the document. Adopting a WG document simply means that the WG will fo=
cus its efforts on that particular draft going forward, and use that docume=
nt for resolving open issues and documenting the WG=92s decisions.

Please indicate whether you support adoption for not, and if not why. Issue=
s you have with the current document itself can also be raised, but they sh=
ould be raised in the context of what should be changed in the document goi=
ng forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that appl=
ies to this draft, in line with the IPR disclosure obligations for WG parti=
cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l=
isted as a document author please respond to this email (to the chairs) whe=
ther or not you are aware of any relevant IPR.

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


--_000_D115309312B5B3wimhenderickxalcatellucentcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable







    support
    


    

    


    
From: <Dolganow>, Andrew Dolg=
anow <andrew.dolga=
now@alcatel-lucent.com>
    
Date: Thursday 26 February 2015 19:=
56
    
To: Jim Guichard <jguichar@cisco.com>
    
Cc: "sfc@ietf.org" <sfc@ietf.=
org>
    
Subject: Re: [sfc] WG call for adop=
tion of draft-quinn-sfc-nsh
    

    


    

    

    

    

    Support
    

    
Andrew


    

    

    Sent from my iPhone
    

    


    

    

    

    

    

    

    

    

    On Feb 26, 2015:7:47 AM, at 7:47 AM, Jim Guichard (jguichar=
) <jguichar@cisco.com> wrote:
    

    

    

    

    

    Greetings WG:
    


    

    

    The document draft-quinn-sfc-nsh-07 (https://datatracker.iet=
f.org/doc/draft-quinn-sfc-nsh/) has recently
 been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.i=
etf.org/doc/draft-zhang-sfc-sch/) have joined the NSH document so that =
the WG can focus on a single encapsulation
 document going forward. This new version of NSH includes an =
open items
section based on discussion between co-authors and members of the list.=
 The WG will work through this list (and any other issues that need to be a=
dded) over the next weeks. We appreciate and recognize the hard work of bot=
h the NSH and SCH authors in pushing
 the SFC encapsulation work forward.
    


    

    

    With that said, the chairs are calling for WG adoption of dra=
ft-quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 =
weeks ending 3/12/2015.
    


    

    

    Please note that this is a call for adoption, and not a=
 last call for content of the document. Adopting a WG document simply means=
 that the WG will focus its efforts on that
 particular draft going forward, and use that document for resolving open i=
ssues and documenting the WG=92s decisions.
    


    

    

    Please indicate whether you support adoption for not, a=
nd if not why. Issues you have with the current document itself can also be=
 raised, but they should be raised in the
 context of what should be changed in the document going forward, rather th=
an a pre-condition for adoption. 
    


    

    

    Finally, now is also a good time to poll for knowledge =
of any IPR that applies to this draft, in line with the IPR disclosure obli=
gations for WG participants (see RFCs 3979,
 4879, 3669 and 5378 for more details). If you are listed as a document aut=
hor please respond to this email (to the chairs) whether or not you are awa=
re of any relevant IPR.
    

    


    

    

    Jim & Thomas
    

    

    

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

    

    

    

    

    

    

    


    

    

    

    

    
    



--_000_D115309312B5B3wimhenderickxalcatellucentcom_--


From nobody Thu Feb 26 11:23:42 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513731A1B83 for ; Thu, 26 Feb 2015 11:23:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tW3cz12kAVNz for ; Thu, 26 Feb 2015 11:23:36 -0800 (PST)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6851A1B6D for ; Thu, 26 Feb 2015 11:23:36 -0800 (PST)
X-AuditID: c6180641-f79916d00000623a-7b-54ef12257ad6
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id CC.EC.25146.5221FE45; Thu, 26 Feb 2015 13:31:33 +0100 (CET)
Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0210.002; Thu, 26 Feb 2015 14:23:02 -0500
From: Jeff Tantsura 
To: "Jim Guichard (jguichar)" , "sfc@ietf.org" 
Thread-Topic: [sfc] WG call for adoption of draft-quinn-sfc-nsh
Thread-Index: AQHQUfmiZDObBxbiIUWmIP9lX1xWpw==
Date: Thu, 26 Feb 2015 19:23:01 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.4.4.140807
x-originating-ip: [147.117.188.10]
Content-Type: multipart/alternative; boundary="_000_D114B2848FACDjefftantsuraericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXRPuK6q0PsQg0W/zS2WzlO3ePJgK7sD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAlbHxyCr2goW2FaealrI0MB416WLk4JAQMJHY sl+pi5ETyBSTuHBvPVsXIxeHkMARRomzLy9DOcsZJV58X8IGUsUmYCDx/9txFhBbRCBY4tXc H4wgtrCAncTL6y/YIOL2End+tkHV6Ens+D2DHWQZi4CqxMI/qSBhXgFziS1n3rCD2IxAi7+f WsMEYjMLiEvcejKfCeIgAYkle84zQ9iiEi8f/2MFsUWBRj7bsJkdIq4kMWnpOVaI3hiJja9v sULMF5Q4OfMJywRG4VlIxs5CUjYLSRlE3EDi/bn5zBC2tsSyha+hbH2JjV/OMkLY1hKPWs6z IatZwMixipGjtDi1LDfdyHATIzByjkmwOe5gXPDJ8hCjAAejEg/vBul3IUKsiWXFlbmHGKU5 WJTEecuuHAwREkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwOjT+W5TX+XhilqW7isHYvm2GSor fWjw2CIYyvGxbZrH/Q0WlWKCy9S71f08r0dGXw2c4HMkl51VqcFq4Tq24gNa+5/Gyqtbnd96 46l03Q9xi/1Fp4/cds1urf7tuJ27drlk8IWLJicN52j7Grz1v53femjTxYCM/H38S3btDMza Uu+Wadv9RomlOCPRUIu5qDgRANUX7Md9AgAA
Archived-At: 
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh
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, 26 Feb 2015 19:23:38 -0000

--_000_D114B2848FACDjefftantsuraericssoncom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Yes/support

Cheers,
Jeff

From: "Jim Guichard (jguichar)" >
Date: Thursday, February 26, 2015 at 4:47 AM
To: "sfc@ietf.org" >
Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh

Greetings WG:

The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft=
-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc=
-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined =
the NSH document so that the WG can focus on a single encapsulation documen=
t going forward. This new version of NSH includes an open items section bas=
ed on discussion between co-authors and members of the list. The WG will wo=
rk through this list (and any other issues that need to be added) over the =
next weeks. We appreciate and recognize the hard work of both the NSH and S=
CH authors in pushing the SFC encapsulation work forward.

With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n=
sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3=
/12/2015.

Please note that this is a call for adoption, and not a last call for conte=
nt of the document. Adopting a WG document simply means that the WG will fo=
cus its efforts on that particular draft going forward, and use that docume=
nt for resolving open issues and documenting the WG=92s decisions.

Please indicate whether you support adoption for not, and if not why. Issue=
s you have with the current document itself can also be raised, but they sh=
ould be raised in the context of what should be changed in the document goi=
ng forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that appl=
ies to this draft, in line with the IPR disclosure obligations for WG parti=
cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l=
isted as a document author please respond to this email (to the chairs) whe=
ther or not you are aware of any relevant IPR.

Jim & Thomas

--_000_D114B2848FACDjefftantsuraericssoncom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <37032357F88CD14292B99802B7F0685D@ericsson.com>
Content-Transfer-Encoding: quoted-printable







    

    

    Yes/support
    

    


    

    

    Cheers,
    

    Jeff
    

    

    

    


    

    


    
From: "Jim Guichard (jguichar)=
" <jguichar@cisco.com>=

    
Date: Thursday, February 26, 2015 a=
t 4:47 AM
    
To: "sfc@ietf.org" <sfc@ietf.=
org>
    
Subject: [sfc] WG call for adoption=
 of draft-quinn-sfc-nsh
    

    


    

    

    

    

    

    

    Greetings WG:
    


    

    

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/dra=
ft-quinn-sfc-nsh/) has recently been
 reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draf=
t-zhang-sfc-sch/) have joined the NSH document so that the WG can focus=
 on a single encapsulation document
 going forward. This new version of NSH includes an open items secti=
on based on discussion between co-authors and members of the list. The WG w=
ill work through this list (and any other issues that need to be added) ove=
r the next weeks. We appreciate
 and recognize the hard work of both the NSH and SCH authors in pushing the=
 SFC encapsulation work forward.
    


    

    

    With that said, the chairs are calling for WG adoption of draft=
-quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 we=
eks ending 3/12/2015.
    


    

    

    Please note t=
hat this is a call for adoption, and not a last call for content of the doc=
ument. Adopting a WG document simply means that the WG will focus its effor=
ts on that particular draft going forward,
 and use that document for resolving open issues and documenting the WG=92s=
 decisions.
    


    

    

    Please indica=
te whether you support adoption for not, and if not why. Issues you have wi=
th the current document itself can also be raised, but they should be raise=
d in the context of what should be changed
 in the document going forward, rather than a pre-condition for adoption.&n=
bsp;
    


    

    

    Finally, now =
is also a good time to poll for knowledge of any IPR that applies to this d=
raft, in line with the IPR disclosure obligations for WG participants (see =
RFCs 3979, 4879, 3669 and 5378 for more
 details). If you are listed as a document author please respond to this em=
ail (to the chairs) whether or not you are aware of any relevant IPR.
    

    


    

    

    Jim & Thomas
    

    

    

    

    

    
    



--_000_D114B2848FACDjefftantsuraericssoncom_--


From nobody Thu Feb 26 11:36: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 B0E421AC3FC for ; Thu, 26 Feb 2015 11:36:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HEMcucO2WDK6 for ; Thu, 26 Feb 2015 11:36:49 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7761A7D80 for ; Thu, 26 Feb 2015 11:36:48 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTA51458; Thu, 26 Feb 2015 19:36:41 +0000 (GMT)
Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Feb 2015 19:36:40 +0000
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Thu, 26 Feb 2015 11:36:24 -0800
From: Lucy yong 
To: Cathy Zhang , "Jim Guichard (jguichar)" , "sfc@ietf.org" 
Thread-Topic: WG call for adoption of draft-quinn-sfc-nsh
Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50DTThQgAAGWHA=
Date: Thu, 26 Feb 2015 19:36:23 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45457A24@dfweml701-chm>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.47.146.134]
Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D45457A24dfweml701chm_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh
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, 26 Feb 2015 19:36:52 -0000

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

Support!

Lucy

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Cathy Zhang
Sent: Thursday, February 26, 2015 1:15 PM
To: Jim Guichard (jguichar); sfc@ietf.org
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh

Support as a co-author.

Cathy

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar=
)
Sent: Thursday, February 26, 2015 4:47 AM
To: sfc@ietf.org
Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh

Greetings WG:

The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft=
-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc=
-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined =
the NSH document so that the WG can focus on a single encapsulation documen=
t going forward. This new version of NSH includes an open items section bas=
ed on discussion between co-authors and members of the list. The WG will wo=
rk through this list (and any other issues that need to be added) over the =
next weeks. We appreciate and recognize the hard work of both the NSH and S=
CH authors in pushing the SFC encapsulation work forward.

With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n=
sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3=
/12/2015.

Please note that this is a call for adoption, and not a last call for conte=
nt of the document. Adopting a WG document simply means that the WG will fo=
cus its efforts on that particular draft going forward, and use that docume=
nt for resolving open issues and documenting the WG's decisions.

Please indicate whether you support adoption for not, and if not why. Issue=
s you have with the current document itself can also be raised, but they sh=
ould be raised in the context of what should be changed in the document goi=
ng forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that appl=
ies to this draft, in line with the IPR disclosure obligations for WG parti=
cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l=
isted as a document author please respond to this email (to the chairs) whe=
ther or not you are aware of any relevant IPR.

Jim & Thomas

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









    

    Support!
    

     <=
/p>

    Lucy

     <=
/p>

    

    

    From: sfc [mai=
lto:sfc-bounces@ietf.org]
On Behalf Of Cathy Zhang
    
Sent: Thursday, February 26, 2015 1:15 PM
    
To: Jim Guichard (jguichar); sfc@ietf.org
    
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh<=
/o:p>
    

    

    

     
    

    Support as a co-author.
    

     <=
/p>

    Cathy

     <=
/p>

    

    

    From: sfc [mailto:sfc-bounces@ietf.org]
On Behalf Of Jim Guichard (jguichar)
    
Sent: Thursday, February 26, 2015 4:47 AM
    
To: sfc@ietf.org
    
Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh
    

    

    

     
    

    

    

    Greetings WG:
    

    

    

     =

    

    

    

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/dr=
aft-quinn-sfc-nsh/) has recently been
 reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draf=
t-zhang-sfc-sch/) have joined the NSH document so that the WG can focus=
 on a single encapsulation document
 going forward. This new version of NSH includes an open items secti=
on based on discussion between co-authors and members of the list. The WG w=
ill work through this list (and any other issues that need to be added) ove=
r the next weeks. We appreciate
 and recognize the hard work of both the NSH and SCH authors in pushing the=
 SFC encapsulation work forward.
    

    

    

     =

    

    

    

    With that said, the chairs are calling for WG adoption of draf=
t-quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 w=
eeks ending 3/12/2015.=

    

    

    

     =

    

    

    

    Please note that this is a call for adoption, and not a last call for cont=
ent of the document. Adopting a WG document simply means that the WG will f=
ocus its efforts on that particular
 draft going forward, and use that document for resolving open issues and d=
ocumenting the WG’s decisions.
    

    

    

     
    

    

    

    Please indicate whether you support adoption for not, and if not why. Issu=
es you have with the current document itself can also be raised, but they s=
hould be raised in the context of what
 should be changed in the document going forward, rather than a pre-conditi=
on for adoption. 
    

    

    

     
    

    

    

    Finally, now is also a good time to poll for knowledge of any IPR that app=
lies to this draft, in line with the IPR disclosure obligations for WG part=
icipants (see RFCs 3979, 4879, 3669
 and 5378 for more details). If you are listed as a document author please =
respond to this email (to the chairs) whether or not you are aware of any r=
elevant IPR.
    

    

    

     
    

    

    

    Jim & Thomas
    

    

    

    



--_000_2691CE0099834E4A9C5044EEC662BB9D45457A24dfweml701chm_--


From nobody Thu Feb 26 12:10:20 2015
Return-Path: 
X-Original-To: sfc@ietfa.amsl.com
Delivered-To: sfc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7491A19FE for ; Thu, 26 Feb 2015 12:10:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level: 
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PYTYnlAIcAMQ for ; Thu, 26 Feb 2015 12:10:15 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B701A03A2 for ; Thu, 26 Feb 2015 12:10:15 -0800 (PST)
Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id DBA352153C592; Thu, 26 Feb 2015 20:10:07 +0000 (GMT)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id t1QKAASb032030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Feb 2015 15:10:10 -0500
Received: from US70TWXCHMBA10.zam.alcatel-lucent.com ([169.254.4.234]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 15:10:10 -0500
From: "Muley, Praveen V (Praveen)" 
To: "Henderickx, Wim (Wim)" , "Dolganow, Andrew (Andrew)" , Guichard Jim 
Thread-Topic: [sfc] WG call for adoption of draft-quinn-sfc-nsh
Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50DDHSAgAArO4CAABdnAIAADbww
Date: Thu, 26 Feb 2015 20:10:09 +0000
Message-ID: <22069265D1B36949926E9422EBF3B88173CC0F7A@US70TWXCHMBA10.zam.alcatel-lucent.com>
References:   <98EEF036-6D81-4030-84D3-BFB17F2C33BA@alcatel-lucent.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.18]
Content-Type: multipart/alternative; boundary="_000_22069265D1B36949926E9422EBF3B88173CC0F7AUS70TWXCHMBA10z_"
MIME-Version: 1.0
Archived-At: 
Cc: "sfc@ietf.org" 
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh
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, 26 Feb 2015 20:10:18 -0000

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

Support.


Sent from my iPhone

On Feb 26, 2015:7:47 AM, at 7:47 AM, Jim Guichard (jguichar) > wrote:

Greetings WG:

The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft=
-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc=
-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined =
the NSH document so that the WG can focus on a single encapsulation documen=
t going forward. This new version of NSH includes an open items section bas=
ed on discussion between co-authors and members of the list. The WG will wo=
rk through this list (and any other issues that need to be added) over the =
next weeks. We appreciate and recognize the hard work of both the NSH and S=
CH authors in pushing the SFC encapsulation work forward.

With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n=
sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3=
/12/2015.

Please note that this is a call for adoption, and not a last call for conte=
nt of the document. Adopting a WG document simply means that the WG will fo=
cus its efforts on that particular draft going forward, and use that docume=
nt for resolving open issues and documenting the WG's decisions.

Please indicate whether you support adoption for not, and if not why. Issue=
s you have with the current document itself can also be raised, but they sh=
ould be raised in the context of what should be changed in the document goi=
ng forward, rather than a pre-condition for adoption.

Finally, now is also a good time to poll for knowledge of any IPR that appl=
ies to this draft, in line with the IPR disclosure obligations for WG parti=
cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l=
isted as a document author please respond to this email (to the chairs) whe=
ther or not you are aware of any relevant IPR.

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


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









    

    

    

    

    

    Support.

    

     <=
/p>

     <=
/p>

    Sent from my iPhone
    

    

    

    

     
    

    

    

    

    

    

    

    

    On Feb 26, 2015:7:47 AM, at=
 7:47 AM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:
    

    

     

    

    

    

    

    Greetings WG:
    

    

    

     

    

    

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/dr=
aft-quinn-sfc-nsh/) has recently been
 reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draf=
t-zhang-sfc-sch/) have joined the NSH document so that the WG can focus=
 on a single encapsulation document
 going forward. This new version of NSH includes an open items secti=
on based on discussion between co-authors and members of the list. The WG w=
ill work through this list (and any other issues that need to be added) ove=
r the next weeks. We appreciate
 and recognize the hard work of both the NSH and SCH authors in pushing the=
 SFC encapsulation work forward.=

    

    

    

     

    

    

    With that said, the chairs are calling for WG adoption of draf=
t-quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 w=
eeks ending 3/12/2015.

    

    

     

    

    

    Please note that this is a call for adoption, and not a last c=
all for content of the document. Adopting a WG document simply means that t=
he WG will focus its efforts on that
 particular draft going forward, and use that document for resolving open i=
ssues and documenting the WG’s decisions.
    

    

    

     

    

    

    Please indicate whether you support adoption for not, and if n=
ot why. Issues you have with the current document itself can also be raised=
, but they should be raised in the context
 of what should be changed in the document going forward, rather than a pre=
-condition for adoption. 
    

    

    

     

    

    

    Finally, now is also a good time to poll for knowledge of any =
IPR that applies to this draft, in line with the IPR disclosure obligations=
 for WG participants (see RFCs 3979,
 4879, 3669 and 5378 for more details). If you are listed as a document aut=
hor please respond to this email (to the chairs) whether or not you are awa=
re of any relevant IPR.

    

    

     
    

    

    

    Jim & Thomas
    

    

    

    

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

    

    

    

    

    

    

    

    

     

    

    

    

    

    



--_000_22069265D1B36949926E9422EBF3B88173CC0F7AUS70TWXCHMBA10z_--


From nobody Thu Feb 26 12:15:03 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 B74801A1B48 for ; Thu, 26 Feb 2015 12:15:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.009
X-Spam-Level: 
X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pzp6k-Dc8jpc for ; Thu, 26 Feb 2015 12:14:59 -0800 (PST)
Received: from nm12-vm2.access.bullet.mail.bf1.yahoo.com (nm12-vm2.access.bullet.mail.bf1.yahoo.com [216.109.114.241]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA381A03A2 for ; Thu, 26 Feb 2015 12:14:58 -0800 (PST)
Received: from [66.196.81.163] by nm12.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Feb 2015 20:14:55 -0000
Received: from [66.196.81.148] by tm9.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Feb 2015 20:14:55 -0000
Received: from [127.0.0.1] by omp1024.access.mail.bf1.yahoo.com with NNFMP; 26 Feb 2015 20:14:55 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 926990.24156.bm@omp1024.access.mail.bf1.yahoo.com
Received: (qmail 29125 invoked by uid 60001); 26 Feb 2015 20:14:55 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1424981695; bh=d8nykHF4kNyNIy4oztqOSoqhhHIMebB+B7Fb8I/Kg2E=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=q+emYgRIJOmUvq8wgOsA0QHI8Bvmxzds++FeesYpzY6OWSL1Ukuc8tAKNc2xHnWUXLkc+G8IUefQiV518zJ3mkJgZE4d/5o5d+5OKd9NVNyR1FiButz5XCYESefZBp3LkHIKaWSSirUxfmxjtqiDGGUjv9KowWdn0MQSwm/FoUA=
X-YMail-OSG: x83DRiMVM1n6bxSouBQbN9U37Y2mY6pLVQCMbiPktiJB.YZ 0AeVW.nYkckRSS1hMjcYnEEdysleGj6zEvDx6DJQq8pO68bEUUiSuVEmT7n9 .rBQojN_OL7txFSjgeorlCFu283P7qC_X2o0LbJfjuFMPrK6Ylyh.3FYqubY Gr1Wb6G3SPxsVXe.fRBAwGvWc8_mxtelts4mIlf7R9v3q4c03hrjL9jxs2kP SDyaGFl0Ok5BkTRVquRbc2jPT0_t2YRQx4q7fbUPxy.O1UQHr8FaldDAY0MZ QGupvIpqq6sh3CNKsxWZfEIi.zTrdPw7QjNdU5nSq_4RdlEbfVn6Y_RRUhid 5_YguB48CaYWZBtuVX_CHT2eeDOwACsfZgZH9w8XZJQEAneTjdbPd.WgpP1v tCV.Y7RetPsdat2iPUH9hEo89OtgFIHXCdsgvnswB6mDOSTUMFixxqq3DEFb 6xZW_FJ3DZwuqAVdgKMYBhEpt_bwIdMxuG_xuR0gHLziZ9MgmowbT52K9jEP NMBKRV7BjFcBaygQ25LsZ1IQdlZp6IJEuUO8J3BqToc8JbXO8omm2Ud6QfYd pTP7.bf6aIeE-
Received: from [76.247.118.9] by web181403.mail.ne1.yahoo.com via HTTP; Thu, 26 Feb 2015 12:14:55 PST
X-Rocket-MIMEInfo: 002.001, U3VwcG9ydAoKCgpPbiBUaHVyc2RheSwgRmVicnVhcnkgMjYsIDIwMTUgMTI6MTAgUE0sICJNdWxleSwgUHJhdmVlbiBWIChQcmF2ZWVuKSIgPHByYXZlZW4ubXVsZXlAYWxjYXRlbC1sdWNlbnQuY29tPiB3cm90ZToKIAoKClN1cHBvcnQuIAogCiAKU2VudCBmcm9tIG15IGlQaG9uZQogCk9uIEZlYiAyNiwgMjAxNTo3OjQ3IEFNLCBhdCA3OjQ3IEFNLCBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSA8amd1aWNoYXJAY2lzY28uY29tPiB3cm90ZToKPj4gCj4.R3JlZXRpbmdzIFdHOgo.PiAKPj5UaGUgZG9jdW1lbnQBMAEBAQE-
X-Mailer: YahooMailWebService/0.8.203.740
References:   <98EEF036-6D81-4030-84D3-BFB17F2C33BA@alcatel-lucent.com>  <22069265D1B36949926E9422EBF3B88173CC0F7A@US70TWXCHMBA10.zam.alcatel-lucent.com>
Message-ID: <1424981695.73367.YahooMailNeo@web181403.mail.ne1.yahoo.com>
Date: Thu, 26 Feb 2015 12:14:55 -0800
From: Sumandra Majee 
To: "Muley, Praveen V \(Praveen\)" , "Henderickx, Wim \(Wim\)" , "Dolganow, Andrew \(Andrew\)" , Guichard Jim 
In-Reply-To: <22069265D1B36949926E9422EBF3B88173CC0F7A@US70TWXCHMBA10.zam.alcatel-lucent.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="1944329922-876896527-1424981695=:73367"
Archived-At: 
Cc: "sfc@ietf.org" 
Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Sumandra Majee 
List-Id: Network Service Chaining 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Feb 2015 20:15:01 -0000

--1944329922-876896527-1424981695=:73367
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Support=0A=0A=0A=0AOn Thursday, February 26, 2015 12:10 PM, "Muley, Praveen=
 V (Praveen)"  wrote:=0A =0A=0A=0ASupport=
. =0A =0A =0ASent from my iPhone=0A =0AOn Feb 26, 2015:7:47 AM, at 7:47 AM,=
 Jim Guichard (jguichar)  wrote:=0A>> =0A>>Greetings WG=
:=0A>> =0A>>The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.o=
rg/doc/draft-quinn-sfc-nsh/) has recently been reissued. The authors of dra=
ft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) =
have joined the NSH document so that the WG can focus on a single encapsula=
tion document going forward. This new version of NSH includes an open items=
 section based on discussion between co-authors and members of the list. Th=
e WG will work through this list (and any other issues that need to be adde=
d) over the next weeks. We appreciate and recognize the hard work of both t=
he NSH and SCH authors in pushing the SFC encapsulation work forward.=0A>> =
=0A>>With that said, the chairs are calling for WG adoption of draft-quinn-=
sfc-nsh-07 as a WG document. The call for adoption will run for 2 weeks end=
ing 3/12/2015.=0A>> =0A>>Please note that this is a call for adoption, and =
not a last call for content of the document. Adopting a WG document simply =
means that the WG will focus its efforts on that particular draft going for=
ward, and use that document for resolving open issues and documenting the W=
G=E2=80=99s decisions.=0A>> =0A>>Please indicate whether you support adopti=
on for not, and if not why. Issues you have with the current document itsel=
f can also be raised, but they should be raised in the context of what shou=
ld be changed in the document going forward, rather than a pre-condition fo=
r adoption. =0A>> =0A>>Finally, now is also a good time to poll for knowled=
ge of any IPR that applies to this draft, in line with the IPR disclosure o=
bligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more=
 details). If you are listed as a document author please respond to this em=
ail (to the chairs) whether or not you are aware of any relevant IPR.=0A>> =
=0A>>Jim & Thomas=0A>>_______________________________________________=0A>>s=
fc mailing list=0A>>sfc@ietf.org=0A>>https://www.ietf.org/mailman/listinfo/=
sfc=0A =0A=0A_______________________________________________=0Asfc mailing =
list=0Asfc@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/sfc
--1944329922-876896527-1424981695=:73367
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    Support
     
    =


     
     
     
      On Thursday=
, February 26, 2015 12:10 PM, "Muley, Praveen V (Praveen)" <praveen.mule=
y@alcatel-lucent.com> wrote:
          
      

     
    =0A
    =0A
    =0A=

    =0A
    =0A
    =0A
    Support.=0A
     =0A
      
     =0A  =
;
     =0A
    Sent from my iPhone
     =0A
    =0A
    =0A
    =
=0A
      
     =0A
    =0A=0A
    =0A
    =0A
    =
=0A
    =0A
    =0A<=
div class=3D"yiv4085190372MsoNormal">On F=
eb 26, 2015:7:47 AM, at 7:47 AM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:
     =0A
    =0A
      
     =0A
    =0A
    =0A
    =0A
    =0A<=
div class=3D"yiv4085190372MsoNormal">Greetings WG:
     =0A
    =0A
    =0A
      
     =0A
    =0A=0A
    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft-q=
uinn-sfc-nsh/) has recently been=0A reissued. The authors of draft-zhan=
g-sfc-sch-03 (http://datatracker.iet=
f.org/doc/draft-zhang-sfc-sch/) have joined the NSH document so that th=
e WG can focus on a single encapsulation document=0A going forward. This ne=
w version of NSH includes an open items section based on discussion =
between co-authors and members of the list. The WG will work through this l=
ist (and any other issues that need to be added) over the next weeks. We ap=
preciate=0A and recognize the hard work of both the NSH and SCH authors in =
pushing the SFC encapsulation work forward.
     =0A
    =0A
    =0A
      
     =0A
    =0A=0A
    With that said, the chairs are calling f=
or WG adoption of draft-quinn-sfc-nsh-07 as a WG document. The call for ado=
ption will run for 2 weeks ending 3/12/2015.
     =0A
    =0A
    =0A
      
     =0A
    =0A<=
div>=0A
    Please note that this is a call for ado=
ption, and not a last call for content of the document. Adopting a WG docum=
ent simply means that the WG will focus its efforts on that=0A particular d=
raft going forward, and use that document for resolving open issues and doc=
umenting the WG=E2=80=99s decisions.
     =0A
    =0A
    =0A
    <=
span style=3D"font-size:10.5pt;">  
     =0A
    =0A
    =0A<=
div class=3D"yiv4085190372MsoNormal">Please indicate whether you support adoption fo=
r not, and if not why. Issues you have with the current document itself can=
 also be raised, but they should be raised in the context=0A of what should=
 be changed in the document going forward, rather than a pre-condition for =
adoption. 
     =0A=0A
    =0A
      
     =0A
    =0A
    =0A
    Finally, now is also a good time to poll for knowledge of any IPR th=
at applies to this draft, in line with the IPR disclosure obligations for W=
G participants (see RFCs 3979,=0A 4879, 3669 and 5378 for more details). If=
 you are listed as a document author please respond to this email (to the c=
hairs) whether or not you are aware of any relevant IPR.
     =0A
    =0A
    =0A
      
     =0A
    =0A
    =0A
    Jim & Thomas
     =0A
    =0A
    =0A
    =0A
    ____________=
___________________________________
    =0Asfc mailing list=0Asfc@ietf.org=

    =0Ahttps://www.ietf.org/mai=
lman/listinfo/sfc
     =0A
    =0A=0A
    =0A=0A
    =0A=0A
    =0A
    =0A
      
     =0A
    =0A
    =0A=0A
    =0A
    =0A

    _______________________________________________
    sfc mailing list
    sfc@ietf.org
    https://www.ietf.org/mailman/listinfo/sfc
    --1944329922-876896527-1424981695=:73367-- From nobody Thu Feb 26 12:19:04 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 8E4561A1BAE for ; Thu, 26 Feb 2015 12:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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] 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 n5JaF16WlEl5 for ; Thu, 26 Feb 2015 12:19:01 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8FAB1A03A2 for ; Thu, 26 Feb 2015 12:19:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1424981940; x=1456517940; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ybDe3xNgVaCu0qEd5A7w8FNqUegbgsCbJdHYjCqWBr0=; b=LI7WqPGZYF74RxbaUZXrsowB0IEPcQ55IuyuEYlW675wcvZO4HO/MeUM Kf53hSWADYppE4o6f1yetFoIF5NphRcyhA1JXAGXVZTH94Q3tAeCOh7/v cdtgYeTkqr4Q7uFdKozwHywU2mWJXJag6/gJjmc/x6axtvyRquqhKCWQC Y=; X-IronPort-AV: E=Sophos;i="5.09,654,1418083200"; d="scan'208";a="150864652" X-IPAS-Result: A2CSBQAlf+9U/+sKqMBbg1RaBIMFvlsaCoVwAhyBVQEBAQEBAXyEDwEBAQECAQEBASAEDToLDAQCAQgOAwQBAQECAiMDAgICJQsUAQgIAgQBDQUJEogMFb0+mXYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSGJcoQdAQEcCBAbBwICAoJigUMFhW2NYocAOYJli1KDPoIlHIFQbwGBCjl/AQEB Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 26 Feb 2015 20:18:59 +0000 Received: from SEAEXCHMBX01.olympus.F5Net.com (192.168.15.223) by SEAEXCHMBX05.olympus.F5Net.com (192.168.15.227) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 26 Feb 2015 12:18:58 -0800 Received: from SEAEXCHMBX01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75]) by seaexchmbx01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75%13]) with mapi id 15.00.1044.021; Thu, 26 Feb 2015 12:18:58 -0800 From: Sumandra Majee To: Dave Dolson , Ron Parker , "Jim Guichard (jguichar)" , "Joel M. Halpern" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals Thread-Index: AdBRyhUadMfMQp0TQVyP+AHUYniSlAASzvcAAABleoAAAFj2AAACvdgAABC+XSD//4AdAIAAhcqg//99lID//7LyAA== Date: Thu, 26 Feb 2015 20:18:58 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3584.2080005@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.3.9.131030 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="utf-8" Content-ID: <8979BEC6ACDF814B8DC809BFE49B501C@F5.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals 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, 26 Feb 2015 20:19:03 -0000 SSB0aGluayB0aGlzIHdvdWxkIGJlIGltcGxlbWVudGF0aW9uIGNob2ljZS4NCg0KRm8gZXhhbXBs ZSB0cmFmZmljIGNvbWVzIGJhY2sgdG8gYSBzdGVlcmluZyBkZXZpY2UgbXVsdGlwbGUgdGltZXMg KGFzDQppbXBsZW1lbnRlZCB0b2RheSkgYW5kIHRoZSBkaWZmZXJlbnRpYXRvciBpcyBlaXRoZXIg dGhlIFZMQU4sIHR1bm5lbCBvcg0KcG9ydC4gVGhpcyBpcyBzaW1pbGFyIHRvIFNGIGluZGV4LCBh bmQgSSBhZ3JlZSB3aXRoIERhdmUgdGhhdCB3aGF0IG1pZ2h0DQp0aGUgbW9zdCBjb21tb24gd2F5 IG9mIHNvbHZpbmcgc3BpcmFsaW5nIHByb2JsZW0uIEJ1dCBteSBwZXJzb25hbCBvcGluaW9uDQpp cyBub3QgdG8gZW5jdW1iZXIgcHJvdG9jb2wgd2l0aCB0aGVzZSBkZXRhaWwuDQoNClN1bWFuZHJh DQoNCk9uIDIvMjYvMTUsIDg6NTQgQU0sICJEYXZlIERvbHNvbiIgPGRkb2xzb25Ac2FuZHZpbmUu Y29tPiB3cm90ZToNCg0KPkkgdGhpbmsgdXNpbmcgbWV0YWRhdGEgaXMgbW9yZSBjb21wbGljYXRl ZCB0aGFuIHVzaW5nIHRoZSBwYXRoIEluZGV4Lg0KPllvdSdkIGhhdmUgdG8gYXJyYW5nZSBmb3Ig aXQgdG8gYmUgc2V0IHByb3Blcmx5IGJ5IG5laWdoYm9ycy4gSXQganVzdA0KPm1ha2VzIGl0IHNv bWVvbmUgZWxzZSdzIHByb2JsZW0sIHdoaWNoIGlzIGEgbW9yZSBkaWZmaWN1bHQgcHJvYmxlbS4N Cj4NCj5PbiB0aGUgb3RoZXIgaGFuZCwgdGhlIEluZGV4IGlzIGFscmVhZHkgZ3VhcmFudGVlZCB0 byBiZSB1bmlxdWUgYXQgZWFjaA0KPmxpbmsgaW4gdGhlIGNoYWluLg0KPg0KPg0KPi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogUm9uIFBhcmtlciBbbWFpbHRvOlJvbl9QYXJrZXJA YWZmaXJtZWRuZXR3b3Jrcy5jb21dDQo+U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE1 IDExOjQ3IEFNDQo+VG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBEYXZlIERvbHNvbjsgSm9l bCBNLiBIYWxwZXJuOw0KPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9y Zw0KPkNjOiBCZW4gV3JpZ2h0IChCZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tKQ0KPlN1YmplY3Q6 IFJFOiBbc2ZjXSBkcmFmdC1xdWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHMNCj4N Cj5BZ3JlZSB0aGF0IG1ldGFkYXRhIGlzIG9uZSB3YXkgdG8gaGFuZGxlIHRoaXMsIGltcGx5aW5n IHRoYXQgU0YtZm9vIGluIG15DQo+ZXhhbXBsZSBrbmV3IHRoYXQgZm9yIHRoaXMgcGFydGljdWxh ciBjaGFpbiBpdCB3YXMgaW52b2tlZCBpbiBhIHNwaXJhbA0KPmFuZCB0aGVyZWZvcmUgaXRzIGZp cnN0IGludm9jYXRpb24gbmVlZGVkIHRvIGluc2VydCBtZXRhZGF0YSBzbyB0aGF0IGl0cw0KPnN1 YnNlcXVlbnQgaW52b2NhdGlvbnMgY291bGQgZG8gdGhlIHJpZ2h0IHRoaW5nLg0KPg0KPlRoZXJl IGlzIGFsc28gYW4gaW1wbGljYXRpb24gb24gUlNQIGNvbnN0cnVjdGlvbiBhbmQgYmluZGluZyAt LSB0aGUgc2FtZQ0KPmluc3RhbmNlIG9mIFNGRi1mb28gbGlrZWx5IG5lZWRzIHRvIGJlIHNlbGVj dGVkIGF0IGVhY2ggcG9zaXRpb24gdGhhdCBpdA0KPm9jY3VycyB3aXRoaW4gdGhlIFNGUC4NCj4N Cj4gICBSb24NCj4NCj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IEppbSBH dWljaGFyZCAoamd1aWNoYXIpIFttYWlsdG86amd1aWNoYXJAY2lzY28uY29tXQ0KPlNlbnQ6IFRo dXJzZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAxMTo0MyBBTQ0KPlRvOiBSb24gUGFya2VyOyBEYXZl IERvbHNvbjsgSm9lbCBNLiBIYWxwZXJuOw0KPm1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207 IHNmY0BpZXRmLm9yZw0KPkNjOiBCZW4gV3JpZ2h0IChCZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29t KQ0KPlN1YmplY3Q6IFJlOiBbc2ZjXSBkcmFmdC1xdWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNG IFNwaXJhbHMNCj4NCj5TdXJlbHkgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBTRkMgaW5mcmFz dHJ1Y3R1cmUgaXMgdG8gZGVsaXZlciBwYWNrZXRzDQo+dG8gdGhlIFNGIHdoZXJlIHNhaWQgU0Yg wrNkb2VzIGl0IHRoaW5nwrIuIEl0IHNlZW1zIHRvIG1lIHRoYXQgaWYgeW91IHdhbnQNCj5kaWZm ZXJlbnQgYmVoYXZpb3IgZWFjaCB0aW1lIHlvdSB2aXNpdCBhIGdpdmVuIFNGIHRoZW4geW91IG5l ZWQgdG8NCj5wcm92aWRlIGl0IGNvbnRleHQgd2l0aGluIHRoZSBtZXRhZGF0YSBzbyBpdCBjYW4g cGVyZm9ybSB0aGUgcmlnaHQgdGFzay4NCj4NCj5PbiAyLzI2LzE1LCAxMTozMCBBTSwgIlJvbiBQ YXJrZXIiIDxSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPg0KPndyb3RlOg0KPg0KPj5I aSwgRGF2ZS4NCj4+DQo+PkkgYWdyZWUgdGhhdCBvbiB0aGUgd2lyZSwgdGhpcyBpcyB0aGUgd2F5 IGl0IHdvdWxkIHdvcmsuDQo+Pg0KPj5CdXQsIHdoZW4gY29tcG9zaW5nIHRoZSBjaGFpbiwgaXQg c2VlbXMgbGlrZSBpbmZvcm1hdGlvbiB3b3VsZCBiZQ0KPj5sYWNraW5nIGlmIGEgY2hhaW4gd2Vy ZSBleHByZXNzZWQgc2ltcGx5IGFzIHtTRi1mb28sIFNGLWJhciwgU0YtZm9vLA0KPj5TRi1mb29i YXJ9Lg0KPj4gIEl0IGlzIGNvbXBsZXRlbHkgaW1wbGljaXQgdGhhdCBzaW5jZSBTRi1mb28gYXBw ZWFycyB0d2ljZSwgaXQgcGVyaGFwcw0KPj5zaG91bGQgcGVyZm9ybSBzb21lIGRpZmZlcmVudCBk dXR5IHdoZW4gaW5kZXggPSAwIHZzIHdoZW4gaW5kZXggPSAyLg0KPj4NCj4+QXQgZmlyc3QsIEkg dGhvdWdodCB0aGF0IGFuIGFsdGVybmF0aXZlIHdheSB0byBoYW5kbGUgdGhpcyB3b3VsZCBiZSB0 bw0KPj51c2UgbXVsdGlwbGUgbG9naWNhbCBpZGVudGl0aWVzIGZvciBTRi1mb28uICBJbiB0aGlz IGNhc2UsIHRoZSBjaGFpbg0KPj5hYm92ZSB3b3VsZCBiZSBleHByZXNzZWQgYXMge1NGLWZvby1m aXJzdC1iZWhhdmlvciwgU0YtYmFyLA0KPj5TRi1mb28tc2Vjb25kLWJlaGF2aW9yLCBTRi1mb29i YXJ9LiAgIEJ1dCwgdGhlIHByb2JsZW0gaGVyZSBpcyBzZWxlY3RpbmcNCj4+dGhlIFJTUCwgYXNz dW1pbmcgdGhhdCBTRi1mb28gaGFzIG11bHRpcGxlIGluc3RhbmNlcy4gICBOb3RoaW5nIGluIHRo aXMNCj4+c2Vjb25kIGZsYXZvciBvZiBjaGFpbiBzYXlzIHRoYXQgdGhlIHNhbWUgaW5zdGFuY2Ug b2YgU0YtZm9vLSogbXVzdCBiZQ0KPj5zZWxlY3RlZCB0byBzYXRpc2Z5IFNGLWZvby1maXJzdC1i ZWhhdmlvciBhbmQgU0YtZm9vLXNlY29uZC1iZWhhdmlvcg0KPj4od2hpY2ggbWF5IG5vdCBiZSBy ZXF1aXJlZCwgYnV0IHNob3VsZCBiZSBwb3NzaWJsZSB0byBmb3JjZSBhcyBzdWNoKS4NCj4+DQo+ PkkgZ3Vlc3Mgd2hhdCBJJ20gc2F5aW5nIGlzIHRoYXQgc3BpcmFsaW5nIGhhcyBhIHN1YnRsZXR5 IHRvIGl0IHRoYXQNCj4+aXNuJ3QgeWV0IGFkZXF1YXRlbHkgYWRkcmVzc2VkIGFuZCB0aGF0IEkg ZG9uJ3QgaGF2ZSBhIHNwZWNpZmljDQo+PnByb3Bvc2FsIHRvIHNvbHZlIGl0LCBlaXRoZXIuDQo+ Pg0KPj4gICBSb24NCj4+DQo+Pg0KPj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9t OiBzZmMgW21haWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmUgRG9s c29uDQo+PlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAxMToyMSBBTQ0KPj5Ubzog Sm9lbCBNLiBIYWxwZXJuOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5v cmcNCj4+Q2M6IEJlbiBXcmlnaHQgKEJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb20pDQo+PlN1Ympl Y3Q6IFJlOiBbc2ZjXSBkcmFmdC1xdWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHMN Cj4+DQo+PklmIEkgbWF5IHRyeSB0byBwdXQgaXQgc2ltcGx5LCBJJ3ZlIGFsd2F5cyB0aG91Z2h0 IG9mIGl0IHRoaXMgd2F5Og0KPj4tLT4gRWFjaCBub2RlIGluIHRoZSBjaGFpbiBzZWxlY3RzIHRo ZSBjb250ZXh0IGZvciBwcm9jZXNzaW5nIGFuZCB0aGUNCj4+bmV4dCBob3Agb24gdGhlIGJhc2lz IG9mIEJPVEggcGF0aCBJRCBhbmQgSW5kZXgsIHdoaWxlIGRlY3JlbWVudGluZyB0aGUNCj4+aW5k ZXggZm9yIHRoZSBuZXh0IGhvcC4NCj4+DQo+PlRoYXQgYmVoYXZpb3Igc3VwcG9ydHMgc3BpcmFs aW5nLg0KPj4NCj4+DQo+Pg0KPj4tRGF2ZQ0KPj4NCj4+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+PkZyb206IHNmYyBbbWFpbHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSm9lbCBNLiBIYWxwZXJuDQo+PlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNiwgMjAx NSAxMDowMiBBTQ0KPj5UbzogbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYu b3JnDQo+PkNjOiBCZW4gV3JpZ2h0IChCZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tKQ0KPj5TdWJq ZWN0OiBSZTogW3NmY10gZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxz DQo+Pg0KPj5UaGVyZSBhcmUgdHdvIGRpZmZlcmVudCBhc3BlY3RzIG9mIFNwaXJhbHMuDQo+Pg0K Pj5PbmUgb2YgdGhlIHR3byBhc3BlY3RzIGlzIGVuYWJsaW5nIGEgcGFja2V0IHRoYXQgcmVwZWF0 ZWRseSBhcnJpdmVzIGF0DQo+PnRoZSBzYW1lIFNGRiB0byBnZXQgdGhlIGNvcnJlY3Qgc2Vydmlj ZXMgcHJvdmlkZWQgZWFjaCB0aW1lIGl0IGFycml2ZXMsDQo+PmFuZCB0byBnbyB0byB0aGUgY29y cmVjdCBuZXh0IFNGRiBlYWNoIHRpbWUgaXQgYXJyaXZlcy4gIFRoZSBTZXJ2aWNlDQo+PlBhdGgg SW5kZXgsIHVzZWQgYnkgdGhlIFNGRiB0byBzZWxlY3Qgc2VydmljZSBmdW5jdGlvbnMgYW5kIG5l eHQgU0ZGLA0KPj5wcm92aWRlcyB0aGF0IGNhcGFiaWxpdHkuDQo+Pg0KPj5UaGUgb3RoZXIgYXNw ZWN0IGlzIGhvdyB0aGUgU2VydmljZSBGdW5jdGlvbnMgdGhlbXNlbHZlcyBoYW5kbGUgc3BpcmFs cy4NCj4+ICBUbyBhIGxhcmdlIGRlZ3JlZSwgdGhhdCBkZXBlbmRzIHVwb24gdGhlIGluZGl2aWR1 YWwgc2VydmljZSBmdW5jdGlvbi4NCj4+ICBJIG5vcm1hbGx5IGFzc3VtZSB0aGF0IGl0IHdvdWxk IHVzZSBwYWNrZXQgY29udGV4dCAoYXMgZGVzY3JpYmVkIGluDQo+PnRoZSB0ZXh0IHlvdSBxdW90 ZSkgdG8gZGV0ZXJtaW5lIHdoYXQgdG8gZG8uDQo+Pg0KPj5TaW5jZSBJIHdvdWxkIHByZWZlciB0 aGF0IHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBpbmRlcGVuZGVudCBvZiB0aGUNCj4+dW5kZXJseWlu ZyBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIGluZnJhc3RydWN0dXJlLCBhbmQgYXJlIG5vdA0K Pj5zZW5zaXRpdmUgdG8gaG93IG1hbnkgZnVuY3Rpb25zIGFyZSBiZWZvcmUgb3IgYWZ0ZXIgdGhl bSBpbiB0aGUgY2hhaW4sDQo+Pkkgd291bGQgcGVyc29uYWxseSBwcmVmZXIgdGhhdCB0aGV5IG5v dCB1c2UgdGhlIHBhdGggaW5kZXggZm9yIHRoYXQuICBJDQo+PndvdWxkIHJlY29tbWVuZCB0aGF0 IGlmIHRoZSBwYWNrZXQgZG9lcyBub3QgY2FycnkgZW5vdWdoIGNvbnRleHQgdGhhdA0KPj50aGUg c2VydmljZSBmdW5jdGlvbiBjb3VsZCBhbmQgc2hvdWxkIHVzZSBtZXRhZGF0YSB0byBjYXJyeSBp dHMgbmVlZGVkDQo+PnN0YXRlIGluZm9ybWF0aW9uLiAgQnV0IG5laXRoZXIgSSBwZXJzb25hbGx5 IG5vciB0aGUgU0ZDIFdvcmtpbmcgR3JvdXANCj4+Z2V0IHRvIHRlbGwgZm9sa3MgaG93IHRvIGJ1 aWxkIHRoZWlyIHNlcnZpY2UgZnVuY3Rpb25zLiAgU28gdGhleSBtYXkNCj4+Y29tZSB1cCB3aXRo IG90aGVyIG1ldGhvZHMgZm9yIGFkZHJlc3NpbmcgdGhlaXIgbmVlZHMuICBXaGljaCBpcyBhbHNv DQo+PmZpbmUuDQo+Pg0KPj5UaHVzLCBJIHdvdWxkIG5vdCBleHBlY3QgdGhpcyBkb2N1bWVudCB0 byBkaXNjdXNzIGhvdyBzZXJ2aWNlIGZ1bmN0aW9ucw0KPj50aGVtc2VsdmVzIGhhbmRsZSByZXZp c2l0aW5nLiAgQnV0IG1ldGFkYXRhIGNsZWFybHkgYWxsb3dzIGZvciBhIHJhbmdlDQo+Pm9mIGJl aGF2aW9ycyB0aGF0IHdpbGwgd29yay4gIEFuZCB0aGUgcGF0aCBpbmRleCBoYW5kbGVzIHRoZSBT RkYgbmVlZHMNCj4+cmVsYXRpdmUgdG8gc3BpcmFscywgd2hpY2ggaXMgd2hhdCB3ZSBuZWVkIHRv IGhhbmRsZS4NCj4+DQo+PllvdXJzLA0KPj5Kb2VsDQo+Pg0KPj5PbiAyLzI2LzE1IDk6NTIgQU0s IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+Pj4gUmUtLA0KPj4+DQo+Pj4g U3BpcmFsIGlzIG5vdCBtZW50aW9uZWQgaW4gdGhlIGRyYWZ0LCBidXQgU0YgbG9vcCBpcy4NCj4+ Pg0KPj4+IEknbSBhc2tpbmcgdGhlIHF1ZXN0aW9uIGJlY2F1c2UgSSBkb24ndCBnZXQgZnJvbSB0 aGUgZHJhZnQgaG93DQo+Pj5zcGlyYWxzIGNvdWxkIHdvcmsgKHRoYXQgaXMgYSBTRiBpbnZva2Vk IHNldmVyYWwgdGltZSBpbiB0aGUgY29udGV4dA0KPj4+b2YgdGhlIHNhbWUgU0ZDKS4NCj4+Pg0K Pj4+IEJlZm9yZSBwcm9wb3NpbmcgdGV4dCwgSSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQgZmly c3QgaG93IGl0IHdvcmtzLg0KPj4+SWYgeW91IGNhbiBwcm92aWRlIGFuIGV4YW1wbGUsIHRoaXMg d2lsbCBiZSBldmVuIGdyZWF0Lg0KPj4+DQo+Pj4gVGhhbmsgeW91Lg0KPj4+DQo+Pj4gQ2hlZXJz LA0KPj4+IE1lZA0KPj4+DQo+Pj4+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPj4+PiBE ZSA6IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dIEVudm95w6kg OiBqZXVkaSAyNg0KPj4+PiBmw6l2cmllciAyMDE1IDE1OjQxIMOAIDogQk9VQ0FEQUlSIE1vaGFt ZWQgSU1UL09MTjsgc2ZjQGlldGYub3JnIENjIDoNCj4+Pj4gQmVuIFdyaWdodCAoQmVuLldyaWdo dEBtZXRhc3dpdGNoLmNvbSkgT2JqZXQgOiBSZTogW3NmY10NCj4+Pj4gZHJhZnQtcXVpbm4tc2Zj LW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzDQo+Pj4+DQo+Pj4+IFRoZSBTRiBTcGlyYWxzIHJl cXVpcmVtZW50IGlzIG9uZSBvZiB0aGUga2V5IGRyaXZlcnMgZm9yIHRoZSBpbmRleC4NCj4+Pj4g VGhlIGluZGV4IGFsbG93cyBvbmUgdG8gdGVsbCB3aGVyZSBvbmUgaXMgaW4gdGhlIHNwaXJhbCwg YW5kIGFsc28gdG8NCj4+Pj4gYnJlYWsgYSBsb29wIGlmIG9uZSBoYXMgYSBsb29wIGluc3RlYWQg b2YgYSBzcGlyYWwuDQo+Pj4+DQo+Pj4+IElzIHRoZXJlIHRleHQgdGhhdCB3ZSBjb3VsZCBhZGQg dGhhdCB3b3VsZCBoZWxwIG1ha2UgdGhpcyBjbGVhciwNCj4+Pj4gc2luY2UgeW91ciBlYXJsaWVy IHF1ZXN0aW9uIGFib3V0IHRoZSBwYXRoIGluZGV4IHN1Z2dlc3RzIHRoYXQgaXQgaXMNCj4+Pj4g bm90IGFzIGNsZWFyIGFzIGl0IHNob3VsZCBiZT8NCj4+Pj4NCj4+Pj4gWW91cnMsDQo+Pj4+IEpv ZWwNCj4+Pj4NCj4+Pj4gT24gMi8yNi8xNSA4OjQyIEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tIHdyb3RlOg0KPj4+Pj4gSGkgUGF1bCwgYWxsLA0KPj4+Pj4NCj4+Pj4+IFRoZXJlIHdl cmUgYSBkaXNjdXNzaW9uIGluIHRoZSBtYWlsaW5nIGxpc3QNCj4+Pj4+IChodHRwOi8vd3d3Lmll dGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2ZjL2N1cnJlbnQvbXNnMDE3MDEuaHRtbCkNCj4+Pj4+ IHRoYXQgbGVkIHRvIGRlZmluaW5nIHdoYXQgaXMgbWVhbnQgYnkgU0YgU3BpcmFsczogKGJlbG93 IGlzDQo+Pj4+PiBwcm92aWRlZCBhbiBleGNlcnB0IGZyb20NCj4+Pj4+IGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWJvdWNhZGFpci1zZmMtcmVxdWlyZW1lbnRzLTA2DQo+Pj4+PiB3 aGVyZSB0aGUgY29uY2x1c2lvbnMgb2YgdGhhdCBkaXNjdXNzaW9uIHdlcmUgcmVjb3JkZWQpDQo+ Pj4+Pg0KPj4+Pj4gIiAgIG8gIFNlcnZpY2UgRnVuY3Rpb24gU3BpcmFsOiBkZW5vdGVzIGEgU2Vy dmljZSBGdW5jdGlvbiBDaGFpbiBpbg0KPj4+PiB3aGljaA0KPj4+Pj4NCj4+Pj4+ICAgICAgICAg ZGF0YSBpcyBoYW5kbGVkIGJ5IGEgU2VydmljZSBGdW5jdGlvbiwgZm9yd2FyZGVkIG9ud2FyZHMs DQo+Pj4+PiBhbmQNCj4+Pj4+DQo+Pj4+PiAgICAgICAgIGFycml2ZXMgb25jZSBhZ2FpbiBhdCB0 aGF0IFNlcnZpY2UgRnVuY3Rpb24uDQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAqICBOb3RlIHRoYXQg c29tZSBTZXJ2aWNlIEZ1bmN0aW9ucyBzdXBwb3J0IGJ1aWx0LWluDQo+Pj4+PiBmdW5jdGlvbnMg dG8NCj4+Pj4+DQo+Pj4+PiAgICAgICAgICAgIGFjY29tbW9kYXRlIHNwaXJhbHM7IHRoZXNlIHNl cnZpY2Utc3BlY2lmaWMgZnVuY3Rpb25zDQo+Pj4+PiBtYXkNCj4+Pj4+DQo+Pj4+PiAgICAgICAg ICAgIHJlcXVpcmUgdGhhdCB0aGUgZGF0YSByZWNlaXZlZCBpbiBhIHNwaXJhbCBzaG91bGQgZGlm ZmVyDQo+Pj4+PiBpbiBhDQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAgICB3YXkgdGhhdCB3aWxsIHJl c3VsdCBpbiBhIGRpZmZlcmVudCBwcm9jZXNzaW5nIGRlY2lzaW9uDQo+Pj4+PiB0aGFuDQo+Pj4+ Pg0KPj4+Pj4gICAgICAgICAgICB0aGUgb3JpZ2luYWwgZGF0YS4gIFRoaXMgZG9jdW1lbnQgZG9l cyBub3QgbWFrZSBzdWNoDQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAgICBhc3N1bXB0aW9uLg0KPj4+ Pj4NCj4+Pj4+ICAgICAgICAgKiAgQSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluIG1heSBpbnZvbHZl IG9uZSBvciBtb3JlIFNlcnZpY2UNCj4+Pj4+DQo+Pj4+PiAgICAgICAgICAgIEZ1bmN0aW9uIFNw aXJhbHMuDQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAqICBVbmxpa2UgU2VydmljZSBGdW5jdGlvbiBs b29wLCBzcGlyYWxzIGFyZSBub3QgY29uc2lkZXJlZA0KPj4+Pj4gYXMNCj4+Pj4+DQo+Pj4+PiAg ICAgICAgICAgIGVycm9ycy4iDQo+Pj4+Pg0KPj4+Pj4gQW5kIHRoaXMgY29tcGFuaW9uIHJlcXVp cmVtZW50Og0KPj4+Pj4NCj4+Pj4+ICIgICAgICAgICAgICAgICBBLiAgU2VydmljZSBGdW5jdGlv bnMgTUFZIGJlIGludm9rZWQgbXVsdGlwbGUgdGltZXMNCj4+Pj4+aW4NCj4+Pj4+DQo+Pj4+PiAg ICAgICAgICAgICAgICAgICAgICB0aGUgc2FtZSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluIChkZW5v dGVkIGFzIFNGDQo+Pj4+Pg0KPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgU3BpcmFsKSwgYnV0 IHRoZSBzb2x1dGlvbiBNVVNUIHByZXZlbnQNCj4+Pj4+IGluZmluaXRlDQo+Pj4+Pg0KPj4+Pj4g ICAgICAgICAgICAgICAgICAgICAgZm9yd2FyZGluZyBsb29wcy4gwrsNCj4+Pj4+DQo+Pj4+PiBS ZWFkaW5nIHRoZSBjdXJyZW50IGRyYWZ0LXF1aW5uLXNmYy1uc2gsIEkgZG9uJ3Qgc2VlIGhvdyB0 aGlzIGlzIG1ldC4NCj4+Pj4+DQo+Pj4+PiBDYW4geW91IHBsZWFzZSBjbGFyaWZ5IHdoZXRoZXIg dGhpcyBpcyBzdXBwb3J0ZWQgYW5kIGhvdz8NCj4+Pj4+DQo+Pj4+PiBUaGFuayB5b3UuDQo+Pj4+ Pg0KPj4+Pj4gQ2hlZXJzLA0KPj4+Pj4NCj4+Pj4+IE1lZA0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pg0K Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ Pj4+IHNmYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IHNmY0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4+Pj4+DQo+Pj4NCj4+DQo+Pl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PnNmYyBtYWlsaW5n IGxpc3QNCj4+c2ZjQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2ZjDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj5zZmMgbWFpbGluZyBsaXN0DQo+PnNmY0BpZXRmLm9yZw0KPj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4NCj4+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+c2ZjIG1haWxpbmcgbGlzdA0KPj5zZmNA aWV0Zi5vcmcNCj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4N Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNmYyBt YWlsaW5nIGxpc3QNCj5zZmNAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KDQo= From nobody Thu Feb 26 12:20: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 8EF001A1BE5 for ; Thu, 26 Feb 2015 12:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 F18GGvMM3Xy9 for ; Thu, 26 Feb 2015 12:20:07 -0800 (PST) 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 3EEF61A1B0E for ; Thu, 26 Feb 2015 12:20:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 2CE6024023A; Thu, 26 Feb 2015 12:20:07 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.95.128.180]) (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 1D1BD24056D; Thu, 26 Feb 2015 12:20:06 -0800 (PST) Message-ID: <54EF7FE1.6010709@joelhalpern.com> Date: Thu, 26 Feb 2015 15:19:45 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: ddolson@sandvine.com, jmh@joelhalpern.com, repenno@cisco.com, ron_parker@affirmednetworks.com, mohamed.boucadair@orange.com, sfc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: ben.wright@metaswitch.com Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals 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, 26 Feb 2015 20:20:09 -0000 That second sentence was supposed to be: For TLV based metadata we probably want a registry with very eeasy entry creation. Sorry, Joel On 2/26/15 1:20 PM, Jmh.direct wrote: > Instruction comes from the sevice function design. Some header > structures augment that with control mapping ibformation to indicate > which metadata field has which use. > > Gor TLV based metadat we probably eant a registry with very easy entry > creation. > > Yours, > Joel > > > Sent from my Samsung smartphone on AT&T > > > > -------- Original message -------- > Subject: RE: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals > From: Dave Dolson > To: "Joel M. Halpern" ,"Reinaldo Penno (repenno)" > ,Ron Parker > ,"mohamed.boucadair@orange.com" > ,"sfc@ietf.org" > CC: "Ben Wright (Ben.Wright@metaswitch.com)" > > > What are the mechanics of using meta-data? > Which element sets it, and how is it instructed to do so? > > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Thursday, February 26, 2015 12:36 PM > To: Dave Dolson; Reinaldo Penno (repenno); Ron Parker; > mohamed.boucadair@orange.com; sfc@ietf.org > Cc: Ben Wright (Ben.Wright@metaswitch.com) > Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals > > Personally, I would prefer that the firewall use metadata rather than > path-index. My reasoning is that if functions get added before or after > the firewall, operations would prefer not to have to change the > configuration of the firewall SF itself. > > Having said that, I don't see any way to stop you from using the path index. > > Yours, > Joel > > On 2/26/15 12:30 PM, Dave Dolson wrote: > > For the sake of argument, suppose I have a firewall SF, and I want to use > > it more than once in a chain. (Maybe I want to book-end the chain > with ingress > > and egress rules.) > > > > Do you agree it would be sufficient to use the Path Index to select > which of > > the ingress or egress rule sets should be used? > > > > I'm probably missing something; I don't understand how the context > headers > > define functionality. Maybe the device could communicate with itself > > (e.g., the ingress portion sending a tag to the egress portion) > > by sending state in the packet. Is that what you are mean by > "contextual info" ? > > > > > > > > -----Original Message----- > > From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] > > Sent: Thursday, February 26, 2015 12:18 PM > > To: Dave Dolson; Ron Parker; Joel M. Halpern; > mohamed.boucadair@orange.com; sfc@ietf.org > > Cc: Ben Wright (Ben.Wright@metaswitch.com) > > Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals > > > > Agreed on all points. I thought I was missing something so before writing > > this email I retested our implementation and it worked off the bat. The > > RSP constructed has the the same (SFF, SF) tuple but different indexes. > > > > The same SF is visited multiple times until the path ends. If the SF > > wants contextual info across visits than context headers are the way to > > go. > > > > > > On 2/26/15, 8:52 AM, "Dave Dolson" wrote: > > > >> Maybe naively, I thought the service functions would be provisioned with > >> a table: > >> > >> E.g., for element foo: > >> Path | Path Index | Next Hop | Function > >> 123 | 4 | SF-bar | first behavior > >> 123 | 2 | SF-foobar | second behavior > >> > >> > >> The Function is clearly implementation specific. Maybe it points to a > >> configuration set or a policy set. I think completely out of scope here. > >> > >> I suggest that this is not a problem for the wire protocol, rather for > >> the configuration model (netconf or whatever). > >> > >> It becomes very much vendor-specific if the behaviors are complex > >> configurations of specialized features. > >> > >> If a person were manually configuring chains, I don't think they'd > have a > >> conceptual problem, because they'd have a diagram they need to > implement: > >> {SF-foo (first-behavior), SF-bar, SF-foo (second-behavior), SF-foobar} > >> > >> If we wanted to standardize it, we could maybe make the Function > simply a > >> label that means something to the device--an indirection to a > >> configuration set. > >> > >> -Dave > >> > >> > >> > >> -----Original Message----- > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker > >> Sent: Thursday, February 26, 2015 11:31 AM > >> To: Dave Dolson; Joel M. Halpern; mohamed.boucadair@orange.com; > >> sfc@ietf.org > >> Cc: Ben Wright (Ben.Wright@metaswitch.com) > >> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals > >> > >> Hi, Dave. > >> > >> I agree that on the wire, this is the way it would work. > >> > >> But, when composing the chain, it seems like information would be > lacking > >> if a chain were expressed simply as {SF-foo, SF-bar, SF-foo, SF-foobar}. > >> It is completely implicit that since SF-foo appears twice, it perhaps > >> should perform some different duty when index = 0 vs when index = 2. > >> > >> At first, I thought that an alternative way to handle this would be to > >> use multiple logical identities for SF-foo. In this case, the chain > >> above would be expressed as {SF-foo-first-behavior, SF-bar, > >> SF-foo-second-behavior, SF-foobar}. But, the problem here is selecting > >> the RSP, assuming that SF-foo has multiple instances. Nothing in this > >> second flavor of chain says that the same instance of SF-foo-* must be > >> selected to satisfy SF-foo-first-behavior and SF-foo-second-behavior > >> (which may not be required, but should be possible to force as such). > >> > >> I guess what I'm saying is that spiraling has a subtlety to it that > isn't > >> yet adequately addressed and that I don't have a specific proposal to > >> solve it, either. > >> > >> Ron > >> > >> > >> -----Original Message----- > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson > >> Sent: Thursday, February 26, 2015 11:21 AM > >> To: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org > >> Cc: Ben Wright (Ben.Wright@metaswitch.com) > >> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals > >> > >> If I may try to put it simply, I've always thought of it this way: > >> --> Each node in the chain selects the context for processing and the > >> next hop on the basis of BOTH path ID and Index, while decrementing the > >> index for the next hop. > >> > >> That behavior supports spiraling. > >> > >> > >> > >> -Dave > >> > >> > >> -----Original Message----- > >> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > >> Sent: Thursday, February 26, 2015 10:02 AM > >> To: mohamed.boucadair@orange.com; sfc@ietf.org > >> Cc: Ben Wright (Ben.Wright@metaswitch.com) > >> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals > >> > >> There are two different aspects of Spirals. > >> > >> One of the two aspects is enabling a packet that repeatedly arrives at > >> the same SFF to get the correct services provided each time it arrives, > >> and to go to the correct next SFF each time it arrives. The Service > Path > >> Index, used by the SFF to select service functions and next SFF, > provides > >> that capability. > >> > >> The other aspect is how the Service Functions themselves handle spirals. > >> To a large degree, that depends upon the individual service function. > >> I normally assume that it would use packet context (as described > in the > >> text you quote) to determine what to do. > >> > >> Since I would prefer that service functions are independent of the > >> underlying service function chaining infrastructure, and are not > >> sensitive to how many functions are before or after them in the chain, I > >> would personally prefer that they not use the path index for that. I > >> would recommend that if the packet does not carry enough context > that the > >> service function could and should use metadata to carry its needed state > >> information. But neither I personally nor the SFC Working Group get to > >> tell folks how to build their service functions. So they may come up > >> with other methods for addressing their needs. Which is also fine. > >> > >> Thus, I would not expect this document to discuss how service functions > >> themselves handle revisiting. But metadata clearly allows for a > range of > >> behaviors that will work. And the path index handles the SFF needs > >> relative to spirals, which is what we need to handle. > >> > >> Yours, > >> Joel > >> > >> On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote: > >>> Re-, > >>> > >>> Spiral is not mentioned in the draft, but SF loop is. > >>> > >>> I'm asking the question because I don't get from the draft how spirals > >>> could work (that is a SF invoked several time in the context of the > same > >>> SFC). > >>> > >>> Before proposing text, I would like to understand first how it works. > >>> If you can provide an example, this will be even great. > >>> > >>> Thank you. > >>> > >>> Cheers, > >>> Med > >>> > >>>> -----Message d'origine----- > >>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoyé : jeudi 26 > >>>> février 2015 15:41 À : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Cc : > >>>> Ben Wright (Ben.Wright@metaswitch.com) Objet : Re: [sfc] > >>>> draft-quinn-sfc-nsh: Support of SF Spiralsgt;>>> > >>>> The SF Spirals requirement is one of the key drivers for the index. > >>>> The index allows one to tell where one is in the spiral, and also to > >>>> break a loop if one has a loop instead of a spiral. > >>>> > >>>> Is there text that we could add that would help make this clear, > >>>> since your earlier question about the path index suggests that it is > >>>> not as clear as it should be? > >>>> > >>>> Yours, > >>>> Joel > >>>> > >>>> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote: > >>>>> Hi Paul, all, > >>>>> > >>>>> There were a discussion in the mailing list > >>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html) > >>>>> that led to defining what is meant by SF Spirals: (below is provided > >>>>> an excerpt from > >>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where > >>>>> the conclusions of that discussion were recorded) > >>>>> > >>>>> " o Service Function Spiral: denotes a Service Function Chain in > >>>> which > >>>>> > >>>>> data is handled by a Service Function, forwarded onwards, > >>>>> and > >>>>> > >>>>> arrives once again at that Service Function. > >>>>> > >>>>> * Note that some Service Functions support built-in > >>>>> functions to > >>>>> > >>>>> accommodate spirals; these service-specific functions may > >>>>> > >>>>> require that the data received in a spiral should differ > >>>>> in a > >>>>> > >>>>> way that will result in a different processing decision > >>>>> than > >>>>> > >>>>> the original data. This document does not make such > >>>>> > >>>>> assumption. > >>>>> > >>>>> * A Service Function Chain may involve one or more Service > >>>>> > >>>>> Function Spirals. > >>>>> > >>>>> * Unlike Service Function loop, spirals are not considered > >>>>> as > >>>>> > >>>>> errors." > >>>>> > >>>>> And this companion requirement: > >>>>> > >>>>> " A. Service Functions MAY be invoked multiple > times in > >>>>> > >>>>> the same Service Function Chain (denoted as SF > >>>>> > >>>>> Spiral), but the solution MUST prevent infinite > >>>>> > >>>>> forwarding loops. » > >>>>> > >>>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is met. > >>>>> > >>>>> Can you please clarify whether this is supported and how? > >>>>> > >>>>> Thank you. > >>>>> > >>>>> Cheers, > >>>>> > >>>>> Med > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 Thu Feb 26 12:44:12 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5416B1A1DE1 for ; Thu, 26 Feb 2015 12:44:10 -0800 (PST) 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 afos2n8IUBtP for ; Thu, 26 Feb 2015 12:44:08 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37751A039B for ; Thu, 26 Feb 2015 12:44:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7434; q=dns/txt; s=iport; t=1424983448; x=1426193048; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=LbXDyfeiNvUBPkI9tqTMQRGjqBsRokDwrCOOouQ2Uzo=; b=aKQyBZYc9WA5TOHbt7xMXi+nunz06LuRslbnQtuCjpvLqOr2COaMHm8U P3THwL550DhTOP8ouge/PmDDVkCrkTC6DRtgk10Ho4qosMl6HNfEdaeoG oEIjHhh9frUF6Mg6Z0B/lkg14yMVNFkKYy3Ji3jiUKvephZKG18OZcZx8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C3CQBjhe9U/4cNJK1bgj9DUloEskmNDDyBdIVwAoElTQEBAQEBAXyEDwECBB1uAQgRAwECKDkUCQgCBAESiC8N1xwBAQEBAQUBAQEBAQEBG4sThAwRAT8NCgGEKwWPb4NghWWBGzmCZY8QI4ICHIFQb4ELOX8BAQE X-IronPort-AV: E=Sophos;i="5.09,655,1418083200"; d="scan'208,217";a="399454868" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-6.cisco.com with ESMTP; 26 Feb 2015 20:44:07 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t1QKi61c010619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Feb 2015 20:44:06 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.147]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 14:44:06 -0600 From: "Nagendra Kumar Nainar (naikumar)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] WG call for adoption of draft-quinn-sfc-nsh Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50DdyyA Date: Thu, 26 Feb 2015 20:44:05 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.24.182.13] Content-Type: multipart/alternative; boundary="_000_D114EFB27D341naikumarciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 26 Feb 2015 20:44:10 -0000 --_000_D114EFB27D341naikumarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes. Support. Regards, Nagendra From: "Jim Guichard (jguichar)" > Date: Thursday, February 26, 2015 at 7:47 AM To: "sfc@ietf.org" > Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh Greetings WG: The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft= -quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc= -sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined = the NSH document so that the WG can focus on a single encapsulation documen= t going forward. This new version of NSH includes an open items section bas= ed on discussion between co-authors and members of the list. The WG will wo= rk through this list (and any other issues that need to be added) over the = next weeks. We appreciate and recognize the hard work of both the NSH and S= CH authors in pushing the SFC encapsulation work forward. With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n= sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3= /12/2015. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG=92s decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Jim & Thomas --_000_D114EFB27D341naikumarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
    Yes. Support.

    Regards,
    Nagendra

    From: "Jim Guichard (jguichar)= " <jguichar@cisco.com>=
    Date: Thursday, February 26, 2015 a= t 7:47 AM
    To: "sfc@ietf.org" <sfc@ietf.= org>
    Subject: [sfc] WG call for adoption= of draft-quinn-sfc-nsh

    Greetings WG:

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/dra= ft-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draf= t-zhang-sfc-sch/) have joined the NSH document so that the WG can focus= on a single encapsulation document going forward. This new version of NSH includes an open items secti= on based on discussion between co-authors and members of the list. The WG w= ill work through this list (and any other issues that need to be added) ove= r the next weeks. We appreciate and recognize the hard work of both the NSH and SCH authors in pushing the= SFC encapsulation work forward.

    With that said, the chairs are calling for WG adoption of draft= -quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 we= eks ending 3/12/2015.

    Please note t= hat this is a call for adoption, and not a last call for content of the doc= ument. Adopting a WG document simply means that the WG will focus its effor= ts on that particular draft going forward, and use that document for resolving open issues and documenting the WG=92s= decisions.

    Please indica= te whether you support adoption for not, and if not why. Issues you have wi= th the current document itself can also be raised, but they should be raise= d in the context of what should be changed in the document going forward, rather than a pre-condition for adoption.&n= bsp;

    Finally, now = is also a good time to poll for knowledge of any IPR that applies to this d= raft, in line with the IPR disclosure obligations for WG participants (see = RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please respond to this em= ail (to the chairs) whether or not you are aware of any relevant IPR.

    Jim & Thomas
     --_000_D114EFB27D341naikumarciscocom_-- From nobody Thu Feb 26 12:52:03 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 4AD771A8763 for ; Thu, 26 Feb 2015 12:52:02 -0800 (PST) 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 IjOVzGz2o1JG for ; Thu, 26 Feb 2015 12:51:59 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D361A2119 for ; Thu, 26 Feb 2015 12:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12081; q=dns/txt; s=iport; t=1424983919; x=1426193519; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=b+FpezwghStjheprvlHV+5md1f4WILwAkEZKIFYC0kc=; b=m6wUKD/4GOwsB/57IHlWTDOOL8a9IqzPMkgt077+GP3yN4FILM4lkY9s A7/E/khsivVssMo8i4I8X3RgavV5KjGtb3+IogbDWX+VS+CJiEVHKJ6lY gG0LlH0CKcOtgrwMVdNBHw2wBW8lfog+xpAw/dAPY9oiLNSI8QI+oAeVt k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DZBQBYhu9U/4UNJK1bgwJSWgTBewqFcAKBJk0BAQEBAQF8hA8BAQEEAQEBJEcLDAQCAQgRBAEBAScHJwsUCQgCBAENBQkSiBQN1x0BAQEBAQEBAQEBAQEBAQEBAQEBAQEXixOEDBACARwzAgUGhCUFhW2EPYNMgXmDYIVlgRs5gmWLUoM+I4ICHIFQbwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.09,655,1418083200"; d="scan'208";a="127307986" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP; 26 Feb 2015 20:51:58 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t1QKpvaF002971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Feb 2015 20:51:57 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.43]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 14:51:57 -0600 From: "Surendra Kumar (smkumar)" To: "Joel M. Halpern" , Dave Dolson , "Reinaldo Penno (repenno)" , "Ron Parker" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals Thread-Index: AdBRyhUadMfMQp0TQVyP+AHUYniSlAAOnhUAAABleoAAAFj2AAACvdgAAABVPAAAAMCGAAAA6mWAAABpgIAAADI4AP//sLIA Date: Thu, 26 Feb 2015 20:51:56 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3584.2080005@joelhalpern.com> <54EF596C.1080608@joelhalpern.com> In-Reply-To: <54EF596C.1080608@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.155.33.110] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2C4FDDADEBCB4D4296F4C437653D4A76@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals 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, 26 Feb 2015 20:52:02 -0000 I would agree with that. An SF trying to figure out what SFCs it is part of and at what location it is present in each of those SFCs, thus adds severe constraints to how such an SF can be deployed. An SF limiting itself to service function delivery alone, aided by the metadata, not only keeps the SF simple, allows for very flexible deployments as well. Surendra. On 2/26/15, 9:35 AM, "Joel M. Halpern" wrote: >Personally, I would prefer that the firewall use metadata rather than >path-index. My reasoning is that if functions get added before or after >the firewall, operations would prefer not to have to change the >configuration of the firewall SF itself. > >Having said that, I don't see any way to stop you from using the path >index. > >Yours, >Joel > >On 2/26/15 12:30 PM, Dave Dolson wrote: >> For the sake of argument, suppose I have a firewall SF, and I want to >>use >> it more than once in a chain. (Maybe I want to book-end the chain with >>ingress >> and egress rules.) >> >> Do you agree it would be sufficient to use the Path Index to select >>which of >> the ingress or egress rule sets should be used? >> >> I'm probably missing something; I don't understand how the context >>headers >> define functionality. Maybe the device could communicate with itself >> (e.g., the ingress portion sending a tag to the egress portion) >> by sending state in the packet. Is that what you are mean by >>"contextual info" ? >> >> >> >> -----Original Message----- >> From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] >> Sent: Thursday, February 26, 2015 12:18 PM >> To: Dave Dolson; Ron Parker; Joel M. Halpern; >>mohamed.boucadair@orange.com; sfc@ietf.org >> Cc: Ben Wright (Ben.Wright@metaswitch.com) >> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >> >> Agreed on all points. I thought I was missing something so before >>writing >> this email I retested our implementation and it worked off the bat. The >> RSP constructed has the the same (SFF, SF) tuple but different indexes. >> >> The same SF is visited multiple times until the path ends. If the SF >> wants contextual info across visits than context headers are the way to >> go. >> >> >> On 2/26/15, 8:52 AM, "Dave Dolson" wrote: >> >>> Maybe naively, I thought the service functions would be provisioned >>>with >>> a table: >>> >>> E.g., for element foo: >>> Path | Path Index | Next Hop | Function >>> 123 | 4 | SF-bar | first behavior >>> 123 | 2 | SF-foobar | second behavior >>> >>> >>> The Function is clearly implementation specific. Maybe it points to a >>> configuration set or a policy set. I think completely out of scope >>>here. >>> >>> I suggest that this is not a problem for the wire protocol, rather for >>> the configuration model (netconf or whatever). >>> >>> It becomes very much vendor-specific if the behaviors are complex >>> configurations of specialized features. >>> >>> If a person were manually configuring chains, I don't think they'd >>>have a >>> conceptual problem, because they'd have a diagram they need to >>>implement: >>> {SF-foo (first-behavior), SF-bar, SF-foo (second-behavior), SF-foobar} >>> >>> If we wanted to standardize it, we could maybe make the Function >>>simply a >>> label that means something to the device--an indirection to a >>> configuration set. >>> >>> -Dave >>> >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker >>> Sent: Thursday, February 26, 2015 11:31 AM >>> To: Dave Dolson; Joel M. Halpern; mohamed.boucadair@orange.com; >>> sfc@ietf.org >>> Cc: Ben Wright (Ben.Wright@metaswitch.com) >>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >>> >>> Hi, Dave. >>> >>> I agree that on the wire, this is the way it would work. >>> >>> But, when composing the chain, it seems like information would be >>>lacking >>> if a chain were expressed simply as {SF-foo, SF-bar, SF-foo, >>>SF-foobar}. >>> It is completely implicit that since SF-foo appears twice, it perhaps >>> should perform some different duty when index =3D 0 vs when index =3D 2= . >>> >>> At first, I thought that an alternative way to handle this would be to >>> use multiple logical identities for SF-foo. In this case, the chain >>> above would be expressed as {SF-foo-first-behavior, SF-bar, >>> SF-foo-second-behavior, SF-foobar}. But, the problem here is >>>selecting >>> the RSP, assuming that SF-foo has multiple instances. Nothing in this >>> second flavor of chain says that the same instance of SF-foo-* must be >>> selected to satisfy SF-foo-first-behavior and SF-foo-second-behavior >>> (which may not be required, but should be possible to force as such). >>> >>> I guess what I'm saying is that spiraling has a subtlety to it that >>>isn't >>> yet adequately addressed and that I don't have a specific proposal to >>> solve it, either. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>> Sent: Thursday, February 26, 2015 11:21 AM >>> To: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>> Cc: Ben Wright (Ben.Wright@metaswitch.com) >>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >>> >>> If I may try to put it simply, I've always thought of it this way: >>> --> Each node in the chain selects the context for processing and the >>> next hop on the basis of BOTH path ID and Index, while decrementing the >>> index for the next hop. >>> >>> That behavior supports spiraling. >>> >>> >>> >>> -Dave >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Thursday, February 26, 2015 10:02 AM >>> To: mohamed.boucadair@orange.com; sfc@ietf.org >>> Cc: Ben Wright (Ben.Wright@metaswitch.com) >>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >>> >>> There are two different aspects of Spirals. >>> >>> One of the two aspects is enabling a packet that repeatedly arrives at >>> the same SFF to get the correct services provided each time it arrives, >>> and to go to the correct next SFF each time it arrives. The Service >>>Path >>> Index, used by the SFF to select service functions and next SFF, >>>provides >>> that capability. >>> >>> The other aspect is how the Service Functions themselves handle >>>spirals. >>> To a large degree, that depends upon the individual service function. >>> I normally assume that it would use packet context (as described in >>>the >>> text you quote) to determine what to do. >>> >>> Since I would prefer that service functions are independent of the >>> underlying service function chaining infrastructure, and are not >>> sensitive to how many functions are before or after them in the chain, >>>I >>> would personally prefer that they not use the path index for that. I >>> would recommend that if the packet does not carry enough context that >>>the >>> service function could and should use metadata to carry its needed >>>state >>> information. But neither I personally nor the SFC Working Group get to >>> tell folks how to build their service functions. So they may come up >>> with other methods for addressing their needs. Which is also fine. >>> >>> Thus, I would not expect this document to discuss how service functions >>> themselves handle revisiting. But metadata clearly allows for a range >>>of >>> behaviors that will work. And the path index handles the SFF needs >>> relative to spirals, which is what we need to handle. >>> >>> Yours, >>> Joel >>> >>> On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote: >>>> Re-, >>>> >>>> Spiral is not mentioned in the draft, but SF loop is. >>>> >>>> I'm asking the question because I don't get from the draft how spirals >>>> could work (that is a SF invoked several time in the context of the >>>>same >>>> SFC). >>>> >>>> Before proposing text, I would like to understand first how it works. >>>> If you can provide an example, this will be even great. >>>> >>>> Thank you. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : jeudi 26 >>>>> f=E9vrier 2015 15:41 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Cc= : >>>>> Ben Wright (Ben.Wright@metaswitch.com) Objet : Re: [sfc] >>>>> draft-quinn-sfc-nsh: Support of SF Spirals >>>>> >>>>> The SF Spirals requirement is one of the key drivers for the index. >>>>> The index allows one to tell where one is in the spiral, and also to >>>>> break a loop if one has a loop instead of a spiral. >>>>> >>>>> Is there text that we could add that would help make this clear, >>>>> since your earlier question about the path index suggests that it is >>>>> not as clear as it should be? >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote: >>>>>> Hi Paul, all, >>>>>> >>>>>> There were a discussion in the mailing list >>>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html) >>>>>> that led to defining what is meant by SF Spirals: (below is provided >>>>>> an excerpt from >>>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where >>>>>> the conclusions of that discussion were recorded) >>>>>> >>>>>> " o Service Function Spiral: denotes a Service Function Chain in >>>>> which >>>>>> >>>>>> data is handled by a Service Function, forwarded onwards, >>>>>> and >>>>>> >>>>>> arrives once again at that Service Function. >>>>>> >>>>>> * Note that some Service Functions support built-in >>>>>> functions to >>>>>> >>>>>> accommodate spirals; these service-specific functions >>>>>>may >>>>>> >>>>>> require that the data received in a spiral should differ >>>>>> in a >>>>>> >>>>>> way that will result in a different processing decision >>>>>> than >>>>>> >>>>>> the original data. This document does not make such >>>>>> >>>>>> assumption. >>>>>> >>>>>> * A Service Function Chain may involve one or more Service >>>>>> >>>>>> Function Spirals. >>>>>> >>>>>> * Unlike Service Function loop, spirals are not considered >>>>>> as >>>>>> >>>>>> errors." >>>>>> >>>>>> And this companion requirement: >>>>>> >>>>>> " A. Service Functions MAY be invoked multiple times >>>>>>in >>>>>> >>>>>> the same Service Function Chain (denoted as SF >>>>>> >>>>>> Spiral), but the solution MUST prevent >>>>>>infinite >>>>>> >>>>>> forwarding loops. =BB >>>>>> >>>>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is >>>>>>met. >>>>>> >>>>>> Can you please clarify whether this is supported and how? >>>>>> >>>>>> Thank you. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Med >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Feb 26 13:03: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 A271D1A87B9 for ; Thu, 26 Feb 2015 13:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FbeYOd9rUQ5 for ; Thu, 26 Feb 2015 13:03:12 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1CB71A8842 for ; Thu, 26 Feb 2015 13:03:12 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-97-54ef359f2b5c Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 08.F7.03307.0A53FE45; Thu, 26 Feb 2015 16:02:56 +0100 (CET) Received: from eusjgala119.dyn.sj.us.am.ericsson.se (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.95) with Microsoft SMTP Server id 14.3.210.2; Thu, 26 Feb 2015 16:03:03 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_C1C62CA6-CEAF-4AF6-B229-F2A93BFDAC6E" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Wassim Haddad In-Reply-To: Date: Thu, 26 Feb 2015 13:03:30 -0800 Message-ID: References: To: "Jim Guichard (jguichar)" X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrHLMWRmVeSWpSXmKPExsUyuXRPrO4C0/chBuePilosnadu8eTBVnYH Jo8pvzeyeixZ8pMpgCmKyyYlNSezLLVI3y6BK+Pzp/OMBRfNK46duM/SwHhBv4uRk0NCwETi +d0jTBC2mMSFe+vZuhi5OIQEjjBKfDi5jh0kISRwmFHi13VjEJtZIEni5sp2ZhCbV8BA4vj3 nywgtrCAncTL6y/YQGw2oPjX5WdZQWxOAX2JT/92gM1hEVCV+PhzOwvEHF+JfR1PgGo4gObY S9x56AmxSk/i/tWjYCUiAkYS3Zfes0LcJi/x4cNxqHPUJabcmsAygVFgFpKLZiG5CCKuLbFs 4WtmCNtA4siiOayY4voS1+/cZ13AyLaKkaO0OLUsN93IYBMjMICPSbDp7mDc89LyEKMAB6MS D+8G6XchQqyJZcWVuYcYpTlYlMR5Fz04GCIkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBMcA0 g1FY37xKbGr9vUxxQ8nl1+5Mv6jVfzpJ5emBE6x7Hq39ycR4XGvOltNus3cwLU5rLHn3dcY3 +Z4JklZF1TJanI8aPNhSrnm/ZU1etizOKHzrZ5kCbQfGOxH3axa9iPxw3G1PpK2P+wfWR42/ NX59sNiulLuq5Jx2jaHb1v3HF2c3yJfkK7EUZyQaajEXFScCABl+L1xBAgAA Archived-At: Cc: Wassim Haddad , "sfc@ietf.org" Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 26 Feb 2015 21:03:15 -0000 --Apple-Mail=_C1C62CA6-CEAF-4AF6-B229-F2A93BFDAC6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" Support Regards, Wassim H. On Feb 26, 2015, at 4:47 AM, Jim Guichard (jguichar) = wrote: > Greetings WG: >=20 > The document draft-quinn-sfc-nsh-07 = (https://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/) has recently = been reissued. The authors of draft-zhang-sfc-sch-03 = (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined the = NSH document so that the WG can focus on a single encapsulation document = going forward. This new version of NSH includes an open items section = based on discussion between co-authors and members of the list. The WG = will work through this list (and any other issues that need to be added) = over the next weeks. We appreciate and recognize the hard work of both = the NSH and SCH authors in pushing the SFC encapsulation work forward. >=20 > With that said, the chairs are calling for WG adoption of = draft-quinn-sfc-nsh-07 as a WG document. The call for adoption will run = for 2 weeks ending 3/12/2015. >=20 > Please note that this is a call for adoption, and not a last call for = content of the document. Adopting a WG document simply means that the WG = will focus its efforts on that particular draft going forward, and use = that document for resolving open issues and documenting the WG=92s = decisions. >=20 > Please indicate whether you support adoption for not, and if not why. = Issues you have with the current document itself can also be raised, but = they should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for adoption.=20 >=20 > Finally, now is also a good time to poll for knowledge of any IPR that = applies to this draft, in line with the IPR disclosure obligations for = WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). = If you are listed as a document author please respond to this email (to = the chairs) whether or not you are aware of any relevant IPR. >=20 > Jim & Thomas > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_C1C62CA6-CEAF-4AF6-B229-F2A93BFDAC6E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252" Support




    On Feb 26, 2015, at 4:47 AM, Jim Guichard = (jguichar) <jguichar@cisco.com> = wrote:

    Greetings WG:

    The = document draft-quinn-sfc-nsh-07 (https://data= tracker.ietf.org/doc/draft-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatr= acker.ietf.org/doc/draft-zhang-sfc-sch/) have joined the NSH = document so that the WG can focus on a single encapsulation document going forward. This new version of NSH includes an open items = section based on discussion between co-authors and members of the = list. The WG will work through this list (and any other issues that need = to be added) over the next weeks. We appreciate and recognize the hard work of both the NSH and SCH authors in pushing = the SFC encapsulation work forward.

    With = that said, the chairs are calling for WG adoption of = draft-quinn-sfc-nsh-07 as a WG document. The call for adoption will run = for 2 weeks ending 3/12/2015.

    Please note that this is a call for = adoption, and not a last call for content of the document. Adopting a WG = document simply means that the WG will focus its efforts on that = particular draft going forward, and use that document for resolving open issues and documenting the = WG=92s decisions.

    Please indicate whether you support = adoption for not, and if not why. Issues you have with the current = document itself can also be raised, but they should be raised in the = context of what should be changed in the document going forward, rather than a pre-condition for = adoption. 

    Finally, now is also a good time to poll = for knowledge of any IPR that applies to this draft, in line with the = IPR disclosure obligations for WG participants (see RFCs 3979, 4879, = 3669 and 5378 for more details). If you are listed as a document author please respond to this = email (to the chairs) whether or not you are aware of any relevant = IPR.

    Jim & Thomas
    _______________________________________________
    sfc mailing = list
    sfc@ietf.org
    https://www.ietf.org/mail= man/listinfo/sfc

    = --Apple-Mail=_C1C62CA6-CEAF-4AF6-B229-F2A93BFDAC6E-- From nobody Thu Feb 26 13:09:34 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E96E1A87B0 for ; Thu, 26 Feb 2015 13:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, 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 8BWKCUGeTJq6 for ; Thu, 26 Feb 2015 13:09:30 -0800 (PST) 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 1417D1AC3FE for ; Thu, 26 Feb 2015 13:09:30 -0800 (PST) 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, 26 Feb 2015 13:09:29 -0800 From: Ron Parker To: "Joel M. Halpern" , "ddolson@sandvine.com" , "repenno@cisco.com" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals Thread-Index: AQHQUfDWdMfMQp0TQVyP+AHUYniSlJ0D5VmA//+GlyA= Date: Thu, 26 Feb 2015 21:09:29 +0000 Message-ID: References: <54EF7FE1.6010709@joelhalpern.com> In-Reply-To: <54EF7FE1.6010709@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ben.wright@metaswitch.com" Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals 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, 26 Feb 2015 21:09:33 -0000 QWdyZWUuICAgDQoNCk9uZSBhcHByb2FjaCB0aGF0IHdhcyBkZXNjcmliZWQgaW4gYSBub3ctYWJh bmRvbmVkIGRyYWZ0IGlzIHRvIGhhdmUgYm90aCB0aGUgcmVnaXN0ZXJlZCBUeXBlcyB0aGF0IEpv ZWwgcmVmZXJzIHRvIGFuZCBhbHNvIHRoZSBhYmlsaXR5IHRvIGRlZmluZSB2ZW5kb3Itc3BlY2lm aWMgdHlwZXMuICAgQSBmbGFnIGJpdCBpbiB0aGUgVExWIGhlYWRlciBjb3VsZCBjb250cm9sIHdo ZXRoZXIgdGhlICdUJyBpbiB0aGUgVExWIGlzIHJlZ2lzdGVyZWQgb3IgdmVuZG9yLXNwZWNpZmlj LiAgIElmIHZlbmRvci1zcGVjaWZpYywgYW4gT1VJIHdvcmQgd291bGQgYmUgcmVxdWlyZWQgaW4g dGhlIFRMViBpbiBvcmRlciB0byBkZWZpbmUgdGhlIG51bWJlciBzcGFjZSB0byBpbnRlcnByZXQg dGhlICdUJy4NCg0KICAgUm9uDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dIA0KU2VudDogVGh1 cnNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE1IDM6MjAgUE0NClRvOiBkZG9sc29uQHNhbmR2aW5lLmNv bTsgam1oQGpvZWxoYWxwZXJuLmNvbTsgcmVwZW5ub0BjaXNjby5jb207IFJvbiBQYXJrZXI7IG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KQ2M6IGJlbi53cmlnaHRA bWV0YXN3aXRjaC5jb20NClN1YmplY3Q6IFJlOiBbc2ZjXSBkcmFmdC1xdWlubi1zZmMtbnNoOiBT dXBwb3J0IG9mIFNGIFNwaXJhbHMNCg0KVGhhdCBzZWNvbmQgc2VudGVuY2Ugd2FzIHN1cHBvc2Vk IHRvIGJlOg0KDQpGb3IgVExWIGJhc2VkIG1ldGFkYXRhIHdlIHByb2JhYmx5IHdhbnQgYSByZWdp c3RyeSB3aXRoIHZlcnkgZWVhc3kgZW50cnkgY3JlYXRpb24uDQoNClNvcnJ5LA0KSm9lbA0KDQpP biAyLzI2LzE1IDE6MjAgUE0sIEptaC5kaXJlY3Qgd3JvdGU6DQo+IEluc3RydWN0aW9uIGNvbWVz IGZyb20gdGhlIHNldmljZSBmdW5jdGlvbiBkZXNpZ24uICBTb21lIGhlYWRlciANCj4gc3RydWN0 dXJlcyBhdWdtZW50IHRoYXQgd2l0aCBjb250cm9sIG1hcHBpbmcgaWJmb3JtYXRpb24gdG8gaW5k aWNhdGUgDQo+IHdoaWNoIG1ldGFkYXRhIGZpZWxkIGhhcyB3aGljaCB1c2UuDQo+DQo+IEdvciBU TFYgYmFzZWQgbWV0YWRhdCB3ZSBwcm9iYWJseSBlYW50IGEgcmVnaXN0cnkgd2l0aCB2ZXJ5IGVh c3kgZW50cnkgDQo+IGNyZWF0aW9uLg0KPg0KPiBZb3VycywNCj4gSm9lbA0KPg0KPg0KPiBTZW50 IGZyb20gbXkgU2Ftc3VuZyBzbWFydHBob25lIG9uIEFUJlQNCj4NCj4NCj4NCj4gLS0tLS0tLS0g T3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQ0KPiBTdWJqZWN0OiBSRTogW3NmY10gZHJhZnQtcXVp bm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzDQo+IEZyb206IERhdmUgRG9sc29uIDxk ZG9sc29uQHNhbmR2aW5lLmNvbT4NCj4gVG86ICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhh bHBlcm4uY29tPiwiUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pIg0KPiA8cmVwZW5ub0BjaXNjby5j b20+LFJvbiBQYXJrZXINCj4gPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+LCJtb2hh bWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIg0KPiA8bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNv bT4sInNmY0BpZXRmLm9yZyIgPHNmY0BpZXRmLm9yZz4NCj4gQ0M6ICJCZW4gV3JpZ2h0IChCZW4u V3JpZ2h0QG1ldGFzd2l0Y2guY29tKSIgDQo+IDxCZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tPg0K Pg0KPg0KPiBXaGF0IGFyZSB0aGUgbWVjaGFuaWNzIG9mIHVzaW5nIG1ldGEtZGF0YT8NCj4gV2hp Y2ggZWxlbWVudCBzZXRzIGl0LCBhbmQgaG93IGlzIGl0IGluc3RydWN0ZWQgdG8gZG8gc28/DQo+ DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZWwgTS4gSGFscGVy biBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFy eSAyNiwgMjAxNSAxMjozNiBQTQ0KPiBUbzogRGF2ZSBEb2xzb247IFJlaW5hbGRvIFBlbm5vIChy ZXBlbm5vKTsgUm9uIFBhcmtlcjsgDQo+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNm Y0BpZXRmLm9yZw0KPiBDYzogQmVuIFdyaWdodCAoQmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbSkN Cj4gU3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LXF1aW5uLXNmYy1uc2g6IFN1cHBvcnQgb2YgU0Yg U3BpcmFscw0KPg0KPiBQZXJzb25hbGx5LCBJIHdvdWxkIHByZWZlciB0aGF0IHRoZSBmaXJld2Fs bCB1c2UgbWV0YWRhdGEgcmF0aGVyIHRoYW4gDQo+IHBhdGgtaW5kZXguICBNeSByZWFzb25pbmcg aXMgdGhhdCBpZiBmdW5jdGlvbnMgZ2V0IGFkZGVkIGJlZm9yZSBvciANCj4gYWZ0ZXIgdGhlIGZp cmV3YWxsLCBvcGVyYXRpb25zIHdvdWxkIHByZWZlciBub3QgdG8gaGF2ZSB0byBjaGFuZ2UgdGhl IA0KPiBjb25maWd1cmF0aW9uIG9mIHRoZSBmaXJld2FsbCBTRiBpdHNlbGYuDQo+DQo+IEhhdmlu ZyBzYWlkIHRoYXQsIEkgZG9uJ3Qgc2VlIGFueSB3YXkgdG8gc3RvcCB5b3UgZnJvbSB1c2luZyB0 aGUgcGF0aCBpbmRleC4NCj4NCj4gWW91cnMsDQo+IEpvZWwNCj4NCj4gT24gMi8yNi8xNSAxMjoz MCBQTSwgRGF2ZSBEb2xzb24gd3JvdGU6DQo+ICA+IEZvciB0aGUgc2FrZSBvZiBhcmd1bWVudCwg c3VwcG9zZSBJIGhhdmUgYSBmaXJld2FsbCBTRiwgYW5kIEkgd2FudCANCj4gdG8gdXNlICA+IGl0 IG1vcmUgdGhhbiBvbmNlIGluIGEgY2hhaW4uIChNYXliZSBJIHdhbnQgdG8gYm9vay1lbmQgdGhl IA0KPiBjaGFpbiB3aXRoIGluZ3Jlc3MgID4gYW5kIGVncmVzcyBydWxlcy4pICA+ICA+IERvIHlv dSBhZ3JlZSBpdCB3b3VsZCANCj4gYmUgc3VmZmljaWVudCB0byB1c2UgdGhlIFBhdGggSW5kZXgg dG8gc2VsZWN0IHdoaWNoIG9mICA+IHRoZSBpbmdyZXNzIA0KPiBvciBlZ3Jlc3MgcnVsZSBzZXRz IHNob3VsZCBiZSB1c2VkPw0KPiAgPg0KPiAgPiBJJ20gcHJvYmFibHkgbWlzc2luZyBzb21ldGhp bmc7IEkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgdGhlIGNvbnRleHQgDQo+IGhlYWRlcnMgID4gZGVm aW5lIGZ1bmN0aW9uYWxpdHkuIE1heWJlIHRoZSBkZXZpY2UgY291bGQgY29tbXVuaWNhdGUgDQo+ IHdpdGggaXRzZWxmICA+IChlLmcuLCB0aGUgaW5ncmVzcyBwb3J0aW9uIHNlbmRpbmcgYSB0YWcg dG8gdGhlIGVncmVzcyANCj4gcG9ydGlvbikgID4gYnkgc2VuZGluZyBzdGF0ZSBpbiB0aGUgcGFj a2V0LiBJcyB0aGF0IHdoYXQgeW91IGFyZSBtZWFuIA0KPiBieSAiY29udGV4dHVhbCBpbmZvIiA/ DQo+ICA+DQo+ICA+DQo+ICA+DQo+ICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICA+ IEZyb206IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKSBbbWFpbHRvOnJlcGVubm9AY2lzY28uY29t XSAgPiBTZW50OiANCj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE1IDEyOjE4IFBNICA+IFRv OiBEYXZlIERvbHNvbjsgUm9uIFBhcmtlcjsgDQo+IEpvZWwgTS4gSGFscGVybjsgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnICA+IENjOiBCZW4gDQo+IFdyaWdodCAo QmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbSkgID4gU3ViamVjdDogUmU6IFtzZmNdIA0KPiBkcmFm dC1xdWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHMgID4gID4gQWdyZWVkIG9uIGFs bCBwb2ludHMuIA0KPiBJIHRob3VnaHQgSSB3YXMgbWlzc2luZyBzb21ldGhpbmcgc28gYmVmb3Jl IHdyaXRpbmcgID4gdGhpcyBlbWFpbCBJIA0KPiByZXRlc3RlZCBvdXIgaW1wbGVtZW50YXRpb24g YW5kIGl0IHdvcmtlZCBvZmYgdGhlIGJhdC4gVGhlICA+IFJTUCANCj4gY29uc3RydWN0ZWQgaGFz IHRoZSB0aGUgc2FtZSAoU0ZGLCBTRikgdHVwbGUgYnV0IGRpZmZlcmVudCBpbmRleGVzLg0KPiAg Pg0KPiAgPiBUaGUgc2FtZSBTRiBpcyB2aXNpdGVkIG11bHRpcGxlIHRpbWVzIHVudGlsIHRoZSBw YXRoIGVuZHMuICBJZiB0aGUgDQo+IFNGICA+IHdhbnRzIGNvbnRleHR1YWwgaW5mbyBhY3Jvc3Mg dmlzaXRzIHRoYW4gY29udGV4dCBoZWFkZXJzIGFyZSB0aGUgDQo+IHdheSB0byAgPiBnby4NCj4g ID4NCj4gID4NCj4gID4gT24gMi8yNi8xNSwgODo1MiBBTSwgIkRhdmUgRG9sc29uIiA8ZGRvbHNv bkBzYW5kdmluZS5jb20+IHdyb3RlOg0KPiAgPg0KPiAgPj4gTWF5YmUgbmFpdmVseSwgSSB0aG91 Z2h0IHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyB3b3VsZCBiZSANCj4gcHJvdmlzaW9uZWQgd2l0aCAg Pj4gYSB0YWJsZToNCj4gID4+DQo+ICA+PiBFLmcuLCBmb3IgZWxlbWVudCBmb286DQo+ICA+PiBQ YXRoIHwgUGF0aCBJbmRleCB8IE5leHQgSG9wICB8IEZ1bmN0aW9uDQo+ICA+PiAxMjMgfCAgNCAg ICAgICAgIHwgICBTRi1iYXIgIHwgZmlyc3QgYmVoYXZpb3INCj4gID4+IDEyMyB8ICAyICAgICAg ICAgfCBTRi1mb29iYXIgfCBzZWNvbmQgYmVoYXZpb3INCj4gID4+DQo+ICA+Pg0KPiAgPj4gVGhl IEZ1bmN0aW9uIGlzIGNsZWFybHkgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuIE1heWJlIGl0IHBv aW50cyANCj4gdG8gYSAgPj4gY29uZmlndXJhdGlvbiBzZXQgb3IgYSBwb2xpY3kgc2V0LiBJIHRo aW5rIGNvbXBsZXRlbHkgb3V0IG9mIHNjb3BlIGhlcmUuDQo+ICA+Pg0KPiAgPj4gSSBzdWdnZXN0 IHRoYXQgdGhpcyBpcyBub3QgYSBwcm9ibGVtIGZvciB0aGUgd2lyZSBwcm90b2NvbCwgcmF0aGVy IA0KPiBmb3IgID4+IHRoZSBjb25maWd1cmF0aW9uIG1vZGVsIChuZXRjb25mIG9yIHdoYXRldmVy KS4NCj4gID4+DQo+ICA+PiBJdCBiZWNvbWVzIHZlcnkgbXVjaCB2ZW5kb3Itc3BlY2lmaWMgaWYg dGhlIGJlaGF2aW9ycyBhcmUgY29tcGxleCAgDQo+ID4+IGNvbmZpZ3VyYXRpb25zIG9mIHNwZWNp YWxpemVkIGZlYXR1cmVzLg0KPiAgPj4NCj4gID4+IElmIGEgcGVyc29uIHdlcmUgbWFudWFsbHkg Y29uZmlndXJpbmcgY2hhaW5zLCBJIGRvbid0IHRoaW5rIHRoZXknZCANCj4gaGF2ZSBhICA+PiBj b25jZXB0dWFsIHByb2JsZW0sIGJlY2F1c2UgdGhleSdkIGhhdmUgYSBkaWFncmFtIHRoZXkgbmVl ZCANCj4gdG8NCj4gaW1wbGVtZW50Og0KPiAgPj4ge1NGLWZvbyAoZmlyc3QtYmVoYXZpb3IpLCBT Ri1iYXIsIFNGLWZvbyAoc2Vjb25kLWJlaGF2aW9yKSwgDQo+IFNGLWZvb2Jhcn0gID4+ICA+PiBJ ZiB3ZSB3YW50ZWQgdG8gc3RhbmRhcmRpemUgaXQsIHdlIGNvdWxkIG1heWJlIG1ha2UgDQo+IHRo ZSBGdW5jdGlvbiBzaW1wbHkgYSAgPj4gbGFiZWwgdGhhdCBtZWFucyBzb21ldGhpbmcgdG8gdGhl IGRldmljZS0tYW4gDQo+IGluZGlyZWN0aW9uIHRvIGEgID4+IGNvbmZpZ3VyYXRpb24gc2V0Lg0K PiAgPj4NCj4gID4+IC1EYXZlDQo+ICA+Pg0KPiAgPj4NCj4gID4+DQo+ICA+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiAgPj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBSb24gUGFya2VyICANCj4gPj4gU2VudDogVGh1cnNkYXksIEZl YnJ1YXJ5IDI2LCAyMDE1IDExOjMxIEFNICA+PiBUbzogRGF2ZSBEb2xzb247IA0KPiBKb2VsIE0u IEhhbHBlcm47IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207ICA+PiBzZmNAaWV0Zi5vcmcg ID4+IA0KPiBDYzogQmVuIFdyaWdodCAoQmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbSkgID4+IFN1 YmplY3Q6IFJlOiBbc2ZjXSANCj4gZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBT cGlyYWxzICA+PiAgPj4gSGksIERhdmUuDQo+ICA+Pg0KPiAgPj4gSSBhZ3JlZSB0aGF0IG9uIHRo ZSB3aXJlLCB0aGlzIGlzIHRoZSB3YXkgaXQgd291bGQgd29yay4NCj4gID4+DQo+ICA+PiBCdXQs IHdoZW4gY29tcG9zaW5nIHRoZSBjaGFpbiwgaXQgc2VlbXMgbGlrZSBpbmZvcm1hdGlvbiB3b3Vs ZCBiZSANCj4gbGFja2luZyAgPj4gaWYgYSBjaGFpbiB3ZXJlIGV4cHJlc3NlZCBzaW1wbHkgYXMg e1NGLWZvbywgU0YtYmFyLCANCj4gU0YtZm9vLCBTRi1mb29iYXJ9Lg0KPiAgPj4gICBJdCBpcyBj b21wbGV0ZWx5IGltcGxpY2l0IHRoYXQgc2luY2UgU0YtZm9vIGFwcGVhcnMgdHdpY2UsIGl0IHBl cmhhcHMNCj4gID4+IHNob3VsZCBwZXJmb3JtIHNvbWUgZGlmZmVyZW50IGR1dHkgd2hlbiBpbmRl eCA9IDAgdnMgd2hlbiBpbmRleCA9IDIuDQo+ICA+Pg0KPiAgPj4gQXQgZmlyc3QsIEkgdGhvdWdo dCB0aGF0IGFuIGFsdGVybmF0aXZlIHdheSB0byBoYW5kbGUgdGhpcyB3b3VsZCANCj4gYmUgdG8g ID4+IHVzZSBtdWx0aXBsZSBsb2dpY2FsIGlkZW50aXRpZXMgZm9yIFNGLWZvby4gIEluIHRoaXMg Y2FzZSwgDQo+IHRoZSBjaGFpbiAgPj4gYWJvdmUgd291bGQgYmUgZXhwcmVzc2VkIGFzIHtTRi1m b28tZmlyc3QtYmVoYXZpb3IsIFNGLWJhciwNCj4gID4+IFNGLWZvby1zZWNvbmQtYmVoYXZpb3Is IFNGLWZvb2Jhcn0uICAgQnV0LCB0aGUgcHJvYmxlbSBoZXJlIGlzIHNlbGVjdGluZw0KPiAgPj4g dGhlIFJTUCwgYXNzdW1pbmcgdGhhdCBTRi1mb28gaGFzIG11bHRpcGxlIGluc3RhbmNlcy4gICBO b3RoaW5nIGluIHRoaXMNCj4gID4+IHNlY29uZCBmbGF2b3Igb2YgY2hhaW4gc2F5cyB0aGF0IHRo ZSBzYW1lIGluc3RhbmNlIG9mIFNGLWZvby0qIA0KPiBtdXN0IGJlICA+PiBzZWxlY3RlZCB0byBz YXRpc2Z5IFNGLWZvby1maXJzdC1iZWhhdmlvciBhbmQgDQo+IFNGLWZvby1zZWNvbmQtYmVoYXZp b3IgID4+ICh3aGljaCBtYXkgbm90IGJlIHJlcXVpcmVkLCBidXQgc2hvdWxkIGJlIHBvc3NpYmxl IHRvIGZvcmNlIGFzIHN1Y2gpLg0KPiAgPj4NCj4gID4+IEkgZ3Vlc3Mgd2hhdCBJJ20gc2F5aW5n IGlzIHRoYXQgc3BpcmFsaW5nIGhhcyBhIHN1YnRsZXR5IHRvIGl0IA0KPiB0aGF0IGlzbid0ICA+ PiB5ZXQgYWRlcXVhdGVseSBhZGRyZXNzZWQgYW5kIHRoYXQgSSBkb24ndCBoYXZlIGEgDQo+IHNw ZWNpZmljIHByb3Bvc2FsIHRvICA+PiBzb2x2ZSBpdCwgZWl0aGVyLg0KPiAgPj4NCj4gID4+ICAg IFJvbg0KPiAgPj4NCj4gID4+DQo+ICA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAg Pj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBE YXZlIERvbHNvbiAgDQo+ID4+IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAxMToy MSBBTSAgPj4gVG86IEpvZWwgTS4gSGFscGVybjsgDQo+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb207IHNmY0BpZXRmLm9yZyAgPj4gQ2M6IEJlbiBXcmlnaHQgDQo+IChCZW4uV3JpZ2h0QG1l dGFzd2l0Y2guY29tKSAgPj4gU3ViamVjdDogUmU6IFtzZmNdIA0KPiBkcmFmdC1xdWlubi1zZmMt bnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHMgID4+ICA+PiBJZiBJIG1heSB0cnkgdG8gcHV0IA0K PiBpdCBzaW1wbHksIEkndmUgYWx3YXlzIHRob3VnaHQgb2YgaXQgdGhpcyB3YXk6DQo+ICA+PiAt LT4gRWFjaCBub2RlIGluIHRoZSBjaGFpbiBzZWxlY3RzIHRoZSBjb250ZXh0IGZvciBwcm9jZXNz aW5nIGFuZCANCj4gdGhlICA+PiBuZXh0IGhvcCBvbiB0aGUgYmFzaXMgb2YgQk9USCBwYXRoIElE IGFuZCBJbmRleCwgd2hpbGUgDQo+IGRlY3JlbWVudGluZyB0aGUgID4+IGluZGV4IGZvciB0aGUg bmV4dCBob3AuDQo+ICA+Pg0KPiAgPj4gVGhhdCBiZWhhdmlvciBzdXBwb3J0cyBzcGlyYWxpbmcu DQo+ICA+Pg0KPiAgPj4NCj4gID4+DQo+ICA+PiAtRGF2ZQ0KPiAgPj4NCj4gID4+DQo+ICA+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAgPj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2VsIE0uIA0KPiBIYWxwZXJuICA+PiBTZW50 OiBUaHVyc2RheSwgRmVicnVhcnkgMjYsIDIwMTUgMTA6MDIgQU0gID4+IFRvOiANCj4gbW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsgc2ZjQGlldGYub3JnICA+PiBDYzogQmVuIFdyaWdodCAN Cj4gKEJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb20pICA+PiBTdWJqZWN0OiBSZTogW3NmY10gDQo+ IGRyYWZ0LXF1aW5uLXNmYy1uc2g6IFN1cHBvcnQgb2YgU0YgU3BpcmFscyAgPj4gID4+IFRoZXJl IGFyZSB0d28gDQo+IGRpZmZlcmVudCBhc3BlY3RzIG9mIFNwaXJhbHMuDQo+ICA+Pg0KPiAgPj4g T25lIG9mIHRoZSB0d28gYXNwZWN0cyBpcyBlbmFibGluZyBhIHBhY2tldCB0aGF0IHJlcGVhdGVk bHkgDQo+IGFycml2ZXMgYXQgID4+IHRoZSBzYW1lIFNGRiB0byBnZXQgdGhlIGNvcnJlY3Qgc2Vy dmljZXMgcHJvdmlkZWQgZWFjaCANCj4gdGltZSBpdCBhcnJpdmVzLCAgPj4gYW5kIHRvIGdvIHRv IHRoZSBjb3JyZWN0IG5leHQgU0ZGIGVhY2ggdGltZSBpdCANCj4gYXJyaXZlcy4gIFRoZSBTZXJ2 aWNlIFBhdGggID4+IEluZGV4LCB1c2VkIGJ5IHRoZSBTRkYgdG8gc2VsZWN0IA0KPiBzZXJ2aWNl IGZ1bmN0aW9ucyBhbmQgbmV4dCBTRkYsIHByb3ZpZGVzICA+PiB0aGF0IGNhcGFiaWxpdHkuDQo+ ICA+Pg0KPiAgPj4gVGhlIG90aGVyIGFzcGVjdCBpcyBob3cgdGhlIFNlcnZpY2UgRnVuY3Rpb25z IHRoZW1zZWx2ZXMgaGFuZGxlIHNwaXJhbHMuDQo+ICA+PiAgIFRvIGEgbGFyZ2UgZGVncmVlLCB0 aGF0IGRlcGVuZHMgdXBvbiB0aGUgaW5kaXZpZHVhbCBzZXJ2aWNlIGZ1bmN0aW9uLg0KPiAgPj4g ICBJIG5vcm1hbGx5IGFzc3VtZSB0aGF0IGl0IHdvdWxkIHVzZSBwYWNrZXQgY29udGV4dCAoYXMg ZGVzY3JpYmVkDQo+IGluIHRoZQ0KPiAgPj4gdGV4dCB5b3UgcXVvdGUpIHRvIGRldGVybWluZSB3 aGF0IHRvIGRvLg0KPiAgPj4NCj4gID4+IFNpbmNlIEkgd291bGQgcHJlZmVyIHRoYXQgc2Vydmlj ZSBmdW5jdGlvbnMgYXJlIGluZGVwZW5kZW50IG9mIHRoZSAgDQo+ID4+IHVuZGVybHlpbmcgc2Vy dmljZSBmdW5jdGlvbiBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZSwgYW5kIGFyZSBub3QgIA0KPiA+ PiBzZW5zaXRpdmUgdG8gaG93IG1hbnkgZnVuY3Rpb25zIGFyZSBiZWZvcmUgb3IgYWZ0ZXIgdGhl bSBpbiB0aGUgDQo+IGNoYWluLCBJICA+PiB3b3VsZCBwZXJzb25hbGx5IHByZWZlciB0aGF0IHRo ZXkgbm90IHVzZSB0aGUgcGF0aCBpbmRleCANCj4gZm9yIHRoYXQuICBJICA+PiB3b3VsZCByZWNv bW1lbmQgdGhhdCBpZiB0aGUgcGFja2V0IGRvZXMgbm90IGNhcnJ5IA0KPiBlbm91Z2ggY29udGV4 dCB0aGF0IHRoZSAgPj4gc2VydmljZSBmdW5jdGlvbiBjb3VsZCBhbmQgc2hvdWxkIHVzZSANCj4g bWV0YWRhdGEgdG8gY2FycnkgaXRzIG5lZWRlZCBzdGF0ZSAgPj4gaW5mb3JtYXRpb24uICBCdXQg bmVpdGhlciBJIA0KPiBwZXJzb25hbGx5IG5vciB0aGUgU0ZDIFdvcmtpbmcgR3JvdXAgZ2V0IHRv ICA+PiB0ZWxsIGZvbGtzIGhvdyB0byANCj4gYnVpbGQgdGhlaXIgc2VydmljZSBmdW5jdGlvbnMu ICBTbyB0aGV5IG1heSBjb21lIHVwICA+PiB3aXRoIG90aGVyIA0KPiBtZXRob2RzIGZvciBhZGRy ZXNzaW5nIHRoZWlyIG5lZWRzLiAgV2hpY2ggaXMgYWxzbyBmaW5lLg0KPiAgPj4NCj4gID4+IFRo dXMsIEkgd291bGQgbm90IGV4cGVjdCB0aGlzIGRvY3VtZW50IHRvIGRpc2N1c3MgaG93IHNlcnZp Y2UgDQo+IGZ1bmN0aW9ucyAgPj4gdGhlbXNlbHZlcyBoYW5kbGUgcmV2aXNpdGluZy4gIEJ1dCBt ZXRhZGF0YSBjbGVhcmx5IA0KPiBhbGxvd3MgZm9yIGEgcmFuZ2Ugb2YgID4+IGJlaGF2aW9ycyB0 aGF0IHdpbGwgd29yay4gIEFuZCB0aGUgcGF0aCANCj4gaW5kZXggaGFuZGxlcyB0aGUgU0ZGIG5l ZWRzICA+PiByZWxhdGl2ZSB0byBzcGlyYWxzLCB3aGljaCBpcyB3aGF0IHdlIA0KPiBuZWVkIHRv IGhhbmRsZS4NCj4gID4+DQo+ICA+PiBZb3VycywNCj4gID4+IEpvZWwNCj4gID4+DQo+ICA+PiBP biAyLzI2LzE1IDk6NTIgQU0sIG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ ICA+Pj4gUmUtLA0KPiAgPj4+DQo+ICA+Pj4gU3BpcmFsIGlzIG5vdCBtZW50aW9uZWQgaW4gdGhl IGRyYWZ0LCBidXQgU0YgbG9vcCBpcy4NCj4gID4+Pg0KPiAgPj4+IEknbSBhc2tpbmcgdGhlIHF1 ZXN0aW9uIGJlY2F1c2UgSSBkb24ndCBnZXQgZnJvbSB0aGUgZHJhZnQgaG93IA0KPiBzcGlyYWxz ICA+Pj4gY291bGQgd29yayAodGhhdCBpcyBhIFNGIGludm9rZWQgc2V2ZXJhbCB0aW1lIGluIHRo ZSANCj4gY29udGV4dCBvZiB0aGUgc2FtZSAgPj4+IFNGQykuDQo+ICA+Pj4NCj4gID4+PiBCZWZv cmUgcHJvcG9zaW5nIHRleHQsIEkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIGZpcnN0IGhvdyBp dCB3b3Jrcy4NCj4gID4+PiBJZiB5b3UgY2FuIHByb3ZpZGUgYW4gZXhhbXBsZSwgdGhpcyB3aWxs IGJlIGV2ZW4gZ3JlYXQuDQo+ICA+Pj4NCj4gID4+PiBUaGFuayB5b3UuDQo+ICA+Pj4NCj4gID4+ PiBDaGVlcnMsDQo+ICA+Pj4gTWVkDQo+ICA+Pj4NCj4gID4+Pj4gLS0tLS1NZXNzYWdlIGQnb3Jp Z2luZS0tLS0tDQo+ICA+Pj4+IERlIDogSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am1oQGpvZWxo YWxwZXJuLmNvbV0gRW52b3nDqSA6IGpldWRpIA0KPiAyNiAgPj4+PiBmw6l2cmllciAyMDE1IDE1 OjQxIMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgc2ZjQGlldGYub3JnIENjIDoNCj4g ID4+Pj4gQmVuIFdyaWdodCAoQmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbSkgT2JqZXQgOiBSZTog W3NmY10gID4+Pj4gDQo+IGRyYWZ0LXF1aW5uLXNmYy1uc2g6IFN1cHBvcnQgb2YgU0YgU3BpcmFs c2d0Oz4+PiAgPj4+PiBUaGUgU0YgU3BpcmFscyANCj4gcmVxdWlyZW1lbnQgaXMgb25lIG9mIHRo ZSBrZXkgZHJpdmVycyBmb3IgdGhlIGluZGV4Lg0KPiAgPj4+PiBUaGUgaW5kZXggYWxsb3dzIG9u ZSB0byB0ZWxsIHdoZXJlIG9uZSBpcyBpbiB0aGUgc3BpcmFsLCBhbmQgDQo+IGFsc28gdG8gID4+ Pj4gYnJlYWsgYSBsb29wIGlmIG9uZSBoYXMgYSBsb29wIGluc3RlYWQgb2YgYSBzcGlyYWwuDQo+ ICA+Pj4+DQo+ICA+Pj4+IElzIHRoZXJlIHRleHQgdGhhdCB3ZSBjb3VsZCBhZGQgdGhhdCB3b3Vs ZCBoZWxwIG1ha2UgdGhpcyBjbGVhciwgIA0KPiA+Pj4+IHNpbmNlIHlvdXIgZWFybGllciBxdWVz dGlvbiBhYm91dCB0aGUgcGF0aCBpbmRleCBzdWdnZXN0cyB0aGF0IGl0IA0KPiBpcyAgPj4+PiBu b3QgYXMgY2xlYXIgYXMgaXQgc2hvdWxkIGJlPw0KPiAgPj4+Pg0KPiAgPj4+PiBZb3VycywNCj4g ID4+Pj4gSm9lbA0KPiAgPj4+Pg0KPiAgPj4+PiBPbiAyLzI2LzE1IDg6NDIgQU0sIG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ICA+Pj4+PiBIaSBQYXVsLCBhbGwsDQo+ICA+ Pj4+Pg0KPiAgPj4+Pj4gVGhlcmUgd2VyZSBhIGRpc2N1c3Npb24gaW4gdGhlIG1haWxpbmcgbGlz dCAgPj4+Pj4gDQo+IChodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2ZjL2N1 cnJlbnQvbXNnMDE3MDEuaHRtbCkNCj4gID4+Pj4+IHRoYXQgbGVkIHRvIGRlZmluaW5nIHdoYXQg aXMgbWVhbnQgYnkgU0YgU3BpcmFsczogKGJlbG93IGlzIA0KPiBwcm92aWRlZCAgPj4+Pj4gYW4g ZXhjZXJwdCBmcm9tICA+Pj4+PiANCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Ym91Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDYgd2hlcmUgIA0KPiA+Pj4+PiB0aGUgY29uY2x1 c2lvbnMgb2YgdGhhdCBkaXNjdXNzaW9uIHdlcmUgcmVjb3JkZWQpICA+Pj4+Pg0KPiAgPj4+Pj4g IiAgIG8gIFNlcnZpY2UgRnVuY3Rpb24gU3BpcmFsOiBkZW5vdGVzIGEgU2VydmljZSBGdW5jdGlv biBDaGFpbiBpbg0KPiAgPj4+PiB3aGljaA0KPiAgPj4+Pj4NCj4gID4+Pj4+ICAgICAgICAgIGRh dGEgaXMgaGFuZGxlZCBieSBhIFNlcnZpY2UgRnVuY3Rpb24sIGZvcndhcmRlZCBvbndhcmRzLA0K PiAgPj4+Pj4gYW5kDQo+ICA+Pj4+Pg0KPiAgPj4+Pj4gICAgICAgICAgYXJyaXZlcyBvbmNlIGFn YWluIGF0IHRoYXQgU2VydmljZSBGdW5jdGlvbi4NCj4gID4+Pj4+DQo+ICA+Pj4+PiAgICAgICAg ICAqICBOb3RlIHRoYXQgc29tZSBTZXJ2aWNlIEZ1bmN0aW9ucyBzdXBwb3J0IGJ1aWx0LWluDQo+ ICA+Pj4+PiBmdW5jdGlvbnMgdG8NCj4gID4+Pj4+DQo+ICA+Pj4+PiAgICAgICAgICAgICBhY2Nv bW1vZGF0ZSBzcGlyYWxzOyB0aGVzZSBzZXJ2aWNlLXNwZWNpZmljIGZ1bmN0aW9ucyBtYXkNCj4g ID4+Pj4+DQo+ICA+Pj4+PiAgICAgICAgICAgICByZXF1aXJlIHRoYXQgdGhlIGRhdGEgcmVjZWl2 ZWQgaW4gYSBzcGlyYWwgc2hvdWxkIGRpZmZlcg0KPiAgPj4+Pj4gaW4gYQ0KPiAgPj4+Pj4NCj4g ID4+Pj4+ICAgICAgICAgICAgIHdheSB0aGF0IHdpbGwgcmVzdWx0IGluIGEgZGlmZmVyZW50IHBy b2Nlc3NpbmcgZGVjaXNpb24NCj4gID4+Pj4+IHRoYW4NCj4gID4+Pj4+DQo+ICA+Pj4+PiAgICAg ICAgICAgICB0aGUgb3JpZ2luYWwgZGF0YS4gIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgbWFrZSBz dWNoDQo+ICA+Pj4+Pg0KPiAgPj4+Pj4gICAgICAgICAgICAgYXNzdW1wdGlvbi4NCj4gID4+Pj4+ DQo+ICA+Pj4+PiAgICAgICAgICAqICBBIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gbWF5IGludm9s dmUgb25lIG9yIG1vcmUgU2VydmljZQ0KPiAgPj4+Pj4NCj4gID4+Pj4+ICAgICAgICAgICAgIEZ1 bmN0aW9uIFNwaXJhbHMuDQo+ICA+Pj4+Pg0KPiAgPj4+Pj4gICAgICAgICAgKiAgVW5saWtlIFNl cnZpY2UgRnVuY3Rpb24gbG9vcCwgc3BpcmFscyBhcmUgbm90IGNvbnNpZGVyZWQNCj4gID4+Pj4+ IGFzDQo+ICA+Pj4+Pg0KPiAgPj4+Pj4gICAgICAgICAgICAgZXJyb3JzLiINCj4gID4+Pj4+DQo+ ICA+Pj4+PiBBbmQgdGhpcyBjb21wYW5pb24gcmVxdWlyZW1lbnQ6DQo+ICA+Pj4+Pg0KPiAgPj4+ Pj4gIiAgICAgICAgICAgICAgIEEuICBTZXJ2aWNlIEZ1bmN0aW9ucyBNQVkgYmUgaW52b2tlZCBt dWx0aXBsZQ0KPiB0aW1lcyBpbg0KPiAgPj4+Pj4NCj4gID4+Pj4+ICAgICAgICAgICAgICAgICAg ICAgICB0aGUgc2FtZSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluIChkZW5vdGVkIGFzIFNGDQo+ICA+ Pj4+Pg0KPiAgPj4+Pj4gICAgICAgICAgICAgICAgICAgICAgIFNwaXJhbCksIGJ1dCB0aGUgc29s dXRpb24gTVVTVCBwcmV2ZW50IGluZmluaXRlDQo+ICA+Pj4+Pg0KPiAgPj4+Pj4gICAgICAgICAg ICAgICAgICAgICAgIGZvcndhcmRpbmcgbG9vcHMuIMK7DQo+ICA+Pj4+Pg0KPiAgPj4+Pj4gUmVh ZGluZyB0aGUgY3VycmVudCBkcmFmdC1xdWlubi1zZmMtbnNoLCBJIGRvbid0IHNlZSBob3cgdGhp cyBpcyBtZXQuDQo+ICA+Pj4+Pg0KPiAgPj4+Pj4gQ2FuIHlvdSBwbGVhc2UgY2xhcmlmeSB3aGV0 aGVyIHRoaXMgaXMgc3VwcG9ydGVkIGFuZCBob3c/DQo+ICA+Pj4+Pg0KPiAgPj4+Pj4gVGhhbmsg eW91Lg0KPiAgPj4+Pj4NCj4gID4+Pj4+IENoZWVycywNCj4gID4+Pj4+DQo+ICA+Pj4+PiBNZWQN Cj4gID4+Pj4+DQo+ICA+Pj4+Pg0KPiAgPj4+Pj4NCj4gID4+Pj4+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICA+Pj4+PiBzZmMgbWFpbGluZyBsaXN0 DQo+ICA+Pj4+PiBzZmNAaWV0Zi5vcmcNCj4gID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2ZjDQo+ICA+Pj4+Pg0KPiAgPj4+DQo+ICA+Pg0KPiAgPj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gID4+IHNmYyBtYWls aW5nIGxpc3QNCj4gID4+IHNmY0BpZXRmLm9yZw0KPiAgPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zZmMNCj4gID4+DQo+ICA+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgPj4gc2ZjIG1haWxpbmcgbGlzdA0KPiAgPj4g c2ZjQGlldGYub3JnDQo+ICA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NmYw0KPiAgPj4NCj4gID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ICA+PiBzZmMgbWFpbGluZyBsaXN0DQo+ICA+PiBzZmNAaWV0Zi5vcmcNCj4g ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ICA+Pg0KPiAg Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gID4+ IHNmYyBtYWlsaW5nIGxpc3QNCj4gID4+IHNmY0BpZXRmLm9yZw0KPiAgPj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMNCj4gID4NCj4gID4NCg== From nobody Thu Feb 26 13:22:47 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 1837F1ACCEC for ; Thu, 26 Feb 2015 13:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yB3xz8x_477e for ; Thu, 26 Feb 2015 13:22:40 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9C11AC430 for ; Thu, 26 Feb 2015 13:22:32 -0800 (PST) X-AuditID: c618062d-f79376d000000ceb-d1-54ef3a2e0e42 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 1E.39.03307.E2A3FE45; Thu, 26 Feb 2015 16:22:23 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0210.002; Thu, 26 Feb 2015 16:22:30 -0500 From: Joel Halpern To: Linda Dunbar , Ron Parker , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 Thread-Index: AdBRG3N71HhtcFa0RsuzFw1dT6iegwAAMTdQAABKvqAAABrE4AABrb3gADKL8WAABtoL4A== Date: Thu, 26 Feb 2015 21:22:30 +0000 Message-ID: <6BCE198E4EAEFC4CAB45D75826EFB07603350E22@eusaamb101.ericsson.se> References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE3CC3@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645EE3CC3@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_6BCE198E4EAEFC4CAB45D75826EFB07603350E22eusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLonVlff6n2IwQZXi0/vdrBY3G2ZyGRx 4elUZosnD7ayO7B4vLjyjNljyu+NrB4tR96yeixZ8pMpgCWKyyYlNSezLLVI3y6BK+Pdjnb2 gs5PjBVTV+xka2DsvcrYxcjJISFgItH+bAkzhC0mceHeerYuRi4OIYEjjBKbN11nhnCWM0pc /D4RrIpNQE9i7fvHTCAJEYH1jBLz9y0ESwgLpEtcvjQbzBYRyJA4vbYXaBQHkB0msWBPIkiY RUBVYvaiHlYQm1fAV6Lr+mRWiAWTmSU232tmB0lwCrhKbP61D6yIEeik76fWMIHYzALiEree zGeCOFVAYsme81Bni0q8fPyPFcJWlNjXP50doj5fYvWe08wQywQlTs58wjKBUWQWklGzkJTN QlIGEdeRWLD7ExuErS2xbOFrZhj7zIHHTMjiCxjZVzFylBanluWmGxlsYgTG2jEJNt0djHte Wh5iFOBgVOLh3SD9LkSINbGsuDL3EKM0B4uSOO+iBwdDhATSE0tSs1NTC1KL4otKc1KLDzEy cXBKNTC2c1+4u+3VDdt66+LEM0euztrXGro5T7Rp4QGbfWcqHzXX7pc9dahJQ/PXRUeBLwn1 z6Lbc3oVal4HzbjeYHT01ZHz8xM5RZhCjt42nS88w0NJJi7k3tFP3XP5zi25vYLp8809Wlzf HOa9aynZcWVGctiP7QzVqT1RPZf25Jn5BzPtitQ7+V5fiaU4I9FQi7moOBEAeLvSo5YCAAA= Archived-At: Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 26 Feb 2015 21:22:46 -0000 --_000_6BCE198E4EAEFC4CAB45D75826EFB07603350E22eusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable While Ron's wording was roughly right, it did not seem to add anything to w= hat we had, and was not written as a definition, but as a description. As = such, the question is whether it adds anything to the descriptive text furt= her in the document. Also, it is quite possible to have tighter ordering constraints on an SFP t= han on an SFC. How tight the ordering constraints are in the SFC probably = depends upon the SFC definer and tools. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, February 26, 2015 1:34 PM To: Ron Parker; Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I think Ron's suggested wording for SFC is much more straight forward than = the current SFC definition on the sfc-architecture-05. draft-ietf-sfc-architecture-05 has: Service Function Chain (SFC): A service function chain defines an ordered set of abstract service functions (SFs) and ordering constraints that must be applied to packets and/or frames and/or flows selected as a result of classification. An example of an abstract service function is "a firewall". The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions need to be applied. The term service chain is often used as shorthand for service function chain. Isn't the wording of "an ordered set of abstract service functions (SFs) t= hat must be applied to packets and/or frames and/or flows" already sufficie= nt enough to describe the ordering constraints? Why need the extra wording of "..and ordering constraints"? "...selected as a result of classification" should be more like ".. selecte= d based on a specific matching criteria". I suggest using the following wording: "A service function chain defines an ordered set of abstract service functi= ons (SFs) that must be applied to packets and/or frames and/or flows that meet the sp= ecific matching criteria." It is implementation specific to have a classification node inspecting pack= ets and attaching different SFC-IDs based on the "Service Chain matching Cr= iteria" in the header to make it easier for subsequent nodes. Linda From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 25, 2015 12:02 PM To: Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I think the key concept here is that of a 3 level hierarchy of SFC, SFP, RS= P. I don't think that comes out clearly in the current description, espec= ially when RSP references Service Function Chain rather than Service Functi= on Path. The way I think of it: * SFC - specify the sequence of service function types that need to = be visited * SFP - specify the sequence of service function types that need to = be visited, but also optionally specify instance selection constraining pol= icies for some or all of the types * RSP - specify the exact sequence of service function instances tha= t need to be visited (with the understanding that an instance may optionall= y perform its own internal load balancing) Thanks. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Sent: Wednesday, February 25, 2015 12:11 PM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Service P= ath (RSP) in draft-ietf-sfc-architecture-05 Sorry. A packet is technically using a service function path. It is doing= so if the information in the SFC defined header indicates that the packet = is to forwarded along that service function path. Thus, the assignment / u= sage can be determined from examining the packet. The RSP itself requires = a rather omniscient observer perspective to determine, but does exist conce= ptually. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 12:08 PM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Joel, What does it mean by saying packets "using" a service chain? How does packets "use" a service chain? I am confused. Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Wednesday, February 25, 2015 10:59 AM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I don't think adding another word to the term will help comprehension, and = it will complicate usage. So I would prefer not to do that. As for the other change, packets don't belong to a service chain. They may= be using a service chain. They may be assigned by a classifier to a servi= ce chain, but they don't "belong" to the chain as I understand the words. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 11:52 AM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: wording Suggestion for the Rendered Service Path (RSP) in draft-ie= tf-sfc-architecture-05 Joel and Carlos, The current definition of RSP is: Rendered Service Path (RSP): The Service Function Path is a constrained specification of where packets using a certain service chain must go. While it may be so constrained as to identify the exact locations, it can also be less specific. Packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. Some suggestions: - I would think it is more accurate to call it "Rendered Service Fun= ction Path (RSFP)". - Why do you say "packets using a certain service chain"? It is more= accurate to say "packets belonging to a certain service function chain". Here is my suggested wording for RSP (or RSFP): - The sequence of actual SFFs and SFs in the network traversed by pa= ckets belonging to a specific Service Function Chain is known as the Render= ed Service Function Path (RSFP). Cheers, Linda Dunbar --_000_6BCE198E4EAEFC4CAB45D75826EFB07603350E22eusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    While Ron’s word= ing was roughly right, it did not seem to add anything to what we had, and = was not written as a definition, but as a description.  As such, the q= uestion is whether it adds anything to the descriptive text further in the document.

     

    Also, it is quite poss= ible to have tighter ordering constraints on an SFP than on an SFC.  H= ow tight the ordering constraints are in the SFC probably depends upon the = SFC definer and tools.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei.com]
    Sent: Thursday, February 26, 2015 1:34 PM
    To: Ron Parker; Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.= org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I think Ron’s su= ggested wording for SFC is much more straight forward than the current SFC = definition on the sfc-architecture-05.

     

    draft-ietf-sfc-architecture-05 has:

    Service Function Chain (SFC= ): A service function chain defines an

    ordered set of abstract ser= vice functions (SFs) and ordering

    constraints that must be ap= plied to packets and/or frames and/or

    flows selected as a result = of classification. An example of an

    abstract service function i= s "a firewall". The implied order

    may not be a linear progres= sion as the architecture allows for

    SFCs that copy to more than= one branch, and also allows for

    cases where there is flexib= ility in the order in which service

    functions need to be applie= d. The term service chain is often

    used as shorthand for servi= ce function chain.

     

    Isn’t the wordin= g of  “an ordered set of abstract service functions (SFs) that must be applied = to packets and/or frames and/or flows&= #8221; already sufficient enough to describe the ordering constraints?

     

    Why need the extra wor= ding of “..and ordering = constraints”?

     

    “...selected as a result of cla= ssification” should be more like= “.. selected based on a specific matching criteria”.

     

     

    I suggest using the fo= llowing wording:

     

    “A service function c= hain defines an ordered set of abstract service functions (SFs)

    that must be applied to pac= kets and/or frames and/or flows that meet the specific matching criteria.&#= 8221;

     

     

    It is implementation s= pecific to have a classification node inspecting packets and attaching diff= erent SFC-IDs based on the “Service Chain matching Criteria” in= the header to make it easier for subsequent nodes.

     

    Linda

     

     

    From: Ron Park= er [mailto:Ron_Par= ker@affirmednetworks.com]
    Sent: Wednesday, February 25, 2015 12:02 PM
    To: Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I think the key concep= t here is that of a 3 level hierarchy of SFC, SFP, RSP.   I don&#= 8217;t think that comes out clearly in the current description, especially = when RSP references Service Function Chain rather than Service Function Path.   The way I think of it:

     

    ·SFC – specify the sequence of se= rvice function types that need to be visited

    ·SFP – specify the sequence of se= rvice function types that need to be visited, but also optionally specify i= nstance selection constraining policies for some or all of the types

    ·RSP – specify the exact sequence= of service function instances that need to be visited (with the understand= ing that an instance may optionally perform its own internal load balancing= )

     

    Thanks.

     

       Ron<= /o:p>

     

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern
    Sent: Wednesday, February 25, 2015 12:11 PM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Se= rvice Path (RSP) in draft-ietf-sfc-architecture-05

     

    Sorry.  A packet = is technically using a service function path.  It is doing so if the i= nformation in the SFC defined header indicates that the packet is to forwar= ded along that service function path.  Thus, the assignment / usage can be determined from examining the packet.  The = RSP itself requires a rather omniscient observer perspective to determine, = but does exist conceptually.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Wednesday, February 25, 2015 12:08 PM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Joel,

     

    What does it mean by s= aying packets “using” a service chain?

     

    How does packets  = ;“use” a service chain? I am confused.

     

    Linda

     

    From: Joel Hal= pern [mailto:joel.halpern@= ericsson.com]
    Sent: Wednesday, February 25, 2015 10:59 AM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I don’t think ad= ding another word to the term will help comprehension, and it will complica= te usage.  So I would prefer not to do that.

     

    As for the other chang= e, packets don’t belong to a service chain.  They may be using a= service chain.  They may be assigned by a classifier to a service cha= in, but they don’t “belong” to the chain as I understand the words.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Wednesday, February 25, 2015 11:52 AM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: wording Suggestion for the Rendered Service Path (RSP) in d= raft-ietf-sfc-architecture-05

     

    Joel and Carlos,

     

    The current definition of RSP is:

     

    Rendered Service Path (RSP)= : The Service Function Path is a

    constrained specification o= f where packets using a certain

    service chain must go. Whil= e it may be so constrained as to

    identify the exact location= s, it can also be less specific.

    Packets themselves are of c= ourse transmitted from and to

    specific places in the netw= ork, visiting a specific sequence of

    SFFs and SFs. This sequence= of actual visits by a packet to

    specific SFFs and SFs in th= e network is known as the Rendered

    Service Path (RSP). This de= finition is included here for use by

    later documents, such as wh= en solutions may need to discuss the

    actual sequence of location= s the packets visit.

     

     

    Some suggestions:

    -=         I would think it is more accurate to call it “Rendered Service= Function Path (RSFP)”.

    -=         Why do you say “packets using a certain service chain”? = It is more accurate to say “packets belonging to a certain service fu= nction chain”.

     

     

    Here is my suggested wording for RSP (or RSFP):=

     

    -=         The sequence of actual SFFs and SFs in the network traversed by pack= ets belonging to a specific Service Function Chain is known as the Rendered= Service Function Path (RSFP).

     

    Cheers,

     

    Linda Dunbar

     

    --_000_6BCE198E4EAEFC4CAB45D75826EFB07603350E22eusaamb101erics_-- From nobody Thu Feb 26 13:32: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 F1AFF1AC443 for ; Thu, 26 Feb 2015 13:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0mpQg5r8oYD for ; Thu, 26 Feb 2015 13:32:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E13781A8731 for ; Thu, 26 Feb 2015 13:32:19 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPR13106; Thu, 26 Feb 2015 21:32:17 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Feb 2015 21:32:17 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Thu, 26 Feb 2015 13:32:05 -0800 From: Linda Dunbar To: Joel Halpern , Ron Parker , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 Thread-Index: AdBRG3N71HhtcFa0RsuzFw1dT6iegwAAMTdQAABKvqAAABrE4AABrb3gADKL8WAABtoL4AAAPTwg Date: Thu, 26 Feb 2015 21:32:04 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645EE3E72@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE3CC3@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB07603350E22@eusaamb101.ericsson.se> In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB07603350E22@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.210] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645EE3E72dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 26 Feb 2015 21:32:30 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645EE3E72dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Joel, Agree with what you said: "..., it is quite possible to have tighter ordering constraints on an SFP t= han on an SFC." [Linda] Do you really need the extra wording ""..and ordering constraints" = for the SFC definition? Is it sufficient to say "A service function chain defines an ordered set of= abstract service functions (SFs) that must be applied to packets and/or fr= ames and/or flows"? Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Thursday, February 26, 2015 3:23 PM To: Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 While Ron's wording was roughly right, it did not seem to add anything to w= hat we had, and was not written as a definition, but as a description. As = such, the question is whether it adds anything to the descriptive text furt= her in the document. Also, it is quite possible to have tighter ordering constraints on an SFP t= han on an SFC. How tight the ordering constraints are in the SFC probably = depends upon the SFC definer and tools. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, February 26, 2015 1:34 PM To: Ron Parker; Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I think Ron's suggested wording for SFC is much more straight forward than = the current SFC definition on the sfc-architecture-05. draft-ietf-sfc-architecture-05 has: Service Function Chain (SFC): A service function chain defines an ordered set of abstract service functions (SFs) and ordering constraints that must be applied to packets and/or frames and/or flows selected as a result of classification. An example of an abstract service function is "a firewall". The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions need to be applied. The term service chain is often used as shorthand for service function chain. Isn't the wording of "an ordered set of abstract service functions (SFs) t= hat must be applied to packets and/or frames and/or flows" already sufficie= nt enough to describe the ordering constraints? Why need the extra wording of "..and ordering constraints"? "...selected as a result of classification" should be more like ".. selecte= d based on a specific matching criteria". I suggest using the following wording: "A service function chain defines an ordered set of abstract service functi= ons (SFs) that must be applied to packets and/or frames and/or flows that meet the sp= ecific matching criteria." It is implementation specific to have a classification node inspecting pack= ets and attaching different SFC-IDs based on the "Service Chain matching Cr= iteria" in the header to make it easier for subsequent nodes. Linda From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 25, 2015 12:02 PM To: Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I think the key concept here is that of a 3 level hierarchy of SFC, SFP, RS= P. I don't think that comes out clearly in the current description, espec= ially when RSP references Service Function Chain rather than Service Functi= on Path. The way I think of it: * SFC - specify the sequence of service function types that need to = be visited * SFP - specify the sequence of service function types that need to = be visited, but also optionally specify instance selection constraining pol= icies for some or all of the types * RSP - specify the exact sequence of service function instances tha= t need to be visited (with the understanding that an instance may optionall= y perform its own internal load balancing) Thanks. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Sent: Wednesday, February 25, 2015 12:11 PM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Service P= ath (RSP) in draft-ietf-sfc-architecture-05 Sorry. A packet is technically using a service function path. It is doing= so if the information in the SFC defined header indicates that the packet = is to forwarded along that service function path. Thus, the assignment / u= sage can be determined from examining the packet. The RSP itself requires = a rather omniscient observer perspective to determine, but does exist conce= ptually. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 12:08 PM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Joel, What does it mean by saying packets "using" a service chain? How does packets "use" a service chain? I am confused. Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Wednesday, February 25, 2015 10:59 AM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I don't think adding another word to the term will help comprehension, and = it will complicate usage. So I would prefer not to do that. As for the other change, packets don't belong to a service chain. They may= be using a service chain. They may be assigned by a classifier to a servi= ce chain, but they don't "belong" to the chain as I understand the words. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 11:52 AM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: wording Suggestion for the Rendered Service Path (RSP) in draft-ie= tf-sfc-architecture-05 Joel and Carlos, The current definition of RSP is: Rendered Service Path (RSP): The Service Function Path is a constrained specification of where packets using a certain service chain must go. While it may be so constrained as to identify the exact locations, it can also be less specific. Packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. Some suggestions: - I would think it is more accurate to call it "Rendered Service Fun= ction Path (RSFP)". - Why do you say "packets using a certain service chain"? It is more= accurate to say "packets belonging to a certain service function chain". Here is my suggested wording for RSP (or RSFP): - The sequence of actual SFFs and SFs in the network traversed by pa= ckets belonging to a specific Service Function Chain is known as the Render= ed Service Function Path (RSFP). Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645EE3E72dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Joel,

     

     

    Agree with what you sai= d:

     

    “…<= span style=3D"color:#1F497D">, it is quite possible to have tighter orderin= g constraints on an SFP than on an SFC.” 

     

    [Linda] Do you really = need the extra wording ““..and ordering constraints” for the SFC definition?

    Is it sufficient to sa= y “A serv= ice function chain defines an ordered set of abstract service functions (SF= s) that must be applied to packets and/or frames and/or flows”?

     

     

    Linda

     

    From: Joel Hal= pern [mailto:joel.halpern@ericsson.com]
    Sent: Thursday, February 26, 2015 3:23 PM
    To: Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.= org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    While Ron’s word= ing was roughly right, it did not seem to add anything to what we had, and = was not written as a definition, but as a description.  As such, the q= uestion is whether it adds anything to the descriptive text further in the document.

     

    Also, it is quite poss= ible to have tighter ordering constraints on an SFP than on an SFC.  H= ow tight the ordering constraints are in the SFC probably depends upon the = SFC definer and tools.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Thursday, February 26, 2015 1:34 PM
    To: Ron Parker; Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I think Ron’s su= ggested wording for SFC is much more straight forward than the current SFC = definition on the sfc-architecture-05.

     

    draft-ietf-sfc-architecture-05 has:

    Service Function Chain (SFC= ): A service function chain defines an

    ordered set of abstract ser= vice functions (SFs) and ordering

    constraints that must be ap= plied to packets and/or frames and/or

    flows selected as a result = of classification. An example of an

    abstract service function i= s "a firewall". The implied order

    may not be a linear progres= sion as the architecture allows for

    SFCs that copy to more than= one branch, and also allows for

    cases where there is flexib= ility in the order in which service

    functions need to be applie= d. The term service chain is often

    used as shorthand for servi= ce function chain.

     

    Isn’t the wordin= g of  “an ordered set of abstract service functions (SFs) that must be applied = to packets and/or frames and/or flows&= #8221; already sufficient enough to describe the ordering constraints?

     

    Why need the extra wor= ding of “..and ordering = constraints”?

     

    “...selected as a result of cla= ssification” should be more like= “.. selected based on a specific matching criteria”.

     

     

    I suggest using the fo= llowing wording:

     

    “A service function c= hain defines an ordered set of abstract service functions (SFs)

    that must be applied to pac= kets and/or frames and/or flows that meet the specific matching criteria.&#= 8221;

     

     

    It is implementation s= pecific to have a classification node inspecting packets and attaching diff= erent SFC-IDs based on the “Service Chain matching Criteria” in= the header to make it easier for subsequent nodes.

     

    Linda

     

     

    From: Ron Park= er [mailto:Ron_Par= ker@affirmednetworks.com]
    Sent: Wednesday, February 25, 2015 12:02 PM
    To: Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I think the key concep= t here is that of a 3 level hierarchy of SFC, SFP, RSP.   I don&#= 8217;t think that comes out clearly in the current description, especially = when RSP references Service Function Chain rather than Service Function Path.   The way I think of it:

     

    ·SFC – specify the sequence of se= rvice function types that need to be visited

    ·SFP – specify the sequence of se= rvice function types that need to be visited, but also optionally specify i= nstance selection constraining policies for some or all of the types

    ·RSP – specify the exact sequence= of service function instances that need to be visited (with the understand= ing that an instance may optionally perform its own internal load balancing= )

     

    Thanks.

     

       Ron<= /o:p>

     

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern
    Sent: Wednesday, February 25, 2015 12:11 PM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Se= rvice Path (RSP) in draft-ietf-sfc-architecture-05

     

    Sorry.  A packet = is technically using a service function path.  It is doing so if the i= nformation in the SFC defined header indicates that the packet is to forwar= ded along that service function path.  Thus, the assignment / usage can be determined from examining the packet.  The = RSP itself requires a rather omniscient observer perspective to determine, = but does exist conceptually.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Wednesday, February 25, 2015 12:08 PM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Joel,

     

    What does it mean by s= aying packets “using” a service chain?

     

    How does packets  = ;“use” a service chain? I am confused.

     

    Linda

     

    From: Joel Hal= pern [mailto:joel.halpern@= ericsson.com]
    Sent: Wednesday, February 25, 2015 10:59 AM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I don’t think ad= ding another word to the term will help comprehension, and it will complica= te usage.  So I would prefer not to do that.

     

    As for the other chang= e, packets don’t belong to a service chain.  They may be using a= service chain.  They may be assigned by a classifier to a service cha= in, but they don’t “belong” to the chain as I understand the words.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Wednesday, February 25, 2015 11:52 AM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: wording Suggestion for the Rendered Service Path (RSP) in d= raft-ietf-sfc-architecture-05

     

    Joel and Carlos,

     

    The current definition of RSP is:

     

    Rendered Service Path (RSP)= : The Service Function Path is a

    constrained specification o= f where packets using a certain

    service chain must go. Whil= e it may be so constrained as to

    identify the exact location= s, it can also be less specific.

    Packets themselves are of c= ourse transmitted from and to

    specific places in the netw= ork, visiting a specific sequence of

    SFFs and SFs. This sequence= of actual visits by a packet to

    specific SFFs and SFs in th= e network is known as the Rendered

    Service Path (RSP). This de= finition is included here for use by

    later documents, such as wh= en solutions may need to discuss the

    actual sequence of location= s the packets visit.

     

     

    Some suggestions:

    -=         I would think it is more accurate to call it “Rendered Service= Function Path (RSFP)”.

    -=         Why do you say “packets using a certain service chain”? = It is more accurate to say “packets belonging to a certain service fu= nction chain”.

     

     

    Here is my suggested wording for RSP (or RSFP):=

     

    -=         The sequence of actual SFFs and SFs in the network traversed by pack= ets belonging to a specific Service Function Chain is known as the Rendered= Service Function Path (RSFP).

     

    Cheers,

     

    Linda Dunbar

     

    --_000_4A95BA014132FF49AE685FAB4B9F17F645EE3E72dfweml701chm_-- From nobody Thu Feb 26 13:34:42 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04C31A8854 for ; Thu, 26 Feb 2015 13:34:40 -0800 (PST) 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 UQHHLfP2I3Yq for ; Thu, 26 Feb 2015 13:34:39 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7303C1A8032 for ; Thu, 26 Feb 2015 13:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3480; q=dns/txt; s=iport; t=1424986479; x=1426196079; h=from:to:subject:date:message-id:mime-version; bh=KBl/guZc+KK2sPAQissdMSYotJNiX+KRSPkRG9y68CE=; b=YH0GvcQITqCBzSfpHmz/zrIIkUlxCQ1mwtcnYV5ElpJae31y5ecHVg0Q VaEWAIBIU9VTJ/hSTXPkg2dQ22104xfkvX8vSpnyIobzNzFNT9FaNz4FC wd5coV/3wb0m9uJaeQyTQkDGz+zInZWNizICsH4s/06bWbOFzxY26kVEE E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DUBQDykO9U/5hdJa1bgj9DgSwEx3WBKU0BAQEBAQF8hA8BAgSBCwEIBA0BAgECKDkUAwYKBAESiC/XIAEBAQcBAQEBAR2LE4RdhEMFj2+JRZNJI4IygTxvgUR/AQEB X-IronPort-AV: E=Sophos;i="5.09,655,1418083200"; d="scan'208,217";a="399811351" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 26 Feb 2015 21:34:38 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t1QLYc4M019535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Feb 2015 21:34:38 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.248]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 15:34:38 -0600 From: "Reinaldo Penno (repenno)" To: Joel Halpern , Linda Dunbar , Ron Parker , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 Thread-Index: AQHQUgwFC1K2Lb8DgE2ba2Ni9wetMg== Date: Thu, 26 Feb 2015 21:34:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.24.30.88] Content-Type: multipart/alternative; boundary="_000_D114D154B816repennociscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 26 Feb 2015 21:34:40 -0000 --_000_D114D154B816repennociscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agreed. Constrained Service Paths at the SFP level is important. From: Joel Halpern > Date: Thursday, February 26, 2015 at 1:22 PM To: Linda Dunbar >,= Ron Parker >, "Carlos Pignataro (cpignata)" >, "sfc@ietf.org" > Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) i= n draft-ietf-sfc-architecture-05 Also, it is quite possible to have tighter ordering constraints on an SFP t= han on an SFC. How tight the ordering constraints are in the SFC probably = depends upon the SFC definer and tools. --_000_D114D154B816repennociscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
    Agreed. Constrained Service Paths at the SFP level is important.

    From: Joel Halpern <joel.halpern@ericsson.com>
    Date: Thursday, February 26, 2015 a= t 1:22 PM
    To: Linda Dunbar <linda.dunbar@huawei.com>, Ron Parker &l= t;Ron_Parker@affirmednet= works.com>, "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "sfc@ietf.org" <sfc@ietf.org>
    Subject: Re: [sfc] wording Suggesti= on for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05

    Also, it is quite possible to have tighter ordering constraints on an SFP than o= n an SFC.  How tight the ordering constraints are in the SFC probably = depends upon the SFC definer and tools.     --_000_D114D154B816repennociscocom_-- From nobody Thu Feb 26 13:35: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 B9C221A8877 for ; Thu, 26 Feb 2015 13:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZpfhoIpM0bm for ; Thu, 26 Feb 2015 13:35:42 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859731A8876 for ; Thu, 26 Feb 2015 13:35:41 -0800 (PST) X-AuditID: c6180641-f79916d00000623a-80-54ef311949eb Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id FD.16.25146.9113FE45; Thu, 26 Feb 2015 15:43:37 +0100 (CET) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0210.002; Thu, 26 Feb 2015 16:35:39 -0500 From: Joel Halpern To: Linda Dunbar , Ron Parker , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 Thread-Index: AdBRG3N71HhtcFa0RsuzFw1dT6iegwAAMTdQAABKvqAAABrE4AABrb3gADKL8WAABtoL4AAAPTwgAAA6eQA= Date: Thu, 26 Feb 2015 21:35:38 +0000 Message-ID: <6BCE198E4EAEFC4CAB45D75826EFB07603350EAA@eusaamb101.ericsson.se> References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE3CC3@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB07603350E22@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE3E72@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645EE3E72@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_6BCE198E4EAEFC4CAB45D75826EFB07603350EAAeusaamb101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmkeLIzCtJLcpLzFFi42KZXLrHT1fS8H2IwfEjahaf3u1gsbjbMpHJ 4sLTqcwWTx5sZXdg8Xhx5Rmzx5TfG1k9Wo68ZfVYsuQnUwBLFJdNSmpOZllqkb5dAlfGz0u7 WAq6FzJV3Og6wNjA+PYfYxcjJ4eEgInEkgnXWSBsMYkL99azdTFycQgJHGGUuL7mODtIQkhg OaPE2ydsIDabgJ7E2vePmUCKRATWM0rM37eQGSQhLJAucfnSbDBbRCBD4vTaXjYIO0nixes+ MJtFQFWi+edMsKG8Ar4Ss9ZMYIFYMIlFYmmDFIjNKeAqcfDlKlYQmxHoou+n1jCB2MwC4hK3 nsxngrhUQGLJnvPMELaoxMvH/1ghbEWJff3T2SHq8yUOPdrMArFLUOLkzCcsExhFZiEZNQtJ 2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0VI0dpcWpZbrqR4SZGYKwdk2Bz3MG4 4JPlIUYBDkYlHt4N0u9ChFgTy4orcw8xSnOwKInzll05GCIkkJ5YkpqdmlqQWhRfVJqTWnyI kYmDU6qB0XbrvqT7IdXPelYdOPj7ruU3yQ8F34021uqu5t+rvubc5Gc8WXPMOmaw+u+6udck dOtc8zP+N6su/gyLPpod92zy5Zk1Yqft1p/Vs18WyjTZWc4gaFuSFas2j8MFnWmxjyyibx0y W19W+O2gVsCxf9tq5/+Isl66/G1z2Y4E1poaNo0Ft5Y9mabEUpyRaKjFXFScCADkQbT2lgIA AA== Archived-At: Subject: Re: [sfc] wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 26 Feb 2015 21:35:47 -0000 --_000_6BCE198E4EAEFC4CAB45D75826EFB07603350EAAeusaamb101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry. I now understand your question. As a mathematician, I would probably be happy if the definition simply said= "a partially ordered set of abstract service functions that must be applie= d ..." However, I think most people would find that less than enlightening. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, February 26, 2015 4:32 PM To: Joel Halpern; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Joel, Agree with what you said: "..., it is quite possible to have tighter ordering constraints on an SFP t= han on an SFC." [Linda] Do you really need the extra wording ""..and ordering constraints" = for the SFC definition? Is it sufficient to say "A service function chain defines an ordered set of= abstract service functions (SFs) that must be applied to packets and/or fr= ames and/or flows"? Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Thursday, February 26, 2015 3:23 PM To: Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 While Ron's wording was roughly right, it did not seem to add anything to w= hat we had, and was not written as a definition, but as a description. As = such, the question is whether it adds anything to the descriptive text furt= her in the document. Also, it is quite possible to have tighter ordering constraints on an SFP t= han on an SFC. How tight the ordering constraints are in the SFC probably = depends upon the SFC definer and tools. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, February 26, 2015 1:34 PM To: Ron Parker; Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I think Ron's suggested wording for SFC is much more straight forward than = the current SFC definition on the sfc-architecture-05. draft-ietf-sfc-architecture-05 has: Service Function Chain (SFC): A service function chain defines an ordered set of abstract service functions (SFs) and ordering constraints that must be applied to packets and/or frames and/or flows selected as a result of classification. An example of an abstract service function is "a firewall". The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions need to be applied. The term service chain is often used as shorthand for service function chain. Isn't the wording of "an ordered set of abstract service functions (SFs) t= hat must be applied to packets and/or frames and/or flows" already sufficie= nt enough to describe the ordering constraints? Why need the extra wording of "..and ordering constraints"? "...selected as a result of classification" should be more like ".. selecte= d based on a specific matching criteria". I suggest using the following wording: "A service function chain defines an ordered set of abstract service functi= ons (SFs) that must be applied to packets and/or frames and/or flows that meet the sp= ecific matching criteria." It is implementation specific to have a classification node inspecting pack= ets and attaching different SFC-IDs based on the "Service Chain matching Cr= iteria" in the header to make it easier for subsequent nodes. Linda From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 25, 2015 12:02 PM To: Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I think the key concept here is that of a 3 level hierarchy of SFC, SFP, RS= P. I don't think that comes out clearly in the current description, espec= ially when RSP references Service Function Chain rather than Service Functi= on Path. The way I think of it: * SFC - specify the sequence of service function types that need to = be visited * SFP - specify the sequence of service function types that need to = be visited, but also optionally specify instance selection constraining pol= icies for some or all of the types * RSP - specify the exact sequence of service function instances tha= t need to be visited (with the understanding that an instance may optionall= y perform its own internal load balancing) Thanks. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Sent: Wednesday, February 25, 2015 12:11 PM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Service P= ath (RSP) in draft-ietf-sfc-architecture-05 Sorry. A packet is technically using a service function path. It is doing= so if the information in the SFC defined header indicates that the packet = is to forwarded along that service function path. Thus, the assignment / u= sage can be determined from examining the packet. The RSP itself requires = a rather omniscient observer perspective to determine, but does exist conce= ptually. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 12:08 PM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Joel, What does it mean by saying packets "using" a service chain? How does packets "use" a service chain? I am confused. Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Wednesday, February 25, 2015 10:59 AM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I don't think adding another word to the term will help comprehension, and = it will complicate usage. So I would prefer not to do that. As for the other change, packets don't belong to a service chain. They may= be using a service chain. They may be assigned by a classifier to a servi= ce chain, but they don't "belong" to the chain as I understand the words. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 11:52 AM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: wording Suggestion for the Rendered Service Path (RSP) in draft-ie= tf-sfc-architecture-05 Joel and Carlos, The current definition of RSP is: Rendered Service Path (RSP): The Service Function Path is a constrained specification of where packets using a certain service chain must go. While it may be so constrained as to identify the exact locations, it can also be less specific. Packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. Some suggestions: - I would think it is more accurate to call it "Rendered Service Fun= ction Path (RSFP)". - Why do you say "packets using a certain service chain"? It is more= accurate to say "packets belonging to a certain service function chain". Here is my suggested wording for RSP (or RSFP): - The sequence of actual SFFs and SFs in the network traversed by pa= ckets belonging to a specific Service Function Chain is known as the Render= ed Service Function Path (RSFP). Cheers, Linda Dunbar --_000_6BCE198E4EAEFC4CAB45D75826EFB07603350EAAeusaamb101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Sorry.  I now und= erstand your question.

     

    As a mathematician, I = would probably be happy if the definition simply said “a partially or= dered set of abstract service functions that must be applied …”=

    However, I think most = people would find that less than enlightening.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei.com]
    Sent: Thursday, February 26, 2015 4:32 PM
    To: Joel Halpern; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.= org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Joel,

     

     

    Agree with what you sai= d:

     

    “…, it is = quite possible to have tighter ordering constraints on an SFP than on an SF= C.” 

     

    [Linda] Do you really = need the extra wording ““..and ordering constraints” for the SFC definition?

    Is it sufficient to sa= y “A serv= ice function chain defines an ordered set of abstract service functions (SF= s) that must be applied to packets and/or frames and/or flows”?

     

     

    Linda

     

    From: Joel Hal= pern [mailto:joel.halpern@= ericsson.com]
    Sent: Thursday, February 26, 2015 3:23 PM
    To: Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    While Ron’s word= ing was roughly right, it did not seem to add anything to what we had, and = was not written as a definition, but as a description.  As such, the q= uestion is whether it adds anything to the descriptive text further in the document.

     

    Also, it is quite poss= ible to have tighter ordering constraints on an SFP than on an SFC.  H= ow tight the ordering constraints are in the SFC probably depends upon the = SFC definer and tools.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Thursday, February 26, 2015 1:34 PM
    To: Ron Parker; Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I think Ron’s su= ggested wording for SFC is much more straight forward than the current SFC = definition on the sfc-architecture-05.

     

    draft-ietf-sfc-architecture-05 has:

    Service Function Chain (SFC= ): A service function chain defines an

    ordered set of abstract ser= vice functions (SFs) and ordering

    constraints that must be ap= plied to packets and/or frames and/or

    flows selected as a result = of classification. An example of an

    abstract service function i= s "a firewall". The implied order

    may not be a linear progres= sion as the architecture allows for

    SFCs that copy to more than= one branch, and also allows for

    cases where there is flexib= ility in the order in which service

    functions need to be applie= d. The term service chain is often

    used as shorthand for servi= ce function chain.

     

    Isn’t the wordin= g of  “an ordered set of abstract service functions (SFs) that must be applied = to packets and/or frames and/or flows&= #8221; already sufficient enough to describe the ordering constraints?

     

    Why need the extra wor= ding of “..and ordering = constraints”?

     

    “...selected as a result of cla= ssification” should be more like= “.. selected based on a specific matching criteria”.

     

     

    I suggest using the fo= llowing wording:

     

    “A service function c= hain defines an ordered set of abstract service functions (SFs)

    that must be applied to pac= kets and/or frames and/or flows that meet the specific matching criteria.&#= 8221;

     

     

    It is implementation s= pecific to have a classification node inspecting packets and attaching diff= erent SFC-IDs based on the “Service Chain matching Criteria” in= the header to make it easier for subsequent nodes.

     

    Linda

     

     

    From: Ron Park= er [mailto:Ron_Par= ker@affirmednetworks.com]
    Sent: Wednesday, February 25, 2015 12:02 PM
    To: Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I think the key concep= t here is that of a 3 level hierarchy of SFC, SFP, RSP.   I don&#= 8217;t think that comes out clearly in the current description, especially = when RSP references Service Function Chain rather than Service Function Path.   The way I think of it:

     

    ·SFC – specify the sequence of se= rvice function types that need to be visited

    ·SFP – specify the sequence of se= rvice function types that need to be visited, but also optionally specify i= nstance selection constraining policies for some or all of the types

    ·RSP – specify the exact sequence= of service function instances that need to be visited (with the understand= ing that an instance may optionally perform its own internal load balancing= )

     

    Thanks.

     

       Ron<= /o:p>

     

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern
    Sent: Wednesday, February 25, 2015 12:11 PM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Se= rvice Path (RSP) in draft-ietf-sfc-architecture-05

     

    Sorry.  A packet = is technically using a service function path.  It is doing so if the i= nformation in the SFC defined header indicates that the packet is to forwar= ded along that service function path.  Thus, the assignment / usage can be determined from examining the packet.  The = RSP itself requires a rather omniscient observer perspective to determine, = but does exist conceptually.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Wednesday, February 25, 2015 12:08 PM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Joel,

     

    What does it mean by s= aying packets “using” a service chain?

     

    How does packets  = ;“use” a service chain? I am confused.

     

    Linda

     

    From: Joel Hal= pern [mailto:joel.halpern@= ericsson.com]
    Sent: Wednesday, February 25, 2015 10:59 AM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I don’t think ad= ding another word to the term will help comprehension, and it will complica= te usage.  So I would prefer not to do that.

     

    As for the other chang= e, packets don’t belong to a service chain.  They may be using a= service chain.  They may be assigned by a classifier to a service cha= in, but they don’t “belong” to the chain as I understand the words.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Wednesday, February 25, 2015 11:52 AM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: wording Suggestion for the Rendered Service Path (RSP) in d= raft-ietf-sfc-architecture-05

     

    Joel and Carlos,

     

    The current definition of RSP is:

     

    Rendered Service Path (RSP)= : The Service Function Path is a

    constrained specification o= f where packets using a certain

    service chain must go. Whil= e it may be so constrained as to

    identify the exact location= s, it can also be less specific.

    Packets themselves are of c= ourse transmitted from and to

    specific places in the netw= ork, visiting a specific sequence of

    SFFs and SFs. This sequence= of actual visits by a packet to

    specific SFFs and SFs in th= e network is known as the Rendered

    Service Path (RSP). This de= finition is included here for use by

    later documents, such as wh= en solutions may need to discuss the

    actual sequence of location= s the packets visit.

     

     

    Some suggestions:

    -=         I would think it is more accurate to call it “Rendered Service= Function Path (RSFP)”.

    -=         Why do you say “packets using a certain service chain”? = It is more accurate to say “packets belonging to a certain service fu= nction chain”.

     

     

    Here is my suggested wording for RSP (or RSFP):=

     

    -=         The sequence of actual SFFs and SFs in the network traversed by pack= ets belonging to a specific Service Function Chain is known as the Rendered= Service Function Path (RSFP).

     

    Cheers,

     

    Linda Dunbar

     

    --_000_6BCE198E4EAEFC4CAB45D75826EFB07603350EAAeusaamb101erics_-- From nobody Thu Feb 26 14:03:39 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F001A1EF2 for ; Thu, 26 Feb 2015 14:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, 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 RzalliZZTTIy for ; Thu, 26 Feb 2015 14:03:35 -0800 (PST) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 059C21A1B25 for ; Thu, 26 Feb 2015 14:03:35 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0224.002; Thu, 26 Feb 2015 14:03:34 -0800 From: Ron Parker To: Ron Parker , "Joel M. Halpern" , "ddolson@sandvine.com" , "repenno@cisco.com" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals Thread-Index: AQHQUfDWdMfMQp0TQVyP+AHUYniSlJ0D5VmA//+GlyCAABAMQA== Date: Thu, 26 Feb 2015 22:03:34 +0000 Message-ID: References: <54EF7FE1.6010709@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ben.wright@metaswitch.com" Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals 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, 26 Feb 2015 22:03:38 -0000 SSdsbCBhZGQgdGhhdCB0aGlzIG9wdGlvbmFsIE9VSSBhcHByb2FjaCB3b3VsZCBvbmx5IGFwcGx5 IHRvIFR5cGUgMiBOU0guDQoNCiAgIFJvbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb24g UGFya2VyDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjYsIDIwMTUgNDowOSBQTQ0KVG86IEpv ZWwgTS4gSGFscGVybjsgZGRvbHNvbkBzYW5kdmluZS5jb207IHJlcGVubm9AY2lzY28uY29tOyBt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcNCkNjOiBiZW4ud3JpZ2h0 QG1ldGFzd2l0Y2guY29tDQpTdWJqZWN0OiBSZTogW3NmY10gZHJhZnQtcXVpbm4tc2ZjLW5zaDog U3VwcG9ydCBvZiBTRiBTcGlyYWxzDQoNCkFncmVlLiAgIA0KDQpPbmUgYXBwcm9hY2ggdGhhdCB3 YXMgZGVzY3JpYmVkIGluIGEgbm93LWFiYW5kb25lZCBkcmFmdCBpcyB0byBoYXZlIGJvdGggdGhl IHJlZ2lzdGVyZWQgVHlwZXMgdGhhdCBKb2VsIHJlZmVycyB0byBhbmQgYWxzbyB0aGUgYWJpbGl0 eSB0byBkZWZpbmUgdmVuZG9yLXNwZWNpZmljIHR5cGVzLiAgIEEgZmxhZyBiaXQgaW4gdGhlIFRM ViBoZWFkZXIgY291bGQgY29udHJvbCB3aGV0aGVyIHRoZSAnVCcgaW4gdGhlIFRMViBpcyByZWdp c3RlcmVkIG9yIHZlbmRvci1zcGVjaWZpYy4gICBJZiB2ZW5kb3Itc3BlY2lmaWMsIGFuIE9VSSB3 b3JkIHdvdWxkIGJlIHJlcXVpcmVkIGluIHRoZSBUTFYgaW4gb3JkZXIgdG8gZGVmaW5lIHRoZSBu dW1iZXIgc3BhY2UgdG8gaW50ZXJwcmV0IHRoZSAnVCcuDQoNCiAgIFJvbg0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpqbWhAam9l bGhhbHBlcm4uY29tXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE1IDM6MjAgUE0N ClRvOiBkZG9sc29uQHNhbmR2aW5lLmNvbTsgam1oQGpvZWxoYWxwZXJuLmNvbTsgcmVwZW5ub0Bj aXNjby5jb207IFJvbiBQYXJrZXI7IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0Bp ZXRmLm9yZw0KQ2M6IGJlbi53cmlnaHRAbWV0YXN3aXRjaC5jb20NClN1YmplY3Q6IFJlOiBbc2Zj XSBkcmFmdC1xdWlubi1zZmMtbnNoOiBTdXBwb3J0IG9mIFNGIFNwaXJhbHMNCg0KVGhhdCBzZWNv bmQgc2VudGVuY2Ugd2FzIHN1cHBvc2VkIHRvIGJlOg0KDQpGb3IgVExWIGJhc2VkIG1ldGFkYXRh IHdlIHByb2JhYmx5IHdhbnQgYSByZWdpc3RyeSB3aXRoIHZlcnkgZWVhc3kgZW50cnkgY3JlYXRp b24uDQoNClNvcnJ5LA0KSm9lbA0KDQpPbiAyLzI2LzE1IDE6MjAgUE0sIEptaC5kaXJlY3Qgd3Jv dGU6DQo+IEluc3RydWN0aW9uIGNvbWVzIGZyb20gdGhlIHNldmljZSBmdW5jdGlvbiBkZXNpZ24u ICBTb21lIGhlYWRlciANCj4gc3RydWN0dXJlcyBhdWdtZW50IHRoYXQgd2l0aCBjb250cm9sIG1h cHBpbmcgaWJmb3JtYXRpb24gdG8gaW5kaWNhdGUgDQo+IHdoaWNoIG1ldGFkYXRhIGZpZWxkIGhh cyB3aGljaCB1c2UuDQo+DQo+IEdvciBUTFYgYmFzZWQgbWV0YWRhdCB3ZSBwcm9iYWJseSBlYW50 IGEgcmVnaXN0cnkgd2l0aCB2ZXJ5IGVhc3kgZW50cnkgDQo+IGNyZWF0aW9uLg0KPg0KPiBZb3Vy cywNCj4gSm9lbA0KPg0KPg0KPiBTZW50IGZyb20gbXkgU2Ftc3VuZyBzbWFydHBob25lIG9uIEFU JlQNCj4NCj4NCj4NCj4gLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQ0KPiBTdWJq ZWN0OiBSRTogW3NmY10gZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxz DQo+IEZyb206IERhdmUgRG9sc29uIDxkZG9sc29uQHNhbmR2aW5lLmNvbT4NCj4gVG86ICJKb2Vs IE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiwiUmVpbmFsZG8gUGVubm8gKHJlcGVu bm8pIg0KPiA8cmVwZW5ub0BjaXNjby5jb20+LFJvbiBQYXJrZXINCj4gPFJvbl9QYXJrZXJAYWZm aXJtZWRuZXR3b3Jrcy5jb20+LCJtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIg0KPiA8bW9o YW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4sInNmY0BpZXRmLm9yZyIgPHNmY0BpZXRmLm9yZz4N Cj4gQ0M6ICJCZW4gV3JpZ2h0IChCZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tKSIgDQo+IDxCZW4u V3JpZ2h0QG1ldGFzd2l0Y2guY29tPg0KPg0KPg0KPiBXaGF0IGFyZSB0aGUgbWVjaGFuaWNzIG9m IHVzaW5nIG1ldGEtZGF0YT8NCj4gV2hpY2ggZWxlbWVudCBzZXRzIGl0LCBhbmQgaG93IGlzIGl0 IGluc3RydWN0ZWQgdG8gZG8gc28/DQo+DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+ IFNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyNiwgMjAxNSAxMjozNiBQTQ0KPiBUbzogRGF2ZSBE b2xzb247IFJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKTsgUm9uIFBhcmtlcjsgDQo+IG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZw0KPiBDYzogQmVuIFdyaWdodCAoQmVu LldyaWdodEBtZXRhc3dpdGNoLmNvbSkNCj4gU3ViamVjdDogUmU6IFtzZmNdIGRyYWZ0LXF1aW5u LXNmYy1uc2g6IFN1cHBvcnQgb2YgU0YgU3BpcmFscw0KPg0KPiBQZXJzb25hbGx5LCBJIHdvdWxk IHByZWZlciB0aGF0IHRoZSBmaXJld2FsbCB1c2UgbWV0YWRhdGEgcmF0aGVyIHRoYW4gDQo+IHBh dGgtaW5kZXguICBNeSByZWFzb25pbmcgaXMgdGhhdCBpZiBmdW5jdGlvbnMgZ2V0IGFkZGVkIGJl Zm9yZSBvciANCj4gYWZ0ZXIgdGhlIGZpcmV3YWxsLCBvcGVyYXRpb25zIHdvdWxkIHByZWZlciBu b3QgdG8gaGF2ZSB0byBjaGFuZ2UgdGhlIA0KPiBjb25maWd1cmF0aW9uIG9mIHRoZSBmaXJld2Fs bCBTRiBpdHNlbGYuDQo+DQo+IEhhdmluZyBzYWlkIHRoYXQsIEkgZG9uJ3Qgc2VlIGFueSB3YXkg dG8gc3RvcCB5b3UgZnJvbSB1c2luZyB0aGUgcGF0aCBpbmRleC4NCj4NCj4gWW91cnMsDQo+IEpv ZWwNCj4NCj4gT24gMi8yNi8xNSAxMjozMCBQTSwgRGF2ZSBEb2xzb24gd3JvdGU6DQo+ICA+IEZv ciB0aGUgc2FrZSBvZiBhcmd1bWVudCwgc3VwcG9zZSBJIGhhdmUgYSBmaXJld2FsbCBTRiwgYW5k IEkgd2FudCANCj4gdG8gdXNlICA+IGl0IG1vcmUgdGhhbiBvbmNlIGluIGEgY2hhaW4uIChNYXli ZSBJIHdhbnQgdG8gYm9vay1lbmQgdGhlIA0KPiBjaGFpbiB3aXRoIGluZ3Jlc3MgID4gYW5kIGVn cmVzcyBydWxlcy4pICA+ICA+IERvIHlvdSBhZ3JlZSBpdCB3b3VsZCANCj4gYmUgc3VmZmljaWVu dCB0byB1c2UgdGhlIFBhdGggSW5kZXggdG8gc2VsZWN0IHdoaWNoIG9mICA+IHRoZSBpbmdyZXNz IA0KPiBvciBlZ3Jlc3MgcnVsZSBzZXRzIHNob3VsZCBiZSB1c2VkPw0KPiAgPg0KPiAgPiBJJ20g cHJvYmFibHkgbWlzc2luZyBzb21ldGhpbmc7IEkgZG9uJ3QgdW5kZXJzdGFuZCBob3cgdGhlIGNv bnRleHQgDQo+IGhlYWRlcnMgID4gZGVmaW5lIGZ1bmN0aW9uYWxpdHkuIE1heWJlIHRoZSBkZXZp Y2UgY291bGQgY29tbXVuaWNhdGUgDQo+IHdpdGggaXRzZWxmICA+IChlLmcuLCB0aGUgaW5ncmVz cyBwb3J0aW9uIHNlbmRpbmcgYSB0YWcgdG8gdGhlIGVncmVzcw0KPiBwb3J0aW9uKSAgPiBieSBz ZW5kaW5nIHN0YXRlIGluIHRoZSBwYWNrZXQuIElzIHRoYXQgd2hhdCB5b3UgYXJlIG1lYW4gDQo+ IGJ5ICJjb250ZXh0dWFsIGluZm8iID8NCj4gID4NCj4gID4NCj4gID4NCj4gID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gID4gRnJvbTogUmVpbmFsZG8gUGVubm8gKHJlcGVubm8pIFtt YWlsdG86cmVwZW5ub0BjaXNjby5jb21dICA+IFNlbnQ6IA0KPiBUaHVyc2RheSwgRmVicnVhcnkg MjYsIDIwMTUgMTI6MTggUE0gID4gVG86IERhdmUgRG9sc29uOyBSb24gUGFya2VyOyANCj4gSm9l bCBNLiBIYWxwZXJuOyBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tOyBzZmNAaWV0Zi5vcmcg ID4gQ2M6IEJlbiANCj4gV3JpZ2h0IChCZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tKSAgPiBTdWJq ZWN0OiBSZTogW3NmY10NCj4gZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGly YWxzICA+ICA+IEFncmVlZCBvbiBhbGwgcG9pbnRzLiANCj4gSSB0aG91Z2h0IEkgd2FzIG1pc3Np bmcgc29tZXRoaW5nIHNvIGJlZm9yZSB3cml0aW5nICA+IHRoaXMgZW1haWwgSSANCj4gcmV0ZXN0 ZWQgb3VyIGltcGxlbWVudGF0aW9uIGFuZCBpdCB3b3JrZWQgb2ZmIHRoZSBiYXQuIFRoZSAgPiBS U1AgDQo+IGNvbnN0cnVjdGVkIGhhcyB0aGUgdGhlIHNhbWUgKFNGRiwgU0YpIHR1cGxlIGJ1dCBk aWZmZXJlbnQgaW5kZXhlcy4NCj4gID4NCj4gID4gVGhlIHNhbWUgU0YgaXMgdmlzaXRlZCBtdWx0 aXBsZSB0aW1lcyB1bnRpbCB0aGUgcGF0aCBlbmRzLiAgSWYgdGhlIA0KPiBTRiAgPiB3YW50cyBj b250ZXh0dWFsIGluZm8gYWNyb3NzIHZpc2l0cyB0aGFuIGNvbnRleHQgaGVhZGVycyBhcmUgdGhl IA0KPiB3YXkgdG8gID4gZ28uDQo+ICA+DQo+ICA+DQo+ICA+IE9uIDIvMjYvMTUsIDg6NTIgQU0s ICJEYXZlIERvbHNvbiIgPGRkb2xzb25Ac2FuZHZpbmUuY29tPiB3cm90ZToNCj4gID4NCj4gID4+ IE1heWJlIG5haXZlbHksIEkgdGhvdWdodCB0aGUgc2VydmljZSBmdW5jdGlvbnMgd291bGQgYmUg DQo+IHByb3Zpc2lvbmVkIHdpdGggID4+IGEgdGFibGU6DQo+ICA+Pg0KPiAgPj4gRS5nLiwgZm9y IGVsZW1lbnQgZm9vOg0KPiAgPj4gUGF0aCB8IFBhdGggSW5kZXggfCBOZXh0IEhvcCAgfCBGdW5j dGlvbg0KPiAgPj4gMTIzIHwgIDQgICAgICAgICB8ICAgU0YtYmFyICB8IGZpcnN0IGJlaGF2aW9y DQo+ICA+PiAxMjMgfCAgMiAgICAgICAgIHwgU0YtZm9vYmFyIHwgc2Vjb25kIGJlaGF2aW9yDQo+ ICA+Pg0KPiAgPj4NCj4gID4+IFRoZSBGdW5jdGlvbiBpcyBjbGVhcmx5IGltcGxlbWVudGF0aW9u IHNwZWNpZmljLiBNYXliZSBpdCBwb2ludHMgDQo+IHRvIGEgID4+IGNvbmZpZ3VyYXRpb24gc2V0 IG9yIGEgcG9saWN5IHNldC4gSSB0aGluayBjb21wbGV0ZWx5IG91dCBvZiBzY29wZSBoZXJlLg0K PiAgPj4NCj4gID4+IEkgc3VnZ2VzdCB0aGF0IHRoaXMgaXMgbm90IGEgcHJvYmxlbSBmb3IgdGhl IHdpcmUgcHJvdG9jb2wsIHJhdGhlciANCj4gZm9yICA+PiB0aGUgY29uZmlndXJhdGlvbiBtb2Rl bCAobmV0Y29uZiBvciB3aGF0ZXZlcikuDQo+ICA+Pg0KPiAgPj4gSXQgYmVjb21lcyB2ZXJ5IG11 Y2ggdmVuZG9yLXNwZWNpZmljIGlmIHRoZSBiZWhhdmlvcnMgYXJlIGNvbXBsZXgNCj4gPj4gY29u ZmlndXJhdGlvbnMgb2Ygc3BlY2lhbGl6ZWQgZmVhdHVyZXMuDQo+ICA+Pg0KPiAgPj4gSWYgYSBw ZXJzb24gd2VyZSBtYW51YWxseSBjb25maWd1cmluZyBjaGFpbnMsIEkgZG9uJ3QgdGhpbmsgdGhl eSdkIA0KPiBoYXZlIGEgID4+IGNvbmNlcHR1YWwgcHJvYmxlbSwgYmVjYXVzZSB0aGV5J2QgaGF2 ZSBhIGRpYWdyYW0gdGhleSBuZWVkIA0KPiB0bw0KPiBpbXBsZW1lbnQ6DQo+ICA+PiB7U0YtZm9v IChmaXJzdC1iZWhhdmlvciksIFNGLWJhciwgU0YtZm9vIChzZWNvbmQtYmVoYXZpb3IpLCANCj4g U0YtZm9vYmFyfSAgPj4gID4+IElmIHdlIHdhbnRlZCB0byBzdGFuZGFyZGl6ZSBpdCwgd2UgY291 bGQgbWF5YmUgbWFrZSANCj4gdGhlIEZ1bmN0aW9uIHNpbXBseSBhICA+PiBsYWJlbCB0aGF0IG1l YW5zIHNvbWV0aGluZyB0byB0aGUgZGV2aWNlLS1hbiANCj4gaW5kaXJlY3Rpb24gdG8gYSAgPj4g Y29uZmlndXJhdGlvbiBzZXQuDQo+ICA+Pg0KPiAgPj4gLURhdmUNCj4gID4+DQo+ICA+Pg0KPiAg Pj4NCj4gID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICA+PiBGcm9tOiBzZmMgW21h aWx0bzpzZmMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbiBQYXJrZXINCj4gPj4g U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE1IDExOjMxIEFNICA+PiBUbzogRGF2ZSBE b2xzb247DQo+IEpvZWwgTS4gSGFscGVybjsgbW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTsg ID4+IHNmY0BpZXRmLm9yZyAgPj4NCj4gQ2M6IEJlbiBXcmlnaHQgKEJlbi5XcmlnaHRAbWV0YXN3 aXRjaC5jb20pICA+PiBTdWJqZWN0OiBSZTogW3NmY10NCj4gZHJhZnQtcXVpbm4tc2ZjLW5zaDog U3VwcG9ydCBvZiBTRiBTcGlyYWxzICA+PiAgPj4gSGksIERhdmUuDQo+ICA+Pg0KPiAgPj4gSSBh Z3JlZSB0aGF0IG9uIHRoZSB3aXJlLCB0aGlzIGlzIHRoZSB3YXkgaXQgd291bGQgd29yay4NCj4g ID4+DQo+ICA+PiBCdXQsIHdoZW4gY29tcG9zaW5nIHRoZSBjaGFpbiwgaXQgc2VlbXMgbGlrZSBp bmZvcm1hdGlvbiB3b3VsZCBiZSANCj4gbGFja2luZyAgPj4gaWYgYSBjaGFpbiB3ZXJlIGV4cHJl c3NlZCBzaW1wbHkgYXMge1NGLWZvbywgU0YtYmFyLCANCj4gU0YtZm9vLCBTRi1mb29iYXJ9Lg0K PiAgPj4gICBJdCBpcyBjb21wbGV0ZWx5IGltcGxpY2l0IHRoYXQgc2luY2UgU0YtZm9vIGFwcGVh cnMgdHdpY2UsIGl0IHBlcmhhcHMNCj4gID4+IHNob3VsZCBwZXJmb3JtIHNvbWUgZGlmZmVyZW50 IGR1dHkgd2hlbiBpbmRleCA9IDAgdnMgd2hlbiBpbmRleCA9IDIuDQo+ICA+Pg0KPiAgPj4gQXQg Zmlyc3QsIEkgdGhvdWdodCB0aGF0IGFuIGFsdGVybmF0aXZlIHdheSB0byBoYW5kbGUgdGhpcyB3 b3VsZCANCj4gYmUgdG8gID4+IHVzZSBtdWx0aXBsZSBsb2dpY2FsIGlkZW50aXRpZXMgZm9yIFNG LWZvby4gIEluIHRoaXMgY2FzZSwgDQo+IHRoZSBjaGFpbiAgPj4gYWJvdmUgd291bGQgYmUgZXhw cmVzc2VkIGFzIHtTRi1mb28tZmlyc3QtYmVoYXZpb3IsIFNGLWJhciwNCj4gID4+IFNGLWZvby1z ZWNvbmQtYmVoYXZpb3IsIFNGLWZvb2Jhcn0uICAgQnV0LCB0aGUgcHJvYmxlbSBoZXJlIGlzIHNl bGVjdGluZw0KPiAgPj4gdGhlIFJTUCwgYXNzdW1pbmcgdGhhdCBTRi1mb28gaGFzIG11bHRpcGxl IGluc3RhbmNlcy4gICBOb3RoaW5nIGluIHRoaXMNCj4gID4+IHNlY29uZCBmbGF2b3Igb2YgY2hh aW4gc2F5cyB0aGF0IHRoZSBzYW1lIGluc3RhbmNlIG9mIFNGLWZvby0qIA0KPiBtdXN0IGJlICA+ PiBzZWxlY3RlZCB0byBzYXRpc2Z5IFNGLWZvby1maXJzdC1iZWhhdmlvciBhbmQgDQo+IFNGLWZv by1zZWNvbmQtYmVoYXZpb3IgID4+ICh3aGljaCBtYXkgbm90IGJlIHJlcXVpcmVkLCBidXQgc2hv dWxkIGJlIHBvc3NpYmxlIHRvIGZvcmNlIGFzIHN1Y2gpLg0KPiAgPj4NCj4gID4+IEkgZ3Vlc3Mg d2hhdCBJJ20gc2F5aW5nIGlzIHRoYXQgc3BpcmFsaW5nIGhhcyBhIHN1YnRsZXR5IHRvIGl0IA0K PiB0aGF0IGlzbid0ICA+PiB5ZXQgYWRlcXVhdGVseSBhZGRyZXNzZWQgYW5kIHRoYXQgSSBkb24n dCBoYXZlIGEgDQo+IHNwZWNpZmljIHByb3Bvc2FsIHRvICA+PiBzb2x2ZSBpdCwgZWl0aGVyLg0K PiAgPj4NCj4gID4+ICAgIFJvbg0KPiAgPj4NCj4gID4+DQo+ICA+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiAgPj4gRnJvbTogc2ZjIFttYWlsdG86c2ZjLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBEYXZlIERvbHNvbg0KPiA+PiBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkg MjYsIDIwMTUgMTE6MjEgQU0gID4+IFRvOiBKb2VsIE0uIEhhbHBlcm47DQo+IG1vaGFtZWQuYm91 Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZyAgPj4gQ2M6IEJlbiBXcmlnaHQNCj4gKEJl bi5XcmlnaHRAbWV0YXN3aXRjaC5jb20pICA+PiBTdWJqZWN0OiBSZTogW3NmY10NCj4gZHJhZnQt cXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzICA+PiAgPj4gSWYgSSBtYXkgdHJ5 IHRvIHB1dCANCj4gaXQgc2ltcGx5LCBJJ3ZlIGFsd2F5cyB0aG91Z2h0IG9mIGl0IHRoaXMgd2F5 Og0KPiAgPj4gLS0+IEVhY2ggbm9kZSBpbiB0aGUgY2hhaW4gc2VsZWN0cyB0aGUgY29udGV4dCBm b3IgcHJvY2Vzc2luZyBhbmQgDQo+IHRoZSAgPj4gbmV4dCBob3Agb24gdGhlIGJhc2lzIG9mIEJP VEggcGF0aCBJRCBhbmQgSW5kZXgsIHdoaWxlIA0KPiBkZWNyZW1lbnRpbmcgdGhlICA+PiBpbmRl eCBmb3IgdGhlIG5leHQgaG9wLg0KPiAgPj4NCj4gID4+IFRoYXQgYmVoYXZpb3Igc3VwcG9ydHMg c3BpcmFsaW5nLg0KPiAgPj4NCj4gID4+DQo+ICA+Pg0KPiAgPj4gLURhdmUNCj4gID4+DQo+ICA+ Pg0KPiAgPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gID4+IEZyb206IHNmYyBbbWFp bHRvOnNmYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9lbCBNLiANCj4gSGFscGVy biAgPj4gU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDI2LCAyMDE1IDEwOjAyIEFNICA+PiBUbzog DQo+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNmY0BpZXRmLm9yZyAgPj4gQ2M6IEJl biBXcmlnaHQNCj4gKEJlbi5XcmlnaHRAbWV0YXN3aXRjaC5jb20pICA+PiBTdWJqZWN0OiBSZTog W3NmY10NCj4gZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGlyYWxzICA+PiAg Pj4gVGhlcmUgYXJlIHR3byANCj4gZGlmZmVyZW50IGFzcGVjdHMgb2YgU3BpcmFscy4NCj4gID4+ DQo+ICA+PiBPbmUgb2YgdGhlIHR3byBhc3BlY3RzIGlzIGVuYWJsaW5nIGEgcGFja2V0IHRoYXQg cmVwZWF0ZWRseSANCj4gYXJyaXZlcyBhdCAgPj4gdGhlIHNhbWUgU0ZGIHRvIGdldCB0aGUgY29y cmVjdCBzZXJ2aWNlcyBwcm92aWRlZCBlYWNoIA0KPiB0aW1lIGl0IGFycml2ZXMsICA+PiBhbmQg dG8gZ28gdG8gdGhlIGNvcnJlY3QgbmV4dCBTRkYgZWFjaCB0aW1lIGl0IA0KPiBhcnJpdmVzLiAg VGhlIFNlcnZpY2UgUGF0aCAgPj4gSW5kZXgsIHVzZWQgYnkgdGhlIFNGRiB0byBzZWxlY3QgDQo+ IHNlcnZpY2UgZnVuY3Rpb25zIGFuZCBuZXh0IFNGRiwgcHJvdmlkZXMgID4+IHRoYXQgY2FwYWJp bGl0eS4NCj4gID4+DQo+ICA+PiBUaGUgb3RoZXIgYXNwZWN0IGlzIGhvdyB0aGUgU2VydmljZSBG dW5jdGlvbnMgdGhlbXNlbHZlcyBoYW5kbGUgc3BpcmFscy4NCj4gID4+ICAgVG8gYSBsYXJnZSBk ZWdyZWUsIHRoYXQgZGVwZW5kcyB1cG9uIHRoZSBpbmRpdmlkdWFsIHNlcnZpY2UgZnVuY3Rpb24u DQo+ICA+PiAgIEkgbm9ybWFsbHkgYXNzdW1lIHRoYXQgaXQgd291bGQgdXNlIHBhY2tldCBjb250 ZXh0IChhcyBkZXNjcmliZWQNCj4gaW4gdGhlDQo+ICA+PiB0ZXh0IHlvdSBxdW90ZSkgdG8gZGV0 ZXJtaW5lIHdoYXQgdG8gZG8uDQo+ICA+Pg0KPiAgPj4gU2luY2UgSSB3b3VsZCBwcmVmZXIgdGhh dCBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUgaW5kZXBlbmRlbnQgb2YgdGhlDQo+ID4+IHVuZGVybHlp bmcgc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBpbmZyYXN0cnVjdHVyZSwgYW5kIGFyZSBub3Qg DQo+ID4+IHNlbnNpdGl2ZSB0byBob3cgbWFueSBmdW5jdGlvbnMgYXJlIGJlZm9yZSBvciBhZnRl ciB0aGVtIGluIHRoZQ0KPiBjaGFpbiwgSSAgPj4gd291bGQgcGVyc29uYWxseSBwcmVmZXIgdGhh dCB0aGV5IG5vdCB1c2UgdGhlIHBhdGggaW5kZXggDQo+IGZvciB0aGF0LiAgSSAgPj4gd291bGQg cmVjb21tZW5kIHRoYXQgaWYgdGhlIHBhY2tldCBkb2VzIG5vdCBjYXJyeSANCj4gZW5vdWdoIGNv bnRleHQgdGhhdCB0aGUgID4+IHNlcnZpY2UgZnVuY3Rpb24gY291bGQgYW5kIHNob3VsZCB1c2Ug DQo+IG1ldGFkYXRhIHRvIGNhcnJ5IGl0cyBuZWVkZWQgc3RhdGUgID4+IGluZm9ybWF0aW9uLiAg QnV0IG5laXRoZXIgSSANCj4gcGVyc29uYWxseSBub3IgdGhlIFNGQyBXb3JraW5nIEdyb3VwIGdl dCB0byAgPj4gdGVsbCBmb2xrcyBob3cgdG8gDQo+IGJ1aWxkIHRoZWlyIHNlcnZpY2UgZnVuY3Rp b25zLiAgU28gdGhleSBtYXkgY29tZSB1cCAgPj4gd2l0aCBvdGhlciANCj4gbWV0aG9kcyBmb3Ig YWRkcmVzc2luZyB0aGVpciBuZWVkcy4gIFdoaWNoIGlzIGFsc28gZmluZS4NCj4gID4+DQo+ICA+ PiBUaHVzLCBJIHdvdWxkIG5vdCBleHBlY3QgdGhpcyBkb2N1bWVudCB0byBkaXNjdXNzIGhvdyBz ZXJ2aWNlIA0KPiBmdW5jdGlvbnMgID4+IHRoZW1zZWx2ZXMgaGFuZGxlIHJldmlzaXRpbmcuICBC dXQgbWV0YWRhdGEgY2xlYXJseSANCj4gYWxsb3dzIGZvciBhIHJhbmdlIG9mICA+PiBiZWhhdmlv cnMgdGhhdCB3aWxsIHdvcmsuICBBbmQgdGhlIHBhdGggDQo+IGluZGV4IGhhbmRsZXMgdGhlIFNG RiBuZWVkcyAgPj4gcmVsYXRpdmUgdG8gc3BpcmFscywgd2hpY2ggaXMgd2hhdCB3ZSANCj4gbmVl ZCB0byBoYW5kbGUuDQo+ICA+Pg0KPiAgPj4gWW91cnMsDQo+ICA+PiBKb2VsDQo+ICA+Pg0KPiAg Pj4gT24gMi8yNi8xNSA5OjUyIEFNLCBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3Rl Og0KPiAgPj4+IFJlLSwNCj4gID4+Pg0KPiAgPj4+IFNwaXJhbCBpcyBub3QgbWVudGlvbmVkIGlu IHRoZSBkcmFmdCwgYnV0IFNGIGxvb3AgaXMuDQo+ICA+Pj4NCj4gID4+PiBJJ20gYXNraW5nIHRo ZSBxdWVzdGlvbiBiZWNhdXNlIEkgZG9uJ3QgZ2V0IGZyb20gdGhlIGRyYWZ0IGhvdyANCj4gc3Bp cmFscyAgPj4+IGNvdWxkIHdvcmsgKHRoYXQgaXMgYSBTRiBpbnZva2VkIHNldmVyYWwgdGltZSBp biB0aGUgDQo+IGNvbnRleHQgb2YgdGhlIHNhbWUgID4+PiBTRkMpLg0KPiAgPj4+DQo+ICA+Pj4g QmVmb3JlIHByb3Bvc2luZyB0ZXh0LCBJIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCBmaXJzdCBo b3cgaXQgd29ya3MuDQo+ICA+Pj4gSWYgeW91IGNhbiBwcm92aWRlIGFuIGV4YW1wbGUsIHRoaXMg d2lsbCBiZSBldmVuIGdyZWF0Lg0KPiAgPj4+DQo+ICA+Pj4gVGhhbmsgeW91Lg0KPiAgPj4+DQo+ ICA+Pj4gQ2hlZXJzLA0KPiAgPj4+IE1lZA0KPiAgPj4+DQo+ICA+Pj4+IC0tLS0tTWVzc2FnZSBk J29yaWdpbmUtLS0tLQ0KPiAgPj4+PiBEZSA6IEpvZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBq b2VsaGFscGVybi5jb21dIEVudm95w6kgOiBqZXVkaQ0KPiAyNiAgPj4+PiBmw6l2cmllciAyMDE1 IDE1OjQxIMOAIDogQk9VQ0FEQUlSIE1vaGFtZWQgSU1UL09MTjsgc2ZjQGlldGYub3JnIENjIDoN Cj4gID4+Pj4gQmVuIFdyaWdodCAoQmVuLldyaWdodEBtZXRhc3dpdGNoLmNvbSkgT2JqZXQgOiBS ZTogW3NmY10gID4+Pj4NCj4gZHJhZnQtcXVpbm4tc2ZjLW5zaDogU3VwcG9ydCBvZiBTRiBTcGly YWxzZ3Q7Pj4+ICA+Pj4+IFRoZSBTRiBTcGlyYWxzIA0KPiByZXF1aXJlbWVudCBpcyBvbmUgb2Yg dGhlIGtleSBkcml2ZXJzIGZvciB0aGUgaW5kZXguDQo+ICA+Pj4+IFRoZSBpbmRleCBhbGxvd3Mg b25lIHRvIHRlbGwgd2hlcmUgb25lIGlzIGluIHRoZSBzcGlyYWwsIGFuZCANCj4gYWxzbyB0byAg Pj4+PiBicmVhayBhIGxvb3AgaWYgb25lIGhhcyBhIGxvb3AgaW5zdGVhZCBvZiBhIHNwaXJhbC4N Cj4gID4+Pj4NCj4gID4+Pj4gSXMgdGhlcmUgdGV4dCB0aGF0IHdlIGNvdWxkIGFkZCB0aGF0IHdv dWxkIGhlbHAgbWFrZSB0aGlzIGNsZWFyLA0KPiA+Pj4+IHNpbmNlIHlvdXIgZWFybGllciBxdWVz dGlvbiBhYm91dCB0aGUgcGF0aCBpbmRleCBzdWdnZXN0cyB0aGF0IGl0DQo+IGlzICA+Pj4+IG5v dCBhcyBjbGVhciBhcyBpdCBzaG91bGQgYmU/DQo+ICA+Pj4+DQo+ICA+Pj4+IFlvdXJzLA0KPiAg Pj4+PiBKb2VsDQo+ICA+Pj4+DQo+ICA+Pj4+IE9uIDIvMjYvMTUgODo0MiBBTSwgbW9oYW1lZC5i b3VjYWRhaXJAb3JhbmdlLmNvbSB3cm90ZToNCj4gID4+Pj4+IEhpIFBhdWwsIGFsbCwNCj4gID4+ Pj4+DQo+ICA+Pj4+PiBUaGVyZSB3ZXJlIGEgZGlzY3Vzc2lvbiBpbiB0aGUgbWFpbGluZyBsaXN0 ICA+Pj4+Pg0KPiAoaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NmYy9jdXJy ZW50L21zZzAxNzAxLmh0bWwpDQo+ICA+Pj4+PiB0aGF0IGxlZCB0byBkZWZpbmluZyB3aGF0IGlz IG1lYW50IGJ5IFNGIFNwaXJhbHM6IChiZWxvdyBpcyANCj4gcHJvdmlkZWQgID4+Pj4+IGFuIGV4 Y2VycHQgZnJvbSAgPj4+Pj4NCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm91 Y2FkYWlyLXNmYy1yZXF1aXJlbWVudHMtMDYgd2hlcmUNCj4gPj4+Pj4gdGhlIGNvbmNsdXNpb25z IG9mIHRoYXQgZGlzY3Vzc2lvbiB3ZXJlIHJlY29yZGVkKSAgPj4+Pj4NCj4gID4+Pj4+ICIgICBv ICBTZXJ2aWNlIEZ1bmN0aW9uIFNwaXJhbDogZGVub3RlcyBhIFNlcnZpY2UgRnVuY3Rpb24gQ2hh aW4gaW4NCj4gID4+Pj4gd2hpY2gNCj4gID4+Pj4+DQo+ICA+Pj4+PiAgICAgICAgICBkYXRhIGlz IGhhbmRsZWQgYnkgYSBTZXJ2aWNlIEZ1bmN0aW9uLCBmb3J3YXJkZWQgb253YXJkcywNCj4gID4+ Pj4+IGFuZA0KPiAgPj4+Pj4NCj4gID4+Pj4+ICAgICAgICAgIGFycml2ZXMgb25jZSBhZ2FpbiBh dCB0aGF0IFNlcnZpY2UgRnVuY3Rpb24uDQo+ICA+Pj4+Pg0KPiAgPj4+Pj4gICAgICAgICAgKiAg Tm90ZSB0aGF0IHNvbWUgU2VydmljZSBGdW5jdGlvbnMgc3VwcG9ydCBidWlsdC1pbg0KPiAgPj4+ Pj4gZnVuY3Rpb25zIHRvDQo+ICA+Pj4+Pg0KPiAgPj4+Pj4gICAgICAgICAgICAgYWNjb21tb2Rh dGUgc3BpcmFsczsgdGhlc2Ugc2VydmljZS1zcGVjaWZpYyBmdW5jdGlvbnMgbWF5DQo+ICA+Pj4+ Pg0KPiAgPj4+Pj4gICAgICAgICAgICAgcmVxdWlyZSB0aGF0IHRoZSBkYXRhIHJlY2VpdmVkIGlu IGEgc3BpcmFsIHNob3VsZCBkaWZmZXINCj4gID4+Pj4+IGluIGENCj4gID4+Pj4+DQo+ICA+Pj4+ PiAgICAgICAgICAgICB3YXkgdGhhdCB3aWxsIHJlc3VsdCBpbiBhIGRpZmZlcmVudCBwcm9jZXNz aW5nIGRlY2lzaW9uDQo+ICA+Pj4+PiB0aGFuDQo+ICA+Pj4+Pg0KPiAgPj4+Pj4gICAgICAgICAg ICAgdGhlIG9yaWdpbmFsIGRhdGEuICBUaGlzIGRvY3VtZW50IGRvZXMgbm90IG1ha2Ugc3VjaA0K PiAgPj4+Pj4NCj4gID4+Pj4+ICAgICAgICAgICAgIGFzc3VtcHRpb24uDQo+ICA+Pj4+Pg0KPiAg Pj4+Pj4gICAgICAgICAgKiAgQSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluIG1heSBpbnZvbHZlIG9u ZSBvciBtb3JlIFNlcnZpY2UNCj4gID4+Pj4+DQo+ICA+Pj4+PiAgICAgICAgICAgICBGdW5jdGlv biBTcGlyYWxzLg0KPiAgPj4+Pj4NCj4gID4+Pj4+ICAgICAgICAgICogIFVubGlrZSBTZXJ2aWNl IEZ1bmN0aW9uIGxvb3AsIHNwaXJhbHMgYXJlIG5vdCBjb25zaWRlcmVkDQo+ICA+Pj4+PiBhcw0K PiAgPj4+Pj4NCj4gID4+Pj4+ICAgICAgICAgICAgIGVycm9ycy4iDQo+ICA+Pj4+Pg0KPiAgPj4+ Pj4gQW5kIHRoaXMgY29tcGFuaW9uIHJlcXVpcmVtZW50Og0KPiAgPj4+Pj4NCj4gID4+Pj4+ICIg ICAgICAgICAgICAgICBBLiAgU2VydmljZSBGdW5jdGlvbnMgTUFZIGJlIGludm9rZWQgbXVsdGlw bGUNCj4gdGltZXMgaW4NCj4gID4+Pj4+DQo+ICA+Pj4+PiAgICAgICAgICAgICAgICAgICAgICAg dGhlIHNhbWUgU2VydmljZSBGdW5jdGlvbiBDaGFpbiAoZGVub3RlZCBhcyBTRg0KPiAgPj4+Pj4N Cj4gID4+Pj4+ICAgICAgICAgICAgICAgICAgICAgICBTcGlyYWwpLCBidXQgdGhlIHNvbHV0aW9u IE1VU1QgcHJldmVudCBpbmZpbml0ZQ0KPiAgPj4+Pj4NCj4gID4+Pj4+ICAgICAgICAgICAgICAg ICAgICAgICBmb3J3YXJkaW5nIGxvb3BzLiDCuw0KPiAgPj4+Pj4NCj4gID4+Pj4+IFJlYWRpbmcg dGhlIGN1cnJlbnQgZHJhZnQtcXVpbm4tc2ZjLW5zaCwgSSBkb24ndCBzZWUgaG93IHRoaXMgaXMg bWV0Lg0KPiAgPj4+Pj4NCj4gID4+Pj4+IENhbiB5b3UgcGxlYXNlIGNsYXJpZnkgd2hldGhlciB0 aGlzIGlzIHN1cHBvcnRlZCBhbmQgaG93Pw0KPiAgPj4+Pj4NCj4gID4+Pj4+IFRoYW5rIHlvdS4N Cj4gID4+Pj4+DQo+ICA+Pj4+PiBDaGVlcnMsDQo+ICA+Pj4+Pg0KPiAgPj4+Pj4gTWVkDQo+ICA+ Pj4+Pg0KPiAgPj4+Pj4NCj4gID4+Pj4+DQo+ICA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAgPj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPiAg Pj4+Pj4gc2ZjQGlldGYub3JnDQo+ICA+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NmYw0KPiAgPj4+Pj4NCj4gID4+Pg0KPiAgPj4NCj4gID4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICA+PiBzZmMgbWFpbGluZyBs aXN0DQo+ICA+PiBzZmNAaWV0Zi5vcmcNCj4gID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2ZjDQo+ICA+Pg0KPiAgPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gID4+IHNmYyBtYWlsaW5nIGxpc3QNCj4gID4+IHNmY0Bp ZXRmLm9yZw0KPiAgPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZmMN Cj4gID4+DQo+ICA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiAgPj4gc2ZjIG1haWxpbmcgbGlzdA0KPiAgPj4gc2ZjQGlldGYub3JnDQo+ICA+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiAgPj4NCj4gID4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICA+PiBzZmMg bWFpbGluZyBsaXN0DQo+ICA+PiBzZmNAaWV0Zi5vcmcNCj4gID4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2ZjDQo+ICA+DQo+ICA+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2ZjIG1haWxpbmcgbGlzdA0Kc2ZjQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0K From nobody Thu Feb 26 14:10:55 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57BFC1A6EF4 for ; Thu, 26 Feb 2015 14:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 AiJiGPNWr12M for ; Thu, 26 Feb 2015 14:10:51 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D23B1A8547 for ; Thu, 26 Feb 2015 14:10:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,655,1418083200"; d="scan'208,217";a="150981464" X-IPAS-Result: A2CmBACbmO9U/+sKqMBbgj+Bc8F2h3UBAQEBAQF8hBYnZAEMDmYXEATgBZQzBYoqg0yfB4FoDAEwHIFQgjN/AQEB Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 26 Feb 2015 22:10:45 +0000 Received: from SEAEXCHMBX01.olympus.F5Net.com (192.168.15.223) by SEAEXCHMBX05.olympus.F5Net.com (192.168.15.227) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 26 Feb 2015 14:10:44 -0800 Received: from SEAEXCHMBX01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75]) by seaexchmbx01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75%13]) with mapi id 15.00.1044.021; Thu, 26 Feb 2015 14:10:44 -0800 From: Sumandra Majee To: "sfc@ietf.org" Thread-Topic: Support Bidirection/Symmetric flow Thread-Index: AQHQUhEQI2Pu+LmiWUKdVa7GMQ9w3w== Date: Thu, 26 Feb 2015 22:10:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: multipart/alternative; boundary="_000_D114D9E134F02smajeef5com_" MIME-Version: 1.0 Archived-At: Subject: [sfc] Support Bidirection/Symmetric flow 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, 26 Feb 2015 22:10:53 -0000 --_000_D114D9E134F02smajeef5com_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, The SFC architecture document says (correctly) that ingress path and egress= path of a given flow or work unit could symmetric, asymmetric or hybrid. = However a front/back (end) classifier is not always the correct place to de= rive this information. Some cases are simple, IN: Classifier -> SF1 -> SF2 -> Cache(*) - >SF3 - RTR- OUT: Classifier -> SF3 --> Cache --> RTR The actual chains are not laid out like that, but for this discussion lets = stick with the above figure. In this case a device like cache detects that = both direction of flow must flow thru the cache (cache miss). Now lets replace the cache with a modern ADC device. These devices can and = will make the decision for each flow. For optimal operation it is best to s= ignal the upstream node that flow(X) must come back to this SF or should by= pass this SF. How can we do this signaling? Metadata is an option, but it is a generic us= e case where the format of this metadata then should be standardized. The responsible SF can demand the return PATH to be some 221 that forces re= turn traffic thru that SF, well that may not always be the good. Some sort of label stack? Interested to hear from you.. Regards. Sumandra --_000_D114D9E134F02smajeef5com_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <4E962680E5FC1B4A8EC95E385F4A3E0B@F5.com> Content-Transfer-Encoding: quoted-printable
    Hello,

    The SFC architecture document says (correctly) that ingress path and e= gress path of a given flow or work unit could symmetric, asymmetric or hybr= id.  However a front/back (end) classifier is not always the correct p= lace to derive this information.  Some cases are simple,

      IN:      Classifier —> SF1 —> = SF2 —> Cache(*) — >SF3 — RTR—
     OUT:   Classifier -> SF3 --> Cache ——>= RTR

    The actual chains are not laid out like that, but for this discussion = lets stick with the above figure. In this case a device like cache detects = that both direction of flow must flow thru the cache (cache miss). 

    Now lets replace the cache with a modern ADC device. These devices can= and will make the decision for each flow. For optimal operation it is best= to signal the upstream node that flow(X) must come back to this SF or shou= ld bypass this SF.

    How can we do this signaling? Metadata is an option, but it is a gener= ic use case where the format of this metadata then should be standardized.&= nbsp;
    The responsible SF can demand the return PATH to be some 221 that forc= es return traffic thru that SF,   well that may not always be the good= .

    Some sort of label stack?

    Interested to hear from you..

    Regards.

    Sumandra
    --_000_D114D9E134F02smajeef5com_-- From nobody Thu Feb 26 14:15:39 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47C41A1B25 for ; Thu, 26 Feb 2015 14:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1te8mL0iVBR for ; Thu, 26 Feb 2015 14:15:30 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 293491A016B for ; Thu, 26 Feb 2015 14:15:29 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTA58344; Thu, 26 Feb 2015 22:15:27 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 26 Feb 2015 22:15:26 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Thu, 26 Feb 2015 14:15:20 -0800 From: Linda Dunbar To: Joel Halpern , Ron Parker , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: Service Functions used in a chain is anything but "Abstract" (was RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 Thread-Index: AdBRG3N71HhtcFa0RsuzFw1dT6iegwAAMTdQAABKvqAAABrE4AABrb3gADKL8WAABtoL4AAAPTwgAAA6eQAAAP2qkA== Date: Thu, 26 Feb 2015 22:15:20 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645EE3EF4@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE3CC3@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB07603350E22@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE3E72@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB07603350EAA@eusaamb101.ericsson.se> In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB07603350EAA@eusaamb101.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.210] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645EE3EF4dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [sfc] Service Functions used in a chain is anything but "Abstract" (was RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 26 Feb 2015 22:15:38 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645EE3EF4dfweml701chm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Joel, Thank you for the understanding. Through our 9-vendor joined Service Graph Forwarding Proof of Concept proje= ct for NFV-ONF, we learned that same service function by different vendors = can be very different. E.g. FW by Vendor A can be very different from FW by= Vendor B. So the ordered set of "Service Functions" has to be specific to which vendo= r's service functions. For example, one service function chain could be " --> "; another service function chain could be " --> ". Bottom line, we don't have "abstract service functions". I don't understan= d why SFC definition has to say "order set of abstract service functions". = I suggest removing the word "abstract" from the SFC definition. Cheers, Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Thursday, February 26, 2015 3:36 PM To: Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Sorry. I now understand your question. As a mathematician, I would probably be happy if the definition simply said= "a partially ordered set of abstract service functions that must be applie= d ..." However, I think most people would find that less than enlightening. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, February 26, 2015 4:32 PM To: Joel Halpern; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Joel, Agree with what you said: "..., it is quite possible to have tighter ordering constraints on an SFP t= han on an SFC." [Linda] Do you really need the extra wording ""..and ordering constraints" = for the SFC definition? Is it sufficient to say "A service function chain defines an ordered set of= abstract service functions (SFs) that must be applied to packets and/or fr= ames and/or flows"? Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Thursday, February 26, 2015 3:23 PM To: Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 While Ron's wording was roughly right, it did not seem to add anything to w= hat we had, and was not written as a definition, but as a description. As = such, the question is whether it adds anything to the descriptive text furt= her in the document. Also, it is quite possible to have tighter ordering constraints on an SFP t= han on an SFC. How tight the ordering constraints are in the SFC probably = depends upon the SFC definer and tools. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, February 26, 2015 1:34 PM To: Ron Parker; Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I think Ron's suggested wording for SFC is much more straight forward than = the current SFC definition on the sfc-architecture-05. draft-ietf-sfc-architecture-05 has: Service Function Chain (SFC): A service function chain defines an ordered set of abstract service functions (SFs) and ordering constraints that must be applied to packets and/or frames and/or flows selected as a result of classification. An example of an abstract service function is "a firewall". The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions need to be applied. The term service chain is often used as shorthand for service function chain. Isn't the wording of "an ordered set of abstract service functions (SFs) t= hat must be applied to packets and/or frames and/or flows" already sufficie= nt enough to describe the ordering constraints? Why need the extra wording of "..and ordering constraints"? "...selected as a result of classification" should be more like ".. selecte= d based on a specific matching criteria". I suggest using the following wording: "A service function chain defines an ordered set of abstract service functi= ons (SFs) that must be applied to packets and/or frames and/or flows that meet the sp= ecific matching criteria." It is implementation specific to have a classification node inspecting pack= ets and attaching different SFC-IDs based on the "Service Chain matching Cr= iteria" in the header to make it easier for subsequent nodes. Linda From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 25, 2015 12:02 PM To: Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I think the key concept here is that of a 3 level hierarchy of SFC, SFP, RS= P. I don't think that comes out clearly in the current description, espec= ially when RSP references Service Function Chain rather than Service Functi= on Path. The way I think of it: * SFC - specify the sequence of service function types that need to = be visited * SFP - specify the sequence of service function types that need to = be visited, but also optionally specify instance selection constraining pol= icies for some or all of the types * RSP - specify the exact sequence of service function instances tha= t need to be visited (with the understanding that an instance may optionall= y perform its own internal load balancing) Thanks. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Sent: Wednesday, February 25, 2015 12:11 PM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Service P= ath (RSP) in draft-ietf-sfc-architecture-05 Sorry. A packet is technically using a service function path. It is doing= so if the information in the SFC defined header indicates that the packet = is to forwarded along that service function path. Thus, the assignment / u= sage can be determined from examining the packet. The RSP itself requires = a rather omniscient observer perspective to determine, but does exist conce= ptually. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 12:08 PM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Joel, What does it mean by saying packets "using" a service chain? How does packets "use" a service chain? I am confused. Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Wednesday, February 25, 2015 10:59 AM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I don't think adding another word to the term will help comprehension, and = it will complicate usage. So I would prefer not to do that. As for the other change, packets don't belong to a service chain. They may= be using a service chain. They may be assigned by a classifier to a servi= ce chain, but they don't "belong" to the chain as I understand the words. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 11:52 AM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: wording Suggestion for the Rendered Service Path (RSP) in draft-ie= tf-sfc-architecture-05 Joel and Carlos, The current definition of RSP is: Rendered Service Path (RSP): The Service Function Path is a constrained specification of where packets using a certain service chain must go. While it may be so constrained as to identify the exact locations, it can also be less specific. Packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. Some suggestions: - I would think it is more accurate to call it "Rendered Service Fun= ction Path (RSFP)". - Why do you say "packets using a certain service chain"? It is more= accurate to say "packets belonging to a certain service function chain". Here is my suggested wording for RSP (or RSFP): - The sequence of actual SFFs and SFs in the network traversed by pa= ckets belonging to a specific Service Function Chain is known as the Render= ed Service Function Path (RSFP). Cheers, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645EE3EF4dfweml701chm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Joel,

     

    Thank you for the unde= rstanding.

     

    Through our 9-vendor j= oined Service Graph Forwarding Proof of Concept project for NFV-ONF, we lea= rned that same service function by different vendors can be very different.= E.g. FW by Vendor A can be very different from FW by Vendor B.

     

    So the ordered set of = “Service Functions” has to be specific to which vendor’s = service functions.

     

    For example, one servi= ce function chain could be “<Vendor A><FW> =E0  <Vendor B> <SecurityGW>”; = another service function chain could be “<Vendor B><FW> =E0 <Vendor C><SecurityGW>”.

     

    Bottom line, we don= 217;t have “abstract service functions”.  I don’t un= derstand why SFC definition has to say “order set of abstract service= functions”.  I suggest removing the word “abstract”= from the SFC definition.

     

    Cheers,

    Linda

     

     

     

     

    From: Joel Hal= pern [mailto:joel.halpern@ericsson.com]
    Sent: Thursday, February 26, 2015 3:36 PM
    To: Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.= org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Sorry.  I now und= erstand your question.

     

    As a mathematician, I = would probably be happy if the definition simply said “a partially or= dered set of abstract service functions that must be applied …”=

    However, I think most = people would find that less than enlightening.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Thursday, February 26, 2015 4:32 PM
    To: Joel Halpern; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Joel,

     

     

    Agree with what you sai= d:

     

    “…, it is = quite possible to have tighter ordering constraints on an SFP than on an SF= C.” 

     

    [Linda] Do you really = need the extra wording ““..and ordering constraints” for the SFC definition?

    Is it sufficient to sa= y “A serv= ice function chain defines an ordered set of abstract service functions (SF= s) that must be applied to packets and/or frames and/or flows”?

     

     

    Linda

     

    From: Joel Hal= pern [mailto:joel.halpern@= ericsson.com]
    Sent: Thursday, February 26, 2015 3:23 PM
    To: Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    While Ron’s word= ing was roughly right, it did not seem to add anything to what we had, and = was not written as a definition, but as a description.  As such, the q= uestion is whether it adds anything to the descriptive text further in the document.

     

    Also, it is quite poss= ible to have tighter ordering constraints on an SFP than on an SFC.  H= ow tight the ordering constraints are in the SFC probably depends upon the = SFC definer and tools.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Thursday, February 26, 2015 1:34 PM
    To: Ron Parker; Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I think Ron’s su= ggested wording for SFC is much more straight forward than the current SFC = definition on the sfc-architecture-05.

     

    draft-ietf-sfc-architecture-05 has:

    Service Function Chain (SFC= ): A service function chain defines an

    ordered set of abstract ser= vice functions (SFs) and ordering

    constraints that must be ap= plied to packets and/or frames and/or

    flows selected as a result = of classification. An example of an

    abstract service function i= s "a firewall". The implied order

    may not be a linear progres= sion as the architecture allows for

    SFCs that copy to more than= one branch, and also allows for

    cases where there is flexib= ility in the order in which service

    functions need to be applie= d. The term service chain is often

    used as shorthand for servi= ce function chain.

     

    Isn’t the wordin= g of  “an ordered set of abstract service functions (SFs) that must be applied = to packets and/or frames and/or flows&= #8221; already sufficient enough to describe the ordering constraints?

     

    Why need the extra wor= ding of “..and ordering = constraints”?

     

    “...selected as a result of cla= ssification” should be more like= “.. selected based on a specific matching criteria”.

     

     

    I suggest using the fo= llowing wording:

     

    “A service function c= hain defines an ordered set of abstract service functions (SFs)

    that must be applied to pac= kets and/or frames and/or flows that meet the specific matching criteria.&#= 8221;

     

     

    It is implementation s= pecific to have a classification node inspecting packets and attaching diff= erent SFC-IDs based on the “Service Chain matching Criteria” in= the header to make it easier for subsequent nodes.

     

    Linda

     

     

    From: Ron Park= er [mailto:Ron_Par= ker@affirmednetworks.com]
    Sent: Wednesday, February 25, 2015 12:02 PM
    To: Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I think the key concep= t here is that of a 3 level hierarchy of SFC, SFP, RSP.   I don&#= 8217;t think that comes out clearly in the current description, especially = when RSP references Service Function Chain rather than Service Function Path.   The way I think of it:

     

    =B7&nb= sp;       SFC – specify the sequence of se= rvice function types that need to be visited

    =B7&nb= sp;       SFP – specify the sequence of se= rvice function types that need to be visited, but also optionally specify i= nstance selection constraining policies for some or all of the types

    =B7&nb= sp;       RSP – specify the exact sequence= of service function instances that need to be visited (with the understand= ing that an instance may optionally perform its own internal load balancing= )

     

    Thanks.

     

       Ron<= /o:p>

     

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern
    Sent: Wednesday, February 25, 2015 12:11 PM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Se= rvice Path (RSP) in draft-ietf-sfc-architecture-05

     

    Sorry.  A packet = is technically using a service function path.  It is doing so if the i= nformation in the SFC defined header indicates that the packet is to forwar= ded along that service function path.  Thus, the assignment / usage can be determined from examining the packet.  The = RSP itself requires a rather omniscient observer perspective to determine, = but does exist conceptually.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Wednesday, February 25, 2015 12:08 PM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Joel,

     

    What does it mean by s= aying packets “using” a service chain?

     

    How does packets  = ;“use” a service chain? I am confused.

     

    Linda

     

    From: Joel Hal= pern [mailto:joel.halpern@= ericsson.com]
    Sent: Wednesday, February 25, 2015 10:59 AM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I don’t think ad= ding another word to the term will help comprehension, and it will complica= te usage.  So I would prefer not to do that.

     

    As for the other chang= e, packets don’t belong to a service chain.  They may be using a= service chain.  They may be assigned by a classifier to a service cha= in, but they don’t “belong” to the chain as I understand the words.

     

    Yours,

    Joel=

     

    From: Linda Du= nbar [mailto:linda.dunbar@huawei= .com]
    Sent: Wednesday, February 25, 2015 11:52 AM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: wording Suggestion for the Rendered Service Path (RSP) in d= raft-ietf-sfc-architecture-05

     

    Joel and Carlos,

     

    The current definition of RSP is:

     

    Rendered Service Path (RSP)= : The Service Function Path is a

    constrained specification o= f where packets using a certain

    service chain must go. Whil= e it may be so constrained as to

    identify the exact location= s, it can also be less specific.

    Packets themselves are of c= ourse transmitted from and to

    specific places in the netw= ork, visiting a specific sequence of

    SFFs and SFs. This sequence= of actual visits by a packet to

    specific SFFs and SFs in th= e network is known as the Rendered

    Service Path (RSP). This de= finition is included here for use by

    later documents, such as wh= en solutions may need to discuss the

    actual sequence of location= s the packets visit.

     

     

    Some suggestions:

    -=         I would think it is more accurate to call it “Rendered Service= Function Path (RSFP)”.

    -=         Why do you say “packets using a certain service chain”? = It is more accurate to say “packets belonging to a certain service fu= nction chain”.

     

     

    Here is my suggested wording for RSP (or RSFP):=

     

    -=         The sequence of actual SFFs and SFs in the network traversed by pack= ets belonging to a specific Service Function Chain is known as the Rendered= Service Function Path (RSFP).

     

    Cheers,

     

    Linda Dunbar

     

    --_000_4A95BA014132FF49AE685FAB4B9F17F645EE3EF4dfweml701chm_-- From nobody Thu Feb 26 14:22: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 0C9C61A88AD for ; Thu, 26 Feb 2015 14:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YahZQctwdYg0 for ; Thu, 26 Feb 2015 14:21:58 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3CB1A88A7 for ; Thu, 26 Feb 2015 14:21:58 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0224.002; Thu, 26 Feb 2015 14:21:57 -0800 From: Ron Parker To: Linda Dunbar , Joel Halpern , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" Thread-Topic: Service Functions used in a chain is anything but "Abstract" (was RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 Thread-Index: AdBRG3N71HhtcFa0RsuzFw1dT6iegwAAMTdQAABKvqAAABrE4AABrb3gADKL8WAABtoL4AAAPTwgAAA6eQAAAP2qkAAAfyUw Date: Thu, 26 Feb 2015 22:21:56 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE3CC3@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB07603350E22@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE3E72@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB07603350EAA@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE3EF4@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645EE3EF4@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B2E835B43MBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Service Functions used in a chain is anything but "Abstract" (was RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 26 Feb 2015 22:22:05 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B2E835B43MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Linda, I think 'abstract' here means "one SFC-visible instance of". In your exam= ple, you would have a chain as "one instance of --> one instan= ce of ". A corresponding path would be "one gold inst= ance of --> one purple instance of ". A = corresponding RSP would be "instance-1 of --> instance 3 of , where those instances complied with the gold and purple= instance selection constraints. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Thursday, February 26, 2015 5:15 PM To: Joel Halpern; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org Subject: [sfc] Service Functions used in a chain is anything but "Abstract"= (was RE: wording Suggestion for the Rendered Service Path (RSP) in draft-i= etf-sfc-architecture-05 Joel, Thank you for the understanding. Through our 9-vendor joined Service Graph Forwarding Proof of Concept proje= ct for NFV-ONF, we learned that same service function by different vendors = can be very different. E.g. FW by Vendor A can be very different from FW by= Vendor B. So the ordered set of "Service Functions" has to be specific to which vendo= r's service functions. For example, one service function chain could be " --> "; another service function chain could be " --> ". Bottom line, we don't have "abstract service functions". I don't understan= d why SFC definition has to say "order set of abstract service functions". = I suggest removing the word "abstract" from the SFC definition. Cheers, Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Thursday, February 26, 2015 3:36 PM To: Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Sorry. I now understand your question. As a mathematician, I would probably be happy if the definition simply said= "a partially ordered set of abstract service functions that must be applie= d ..." However, I think most people would find that less than enlightening. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, February 26, 2015 4:32 PM To: Joel Halpern; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Joel, Agree with what you said: "..., it is quite possible to have tighter ordering constraints on an SFP t= han on an SFC." [Linda] Do you really need the extra wording ""..and ordering constraints" = for the SFC definition? Is it sufficient to say "A service function chain defines an ordered set of= abstract service functions (SFs) that must be applied to packets and/or fr= ames and/or flows"? Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Thursday, February 26, 2015 3:23 PM To: Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 While Ron's wording was roughly right, it did not seem to add anything to w= hat we had, and was not written as a definition, but as a description. As = such, the question is whether it adds anything to the descriptive text furt= her in the document. Also, it is quite possible to have tighter ordering constraints on an SFP t= han on an SFC. How tight the ordering constraints are in the SFC probably = depends upon the SFC definer and tools. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Thursday, February 26, 2015 1:34 PM To: Ron Parker; Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I think Ron's suggested wording for SFC is much more straight forward than = the current SFC definition on the sfc-architecture-05. draft-ietf-sfc-architecture-05 has: Service Function Chain (SFC): A service function chain defines an ordered set of abstract service functions (SFs) and ordering constraints that must be applied to packets and/or frames and/or flows selected as a result of classification. An example of an abstract service function is "a firewall". The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions need to be applied. The term service chain is often used as shorthand for service function chain. Isn't the wording of "an ordered set of abstract service functions (SFs) t= hat must be applied to packets and/or frames and/or flows" already sufficie= nt enough to describe the ordering constraints? Why need the extra wording of "..and ordering constraints"? "...selected as a result of classification" should be more like ".. selecte= d based on a specific matching criteria". I suggest using the following wording: "A service function chain defines an ordered set of abstract service functi= ons (SFs) that must be applied to packets and/or frames and/or flows that meet the sp= ecific matching criteria." It is implementation specific to have a classification node inspecting pack= ets and attaching different SFC-IDs based on the "Service Chain matching Cr= iteria" in the header to make it easier for subsequent nodes. Linda From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Wednesday, February 25, 2015 12:02 PM To: Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I think the key concept here is that of a 3 level hierarchy of SFC, SFP, RS= P. I don't think that comes out clearly in the current description, espec= ially when RSP references Service Function Chain rather than Service Functi= on Path. The way I think of it: * SFC - specify the sequence of service function types that need to = be visited * SFP - specify the sequence of service function types that need to = be visited, but also optionally specify instance selection constraining pol= icies for some or all of the types * RSP - specify the exact sequence of service function instances tha= t need to be visited (with the understanding that an instance may optionall= y perform its own internal load balancing) Thanks. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern Sent: Wednesday, February 25, 2015 12:11 PM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Service P= ath (RSP) in draft-ietf-sfc-architecture-05 Sorry. A packet is technically using a service function path. It is doing= so if the information in the SFC defined header indicates that the packet = is to forwarded along that service function path. Thus, the assignment / u= sage can be determined from examining the packet. The RSP itself requires = a rather omniscient observer perspective to determine, but does exist conce= ptually. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 12:08 PM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 Joel, What does it mean by saying packets "using" a service chain? How does packets "use" a service chain? I am confused. Linda From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Wednesday, February 25, 2015 10:59 AM To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org Subject: RE: wording Suggestion for the Rendered Service Path (RSP) in draf= t-ietf-sfc-architecture-05 I don't think adding another word to the term will help comprehension, and = it will complicate usage. So I would prefer not to do that. As for the other change, packets don't belong to a service chain. They may= be using a service chain. They may be assigned by a classifier to a servi= ce chain, but they don't "belong" to the chain as I understand the words. Yours, Joel From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Wednesday, February 25, 2015 11:52 AM To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org Subject: wording Suggestion for the Rendered Service Path (RSP) in draft-ie= tf-sfc-architecture-05 Joel and Carlos, The current definition of RSP is: Rendered Service Path (RSP): The Service Function Path is a constrained specification of where packets using a certain service chain must go. While it may be so constrained as to identify the exact locations, it can also be less specific. Packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. Some suggestions: - I would think it is more accurate to call it "Rendered Service Fun= ction Path (RSFP)". - Why do you say "packets using a certain service chain"? It is more= accurate to say "packets belonging to a certain service function chain". Here is my suggested wording for RSP (or RSFP): - The sequence of actual SFFs and SFs in the network traversed by pa= ckets belonging to a specific Service Function Chain is known as the Render= ed Service Function Path (RSFP). Cheers, Linda Dunbar --_000_CDF2F015F4429F458815ED2A6C2B6B0B2E835B43MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Linda,

     

    I think ‘abstrac= t’ here means “one SFC-visible instance of”.   = In your example, you would have a chain as “one instance of <Vendo= rA-FW> à<= span style=3D"color:#1F497D"> one instance of <VendorB-SecurityGW>= 221;.   A corresponding path would be “one gold instance of= <VendorA-FW> à<= span style=3D"color:#1F497D"> one purple instance of <VendorB-SecurityGW= >”.   A corresponding RSP would be “instance-1 of = <VendorA-FW> à<= span style=3D"color:#1F497D"> instance 3 of <VendorB-SecurityGW>, whe= re those instances complied with the gold and purple instance selection con= straints.

     

       Ron<= /o:p>

     

     

     

    From: sfc [mailto:sfc-bounces@ietf.org] On= Behalf Of Linda Dunbar
    Sent: Thursday, February 26, 2015 5:15 PM
    To: Joel Halpern; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.= org
    Subject: [sfc] Service Functions used in a chain is anything but &qu= ot;Abstract" (was RE: wording Suggestion for the Rendered Service Path= (RSP) in draft-ietf-sfc-architecture-05

     

    Joel,

     

    Thank you for the unde= rstanding.

     

    Through our 9-vendor j= oined Service Graph Forwarding Proof of Concept project for NFV-ONF, we lea= rned that same service function by different vendors can be very different.= E.g. FW by Vendor A can be very different from FW by Vendor B.

     

    So the ordered set of = “Service Functions” has to be specific to which vendor’s = service functions.

     

    For example, one servi= ce function chain could be “<Vendor A><FW> à<= span style=3D"color:#1F497D">  <Vendor B> <SecurityGW>R= 21;; another service function chain could be “<Vendor B><FW&= gt; à<= span style=3D"color:#1F497D"> <Vendor C><SecurityGW>”.

     

    Bottom line, we don= 217;t have “abstract service functions”.  I don’t un= derstand why SFC definition has to say “order set of abstract service= functions”.  I suggest removing the word “abstract”= from the SFC definition.

     

    Cheers,

    Linda

     

     

     

     

    From: Joel Halpern [mailto:joel.halpern@ericsson.com]
    Sent: Thursday, February 26, 2015 3:36 PM
    To: Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Sorry.  I now und= erstand your question.

     

    As a mathematician, I = would probably be happy if the definition simply said “a partially or= dered set of abstract service functions that must be applied …”=

    However, I think most = people would find that less than enlightening.

     

    Yours,

    Joel=

     

    From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
    Sent: Thursday, February 26, 2015 4:32 PM
    To: Joel Halpern; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Joel,

     

     

    Agree with what you said:

     

    “…, it is = quite possible to have tighter ordering constraints on an SFP than on an SF= C.” 

     

    [Linda] Do you really = need the extra wording ““..and ordering constraints” for the SFC definition?

    Is it sufficient to sa= y “A serv= ice function chain defines an ordered set of abstract service functions (SF= s) that must be applied to packets and/or frames and/or flows”?

     

     

    Linda

     

    From: Joel Halpern [mailto:joel.halpern@= ericsson.com]
    Sent: Thursday, February 26, 2015 3:23 PM
    To: Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    While Ron’s word= ing was roughly right, it did not seem to add anything to what we had, and = was not written as a definition, but as a description.  As such, the q= uestion is whether it adds anything to the descriptive text further in the document.

     

    Also, it is quite poss= ible to have tighter ordering constraints on an SFP than on an SFC.  H= ow tight the ordering constraints are in the SFC probably depends upon the = SFC definer and tools.

     

    Yours,

    Joel=

     

    From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
    Sent: Thursday, February 26, 2015 1:34 PM
    To: Ron Parker; Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I think Ron’s su= ggested wording for SFC is much more straight forward than the current SFC = definition on the sfc-architecture-05.

     

    draft-ietf-sfc-architecture-05 has:

    Service Function Chain (SFC= ): A service function chain defines an

    ordered set of abstract ser= vice functions (SFs) and ordering

    constraints that must be ap= plied to packets and/or frames and/or

    flows selected as a result = of classification. An example of an

    abstract service function i= s "a firewall". The implied order

    may not be a linear progres= sion as the architecture allows for

    SFCs that copy to more than= one branch, and also allows for

    cases where there is flexib= ility in the order in which service

    functions need to be applie= d. The term service chain is often

    used as shorthand for servi= ce function chain.

     

    Isn’t the wordin= g of  “an ordered set of abstract service functions (SFs) that must be applied = to packets and/or frames and/or flows&= #8221; already sufficient enough to describe the ordering constraints?

     

    Why need the extra wor= ding of “..and ordering = constraints”?

     

    “...selected as a result of cla= ssification” should be more like= “.. selected based on a specific matching criteria”.

     

     

    I suggest using the fo= llowing wording:

     

    “A service function c= hain defines an ordered set of abstract service functions (SFs)

    that must be applied to pac= kets and/or frames and/or flows that meet the specific matching criteria.&#= 8221;

     

     

    It is implementation s= pecific to have a classification node inspecting packets and attaching diff= erent SFC-IDs based on the “Service Chain matching Criteria” in= the header to make it easier for subsequent nodes.

     

    Linda

     

     

    From: Ron Parker [mailto:Ron_Par= ker@affirmednetworks.com]
    Sent: Wednesday, February 25, 2015 12:02 PM
    To: Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I think the key concep= t here is that of a 3 level hierarchy of SFC, SFP, RSP.   I don&#= 8217;t think that comes out clearly in the current description, especially = when RSP references Service Function Chain rather than Service Function Path.   The way I think of it:

     

    · &nbs= p;      SFC – specify the sequence of se= rvice function types that need to be visited

    · &nbs= p;      SFP – specify the sequence of se= rvice function types that need to be visited, but also optionally specify i= nstance selection constraining policies for some or all of the types

    · &nbs= p;      RSP – specify the exact sequence= of service function instances that need to be visited (with the understand= ing that an instance may optionally perform its own internal load balancing= )

     

    Thanks.

     

       Ron<= /o:p>

     

     

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel Halpern
    Sent: Wednesday, February 25, 2015 12:11 PM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered Se= rvice Path (RSP) in draft-ietf-sfc-architecture-05

     

    Sorry.  A packet = is technically using a service function path.  It is doing so if the i= nformation in the SFC defined header indicates that the packet is to forwar= ded along that service function path.  Thus, the assignment / usage can be determined from examining the packet.  The = RSP itself requires a rather omniscient observer perspective to determine, = but does exist conceptually.

     

    Yours,

    Joel=

     

    From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
    Sent: Wednesday, February 25, 2015 12:08 PM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    Joel,

     

    What does it mean by s= aying packets “using” a service chain?

     

    How does packets  = ;“use” a service chain? I am confused.

     

    Linda

     

    From: Joel Halpern [mailto:joel.halpern@= ericsson.com]
    Sent: Wednesday, February 25, 2015 10:59 AM
    To: Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: RE: wording Suggestion for the Rendered Service Path (RSP) = in draft-ietf-sfc-architecture-05

     

    I don’t think ad= ding another word to the term will help comprehension, and it will complica= te usage.  So I would prefer not to do that.

     

    As for the other chang= e, packets don’t belong to a service chain.  They may be using a= service chain.  They may be assigned by a classifier to a service cha= in, but they don’t “belong” to the chain as I understand the words.

     

    Yours,

    Joel=

     

    From: Linda Dunbar [mailto:linda.dunbar@huawei.com]
    Sent: Wednesday, February 25, 2015 11:52 AM
    To: Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org
    Subject: wording Suggestion for the Rendered Service Path (RSP) in d= raft-ietf-sfc-architecture-05

     

    Joel and Carlos,

     

    The current definition of RSP is:

     

    Rendered Service Path (RSP)= : The Service Function Path is a

    constrained specification o= f where packets using a certain

    service chain must go. Whil= e it may be so constrained as to

    identify the exact location= s, it can also be less specific.

    Packets themselves are of c= ourse transmitted from and to

    specific places in the netw= ork, visiting a specific sequence of

    SFFs and SFs. This sequence= of actual visits by a packet to

    specific SFFs and SFs in th= e network is known as the Rendered

    Service Path (RSP). This de= finition is included here for use by

    later documents, such as wh= en solutions may need to discuss the

    actual sequence of location= s the packets visit.

     

     

    Some suggestions:

    -  =       I would think it is more accurate to call it “Rendered Service= Function Path (RSFP)”.

    -  =       Why do you say “packets using a certain service chain”? = It is more accurate to say “packets belonging to a certain service fu= nction chain”.

     

     

    Here is my suggested wording for RSP (or RSFP):=

     

    -  =       The sequence of actual SFFs and SFs in the network traversed by pack= ets belonging to a specific Service Function Chain is known as the Rendered= Service Function Path (RSFP).

     

    Cheers,

     

    Linda Dunbar

     

    --_000_CDF2F015F4429F458815ED2A6C2B6B0B2E835B43MBX021W3CA2exch_-- From nobody Thu Feb 26 14:40:49 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 A718F1A88F6 for ; Thu, 26 Feb 2015 14:40:48 -0800 (PST) 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 QmvHWzgU5ujC for ; Thu, 26 Feb 2015 14:40:45 -0800 (PST) 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 7F21B1A88F4 for ; Thu, 26 Feb 2015 14:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6923; q=dns/txt; s=iport; t=1424990445; x=1426200045; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=K4OpyaAh7bzs07QNYtLbedd+ibuTia5ImPVxCvB7OLU=; b=UfV6tBzXc5ejfae3dr2bNItf+A45cjrDSl9BtmKk3uERUEquI6JlahMz fKOHfXeqB8V6w9s1p1NPSTj081471S3M5p4SjP0/8WW7rIUrykWq2XxuU tfL6gdB1THQob62nC2Y7DlHb+1iyPBDcJNyFrEm/0Dgk78AJjBlsVVI7f E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DWBQBqoO9U/5FdJa1bgj9DgSwEx3QCgSdNAQEBAQEBfIQPAQEBBCdiAgEIDgMBAgECKAcyFAMGCAIEARIbiBTXJwEBAQEBAQQBAQEBAQEBG4sThF0YAoQpBY12gXmJRZNJI4ICHIFQb4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,655,1418083200"; d="scan'208,217";a="127340353" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-7.cisco.com with ESMTP; 26 Feb 2015 22:40:45 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t1QMeimY024819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Feb 2015 22:40:44 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.248]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 16:40:44 -0600 From: "Reinaldo Penno (repenno)" To: Sumandra Majee , "sfc@ietf.org" Thread-Topic: [sfc] Support Bidirection/Symmetric flow Thread-Index: AQHQUhEQI2Pu+LmiWUKdVa7GMQ9w350DZNqA Date: Thu, 26 Feb 2015 22:40:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.24.224.109] Content-Type: multipart/alternative; boundary="_000_D114E03AB845repennociscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Support Bidirection/Symmetric flow 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, 26 Feb 2015 22:40:48 -0000 --_000_D114E03AB845repennociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It is my impression that if you rewrite the picture like this it might help= working out the solution SF1 SF2 SFF3 | | | IN: Classifier =97> SFF1 =97> SFF2 =97> Cache(*)/SFF =97 RTR=97 Since cache is actually directing (steering packets) it becomes a SFF. If y= ou adapt the reverse picture Cache/SFF will make sure reverse flows to the = same SF3. This is the whole Service Function Groups concept. thanks, From: Sumandra Majee > Date: Thursday, February 26, 2015 at 2:10 PM To: "sfc@ietf.org" > Subject: [sfc] Support Bidirection/Symmetric flow Hello, The SFC architecture document says (correctly) that ingress path and egress= path of a given flow or work unit could symmetric, asymmetric or hybrid. = However a front/back (end) classifier is not always the correct place to de= rive this information. Some cases are simple, IN: Classifier =97> SF1 =97> SF2 =97> Cache(*) =97 >SF3 =97 RTR=97 OUT: Classifier -> SF3 --> Cache =97=97> RTR The actual chains are not laid out like that, but for this discussion lets = stick with the above figure. In this case a device like cache detects that = both direction of flow must flow thru the cache (cache miss). Now lets replace the cache with a modern ADC device. These devices can and = will make the decision for each flow. For optimal operation it is best to s= ignal the upstream node that flow(X) must come back to this SF or should by= pass this SF. How can we do this signaling? Metadata is an option, but it is a generic us= e case where the format of this metadata then should be standardized. The responsible SF can demand the return PATH to be some 221 that forces re= turn traffic thru that SF, well that may not always be the good. Some sort of label stack? Interested to hear from you.. Regards. Sumandra --_000_D114E03AB845repennociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0C6E4EE7F9C3A94995BD8D77B18D2AD3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    It is my impression that if you rewrite the= picture like this it might help working out the solution

                &= nbsp;          SF1      SF2   =       SFF3
                &= nbsp;           |        | &nb= sp;        |
    IN:      Classifier =97> = SFF1 =97> SFF2 =97> Cache(*)/SFF =97 RTR=97

    Since cache is actually directing (steering= packets) it becomes a SFF. If you adapt the reverse picture Cache/SFF will= make sure reverse flows to the same SF3. 

    This is the whole Service Function Groups c= oncept.

    thanks,



    From: Sumandra Majee <S.Majee@F5.com>
    Date: Thursday, February 26, 2015 a= t 2:10 PM
    To: "sfc@ietf.org" <sfc@ietf.= org>
    Subject: [sfc] Support Bidirection/= Symmetric flow

    Hello,

    The SFC architecture document says (correctly) that ingress path and e= gress path of a given flow or work unit could symmetric, asymmetric or hybr= id.  However a front/back (end) classifier is not always the correct p= lace to derive this information.  Some cases are simple,

      IN:      Classifier =97> SF1 =97> SF2 =97&= gt; Cache(*) =97 >SF3 =97 RTR=97
     OUT:   Classifier -> SF3 --> Cache =97=97> RTR

    The actual chains are not laid out like that, but for this discussion = lets stick with the above figure. In this case a device like cache detects = that both direction of flow must flow thru the cache (cache miss). 

    Now lets replace the cache with a modern ADC device. These devices can= and will make the decision for each flow. For optimal operation it is best= to signal the upstream node that flow(X) must come back to this SF or shou= ld bypass this SF.

    How can we do this signaling? Metadata is an option, but it is a gener= ic use case where the format of this metadata then should be standardized.&= nbsp;
    The responsible SF can demand the return PATH to be some 221 that forc= es return traffic thru that SF,   well that may not always be the good= .

    Some sort of label stack?

    Interested to hear from you..

    Regards.

    Sumandra
    --_000_D114E03AB845repennociscocom_-- From nobody Thu Feb 26 14:45: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 B42621A0AF8 for ; Thu, 26 Feb 2015 14:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 r-KHkfVuN_YJ for ; Thu, 26 Feb 2015 14:45:21 -0800 (PST) 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 539251A87E2 for ; Thu, 26 Feb 2015 14:45:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 41F11240E9C; Thu, 26 Feb 2015 14:45:21 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.95.128.180]) (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 DCAF12402EA; Thu, 26 Feb 2015 14:45:20 -0800 (PST) Message-ID: <54EFA1EB.3000306@joelhalpern.com> Date: Thu, 26 Feb 2015 17:44:59 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sumandra Majee , "sfc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Support Bidirection/Symmetric flow 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, 26 Feb 2015 22:45:22 -0000 I would recommend that this sort of signalling be done with control protocols between the SF and the control aspects of service chaining. I would not try to indicate it in the dat path of the service chain. Yours, Joel On 2/26/15 5:10 PM, Sumandra Majee wrote: > Hello, > > The SFC architecture document says (correctly) that ingress path and > egress path of a given flow or work unit could symmetric, asymmetric or > hybrid. However a front/back (end) classifier is not always the correct > place to derive this information. Some cases are simple, > > IN: Classifier —> SF1 —> SF2 —> Cache(*) — >SF3 — RTR— > OUT: Classifier -> SF3 --> Cache ——> RTR > > The actual chains are not laid out like that, but for this discussion > lets stick with the above figure. In this case a device like cache > detects that both direction of flow must flow thru the cache (cache miss). > > Now lets replace the cache with a modern ADC device. These devices can > and will make the decision for each flow. For optimal operation it is > best to signal the upstream node that flow(X) must come back to this SF > or should bypass this SF. > > How can we do this signaling? Metadata is an option, but it is a generic > use case where the format of this metadata then should be standardized. > The responsible SF can demand the return PATH to be some 221 that forces > return traffic thru that SF, well that may not always be the good. > > Some sort of label stack? > > Interested to hear from you.. > > Regards. > > Sumandra > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Feb 26 15:05: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 838F81A890E for ; Thu, 26 Feb 2015 15:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 WSlYI94If33r for ; Thu, 26 Feb 2015 15:05:34 -0800 (PST) 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 CE4011A890A for ; Thu, 26 Feb 2015 15:05:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 93265240840; Thu, 26 Feb 2015 15:05:34 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.95.128.180]) (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 BD9AE2402EA; Thu, 26 Feb 2015 15:05:33 -0800 (PST) Message-ID: <54EFA6A7.1000403@joelhalpern.com> Date: Thu, 26 Feb 2015 18:05:11 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Linda Dunbar , Joel Halpern , Ron Parker , "Carlos Pignataro (cpignata)" , "sfc@ietf.org" References: <4A95BA014132FF49AE685FAB4B9F17F645EE226D@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F522@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE22B4@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB0760334F5DE@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE3CC3@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB07603350E22@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE3E72@dfweml701-chm> <6BCE198E4EAEFC4CAB45D75826EFB07603350EAA@eusaamb101.ericsson.se> <4A95BA014132FF49AE685FAB4B9F17F645EE3EF4@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645EE3EF4@dfweml701-chm> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Service Functions used in a chain is anything but "Abstract" (was RE: wording Suggestion for the Rendered Service Path (RSP) in draft-ietf-sfc-architecture-05 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, 26 Feb 2015 23:05:37 -0000 Assuming we end up with useful definitions of service functions, they can be abstract. AFor now, it may be that things have to be described in terms of specific ids, such as OpenStack may use for deployment of individual functions. But architecturally that is very limiting. Since the SFC working group is not defining the protocols for that aspect of the system, we should talk in terms of abstract services, even if the current implementable control may need to be more specific. Yours, Joel On 2/26/15 5:15 PM, Linda Dunbar wrote: > Joel, > > Thank you for the understanding. > > Through our 9-vendor joined Service Graph Forwarding Proof of Concept > project for NFV-ONF, we learned that same service function by different > vendors can be very different. E.g. FW by Vendor A can be very different > from FW by Vendor B. > > So the ordered set of “Service Functions” has to be specific to which > vendor’s service functions. > > For example, one service function chain could be “ > ŕ ”; another service function chain could be > “ ŕ”. > > Bottom line, we don’t have “abstract service functions”. I don’t > understand why SFC definition has to say “order set of abstract service > functions”. I suggest removing the word “abstract” from the SFC > definition. > > Cheers, > > Linda > > *From:*Joel Halpern [mailto:joel.halpern@ericsson.com] > *Sent:* Thursday, February 26, 2015 3:36 PM > *To:* Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); sfc@ietf.org > *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in > draft-ietf-sfc-architecture-05 > > Sorry. I now understand your question. > > As a mathematician, I would probably be happy if the definition simply > said “a partially ordered set of abstract service functions that must be > applied …” > > However, I think most people would find that less than enlightening. > > Yours, > > Joel > > *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com] > *Sent:* Thursday, February 26, 2015 4:32 PM > *To:* Joel Halpern; Ron Parker; Carlos Pignataro (cpignata); > sfc@ietf.org > *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in > draft-ietf-sfc-architecture-05 > > Joel, > > *Agree with what you said:* > > “…, it is quite possible to have tighter ordering constraints on an SFP > than on an SFC.” > > [Linda] Do you really need the extra wording ““..and ordering > constraints” for the SFC definition? > > Is it sufficient to say “A service function chain defines an ordered set > of abstract service functions (SFs) that must be applied to packets > and/or frames and/or flows”? > > Linda > > *From:*Joel Halpern [mailto:joel.halpern@ericsson.com] > > *Sent:* Thursday, February 26, 2015 3:23 PM > *To:* Linda Dunbar; Ron Parker; Carlos Pignataro (cpignata); > sfc@ietf.org > *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in > draft-ietf-sfc-architecture-05 > > While Ron’s wording was roughly right, it did not seem to add anything > to what we had, and was not written as a definition, but as a > description. As such, the question is whether it adds anything to the > descriptive text further in the document. > > Also, it is quite possible to have tighter ordering constraints on an > SFP than on an SFC. How tight the ordering constraints are in the SFC > probably depends upon the SFC definer and tools. > > Yours, > > Joel > > *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com] > *Sent:* Thursday, February 26, 2015 1:34 PM > *To:* Ron Parker; Joel Halpern; Carlos Pignataro (cpignata); > sfc@ietf.org > *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in > draft-ietf-sfc-architecture-05 > > I think Ron’s suggested wording for SFC is much more straight forward > than the current SFC definition on the sfc-architecture-05. > > draft-ietf-sfc-architecture-05 has: > > Service Function Chain (SFC): A service function chain defines an > > ordered set of abstract service functions (SFs) and ordering > > constraints that must be applied to packets and/or frames and/or > > flows selected as a result of classification. An example of an > > abstract service function is "a firewall". The implied order > > may not be a linear progression as the architecture allows for > > SFCs that copy to more than one branch, and also allows for > > cases where there is flexibility in the order in which service > > functions need to be applied. The term service chain is often > > used as shorthand for service function chain. > > Isn’t the wording of “an ordered set of abstract service functions > (SFs) that must be applied to packets and/or frames and/or flows” > already sufficient enough to describe the ordering constraints? > > Why need the extra wording of “..and ordering constraints”? > > “...selected as a result of classification” should be more like “.. > selected based on a specific matching criteria”. > > I suggest using the following wording: > > “A service function chain defines an ordered set of abstract service > functions (SFs) > > that must be applied to packets and/or frames and/or flows that meet the > specific matching criteria.” > > It is implementation specific to have a classification node inspecting > packets and attaching different SFC-IDs based on the “Service Chain > matching Criteria” in the header to make it easier for subsequent nodes. > > Linda > > *From:*Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > *Sent:* Wednesday, February 25, 2015 12:02 PM > *To:* Joel Halpern; Linda Dunbar; Carlos Pignataro (cpignata); > sfc@ietf.org > *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in > draft-ietf-sfc-architecture-05 > > I think the key concept here is that of a 3 level hierarchy of SFC, SFP, > RSP. I don’t think that comes out clearly in the current description, > especially when RSP references Service Function Chain rather than > Service Function Path. The way I think of it: > > ·SFC – specify the sequence of service function types that need to be > visited > > ·SFP – specify the sequence of service function types that need to be > visited, but also optionally specify instance selection constraining > policies for some or all of the types > > ·RSP – specify the exact sequence of service function instances that > need to be visited (with the understanding that an instance may > optionally perform its own internal load balancing) > > Thanks. > > Ron > > *From:* sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Joel Halpern > *Sent:* Wednesday, February 25, 2015 12:11 PM > *To:* Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org > > *Subject:* [GRAYMAIL] Re: [sfc] wording Suggestion for the Rendered > Service Path (RSP) in draft-ietf-sfc-architecture-05 > > Sorry. A packet is technically using a service function path. It is > doing so if the information in the SFC defined header indicates that the > packet is to forwarded along that service function path. Thus, the > assignment / usage can be determined from examining the packet. The RSP > itself requires a rather omniscient observer perspective to determine, > but does exist conceptually. > > Yours, > > Joel > > *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com] > *Sent:* Wednesday, February 25, 2015 12:08 PM > *To:* Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org > > *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in > draft-ietf-sfc-architecture-05 > > Joel, > > What does it mean by saying packets “using” a service chain? > > How does packets “use” a service chain? I am confused. > > Linda > > *From:*Joel Halpern [mailto:joel.halpern@ericsson.com] > > *Sent:* Wednesday, February 25, 2015 10:59 AM > *To:* Linda Dunbar; Carlos Pignataro (cpignata); sfc@ietf.org > > *Subject:* RE: wording Suggestion for the Rendered Service Path (RSP) in > draft-ietf-sfc-architecture-05 > > I don’t think adding another word to the term will help comprehension, > and it will complicate usage. So I would prefer not to do that. > > As for the other change, packets don’t belong to a service chain. They > may be using a service chain. They may be assigned by a classifier to a > service chain, but they don’t “belong” to the chain as I understand the > words. > > Yours, > > Joel > > *From:*Linda Dunbar [mailto:linda.dunbar@huawei.com] > *Sent:* Wednesday, February 25, 2015 11:52 AM > *To:* Joel Halpern; Carlos Pignataro (cpignata); sfc@ietf.org > > *Subject:* wording Suggestion for the Rendered Service Path (RSP) in > draft-ietf-sfc-architecture-05 > > Joel and Carlos, > > The current definition of RSP is: > > Rendered Service Path (RSP): The Service Function Path is a > > constrained specification of where packets using a certain > > service chain must go. While it may be so constrained as to > > identify the exact locations, it can also be less specific. > > Packets themselves are of course transmitted from and to > > specific places in the network, visiting a specific sequence of > > SFFs and SFs. This sequence of actual visits by a packet to > > specific SFFs and SFs in the network is known as the Rendered > > Service Path (RSP). This definition is included here for use by > > later documents, such as when solutions may need to discuss the > > actual sequence of locations the packets visit. > > Some suggestions: > > -I would think it is more accurate to call it “Rendered Service Function > Path (RSFP)”. > > -Why do you say “packets using a certain service chain”? It is more > accurate to say “packets belonging to a certain service function chain”. > > Here is my suggested wording for RSP (or RSFP): > > -The sequence of actual SFFs and SFs in the network traversed by packets > belonging to a specific Service Function Chain is known as the Rendered > Service Function Path (RSFP). > > Cheers, > > Linda Dunbar > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Feb 26 17:12: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 684D41A1B23 for ; Thu, 26 Feb 2015 17:12:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 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] 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 PAECKfo14g31 for ; Thu, 26 Feb 2015 17:12:19 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F511A1AA7 for ; Thu, 26 Feb 2015 17:12:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1424999541; x=1456535541; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=cK1V8qyXyamiRgwjl3QQQKJzdC4/p/oy0xGtgrzKLHI=; b=NlSdeqZrmjfaugAG4iHL1C/UlW46ronXTA+D4MhZxKI4Z6Cw6B8FZJi/ /3keUblEZfWSYF8JbYmEZq0XH92TvqFweRXHooPFmMDhbC+SAKzUGVjJt 73qXiQrOnvZXtWkNCucNQ/nKzU4uI4di37pHLQhWJm9nhhqhYwyyRBdP4 0=; X-IronPort-AV: E=Sophos;i="5.09,656,1418083200"; d="scan'208,217";a="150906721" X-IPAS-Result: A2AzBQAgw+9U/+sKqMBbgj+BbwSzXJQYAoFtAQEBAQEBfIQPAQEBAQMnYgIBCBEBAgEBAQoeBw8jFAMGCAIEARIb3xMBAQEBAQUBAQEBAQEBAQEZihV+hF0XAQKEKQWIT4Fbg0yfB4IlHIFQb4FEfwEBAQ Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 27 Feb 2015 01:12:20 +0000 Received: from SEAEXCHMBX07.olympus.F5Net.com (192.168.15.50) by seaexchmbx02.olympus.F5Net.com (192.168.15.224) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 26 Feb 2015 17:12:18 -0800 Received: from SEAEXCHMBX01.olympus.F5Net.com (192.168.15.223) by SEAEXCHMBX07.olympus.F5Net.com (192.168.15.50) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 26 Feb 2015 17:12:18 -0800 Received: from SEAEXCHMBX01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75]) by seaexchmbx01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75%13]) with mapi id 15.00.1044.021; Thu, 26 Feb 2015 17:12:18 -0800 From: Sumandra Majee To: "Reinaldo Penno (repenno)" , "sfc@ietf.org" Thread-Topic: [sfc] Support Bidirection/Symmetric flow Thread-Index: AQHQUhVCynhM34uHZEOuTJnMEPtUG50Drfox Date: Fri, 27 Feb 2015 01:12:18 +0000 Message-ID: <1424999534752.97011@F5.com> References: , 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 x-originating-ip: [192.168.15.239] Content-Type: multipart/alternative; boundary="_000_142499953475297011F5com_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Support Bidirection/Symmetric flow 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, 27 Feb 2015 01:12:22 -0000 --_000_142499953475297011F5com_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Reinaldo, The cache example is the easy one. As you noted it could be done by groupin= g, a cache must *always* see both side of the traffic. If I replace cache with ADC or other stateful flow aware devices then the a= lways part is not true. Flow1 can be deemed as must be bidirectional and th= en flow2 can be assymetric, which essentially says bypass me. SF1 SF2 ADC | | | IN: Classifier -> SFF1 -> SFF2 -> SFF3 - SFF4-RTR- Building symmetric and/or hybrid path in dynamic ways is a great tool and I= am hoping this is one area where NSH can help immensely. Because these are run time decision an inband signalling is the reliable wa= y. Regards. Sumandra ________________________________ From: Reinaldo Penno (repenno) Sent: Thursday, February 26, 2015 2:40 PM To: Sumandra Majee; sfc@ietf.org Subject: Re: [sfc] Support Bidirection/Symmetric flow It is my impression that if you rewrite the picture like this it might help= working out the solution SF1 SF2 SFF3 | | | IN: Classifier -> SFF1 -> SFF2 -> Cache(*)/SFF - RTR- Since cache is actually directing (steering packets) it becomes a SFF. If y= ou adapt the reverse picture Cache/SFF will make sure reverse flows to the = same SF3. This is the whole Service Function Groups concept. thanks, From: Sumandra Majee > Date: Thursday, February 26, 2015 at 2:10 PM To: "sfc@ietf.org" > Subject: [sfc] Support Bidirection/Symmetric flow Hello, The SFC architecture document says (correctly) that ingress path and egress= path of a given flow or work unit could symmetric, asymmetric or hybrid. = However a front/back (end) classifier is not always the correct place to de= rive this information. Some cases are simple, IN: Classifier -> SF1 -> SF2 -> Cache(*) - >SF3 - RTR- OUT: Classifier -> SF3 --> Cache --> RTR The actual chains are not laid out like that, but for this discussion lets = stick with the above figure. In this case a device like cache detects that = both direction of flow must flow thru the cache (cache miss). Now lets replace the cache with a modern ADC device. These devices can and = will make the decision for each flow. For optimal operation it is best to s= ignal the upstream node that flow(X) must come back to this SF or should by= pass this SF. How can we do this signaling? Metadata is an option, but it is a generic us= e case where the format of this metadata then should be standardized. The responsible SF can demand the return PATH to be some 221 that forces re= turn traffic thru that SF, well that may not always be the good. Some sort of label stack? Interested to hear from you.. Regards. Sumandra --_000_142499953475297011F5com_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Reinaldo,


    The cache example is the easy one. As you noted it could be done by grou= ping, a cache must *always* see both side of the traffic.


    If I replace cache with ADC or other stateful flow aware devices then th= e always part is not true. Flow1 can be deemed as must be bidirectional and= then flow2 can be assymetric, which essentially says bypass me.
                &= nbsp;          SF1      SF2  &= nbsp;  ADC
                &= nbsp;           |        | &nb= sp;     |
    IN:      Classifier —&= gt; SFF1 —> SFF2 —> SFF3 — SFF4-RTR—

    Building symmetric and/or hybrid path in dynamic ways is a great tool and I= am hoping this is one area where NSH can help immensely.

    Because these are run time decision an inband signalling is the reliable wa= y.

    Regards.

    Sumandra




    From: Reinaldo Penno (repe= nno) <repenno@cisco.com>
    Sent: Thursday, February 26, 2015 2:40 PM
    To: Sumandra Majee; sfc@ietf.org
    Subject: Re: [sfc] Support Bidirection/Symmetric flow
     
    It is my impression that if you rewrite the= picture like this it might help working out the solution

                &= nbsp;          SF1      SF2   =       SFF3
                &= nbsp;           |        | &nb= sp;        |
    IN:      Classifier —&= gt; SFF1 —> SFF2 —> Cache(*)/SFF — RTR—

    Since cache is actually directing (steering= packets) it becomes a SFF. If you adapt the reverse picture Cache/SFF will= make sure reverse flows to the same SF3. 

    This is the whole Service Function Groups c= oncept.

    thanks,



    From: Sumandra Majee <S.Majee@F5.com>
    Date: Thursday, February 26, 2015 a= t 2:10 PM
    To: "sfc@ietf.org" <sfc@ietf.= org>
    Subject: [sfc] Support Bidirection/= Symmetric flow

    Hello,

    The SFC architecture document says (correctly) that ingress path and e= gress path of a given flow or work unit could symmetric, asymmetric or hybr= id.  However a front/back (end) classifier is not always the correct p= lace to derive this information.  Some cases are simple,

      IN:      Classifier —> SF1 —> = SF2 —> Cache(*) — >SF3 — RTR—
     OUT:   Classifier -> SF3 --> Cache ——>= RTR

    The actual chains are not laid out like that, but for this discussion = lets stick with the above figure. In this case a device like cache detects = that both direction of flow must flow thru the cache (cache miss). 

    Now lets replace the cache with a modern ADC device. These devices can= and will make the decision for each flow. For optimal operation it is best= to signal the upstream node that flow(X) must come back to this SF or shou= ld bypass this SF.

    How can we do this signaling? Metadata is an option, but it is a gener= ic use case where the format of this metadata then should be standardized.&= nbsp;
    The responsible SF can demand the return PATH to be some 221 that forc= es return traffic thru that SF,   well that may not always be the good= .

    Some sort of label stack?

    Interested to hear from you..

    Regards.

    Sumandra
    --_000_142499953475297011F5com_-- From nobody Thu Feb 26 17:22:39 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA551A0039 for ; Thu, 26 Feb 2015 17:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 aUldtEdIYTht for ; Thu, 26 Feb 2015 17:22:37 -0800 (PST) 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 1D7421A19EF for ; Thu, 26 Feb 2015 17:22:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 74A6A240CFC; Thu, 26 Feb 2015 17:22:36 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.95.128.180]) (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 CA2AB24023A; Thu, 26 Feb 2015 17:22:35 -0800 (PST) Message-ID: <54EFC6C5.5030805@joelhalpern.com> Date: Thu, 26 Feb 2015 20:22:13 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sumandra Majee , "Reinaldo Penno (repenno)" , "sfc@ietf.org" References: , <1424999534752.97011@F5.com> In-Reply-To: <1424999534752.97011@F5.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Support Bidirection/Symmetric flow 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, 27 Feb 2015 01:22:39 -0000 I am a little confused by your statement that these are "run time decisions" with an apparent implication that they are decisions made by the forwarding infrastructure. Such an approach is permitted, but not req uired, by the architecture and the protocol proposal. So the question of what mechanisms are needed to enable symmetry when required depends upon both what we need. For example, even the use cases you have suggested are ones where the control mechanisms setting up the paths will know whether they need to be symmetric. So they can instantiate suitable state. Now, if an implementation and deployment wants to allow data plane decision, then that implementation needs to come up with a way to meet the symmetry requirements. It has been suggested by some of those who wish to deploy that way that the existing protocol hooks are sufficient for that. Yours, Joel On 2/26/15 8:12 PM, Sumandra Majee wrote: > Reinaldo, > > > The cache example is the easy one. As you noted it could be done by > grouping, a cache must *always* see both side of the traffic. > > > If I replace cache with ADC or other stateful flow aware devices then > the always part is not true. Flow1 can be deemed as must be > bidirectional and then flow2 can be assymetric, which essentially says > bypass me. > > > SF1 SF2 ADC > | | | > IN: Classifier —> SFF1 —> SFF2 —> SFF3 — SFF4-RTR— > > Building symmetric and/or hybrid path in dynamic ways is a great tool > and I am hoping this is one area where NSH can help immensely. > > Because these are run time decision an inband signalling is the reliable > way. > > Regards. > > Sumandra > > > > > ------------------------------------------------------------------------ > *From:* Reinaldo Penno (repenno) > *Sent:* Thursday, February 26, 2015 2:40 PM > *To:* Sumandra Majee; sfc@ietf.org > *Subject:* Re: [sfc] Support Bidirection/Symmetric flow > It is my impression that if you rewrite the picture like this it might > help working out the solution > > SF1 SF2 SFF3 > | | | > IN: Classifier —> SFF1 —> SFF2 —> Cache(*)/SFF — RTR— > > Since cache is actually directing (steering packets) it becomes a SFF. > If you adapt the reverse picture Cache/SFF will make sure reverse flows > to the same SF3. > > This is the whole Service Function Groups concept. > > thanks, > > > > From: Sumandra Majee > > Date: Thursday, February 26, 2015 at 2:10 PM > To: "sfc@ietf.org " > > Subject: [sfc] Support Bidirection/Symmetric flow > > Hello, > > The SFC architecture document says (correctly) that ingress path and > egress path of a given flow or work unit could symmetric, asymmetric or > hybrid. However a front/back (end) classifier is not always the correct > place to derive this information. Some cases are simple, > > IN: Classifier —> SF1 —> SF2 —> Cache(*) — >SF3 — RTR— > OUT: Classifier -> SF3 --> Cache ——> RTR > > The actual chains are not laid out like that, but for this discussion > lets stick with the above figure. In this case a device like cache > detects that both direction of flow must flow thru the cache (cache miss). > > Now lets replace the cache with a modern ADC device. These devices can > and will make the decision for each flow. For optimal operation it is > best to signal the upstream node that flow(X) must come back to this SF > or should bypass this SF. > > How can we do this signaling? Metadata is an option, but it is a generic > use case where the format of this metadata then should be standardized. > The responsible SF can demand the return PATH to be some 221 that forces > return traffic thru that SF, well that may not always be the good. > > Some sort of label stack? > > Interested to hear from you.. > > Regards. > > Sumandra > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Thu Feb 26 17:37: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 A5BC01A1B27 for ; Thu, 26 Feb 2015 17:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 oH9_90SNbhy8 for ; Thu, 26 Feb 2015 17:37:02 -0800 (PST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by ietfa.amsl.com (Postfix) with ESMTP id 55C021A1A22 for ; Thu, 26 Feb 2015 17:37:02 -0800 (PST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 26 Feb 2015 17:28:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,656,1418112000"; d="scan'208,217";a="460105798" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by FMSMGA003.fm.intel.com with ESMTP; 26 Feb 2015 17:21:25 -0800 Received: from orsmsx158.amr.corp.intel.com (10.22.240.20) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 26 Feb 2015 17:37:01 -0800 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.194]) by ORSMSX158.amr.corp.intel.com ([169.254.10.145]) with mapi id 14.03.0195.001; Thu, 26 Feb 2015 17:37:00 -0800 From: "Elzur, Uri" To: Wassim Haddad , "Jim Guichard (jguichar)" Thread-Topic: [sfc] WG call for adoption of draft-quinn-sfc-nsh Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50D8e8A///E9hA= Date: Fri, 27 Feb 2015 01:37:00 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B89958581B932D4@ORSMSX114.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.138] Content-Type: multipart/alternative; boundary="_000_7E05C330D7FD6D4FAD0728C46B89958581B932D4ORSMSX114amrcor_" MIME-Version: 1.0 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 27 Feb 2015 01:37:04 -0000 --_000_7E05C330D7FD6D4FAD0728C46B89958581B932D4ORSMSX114amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Thx Uri ("Oo-Ree") C: 949-378-7568 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Wassim Haddad Sent: Thursday, February 26, 2015 1:04 PM To: Jim Guichard (jguichar) Cc: Wassim Haddad; sfc@ietf.org Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh Support Regards, Wassim H. On Feb 26, 2015, at 4:47 AM, Jim Guichard (jguichar) > wrote: Greetings WG: The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft= -quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc= -sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined = the NSH document so that the WG can focus on a single encapsulation documen= t going forward. This new version of NSH includes an open items section bas= ed on discussion between co-authors and members of the list. The WG will wo= rk through this list (and any other issues that need to be added) over the = next weeks. We appreciate and recognize the hard work of both the NSH and S= CH authors in pushing the SFC encapsulation work forward. With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n= sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3= /12/2015. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Jim & Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_7E05C330D7FD6D4FAD0728C46B89958581B932D4ORSMSX114amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    +1

     <= /p>

    Thx

     <= /p>

    Uri (“Oo-Ree”= )

    C: 949-378-7568

     <= /p>

    From: sfc [m= ailto:sfc-bounces@ietf.org] On Behalf Of Wassim Haddad
    Sent: Thursday, February 26, 2015 1:04 PM
    To: Jim Guichard (jguichar)
    Cc: Wassim Haddad; sfc@ietf.org
    Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh<= /o:p>

     

    Support

     

     

    Regards,

    Wassim H.

     

     

    On Feb 26, 2015, at 4:47 AM, Jim Guichard (jguichar)= <jguichar@cisco.com> wrote= :



    Greetings WG:

     

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft-quinn-sf= c-nsh/) has recently been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sf= c-sch/) have joined the NSH document so that the WG can focus on a sing= le encapsulation document going forward. This new version of NSH includes an open items section based on dis= cussion between co-authors and members of the list. The WG will work throug= h this list (and any other issues that need to be added) over the next week= s. We appreciate and recognize the hard work of both the NSH and SCH authors in pushing the SFC encapsulation= work forward.

     

    With that said, the chairs are calling for WG adoption of draft-quinn-sfc-= nsh-07 as a WG document. The call for adoption will run for 2 weeks ending = 3/12/2015.

     

    Please note tha= t this is a call for adoption, and not a last call for content of the docum= ent. Adopting a WG document simply means that the WG will focus its efforts= on that particular draft going forward, and use that document for resolving open issues and documenting the WGR= 17;s decisions.

     

    Please indicate= whether you support adoption for not, and if not why. Issues you have with= the current document itself can also be raised, but they should be raised = in the context of what should be changed in the document going forward, rather than a pre-condition for adoption.&n= bsp;

     

    Finally, now is= also a good time to poll for knowledge of any IPR that applies to this dra= ft, in line with the IPR disclosure obligations for WG participants (see RF= Cs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please respond to this em= ail (to the chairs) whether or not you are aware of any relevant IPR.

     

    Jim & Thomas

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

     

    --_000_7E05C330D7FD6D4FAD0728C46B89958581B932D4ORSMSX114amrcor_-- From nobody Thu Feb 26 17:52:30 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 B2B6A1A011E for ; Thu, 26 Feb 2015 17:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 TDaJzsIQS1Xr for ; Thu, 26 Feb 2015 17:52:26 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D311A00E5 for ; Thu, 26 Feb 2015 17:52:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,656,1418083200"; d="scan'208";a="151006811" X-IPAS-Result: A2A1BQBgze9U/+sKqMBbg1RaBMFdHQqFcAKBbgEBAQEBAXyEDwEBAQEDAQEBJEcbAgEIEQECAQEBAScHJwsUAwYIAgQBEhuIIdZZAQEBAQYBAQEBAQEBARYEihV+hDs6AoQpBYVslGOOcIM+giUcgVBvgUR/AQEB Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 27 Feb 2015 01:52:26 +0000 Received: from SEAEXCHMBX01.olympus.F5Net.com (192.168.15.223) by seaexchmbx03.olympus.F5Net.com (192.168.15.225) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 26 Feb 2015 17:52:25 -0800 Received: from SEAEXCHMBX01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75]) by seaexchmbx01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75%13]) with mapi id 15.00.1044.021; Thu, 26 Feb 2015 17:52:25 -0800 From: Sumandra Majee To: "Joel M. Halpern" , "Reinaldo Penno (repenno)" , "sfc@ietf.org" Thread-Topic: [sfc] Support Bidirection/Symmetric flow Thread-Index: AQHQUhVCynhM34uHZEOuTJnMEPtUG50DrfoxgACLmID//4JRAA== Date: Fri, 27 Feb 2015 01:52:25 +0000 Message-ID: References: <1424999534752.97011@F5.com> <54EFC6C5.5030805@joelhalpern.com> In-Reply-To: <54EFC6C5.5030805@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7310949C37BF9345A2B04A73AB889FA7@F5.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Support Bidirection/Symmetric flow 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, 27 Feb 2015 01:52:28 -0000 >>I am a little confused by your statement that these are "run time >>decisions" with an apparent implication that they are decisions made by >>the forwarding infrastructure. Such an approach is permitted, but not >>req uired, by the architecture and the protocol proposal. ADC, FW and other types stateful devices has a fair bit of local rules and states. These equipments and rulesets etc. will be there as NSH is introduced in the network. For example the local rule may decide that this particular dst ip doesn=B9t need to be TCP spliced. Since it doesn=B9t do a= ny transformation it might want to bypass on the reverse part of flow. When I say local rule, it could be configuration (static) or generated dynamically from analytics. Both mechanisms are implemented on platforms that I work on. Since it is flow by flow local decision the most reliable way to alter the forwarding path is in band. On 2/26/15, 5:22 PM, "Joel M. Halpern" wrote: >I am a little confused by your statement that these are "run time >decisions" with an apparent implication that they are decisions made by >the forwarding infrastructure. Such an approach is permitted, but not >req uired, by the architecture and the protocol proposal. > >So the question of what mechanisms are needed to enable symmetry when >required depends upon both what we need. For example, even the use >cases you have suggested are ones where the control mechanisms setting >up the paths will know whether they need to be symmetric. So they can >instantiate suitable state. >Now, if an implementation and deployment wants to allow data plane >decision, then that implementation needs to come up with a way to meet >the symmetry requirements. It has been suggested by some of those who >wish to deploy that way that the existing protocol hooks are sufficient >for that. > >Yours, >Joel > >On 2/26/15 8:12 PM, Sumandra Majee wrote: >> Reinaldo, >> >> >> The cache example is the easy one. As you noted it could be done by >> grouping, a cache must *always* see both side of the traffic. >> >> >> If I replace cache with ADC or other stateful flow aware devices then >> the always part is not true. Flow1 can be deemed as must be >> bidirectional and then flow2 can be assymetric, which essentially says >> bypass me. >> >> >> SF1 SF2 ADC >> | | | >> IN: Classifier =8B> SFF1 =8B> SFF2 =8B> SFF3 =8B SFF4-RTR=8B >> >> Building symmetric and/or hybrid path in dynamic ways is a great tool >> and I am hoping this is one area where NSH can help immensely. >> >> Because these are run time decision an inband signalling is the reliable >> way. >> >> Regards. >> >> Sumandra >> >> >> >> >> ------------------------------------------------------------------------ >> *From:* Reinaldo Penno (repenno) >> *Sent:* Thursday, February 26, 2015 2:40 PM >> *To:* Sumandra Majee; sfc@ietf.org >> *Subject:* Re: [sfc] Support Bidirection/Symmetric flow >> It is my impression that if you rewrite the picture like this it might >> help working out the solution >> >> SF1 SF2 SFF3 >> | | | >> IN: Classifier =8B> SFF1 =8B> SFF2 =8B> Cache(*)/SFF =8B RTR=8B >> >> Since cache is actually directing (steering packets) it becomes a SFF. >> If you adapt the reverse picture Cache/SFF will make sure reverse flows >> to the same SF3. >> >> This is the whole Service Function Groups concept. >> >> thanks, >> >> >> >> From: Sumandra Majee > >> Date: Thursday, February 26, 2015 at 2:10 PM >> To: "sfc@ietf.org " > > >> Subject: [sfc] Support Bidirection/Symmetric flow >> >> Hello, >> >> The SFC architecture document says (correctly) that ingress path and >> egress path of a given flow or work unit could symmetric, asymmetric or >> hybrid. However a front/back (end) classifier is not always the correct >> place to derive this information. Some cases are simple, >> >> IN: Classifier =8B> SF1 =8B> SF2 =8B> Cache(*) =8B >SF3 =8B RTR= =8B >> OUT: Classifier -> SF3 --> Cache =8B=8B> RTR >> >> The actual chains are not laid out like that, but for this discussion >> lets stick with the above figure. In this case a device like cache >> detects that both direction of flow must flow thru the cache (cache >>miss). >> >> Now lets replace the cache with a modern ADC device. These devices can >> and will make the decision for each flow. For optimal operation it is >> best to signal the upstream node that flow(X) must come back to this SF >> or should bypass this SF. >> >> How can we do this signaling? Metadata is an option, but it is a generic >> use case where the format of this metadata then should be standardized. >> The responsible SF can demand the return PATH to be some 221 that forces >> return traffic thru that SF, well that may not always be the good. >> >> Some sort of label stack? >> >> Interested to hear from you.. >> >> Regards. >> >> Sumandra >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> From nobody Thu Feb 26 18:06: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 CAC761A1A4B for ; Thu, 26 Feb 2015 18:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 rQ6Fsw_QcT4S for ; Thu, 26 Feb 2015 18:06:37 -0800 (PST) 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 D10FD1A1A07 for ; Thu, 26 Feb 2015 18:06:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id BD79424076D; Thu, 26 Feb 2015 18:06:37 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.95.128.180]) (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 256692402EA; Thu, 26 Feb 2015 18:06:37 -0800 (PST) Message-ID: <54EFD116.2000707@joelhalpern.com> Date: Thu, 26 Feb 2015 21:06:14 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sumandra Majee , "Reinaldo Penno (repenno)" , "sfc@ietf.org" References: <1424999534752.97011@F5.com> <54EFC6C5.5030805@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Support Bidirection/Symmetric flow 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, 27 Feb 2015 02:06:40 -0000 Look at the long-lived flows draft. We talk about exactly that case, and propose an approach to solving it. For local optimization, there is also the bypass draft. Yours, Joel On 2/26/15 8:52 PM, Sumandra Majee wrote: >>> I am a little confused by your statement that these are "run time >>> decisions" with an apparent implication that they are decisions made by >>> the forwarding infrastructure. Such an approach is permitted, but not >>> req uired, by the architecture and the protocol proposal. > > ADC, FW and other types stateful devices has a fair bit of local rules and > states. These equipments and rulesets etc. will be there as NSH is > introduced in the network. For example the local rule may decide that this > particular dst ip doesnąt need to be TCP spliced. Since it doesnąt do any > transformation it might want to bypass on the reverse part of flow. When I > say local rule, it could be configuration (static) or generated > dynamically from analytics. Both mechanisms are implemented on platforms > that I work on. Since it is flow by flow local decision the most reliable > way to alter the forwarding path is in band. > > > > > On 2/26/15, 5:22 PM, "Joel M. Halpern" wrote: > >> I am a little confused by your statement that these are "run time >> decisions" with an apparent implication that they are decisions made by >> the forwarding infrastructure. Such an approach is permitted, but not >> req uired, by the architecture and the protocol proposal. >> >> So the question of what mechanisms are needed to enable symmetry when >> required depends upon both what we need. For example, even the use >> cases you have suggested are ones where the control mechanisms setting >> up the paths will know whether they need to be symmetric. So they can >> instantiate suitable state. >> Now, if an implementation and deployment wants to allow data plane >> decision, then that implementation needs to come up with a way to meet >> the symmetry requirements. It has been suggested by some of those who >> wish to deploy that way that the existing protocol hooks are sufficient >> for that. >> >> Yours, >> Joel >> >> On 2/26/15 8:12 PM, Sumandra Majee wrote: >>> Reinaldo, >>> >>> >>> The cache example is the easy one. As you noted it could be done by >>> grouping, a cache must *always* see both side of the traffic. >>> >>> >>> If I replace cache with ADC or other stateful flow aware devices then >>> the always part is not true. Flow1 can be deemed as must be >>> bidirectional and then flow2 can be assymetric, which essentially says >>> bypass me. >>> >>> >>> SF1 SF2 ADC >>> | | | >>> IN: Classifier ‹> SFF1 ‹> SFF2 ‹> SFF3 ‹ SFF4-RTR‹ >>> >>> Building symmetric and/or hybrid path in dynamic ways is a great tool >>> and I am hoping this is one area where NSH can help immensely. >>> >>> Because these are run time decision an inband signalling is the reliable >>> way. >>> >>> Regards. >>> >>> Sumandra >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Reinaldo Penno (repenno) >>> *Sent:* Thursday, February 26, 2015 2:40 PM >>> *To:* Sumandra Majee; sfc@ietf.org >>> *Subject:* Re: [sfc] Support Bidirection/Symmetric flow >>> It is my impression that if you rewrite the picture like this it might >>> help working out the solution >>> >>> SF1 SF2 SFF3 >>> | | | >>> IN: Classifier ‹> SFF1 ‹> SFF2 ‹> Cache(*)/SFF ‹ RTR‹ >>> >>> Since cache is actually directing (steering packets) it becomes a SFF. >>> If you adapt the reverse picture Cache/SFF will make sure reverse flows >>> to the same SF3. >>> >>> This is the whole Service Function Groups concept. >>> >>> thanks, >>> >>> >>> >>> From: Sumandra Majee > >>> Date: Thursday, February 26, 2015 at 2:10 PM >>> To: "sfc@ietf.org " >> > >>> Subject: [sfc] Support Bidirection/Symmetric flow >>> >>> Hello, >>> >>> The SFC architecture document says (correctly) that ingress path and >>> egress path of a given flow or work unit could symmetric, asymmetric or >>> hybrid. However a front/back (end) classifier is not always the correct >>> place to derive this information. Some cases are simple, >>> >>> IN: Classifier ‹> SF1 ‹> SF2 ‹> Cache(*) ‹ >SF3 ‹ RTR‹ >>> OUT: Classifier -> SF3 --> Cache ‹‹> RTR >>> >>> The actual chains are not laid out like that, but for this discussion >>> lets stick with the above figure. In this case a device like cache >>> detects that both direction of flow must flow thru the cache (cache >>> miss). >>> >>> Now lets replace the cache with a modern ADC device. These devices can >>> and will make the decision for each flow. For optimal operation it is >>> best to signal the upstream node that flow(X) must come back to this SF >>> or should bypass this SF. >>> >>> How can we do this signaling? Metadata is an option, but it is a generic >>> use case where the format of this metadata then should be standardized. >>> The responsible SF can demand the return PATH to be some 221 that forces >>> return traffic thru that SF, well that may not always be the good. >>> >>> Some sort of label stack? >>> >>> Interested to hear from you.. >>> >>> Regards. >>> >>> Sumandra >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> > > From nobody Fri Feb 27 00:07:36 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880A91A9064 for ; Fri, 27 Feb 2015 00:07:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.701 X-Spam-Level: ** X-Spam-Status: No, score=2.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_17=0.6, J_CHICKENPOX_21=0.6, J_CHICKENPOX_31=0.6, J_CHICKENPOX_39=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jDJ8lu29UgZ for ; Fri, 27 Feb 2015 00:07:31 -0800 (PST) Received: from mc32.lon.server.colt.net (mc32.lon.server.colt.net [212.74.77.112]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFC41A9066 for ; Fri, 27 Feb 2015 00:07:26 -0800 (PST) Received: from mc32.lon.server.colt.net (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E1EC534822A for ; Fri, 27 Feb 2015 08:07:24 +0000 (UTC) Received: from mx3.qosmos.com (unknown [195.68.92.43]) by mc32.lon.server.colt.net (Postfix) with ESMTP id BA82F34820A for ; Fri, 27 Feb 2015 08:07:24 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.09,658,1418079600"; d="scan'208,217";a="1558336" Received: from unknown (HELO mailbox.jungle.qosmos.com) ([10.12.1.3]) by mx3.qosmos.com with ESMTP; 27 Feb 2015 09:07:23 +0100 Received: from LILAS.jungle.qosmos.com ([fe80::5524:2c18:b2c3:74d4]) by CAROUBIER.jungle.qosmos.com ([169.254.1.51]) with mapi id 14.01.0438.000; Fri, 27 Feb 2015 09:07:23 +0100 From: Nicolas BOUTHORS To: "Jim Guichard (jguichar)" Thread-Topic: [sfc] WG call for adoption of draft-quinn-sfc-nsh Thread-Index: AQHQUjITiYzHAp/lpka5uhhVzctKUp0EI/ug Date: Fri, 27 Feb 2015 08:07:23 +0000 Message-ID: <76B41B8FACE1514795D30EC137FF391D7D75B6@LILAS.jungle.qosmos.com> References: <7E05C330D7FD6D4FAD0728C46B89958581B932D4@ORSMSX114.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B89958581B932D4@ORSMSX114.amr.corp.intel.com> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.0.22] Content-Type: multipart/alternative; boundary="_000_76B41B8FACE1514795D30EC137FF391D7D75B6LILASjungleqosmos_" MIME-Version: 1.0 X-TM-AS-MML: No X-TM-AS-Product-Ver: IMSVA-8.2.0.1679-7.5.0.1018-21360.005 X-TM-AS-Result: No--16.785-5.0-31-10 X-imss-scan-details: No--16.785-5.0-31-10 X-TM-AS-User-Approved-Sender: No X-TMASE-Version: IMSVA-8.2.0.1679-7.5.1018-21360.005 X-TMASE-Result: 10--16.784900-5.000000 X-TMASE-MatchedRID: kR5ITYfP6C4pwNTiG5IsElrXg0lwq1E09r9tEcSw8jfeAXSz7gr6zh+C hDHqFy+NIooVLaUryu1YNVwHQkZ/pURfCdMIZ+bdJ7VPmvVUDcjAWTziWGaDPBfu/zSku+UHLrv R7aAmJFj1DzpmYbCmAY3R4bLj3CWH61U7IhbBV1IXrP0cYcrA27jqaj+29pPcDO+DX+rUwfbSJ9 lfZ4kLO6rYCqqGWEiszCCJQqTbLYdswyLorcVKWHuzDvI75j0scxdTrzMN2UDJ2i9a4v4pV3Tv7 ZA0xIMkEVtxaPoSt7BtG84TKmZUxovyjdRKrHFazAwlZ8w0UGBbUMPBWMyETi/dJMG52J2yJKip JgRx1kPkWP93Y1C75KfgtzYSuAV4KIB5A7IqyvFoCPffJHlO8HpKrmYbzkHgZ0IzKseMTedHqot PtpMMQA8jebtCGP6Eg96cfVzYJeo25XOhnouJ5RuurbgYp+HQgktEEwPCc6RJ/oIGXyyX8qgFX2 xz5NjH4j4lr4Wn4RisEFKef8ZUxtsoDJz5OAzcY4guKfvwCBYzH3zWWApNw+hdCwCmqxS91qu6w Vw3pg3Rg+9g+UOo0vz4ORscTe1XuHCiSIvAnFuKC6Im4I1RFy2VljVYB9GNw7+XQ3Lk9nmP4+IC g6FamaHFCDR0hHbLKeOueo+W45SNDi1aIK4jegcbMHjYNxGhhZApJAdFDDabKItl61J/yZUdXE/ WGn0FHwAqApZ40aGKIiuM3JGtMd/AJ2Hg69mWpRUfcZzZTBzXpUZhQcarIpXOKChxFZnzfrFMJ2 P2mTg= Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 27 Feb 2015 08:07:34 -0000 --_000_76B41B8FACE1514795D30EC137FF391D7D75B6LILASjungleqosmos_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support Br, Nicolas. On Feb 26, 2015, at 4:47 AM, Jim Guichard (jguichar) > wrote: Greetings WG: The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft= -quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc= -sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined = the NSH document so that the WG can focus on a single encapsulation documen= t going forward. This new version of NSH includes an open items section bas= ed on discussion between co-authors and members of the list. The WG will wo= rk through this list (and any other issues that need to be added) over the = next weeks. We appreciate and recognize the hard work of both the NSH and S= CH authors in pushing the SFC encapsulation work forward. With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n= sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3= /12/2015. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Jim & Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc This message and any attachments (the "message") are confidential, intended= solely for the addressees. If you are not the intended recipient, please n= otify the sender immediately by e-mail and delete this message from your sy= stem. In this case, you are not authorized to use, copy this message and/or= disclose the content to any other person. E-mails are susceptible to alter= ation. Neither Qosmos nor any of its subsidiaries or affiliates shall be li= able for the message if altered, changed or falsified. Ce message et toutes ses pi?ces jointes (ci-apr?s le "message")sont confide= ntiels et ?tablis ? l'intention exclusive de ses destinataires. Si vous ave= z re?u ce message par erreur, merci d'en informer imm?diatement son ?metteu= r par courrier ?lectronique et d'effacer ce message de votre syst?me. Dans = cette hypoth?se, vous n'?tes pas autoris? ? utiliser, copier ce message et/= ou en divulguer le contenu ? un tiers. Tout message ?lectronique est suscep= tible d'alt?ration. Qosmos et ses filiales d?clinent toute responsabilit? a= u titre de ce message s'il a ?t? alt?r?, d?form? ou falsifi?. --_000_76B41B8FACE1514795D30EC137FF391D7D75B6LILASjungleqosmos_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Support

     

    Br,

     

    Nicolas.=

     

    On Feb 26, 2015, at 4:47 AM, Ji= m Guichard (jguichar) <jguichar@ci= sco.com> wrote:

    =  

    Greetings WG:

     

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/do= c/draft-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc= /draft-zhang-sfc-sch/) have joined the NSH document so that the WG can = focus on a single encapsulation document going forward. This new version of NSH includes an open items secti= on based on discussion between co-authors and members of the list. The WG w= ill work through this list (and any other issues that need to be added) ove= r the next weeks. We appreciate and recognize the hard work of both the NSH and SCH authors in pushing the= SFC encapsulation work forward.

     

    With that said, the chairs are calling for WG adoption of = draft-quinn-sfc-nsh-07 as a WG document. The call for adoption will run for= 2 weeks ending 3/12/2015.

     

    = Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that document for resolving open issues and documen= ting the WG’s decisions.

     

    = Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document going forward, rather than a pre-conditi= on for adoption. 

     

    = Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please resp= ond to this email (to the chairs) whether or not you are aware of any relev= ant IPR.

    =  

    Jim & Thomas

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

     

    This message and any attachments (the "message") are confidential= , intended solely for the addressees. If you are not the intended recipient= , please notify the sender immediately by e-mail and delete this message fr= om your system. In this case, you are not authorized to use, copy this message and/or disclose the content to any ot= her person. E-mails are susceptible to alteration. Neither Qosmos nor any o= f its subsidiaries or affiliates shall be liable for the message if altered= , changed or falsified.

    Ce message et toutes ses pièces jointes (ci-après le "me= ssage")sont confidentiels et établis à l'intention exclu= sive de ses destinataires. Si vous avez reçu ce message par erreur, = merci d’en informer immédiatement son émetteur par cour= rier électronique et d’effacer ce message de votre système. Dans cette hypothèse, vous n= 217;êtes pas autorisé à utiliser, copier ce message et/= ou en divulguer le contenu à un tiers. Tout message électroni= que est susceptible d'altération. Qosmos et ses filiales décl= inent toute responsabilité au titre de ce message s'il a été altéré, d&ea= cute;formé ou falsifié.

    --_000_76B41B8FACE1514795D30EC137FF391D7D75B6LILASjungleqosmos_-- From nobody Fri Feb 27 01: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 5F4DA1A1BAC for ; Fri, 27 Feb 2015 01:54:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIE66_RSinGR for ; Fri, 27 Feb 2015 01:54:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A491A1B8E for ; Fri, 27 Feb 2015 01:54:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPR59385; Fri, 27 Feb 2015 09:54:42 +0000 (GMT) Received: from LHREML502-MBS.china.huawei.com ([10.125.30.101]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.03.0158.001; Fri, 27 Feb 2015 09:54:41 +0000 From: Georgios Karagiannis To: Wassim Haddad , "Jim Guichard (jguichar)" Thread-Topic: [sfc] WG call for adoption of draft-quinn-sfc-nsh Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50Da9MAgADXUVA= Date: Fri, 27 Feb 2015 09:54:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.64.14] Content-Type: multipart/alternative; boundary="_000_C5034E44CD620A44971BAAEB372655DC014DE600lhreml502mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 27 Feb 2015 09:54:50 -0000 --_000_C5034E44CD620A44971BAAEB372655DC014DE600lhreml502mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mee too, Support! Regards, Georgios From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Wassim Haddad Sent: Thursday, February 26, 2015 10:04 PM To: Jim Guichard (jguichar) Cc: Wassim Haddad; sfc@ietf.org Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh Support Regards, Wassim H. On Feb 26, 2015, at 4:47 AM, Jim Guichard (jguichar) > wrote: Greetings WG: The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft= -quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc= -sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined = the NSH document so that the WG can focus on a single encapsulation documen= t going forward. This new version of NSH includes an open items section bas= ed on discussion between co-authors and members of the list. The WG will wo= rk through this list (and any other issues that need to be added) over the = next weeks. We appreciate and recognize the hard work of both the NSH and S= CH authors in pushing the SFC encapsulation work forward. With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n= sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3= /12/2015. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Jim & Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_C5034E44CD620A44971BAAEB372655DC014DE600lhreml502mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Mee too,

    Support!

     <= /p>

    Regards,

    Georgios

     <= /p>

    From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Wassim Haddad
    Sent: Thursday, February 26, 2015 10:04 PM
    To: Jim Guichard (jguichar)
    Cc: Wassim Haddad; sfc@ietf.org
    Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh<= /o:p>

     

    Support

     

     

    Regards,

    Wassim H.

     

     

    On Feb 26, 2015, at 4:47 AM, Jim Guichard (jguichar)= <jguichar@cisco.com> wrote= :



    Greetings WG:

     

    The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft-quinn-sf= c-nsh/) has recently been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sf= c-sch/) have joined the NSH document so that the WG can focus on a sing= le encapsulation document going forward. This new version of NSH includes an open items section based on dis= cussion between co-authors and members of the list. The WG will work throug= h this list (and any other issues that need to be added) over the next week= s. We appreciate and recognize the hard work of both the NSH and SCH authors in pushing the SFC encapsulation= work forward.

     

    With that said, the chairs are calling for WG adoption of draft-quinn-sfc-= nsh-07 as a WG document. The call for adoption will run for 2 weeks ending = 3/12/2015.

     

    Please note tha= t this is a call for adoption, and not a last call for content of the docum= ent. Adopting a WG document simply means that the WG will focus its efforts= on that particular draft going forward, and use that document for resolving open issues and documenting the WGR= 17;s decisions.

     

    Please indicate= whether you support adoption for not, and if not why. Issues you have with= the current document itself can also be raised, but they should be raised = in the context of what should be changed in the document going forward, rather than a pre-condition for adoption.&n= bsp;

     

    Finally, now is= also a good time to poll for knowledge of any IPR that applies to this dra= ft, in line with the IPR disclosure obligations for WG participants (see RF= Cs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author please respond to this em= ail (to the chairs) whether or not you are aware of any relevant IPR.

     

    Jim & Thomas

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

     

    --_000_C5034E44CD620A44971BAAEB372655DC014DE600lhreml502mbschi_-- From nobody Fri Feb 27 03:57: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 54F591A92B8 for ; Fri, 27 Feb 2015 03:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BupjSB2jfnC9 for ; Fri, 27 Feb 2015 03:57:02 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2801A92B6 for ; Fri, 27 Feb 2015 03:57:02 -0800 (PST) Received: from vc2.ecl.ntt.co.jp (vc2.ecl.ntt.co.jp [129.60.86.154]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t1RBuxbA027084; Fri, 27 Feb 2015 20:56:59 +0900 Received: from vc2.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 44AA75F611; Fri, 27 Feb 2015 20:56:59 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by vc2.ecl.ntt.co.jp (Postfix) with ESMTP id 319E85F594; Fri, 27 Feb 2015 20:56:59 +0900 (JST) Received: from [IPv6:::1] ([129.60.13.28]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t1RBuqBE029038; Fri, 27 Feb 2015 20:56:58 +0900 Message-ID: <54F05BCC.9050503@lab.ntt.co.jp> Date: Fri, 27 Feb 2015 20:58:04 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit To: "Jim Guichard (jguichar)" , "sfc@ietf.org" X-TM-AS-MML: disable Archived-At: Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 27 Feb 2015 11:57:04 -0000 Support! Shunsuke On 2015/02/26 21:47, Jim Guichard (jguichar) wrote: > Greetings WG: > > The document draft-quinn-sfc-nsh-07 > (https://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/) has recently > been reissued. The authors of draft-zhang-sfc-sch-03 > (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined the > NSH document so that the WG can focus on a single encapsulation document > going forward. This new version of NSH includes an *open items *section > based on discussion between co-authors and members of the list. The WG > will work through this list (and any other issues that need to be added) > over the next weeks. We appreciate and recognize the hard work of both > the NSH and SCH authors in pushing the SFC encapsulation work forward. > > With that said, the chairs are calling for WG adoption of > draft-quinn-sfc-nsh-07 as a WG document. The call for adoption will run > for 2 weeks ending 3/12/2015. > > Please note that this is a call for adoption, and not a last call for > content of the document. Adopting a WG document simply means that the WG > will focus its efforts on that particular draft going forward, and use > that document for resolving open issues and documenting the WG’s decisions. > > Please indicate whether you support adoption for not, and if not why. > Issues you have with the current document itself can also be raised, but > they should be raised in the context of what should be changed in the > document going forward, rather than a pre-condition for adoption. > > Finally, now is also a good time to poll for knowledge of any IPR that > applies to this draft, in line with the IPR disclosure obligations for > WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). > If you are listed as a document author please respond to this email (to > the chairs) whether or not you are aware of any relevant IPR. > > Jim & Thomas > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service System Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Fri Feb 27 06:00:28 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 C638A1A87E2 for ; Fri, 27 Feb 2015 06:00:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 tMOvnHtIZ960 for ; Fri, 27 Feb 2015 06:00:24 -0800 (PST) Received: from mxe02.gs.com (mxe02.gs.com [199.99.47.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52FBD1A00E7 for ; Fri, 27 Feb 2015 06:00:24 -0800 (PST) Received: from pps.filterd (gsppabdp02sd.idz.gs.com [127.0.0.1]) by gsppabdp02sd.idz.gs.com (8.14.5/8.14.5) with SMTP id t1RDxk04016441; Fri, 27 Feb 2015 09:00:20 -0500 Received: from gsppabdp03nd.inz.gs.com ([10.204.43.245]) by gsppabdp02sd.idz.gs.com with ESMTP id 1stsg9gk6t-1; Fri, 27 Feb 2015 09:00:19 -0500 Received: from pps.filterd (gsppabdp03nd.inz.gs.com [127.0.0.1]) by gsppabdp03nd.inz.gs.com (8.14.5/8.14.5) with SMTP id t1RDrBVC012838; Fri, 27 Feb 2015 09:00:20 -0500 Received: from gshccdp11ex.firmwide.corp.gs.com (gshccdp11ex.firmwide.corp.gs.com [10.135.172.89]) by gsppabdp03nd.inz.gs.com with ESMTP id 1stp1q2f75-1; Fri, 27 Feb 2015 09:00:20 -0500 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshccdp11ex.firmwide.corp.gs.com ([10.135.172.89]) with mapi; Fri, 27 Feb 2015 09:00:21 -0500 From: "Zarny, Myo" To: "'Jim Guichard (jguichar)'" , "'sfc@ietf.org'" Date: Fri, 27 Feb 2015 09:00:19 -0500 Thread-Topic: WG call for adoption of draft-quinn-sfc-nsh Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50Eh6sQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C23071C76FC33GSCMAMP19EXfi_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-02-27_05:2015-02-27,2015-02-27,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-02-27_05:2015-02-27,2015-02-27,1970-01-01 signatures=0 Archived-At: Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 27 Feb 2015 14:00:27 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C23071C76FC33GSCMAMP19EXfi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support as a coauthor Myo From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: 26 February 2015 7:47 AM To: sfc@ietf.org Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh Greetings WG: The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft= -quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc= -sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined = the NSH document so that the WG can focus on a single encapsulation documen= t going forward. This new version of NSH includes an open items section bas= ed on discussion between co-authors and members of the list. The WG will wo= rk through this list (and any other issues that need to be added) over the = next weeks. We appreciate and recognize the hard work of both the NSH and S= CH authors in pushing the SFC encapsulation work forward. With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n= sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3= /12/2015. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Jim & Thomas --_000_A3233753A4B65F43BCA1B64DA99A9C23071C76FC33GSCMAMP19EXfi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Support a= s a coauthor

     

    Myo

     

    From: sfc [mailto:sfc-bounces@ietf.org] <= b>On Behalf Of Jim Guichard (jguichar)
    Sent: 26 February 2015= 7:47 AM
    To: sfc@ietf.org
    Subject: [sfc] WG call for ad= option of draft-quinn-sfc-nsh

     

    Greetings WG:

     

    The document draft-quinn-sfc-nsh-07 = (https://d= atatracker.ietf.org/doc/draft-quinn-sfc-nsh/) has recently been reissue= d. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-= sfc-sch/) have joined the NSH document so that the WG can focus on a si= ngle encapsulation document going forward. This new version of NSH includes= an open items section based on discussion between co-authors and me= mbers of the list. The WG will work through this list (and any other issues= that need to be added) over the next weeks. We appreciate and recognize th= e hard work of both the NSH and SCH authors in pushing the SFC encapsulatio= n work forward.

     

    With that said, the chairs are calling for WG adoption of draft= -quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 we= eks ending 3/12/2015.<= /p>

     

    Please note that this is a call for adoption, and not a last call fo= r content of the document. Adopting a WG document simply means that the WG = will focus its efforts on that particular draft going forward, and use that= document for resolving open issues and documenting the WG’s decision= s.

     

    Please in= dicate whether you support adoption for not, and if not why. Issues you hav= e with the current document itself can also be raised, but they should be r= aised in the context of what should be changed in the document going forwar= d, rather than a pre-condition for adoption. 

     

    Finally, now is also a good time to = poll for knowledge of any IPR that applies to this draft, in line with the = IPR disclosure obligations for WG participants (see RFCs 3979, 4879, 3669 a= nd 5378 for more details). If you are listed as a document author please re= spond to this email (to the chairs) whether or not you are aware of any rel= evant IPR.

     

    Jim & Thomas

    = --_000_A3233753A4B65F43BCA1B64DA99A9C23071C76FC33GSCMAMP19EXfi_-- From nobody Fri Feb 27 09:08:58 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 3D9C11ACE88 for ; Fri, 27 Feb 2015 09:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CME6FivavJgL for ; Fri, 27 Feb 2015 09:08:54 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 701711ACE84 for ; Fri, 27 Feb 2015 09:08:52 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Fri, 27 Feb 2015 12:08:52 -0500 From: Dave Dolson To: "Surendra Kumar (smkumar)" , "Joel M. Halpern" , "Reinaldo Penno (repenno)" , "Ron Parker" , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals Thread-Index: AdBRyhUadMfMQp0TQVyP+AHUYniSlAAMhaQAAABleoAAAFj2AAAJAG9w///QlQCAAFBcIP//vPuAgABSEAD//7LOAIAANtYAgABHJZA= Date: Fri, 27 Feb 2015 17:08:50 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3584.2080005@joelhalpern.com> <54EF596C.1080608@joelhalpern.com> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals 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, 27 Feb 2015 17:08:57 -0000 No chain can be deployed without writing to the forwarding table of each SF= in the chain. In other words, an SF must have a table entry for each occurrence in a chai= n, keyed by (SPI, SI) pair. Given that, I think it would be quite useful to add an extra column to the = forwarding table defined in section 9.1: +-------------------+----------+ | SPI | SI | NH | Role | +-------------------+----------+ | 10 | 3 | SF2 | "Foo" | | 245 | 12 | SF34 | "ingress"| | 40 | 9 | SF9 | "egress" | +-------------------+----------+ Call the new column "Role" or "Function". It is an indirection to anything = the SF vendor wishes to permit. In many cases it would be a configuration s= et. I think this gives a mechanism for the spiral use cases. This new column doesn't have any (direct) impact on what appears on the wir= e, so I can see it might not belong in draft-quinn-sfc-nsh, rather in the c= onfiguration model. Speaking of which, I can't find the above SPI/SI/NH table in draft-penno-sf= c-yang. Are these drafts yet to be reconciled? -----Original Message----- From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]=20 Sent: Thursday, February 26, 2015 3:52 PM To: Joel M. Halpern; Dave Dolson; Reinaldo Penno (repenno); Ron Parker; moh= amed.boucadair@orange.com; sfc@ietf.org Cc: Ben Wright (Ben.Wright@metaswitch.com) Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals I would agree with that. An SF trying to figure out what SFCs it is part of and at what location it is present in each of those SFCs, thus adds severe constraints to how such an SF can be deployed. An SF limiting itself to service function delivery alone, aided by the metadata, not only keeps the SF simple, allows for very flexible deployments as well. Surendra. On 2/26/15, 9:35 AM, "Joel M. Halpern" wrote: >Personally, I would prefer that the firewall use metadata rather than >path-index. My reasoning is that if functions get added before or after >the firewall, operations would prefer not to have to change the >configuration of the firewall SF itself. > >Having said that, I don't see any way to stop you from using the path >index. > >Yours, >Joel > >On 2/26/15 12:30 PM, Dave Dolson wrote: >> For the sake of argument, suppose I have a firewall SF, and I want to >>use >> it more than once in a chain. (Maybe I want to book-end the chain with >>ingress >> and egress rules.) >> >> Do you agree it would be sufficient to use the Path Index to select >>which of >> the ingress or egress rule sets should be used? >> >> I'm probably missing something; I don't understand how the context >>headers >> define functionality. Maybe the device could communicate with itself >> (e.g., the ingress portion sending a tag to the egress portion) >> by sending state in the packet. Is that what you are mean by >>"contextual info" ? >> >> >> >> -----Original Message----- >> From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] >> Sent: Thursday, February 26, 2015 12:18 PM >> To: Dave Dolson; Ron Parker; Joel M. Halpern; >>mohamed.boucadair@orange.com; sfc@ietf.org >> Cc: Ben Wright (Ben.Wright@metaswitch.com) >> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >> >> Agreed on all points. I thought I was missing something so before >>writing >> this email I retested our implementation and it worked off the bat. The >> RSP constructed has the the same (SFF, SF) tuple but different indexes. >> >> The same SF is visited multiple times until the path ends. If the SF >> wants contextual info across visits than context headers are the way to >> go. >> >> >> On 2/26/15, 8:52 AM, "Dave Dolson" wrote: >> >>> Maybe naively, I thought the service functions would be provisioned >>>with >>> a table: >>> >>> E.g., for element foo: >>> Path | Path Index | Next Hop | Function >>> 123 | 4 | SF-bar | first behavior >>> 123 | 2 | SF-foobar | second behavior >>> >>> >>> The Function is clearly implementation specific. Maybe it points to a >>> configuration set or a policy set. I think completely out of scope >>>here. >>> >>> I suggest that this is not a problem for the wire protocol, rather for >>> the configuration model (netconf or whatever). >>> >>> It becomes very much vendor-specific if the behaviors are complex >>> configurations of specialized features. >>> >>> If a person were manually configuring chains, I don't think they'd >>>have a >>> conceptual problem, because they'd have a diagram they need to >>>implement: >>> {SF-foo (first-behavior), SF-bar, SF-foo (second-behavior), SF-foobar} >>> >>> If we wanted to standardize it, we could maybe make the Function >>>simply a >>> label that means something to the device--an indirection to a >>> configuration set. >>> >>> -Dave >>> >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker >>> Sent: Thursday, February 26, 2015 11:31 AM >>> To: Dave Dolson; Joel M. Halpern; mohamed.boucadair@orange.com; >>> sfc@ietf.org >>> Cc: Ben Wright (Ben.Wright@metaswitch.com) >>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >>> >>> Hi, Dave. >>> >>> I agree that on the wire, this is the way it would work. >>> >>> But, when composing the chain, it seems like information would be >>>lacking >>> if a chain were expressed simply as {SF-foo, SF-bar, SF-foo, >>>SF-foobar}. >>> It is completely implicit that since SF-foo appears twice, it perhaps >>> should perform some different duty when index =3D 0 vs when index =3D 2= . >>> >>> At first, I thought that an alternative way to handle this would be to >>> use multiple logical identities for SF-foo. In this case, the chain >>> above would be expressed as {SF-foo-first-behavior, SF-bar, >>> SF-foo-second-behavior, SF-foobar}. But, the problem here is >>>selecting >>> the RSP, assuming that SF-foo has multiple instances. Nothing in this >>> second flavor of chain says that the same instance of SF-foo-* must be >>> selected to satisfy SF-foo-first-behavior and SF-foo-second-behavior >>> (which may not be required, but should be possible to force as such). >>> >>> I guess what I'm saying is that spiraling has a subtlety to it that >>>isn't >>> yet adequately addressed and that I don't have a specific proposal to >>> solve it, either. >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>> Sent: Thursday, February 26, 2015 11:21 AM >>> To: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>> Cc: Ben Wright (Ben.Wright@metaswitch.com) >>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >>> >>> If I may try to put it simply, I've always thought of it this way: >>> --> Each node in the chain selects the context for processing and the >>> next hop on the basis of BOTH path ID and Index, while decrementing the >>> index for the next hop. >>> >>> That behavior supports spiraling. >>> >>> >>> >>> -Dave >>> >>> >>> -----Original Message----- >>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>> Sent: Thursday, February 26, 2015 10:02 AM >>> To: mohamed.boucadair@orange.com; sfc@ietf.org >>> Cc: Ben Wright (Ben.Wright@metaswitch.com) >>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >>> >>> There are two different aspects of Spirals. >>> >>> One of the two aspects is enabling a packet that repeatedly arrives at >>> the same SFF to get the correct services provided each time it arrives, >>> and to go to the correct next SFF each time it arrives. The Service >>>Path >>> Index, used by the SFF to select service functions and next SFF, >>>provides >>> that capability. >>> >>> The other aspect is how the Service Functions themselves handle >>>spirals. >>> To a large degree, that depends upon the individual service function. >>> I normally assume that it would use packet context (as described in >>>the >>> text you quote) to determine what to do. >>> >>> Since I would prefer that service functions are independent of the >>> underlying service function chaining infrastructure, and are not >>> sensitive to how many functions are before or after them in the chain, >>>I >>> would personally prefer that they not use the path index for that. I >>> would recommend that if the packet does not carry enough context that >>>the >>> service function could and should use metadata to carry its needed >>>state >>> information. But neither I personally nor the SFC Working Group get to >>> tell folks how to build their service functions. So they may come up >>> with other methods for addressing their needs. Which is also fine. >>> >>> Thus, I would not expect this document to discuss how service functions >>> themselves handle revisiting. But metadata clearly allows for a range >>>of >>> behaviors that will work. And the path index handles the SFF needs >>> relative to spirals, which is what we need to handle. >>> >>> Yours, >>> Joel >>> >>> On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote: >>>> Re-, >>>> >>>> Spiral is not mentioned in the draft, but SF loop is. >>>> >>>> I'm asking the question because I don't get from the draft how spirals >>>> could work (that is a SF invoked several time in the context of the >>>>same >>>> SFC). >>>> >>>> Before proposing text, I would like to understand first how it works. >>>> If you can provide an example, this will be even great. >>>> >>>> Thank you. >>>> >>>> Cheers, >>>> Med >>>> >>>>> -----Message d'origine----- >>>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : jeudi 26 >>>>> f=E9vrier 2015 15:41 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Cc= : >>>>> Ben Wright (Ben.Wright@metaswitch.com) Objet : Re: [sfc] >>>>> draft-quinn-sfc-nsh: Support of SF Spirals >>>>> >>>>> The SF Spirals requirement is one of the key drivers for the index. >>>>> The index allows one to tell where one is in the spiral, and also to >>>>> break a loop if one has a loop instead of a spiral. >>>>> >>>>> Is there text that we could add that would help make this clear, >>>>> since your earlier question about the path index suggests that it is >>>>> not as clear as it should be? >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote: >>>>>> Hi Paul, all, >>>>>> >>>>>> There were a discussion in the mailing list >>>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html) >>>>>> that led to defining what is meant by SF Spirals: (below is provided >>>>>> an excerpt from >>>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where >>>>>> the conclusions of that discussion were recorded) >>>>>> >>>>>> " o Service Function Spiral: denotes a Service Function Chain in >>>>> which >>>>>> >>>>>> data is handled by a Service Function, forwarded onwards, >>>>>> and >>>>>> >>>>>> arrives once again at that Service Function. >>>>>> >>>>>> * Note that some Service Functions support built-in >>>>>> functions to >>>>>> >>>>>> accommodate spirals; these service-specific functions >>>>>>may >>>>>> >>>>>> require that the data received in a spiral should differ >>>>>> in a >>>>>> >>>>>> way that will result in a different processing decision >>>>>> than >>>>>> >>>>>> the original data. This document does not make such >>>>>> >>>>>> assumption. >>>>>> >>>>>> * A Service Function Chain may involve one or more Service >>>>>> >>>>>> Function Spirals. >>>>>> >>>>>> * Unlike Service Function loop, spirals are not considered >>>>>> as >>>>>> >>>>>> errors." >>>>>> >>>>>> And this companion requirement: >>>>>> >>>>>> " A. Service Functions MAY be invoked multiple times >>>>>>in >>>>>> >>>>>> the same Service Function Chain (denoted as SF >>>>>> >>>>>> Spiral), but the solution MUST prevent >>>>>>infinite >>>>>> >>>>>> forwarding loops. =BB >>>>>> >>>>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is >>>>>>met. >>>>>> >>>>>> Can you please clarify whether this is supported and how? >>>>>> >>>>>> Thank you. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Med >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Feb 27 09:12:55 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C2F1ACDBB for ; Fri, 27 Feb 2015 09:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 i627mjNnIZCg for ; Fri, 27 Feb 2015 09:12:50 -0800 (PST) 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 40EF91ACE60 for ; Fri, 27 Feb 2015 09:12:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 2D77C240B8F; Fri, 27 Feb 2015 09:12:50 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.95.128.180]) (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 05B9C24056D; Fri, 27 Feb 2015 09:12:48 -0800 (PST) Message-ID: <54F0A576.8080701@joelhalpern.com> Date: Fri, 27 Feb 2015 12:12:22 -0500 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Dave Dolson , "Surendra Kumar (smkumar)" , "Reinaldo Penno (repenno)" , Ron Parker , "mohamed.boucadair@orange.com" , "sfc@ietf.org" References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3584.2080005@joelhalpern.com> <54EF596C.1080608@joelhalpern.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals 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, 27 Feb 2015 17:12:53 -0000 Do you ean SF or SFF? The table in section 9.1 is an SFF table. I don't understand how adding extra information there would help an SF builder. Yours, Joel On 2/27/15 12:08 PM, Dave Dolson wrote: > No chain can be deployed without writing to the forwarding table of each SF in the chain. > In other words, an SF must have a table entry for each occurrence in a chain, keyed by (SPI, SI) pair. > > Given that, I think it would be quite useful to add an extra column to the forwarding table defined in section 9.1: > > +-------------------+----------+ > | SPI | SI | NH | Role | > +-------------------+----------+ > | 10 | 3 | SF2 | "Foo" | > | 245 | 12 | SF34 | "ingress"| > | 40 | 9 | SF9 | "egress" | > +-------------------+----------+ > > > Call the new column "Role" or "Function". It is an indirection to anything the SF vendor wishes to permit. In many cases it would be a configuration set. > > I think this gives a mechanism for the spiral use cases. > > This new column doesn't have any (direct) impact on what appears on the wire, so I can see it might not belong in draft-quinn-sfc-nsh, rather in the configuration model. > > Speaking of which, I can't find the above SPI/SI/NH table in draft-penno-sfc-yang. Are these drafts yet to be reconciled? > > > > > > -----Original Message----- > From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > Sent: Thursday, February 26, 2015 3:52 PM > To: Joel M. Halpern; Dave Dolson; Reinaldo Penno (repenno); Ron Parker; mohamed.boucadair@orange.com; sfc@ietf.org > Cc: Ben Wright (Ben.Wright@metaswitch.com) > Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals > > > I would agree with that. > > An SF trying to figure out what SFCs it is part of and at what location it > is present in each of those SFCs, thus adds severe constraints to how such > an SF can be deployed. An SF limiting itself to service function delivery > alone, aided by the metadata, not only keeps the SF simple, allows for > very flexible deployments as well. > > Surendra. > > On 2/26/15, 9:35 AM, "Joel M. Halpern" wrote: > >> Personally, I would prefer that the firewall use metadata rather than >> path-index. My reasoning is that if functions get added before or after >> the firewall, operations would prefer not to have to change the >> configuration of the firewall SF itself. >> >> Having said that, I don't see any way to stop you from using the path >> index. >> >> Yours, >> Joel >> >> On 2/26/15 12:30 PM, Dave Dolson wrote: >>> For the sake of argument, suppose I have a firewall SF, and I want to >>> use >>> it more than once in a chain. (Maybe I want to book-end the chain with >>> ingress >>> and egress rules.) >>> >>> Do you agree it would be sufficient to use the Path Index to select >>> which of >>> the ingress or egress rule sets should be used? >>> >>> I'm probably missing something; I don't understand how the context >>> headers >>> define functionality. Maybe the device could communicate with itself >>> (e.g., the ingress portion sending a tag to the egress portion) >>> by sending state in the packet. Is that what you are mean by >>> "contextual info" ? >>> >>> >>> >>> -----Original Message----- >>> From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] >>> Sent: Thursday, February 26, 2015 12:18 PM >>> To: Dave Dolson; Ron Parker; Joel M. Halpern; >>> mohamed.boucadair@orange.com; sfc@ietf.org >>> Cc: Ben Wright (Ben.Wright@metaswitch.com) >>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >>> >>> Agreed on all points. I thought I was missing something so before >>> writing >>> this email I retested our implementation and it worked off the bat. The >>> RSP constructed has the the same (SFF, SF) tuple but different indexes. >>> >>> The same SF is visited multiple times until the path ends. If the SF >>> wants contextual info across visits than context headers are the way to >>> go. >>> >>> >>> On 2/26/15, 8:52 AM, "Dave Dolson" wrote: >>> >>>> Maybe naively, I thought the service functions would be provisioned >>>> with >>>> a table: >>>> >>>> E.g., for element foo: >>>> Path | Path Index | Next Hop | Function >>>> 123 | 4 | SF-bar | first behavior >>>> 123 | 2 | SF-foobar | second behavior >>>> >>>> >>>> The Function is clearly implementation specific. Maybe it points to a >>>> configuration set or a policy set. I think completely out of scope >>>> here. >>>> >>>> I suggest that this is not a problem for the wire protocol, rather for >>>> the configuration model (netconf or whatever). >>>> >>>> It becomes very much vendor-specific if the behaviors are complex >>>> configurations of specialized features. >>>> >>>> If a person were manually configuring chains, I don't think they'd >>>> have a >>>> conceptual problem, because they'd have a diagram they need to >>>> implement: >>>> {SF-foo (first-behavior), SF-bar, SF-foo (second-behavior), SF-foobar} >>>> >>>> If we wanted to standardize it, we could maybe make the Function >>>> simply a >>>> label that means something to the device--an indirection to a >>>> configuration set. >>>> >>>> -Dave >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker >>>> Sent: Thursday, February 26, 2015 11:31 AM >>>> To: Dave Dolson; Joel M. Halpern; mohamed.boucadair@orange.com; >>>> sfc@ietf.org >>>> Cc: Ben Wright (Ben.Wright@metaswitch.com) >>>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >>>> >>>> Hi, Dave. >>>> >>>> I agree that on the wire, this is the way it would work. >>>> >>>> But, when composing the chain, it seems like information would be >>>> lacking >>>> if a chain were expressed simply as {SF-foo, SF-bar, SF-foo, >>>> SF-foobar}. >>>> It is completely implicit that since SF-foo appears twice, it perhaps >>>> should perform some different duty when index = 0 vs when index = 2. >>>> >>>> At first, I thought that an alternative way to handle this would be to >>>> use multiple logical identities for SF-foo. In this case, the chain >>>> above would be expressed as {SF-foo-first-behavior, SF-bar, >>>> SF-foo-second-behavior, SF-foobar}. But, the problem here is >>>> selecting >>>> the RSP, assuming that SF-foo has multiple instances. Nothing in this >>>> second flavor of chain says that the same instance of SF-foo-* must be >>>> selected to satisfy SF-foo-first-behavior and SF-foo-second-behavior >>>> (which may not be required, but should be possible to force as such). >>>> >>>> I guess what I'm saying is that spiraling has a subtlety to it that >>>> isn't >>>> yet adequately addressed and that I don't have a specific proposal to >>>> solve it, either. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>>> Sent: Thursday, February 26, 2015 11:21 AM >>>> To: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>> Cc: Ben Wright (Ben.Wright@metaswitch.com) >>>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >>>> >>>> If I may try to put it simply, I've always thought of it this way: >>>> --> Each node in the chain selects the context for processing and the >>>> next hop on the basis of BOTH path ID and Index, while decrementing the >>>> index for the next hop. >>>> >>>> That behavior supports spiraling. >>>> >>>> >>>> >>>> -Dave >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: Thursday, February 26, 2015 10:02 AM >>>> To: mohamed.boucadair@orange.com; sfc@ietf.org >>>> Cc: Ben Wright (Ben.Wright@metaswitch.com) >>>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >>>> >>>> There are two different aspects of Spirals. >>>> >>>> One of the two aspects is enabling a packet that repeatedly arrives at >>>> the same SFF to get the correct services provided each time it arrives, >>>> and to go to the correct next SFF each time it arrives. The Service >>>> Path >>>> Index, used by the SFF to select service functions and next SFF, >>>> provides >>>> that capability. >>>> >>>> The other aspect is how the Service Functions themselves handle >>>> spirals. >>>> To a large degree, that depends upon the individual service function. >>>> I normally assume that it would use packet context (as described in >>>> the >>>> text you quote) to determine what to do. >>>> >>>> Since I would prefer that service functions are independent of the >>>> underlying service function chaining infrastructure, and are not >>>> sensitive to how many functions are before or after them in the chain, >>>> I >>>> would personally prefer that they not use the path index for that. I >>>> would recommend that if the packet does not carry enough context that >>>> the >>>> service function could and should use metadata to carry its needed >>>> state >>>> information. But neither I personally nor the SFC Working Group get to >>>> tell folks how to build their service functions. So they may come up >>>> with other methods for addressing their needs. Which is also fine. >>>> >>>> Thus, I would not expect this document to discuss how service functions >>>> themselves handle revisiting. But metadata clearly allows for a range >>>> of >>>> behaviors that will work. And the path index handles the SFF needs >>>> relative to spirals, which is what we need to handle. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote: >>>>> Re-, >>>>> >>>>> Spiral is not mentioned in the draft, but SF loop is. >>>>> >>>>> I'm asking the question because I don't get from the draft how spirals >>>>> could work (that is a SF invoked several time in the context of the >>>>> same >>>>> SFC). >>>>> >>>>> Before proposing text, I would like to understand first how it works. >>>>> If you can provide an example, this will be even great. >>>>> >>>>> Thank you. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoyé : jeudi 26 >>>>>> février 2015 15:41 Ŕ : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org Cc : >>>>>> Ben Wright (Ben.Wright@metaswitch.com) Objet : Re: [sfc] >>>>>> draft-quinn-sfc-nsh: Support of SF Spirals >>>>>> >>>>>> The SF Spirals requirement is one of the key drivers for the index. >>>>>> The index allows one to tell where one is in the spiral, and also to >>>>>> break a loop if one has a loop instead of a spiral. >>>>>> >>>>>> Is there text that we could add that would help make this clear, >>>>>> since your earlier question about the path index suggests that it is >>>>>> not as clear as it should be? >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote: >>>>>>> Hi Paul, all, >>>>>>> >>>>>>> There were a discussion in the mailing list >>>>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html) >>>>>>> that led to defining what is meant by SF Spirals: (below is provided >>>>>>> an excerpt from >>>>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 where >>>>>>> the conclusions of that discussion were recorded) >>>>>>> >>>>>>> " o Service Function Spiral: denotes a Service Function Chain in >>>>>> which >>>>>>> >>>>>>> data is handled by a Service Function, forwarded onwards, >>>>>>> and >>>>>>> >>>>>>> arrives once again at that Service Function. >>>>>>> >>>>>>> * Note that some Service Functions support built-in >>>>>>> functions to >>>>>>> >>>>>>> accommodate spirals; these service-specific functions >>>>>>> may >>>>>>> >>>>>>> require that the data received in a spiral should differ >>>>>>> in a >>>>>>> >>>>>>> way that will result in a different processing decision >>>>>>> than >>>>>>> >>>>>>> the original data. This document does not make such >>>>>>> >>>>>>> assumption. >>>>>>> >>>>>>> * A Service Function Chain may involve one or more Service >>>>>>> >>>>>>> Function Spirals. >>>>>>> >>>>>>> * Unlike Service Function loop, spirals are not considered >>>>>>> as >>>>>>> >>>>>>> errors." >>>>>>> >>>>>>> And this companion requirement: >>>>>>> >>>>>>> " A. Service Functions MAY be invoked multiple times >>>>>>> in >>>>>>> >>>>>>> the same Service Function Chain (denoted as SF >>>>>>> >>>>>>> Spiral), but the solution MUST prevent >>>>>>> infinite >>>>>>> >>>>>>> forwarding loops. » >>>>>>> >>>>>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is >>>>>>> met. >>>>>>> >>>>>>> Can you please clarify whether this is supported and how? >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Med >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Fri Feb 27 09:34: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 D79391ACE9B for ; Fri, 27 Feb 2015 09:34:13 -0800 (PST) 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 01zwiM4hbj6U for ; Fri, 27 Feb 2015 09:34:11 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id A3F361ACDE4 for ; Fri, 27 Feb 2015 09:34:11 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0195.001; Fri, 27 Feb 2015 12:34:10 -0500 From: Dave Dolson To: "Joel M. Halpern" , Sumandra Majee , "Reinaldo Penno (repenno)" , "sfc@ietf.org" Thread-Topic: [sfc] Support Bidirection/Symmetric flow Thread-Index: AQHQUhEQI2Pu+LmiWUKdVa7GMQ9w350DZNqAgACfsQCAAALFgIAACHCAgAAD3ACAAKi3AA== Date: Fri, 27 Feb 2015 17:34:09 +0000 Message-ID: References: <1424999534752.97011@F5.com> <54EFC6C5.5030805@joelhalpern.com> <54EFD116.2000707@joelhalpern.com> In-Reply-To: <54EFD116.2000707@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Support Bidirection/Symmetric flow 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, 27 Feb 2015 17:34:14 -0000 Look also at section 3.2.2.1 in draft-homma-sfc-forwarding-methods-analysis= -01 https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-analysis-01#= section-3.2.2.1 This shows a network architecture that allows asymmetric traffic arriving at a large network to be brought to an "SF Domain Proxy" having=20 a single classifier responsible for using bidirectional chains properly. The problem we faced was how to arrange for geographically distributed clas= sifiers=20 to be coordinated well enough to select the correct chains. So the geographically distributed classifiers instead select a data center, using stateless decision-making, and the required coordination is local, by= re-classifying both directions of traffic using a single instance of classifier. Then it becomes reasonable to talk about an SF signaling a single local cla= ssifier to change the chain for a flow. -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern Sent: Thursday, February 26, 2015 9:06 PM To: Sumandra Majee; Reinaldo Penno (repenno); sfc@ietf.org Subject: Re: [sfc] Support Bidirection/Symmetric flow Look at the long-lived flows draft. We talk about exactly that case,=20 and propose an approach to solving it. For local optimization, there is also the bypass draft. Yours, Joel On 2/26/15 8:52 PM, Sumandra Majee wrote: >>> I am a little confused by your statement that these are "run time >>> decisions" with an apparent implication that they are decisions made by >>> the forwarding infrastructure. Such an approach is permitted, but not >>> req uired, by the architecture and the protocol proposal. > > ADC, FW and other types stateful devices has a fair bit of local rules an= d > states. These equipments and rulesets etc. will be there as NSH is > introduced in the network. For example the local rule may decide that thi= s > particular dst ip doesn=B9t need to be TCP spliced. Since it doesn=B9t do= any > transformation it might want to bypass on the reverse part of flow. When = I > say local rule, it could be configuration (static) or generated > dynamically from analytics. Both mechanisms are implemented on platforms > that I work on. Since it is flow by flow local decision the most reliable > way to alter the forwarding path is in band. > > > > > On 2/26/15, 5:22 PM, "Joel M. Halpern" wrote: > >> I am a little confused by your statement that these are "run time >> decisions" with an apparent implication that they are decisions made by >> the forwarding infrastructure. Such an approach is permitted, but not >> req uired, by the architecture and the protocol proposal. >> >> So the question of what mechanisms are needed to enable symmetry when >> required depends upon both what we need. For example, even the use >> cases you have suggested are ones where the control mechanisms setting >> up the paths will know whether they need to be symmetric. So they can >> instantiate suitable state. >> Now, if an implementation and deployment wants to allow data plane >> decision, then that implementation needs to come up with a way to meet >> the symmetry requirements. It has been suggested by some of those who >> wish to deploy that way that the existing protocol hooks are sufficient >> for that. >> >> Yours, >> Joel >> >> On 2/26/15 8:12 PM, Sumandra Majee wrote: >>> Reinaldo, >>> >>> >>> The cache example is the easy one. As you noted it could be done by >>> grouping, a cache must *always* see both side of the traffic. >>> >>> >>> If I replace cache with ADC or other stateful flow aware devices then >>> the always part is not true. Flow1 can be deemed as must be >>> bidirectional and then flow2 can be assymetric, which essentially says >>> bypass me. >>> >>> >>> SF1 SF2 ADC >>> | | | >>> IN: Classifier <> SFF1 <> SFF2 <> SFF3 < SFF4-RTR< >>> >>> Building symmetric and/or hybrid path in dynamic ways is a great tool >>> and I am hoping this is one area where NSH can help immensely. >>> >>> Because these are run time decision an inband signalling is the reliabl= e >>> way. >>> >>> Regards. >>> >>> Sumandra >>> >>> >>> >>> >>> -----------------------------------------------------------------------= - >>> *From:* Reinaldo Penno (repenno) >>> *Sent:* Thursday, February 26, 2015 2:40 PM >>> *To:* Sumandra Majee; sfc@ietf.org >>> *Subject:* Re: [sfc] Support Bidirection/Symmetric flow >>> It is my impression that if you rewrite the picture like this it might >>> help working out the solution >>> >>> SF1 SF2 SFF3 >>> | | | >>> IN: Classifier <> SFF1 <> SFF2 <> Cache(*)/SFF < RTR< >>> >>> Since cache is actually directing (steering packets) it becomes a SFF. >>> If you adapt the reverse picture Cache/SFF will make sure reverse flows >>> to the same SF3. >>> >>> This is the whole Service Function Groups concept. >>> >>> thanks, >>> >>> >>> >>> From: Sumandra Majee > >>> Date: Thursday, February 26, 2015 at 2:10 PM >>> To: "sfc@ietf.org " >> > >>> Subject: [sfc] Support Bidirection/Symmetric flow >>> >>> Hello, >>> >>> The SFC architecture document says (correctly) that ingress path and >>> egress path of a given flow or work unit could symmetric, asymmetric or >>> hybrid. However a front/back (end) classifier is not always the correc= t >>> place to derive this information. Some cases are simple, >>> >>> IN: Classifier <> SF1 <> SF2 <> Cache(*) < >SF3 < RTR< >>> OUT: Classifier -> SF3 --> Cache <<> RTR >>> >>> The actual chains are not laid out like that, but for this discussion >>> lets stick with the above figure. In this case a device like cache >>> detects that both direction of flow must flow thru the cache (cache >>> miss). >>> >>> Now lets replace the cache with a modern ADC device. These devices can >>> and will make the decision for each flow. For optimal operation it is >>> best to signal the upstream node that flow(X) must come back to this SF >>> or should bypass this SF. >>> >>> How can we do this signaling? Metadata is an option, but it is a generi= c >>> use case where the format of this metadata then should be standardized. >>> The responsible SF can demand the return PATH to be some 221 that force= s >>> return traffic thru that SF, well that may not always be the good. >>> >>> Some sort of label stack? >>> >>> Interested to hear from you.. >>> >>> Regards. >>> >>> Sumandra >>> >>> >>> _______________________________________________ >>> 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 Fri Feb 27 09:37: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 821771ACEB4 for ; Fri, 27 Feb 2015 09:37:38 -0800 (PST) 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 CyA3cgRwzKv8 for ; Fri, 27 Feb 2015 09:37:35 -0800 (PST) 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 CC36E1A90C7 for ; Fri, 27 Feb 2015 09:37:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11697; q=dns/txt; s=iport; t=1425058654; x=1426268254; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=9KAe5/f9k0TSvoUMleGR1Uo8y0JDUkuBppmUc7ZF+no=; b=Gy4pf8KgbU5OE9gxXrIA0eZzzYeWOqMmdjv8xjLRpK1l323yl0IAsPAH uGG3/OTDLlsDSKDTUb8uJF6RzqSF+hr8kNhXwgVEbaQ/Na1Cvdm4eKMGz q4X+noDFJbELcaTtvcKhfnFyI3ROPnt6fN37erjPF4winjwnvxlkjl8jv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BhBQAfqvBU/40NJK1bgj9DgSwEyAoCgSZNAQEBAQEBfIQPAQEBBCdiAgEIDgMBAgEBASgHMhQDBggCBAESG4gU11MBAQEBAQEBAQEBAQEBAQEBAQEBAQEXihR+hF0XAQKEKQWIUYUogX2JRZNUI4ICHIFQb4FEfwEBAQ X-IronPort-AV: E=Sophos;i="5.09,661,1418083200"; d="scan'208,217";a="127594331" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 27 Feb 2015 17:37:34 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t1RHbYqW005122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Feb 2015 17:37:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.248]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Fri, 27 Feb 2015 11:37:33 -0600 From: "Reinaldo Penno (repenno)" To: Sumandra Majee , "sfc@ietf.org" Thread-Topic: [sfc] Support Bidirection/Symmetric flow Thread-Index: AQHQUhEQI2Pu+LmiWUKdVa7GMQ9w350DZNqAgACwdACAAI0ogA== Date: Fri, 27 Feb 2015 17:37:33 +0000 Message-ID: References: <1424999534752.97011@F5.com> In-Reply-To: <1424999534752.97011@F5.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.24.225.20] Content-Type: multipart/alternative; boundary="_000_D115EADAB8E5repennociscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Support Bidirection/Symmetric flow 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, 27 Feb 2015 17:37:38 -0000 --_000_D115EADAB8E5repennociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I think the problem is the same and well-understood. Joel has provided som= e good references on the subject. From: Sumandra Majee > Date: Thursday, February 26, 2015 at 5:12 PM To: Reinaldo Penno >, "sfc@ietf= .org" > Subject: Re: [sfc] Support Bidirection/Symmetric flow Reinaldo, The cache example is the easy one. As you noted it could be done by groupin= g, a cache must *always* see both side of the traffic. If I replace cache with ADC or other stateful flow aware devices then the a= lways part is not true. Flow1 can be deemed as must be bidirectional and th= en flow2 can be assymetric, which essentially says bypass me. SF1 SF2 ADC | | | IN: Classifier =97> SFF1 =97> SFF2 =97> SFF3 =97 SFF4-RTR=97 Building symmetric and/or hybrid path in dynamic ways is a great tool and I= am hoping this is one area where NSH can help immensely. Because these are run time decision an inband signalling is the reliable wa= y. Regards. Sumandra ________________________________ From: Reinaldo Penno (repenno) = > Sent: Thursday, February 26, 2015 2:40 PM To: Sumandra Majee; sfc@ietf.org Subject: Re: [sfc] Support Bidirection/Symmetric flow It is my impression that if you rewrite the picture like this it might help= working out the solution SF1 SF2 SFF3 | | | IN: Classifier =97> SFF1 =97> SFF2 =97> Cache(*)/SFF =97 RTR=97 Since cache is actually directing (steering packets) it becomes a SFF. If y= ou adapt the reverse picture Cache/SFF will make sure reverse flows to the = same SF3. This is the whole Service Function Groups concept. thanks, From: Sumandra Majee > Date: Thursday, February 26, 2015 at 2:10 PM To: "sfc@ietf.org" > Subject: [sfc] Support Bidirection/Symmetric flow Hello, The SFC architecture document says (correctly) that ingress path and egress= path of a given flow or work unit could symmetric, asymmetric or hybrid. = However a front/back (end) classifier is not always the correct place to de= rive this information. Some cases are simple, IN: Classifier =97> SF1 =97> SF2 =97> Cache(*) =97 >SF3 =97 RTR=97 OUT: Classifier -> SF3 --> Cache =97=97> RTR The actual chains are not laid out like that, but for this discussion lets = stick with the above figure. In this case a device like cache detects that = both direction of flow must flow thru the cache (cache miss). Now lets replace the cache with a modern ADC device. These devices can and = will make the decision for each flow. For optimal operation it is best to s= ignal the upstream node that flow(X) must come back to this SF or should by= pass this SF. How can we do this signaling? Metadata is an option, but it is a generic us= e case where the format of this metadata then should be standardized. The responsible SF can demand the return PATH to be some 221 that forces re= turn traffic thru that SF, well that may not always be the good. Some sort of label stack? Interested to hear from you.. Regards. Sumandra --_000_D115EADAB8E5repennociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <29B8EA9B15CA234FA2D9F5361C449B56@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
    I think the problem is the same and well-understood.  Joel has pr= ovided some good references on the subject. 

    From: Sumandra Majee <S.Majee@F5.com>
    Date: Thursday, February 26, 2015 a= t 5:12 PM
    To: Reinaldo Penno <repenno@cisco.com>, "sfc@ietf.org" <s= fc@ietf.org>
    Subject: Re: [sfc] Support Bidirect= ion/Symmetric flow

    Reinaldo,


    The cache example is the easy one. As you noted it could be done by grou= ping, a cache must *always* see both side of the traffic.


    If I replace cache with ADC or other stateful flow aware devices then th= e always part is not true. Flow1 can be deemed as must be bidirectional and= then flow2 can be assymetric, which essentially says bypass me.
                &= nbsp;          SF1      SF2  &= nbsp;  ADC
                &= nbsp;           |        | &nb= sp;     |
    IN:      Classifier =97> = SFF1 =97> SFF2 =97> SFF3 =97 SFF4-RTR=97

    Building symmetric and/or hybrid path in dynamic ways is a great tool and I= am hoping this is one area where NSH can help immensely.

    Because these are run time decision an inband signalling is the reliable wa= y.

    Regards.

    Sumandra




    From: Reinaldo Penno (repen= no) <repenno@cisco.com>
    Sent: Thursday, February 26, 2015 2:40 PM
    To: Sumandra Majee; sfc@ietf.org=
    Subject: Re: [sfc] Support Bidirection/Symmetric flow
     
    It is my impression that if you rewrite the= picture like this it might help working out the solution

                &= nbsp;          SF1      SF2   =       SFF3
                &= nbsp;           |        | &nb= sp;        |
    IN:      Classifier =97> = SFF1 =97> SFF2 =97> Cache(*)/SFF =97 RTR=97

    Since cache is actually directing (steering= packets) it becomes a SFF. If you adapt the reverse picture Cache/SFF will= make sure reverse flows to the same SF3. 

    This is the whole Service Function Groups c= oncept.

    thanks,



    From: Sumandra Majee <S.Majee@F5.com>
    Date: Thursday, February 26, 2015 a= t 2:10 PM
    To: "sfc@ietf.org" <sfc@ietf.= org>
    Subject: [sfc] Support Bidirection/= Symmetric flow

    Hello,

    The SFC architecture document says (correctly) that ingress path and e= gress path of a given flow or work unit could symmetric, asymmetric or hybr= id.  However a front/back (end) classifier is not always the correct p= lace to derive this information.  Some cases are simple,

      IN:      Classifier =97> SF1 =97> SF2 =97&= gt; Cache(*) =97 >SF3 =97 RTR=97
     OUT:   Classifier -> SF3 --> Cache =97=97> RTR

    The actual chains are not laid out like that, but for this discussion = lets stick with the above figure. In this case a device like cache detects = that both direction of flow must flow thru the cache (cache miss). 

    Now lets replace the cache with a modern ADC device. These devices can= and will make the decision for each flow. For optimal operation it is best= to signal the upstream node that flow(X) must come back to this SF or shou= ld bypass this SF.

    How can we do this signaling? Metadata is an option, but it is a gener= ic use case where the format of this metadata then should be standardized.&= nbsp;
    The responsible SF can demand the return PATH to be some 221 that forc= es return traffic thru that SF,   well that may not always be the good= .

    Some sort of label stack?

    Interested to hear from you..

    Regards.

    Sumandra
    --_000_D115EADAB8E5repennociscocom_-- From nobody Fri Feb 27 09:55:22 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 E187E1ACF1A for ; Fri, 27 Feb 2015 09:55:20 -0800 (PST) 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 4nlr0W4szJbD for ; Fri, 27 Feb 2015 09:55:17 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 4595A1ACF1D for ; Fri, 27 Feb 2015 09:55:03 -0800 (PST) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 27 Feb 2015 12:55:02 -0500 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; Fri, 27 Feb 2015 12:55:02 -0500 From: Dave Dolson To: Joel Halpern Direct , "Surendra Kumar (smkumar)" , "Reinaldo Penno (repenno)" , Ron Parker , "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals Thread-Index: AdBRyhUadMfMQp0TQVyP+AHUYniSlAAMhaQAAABleoAAAFj2AAAJAG9w///QlQCAAFBcIP//vPuAgABSEAD//7LOAIAANtYAgABHJZCAAQ3XAIAATakA Date: Fri, 27 Feb 2015 17:55:01 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B9330049159EC@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3086.8040700@joelhalpern.com> <787AE7BB302AE849A7480A190F8B933004915B0E@OPEXCLILM23.corporate.adroot.infra.ftgroup> <54EF3584.2080005@joelhalpern.com> <54EF596C.1080608@joelhalpern.com> <54F0A576.8080701@joelhalpern.com> In-Reply-To: <54F0A576.8080701@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Ben Wright \(Ben.Wright@metaswitch.com\)" Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals 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, 27 Feb 2015 17:55:21 -0000 Ahhh, that's my mistake, being stuck with the mental model of a device with= combined SF/SFF features. Thank you for helping me sort that out. An SFC-aware SF could have a table like the following, but there is probabl= y no need to standardize it at this level. Maybe at netconf level. +-----------+----------+ | SPI | SI | Role | +-----------+----------+ | 10 | 3 | "Foo" | | 245 | 12 | "ingress"| | 40 | 9 | "egress" | +-----------+----------+ -----Original Message----- From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com]=20 Sent: Friday, February 27, 2015 12:12 PM To: Dave Dolson; Surendra Kumar (smkumar); Reinaldo Penno (repenno); Ron Pa= rker; mohamed.boucadair@orange.com; sfc@ietf.org Cc: Ben Wright (Ben.Wright@metaswitch.com) Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals Do you ean SF or SFF? The table in section 9.1 is an SFF table. I=20 don't understand how adding extra information there would help an SF=20 builder. Yours, Joel On 2/27/15 12:08 PM, Dave Dolson wrote: > No chain can be deployed without writing to the forwarding table of each = SF in the chain. > In other words, an SF must have a table entry for each occurrence in a ch= ain, keyed by (SPI, SI) pair. > > Given that, I think it would be quite useful to add an extra column to th= e forwarding table defined in section 9.1: > > +-------------------+----------+ > | SPI | SI | NH | Role | > +-------------------+----------+ > | 10 | 3 | SF2 | "Foo" | > | 245 | 12 | SF34 | "ingress"| > | 40 | 9 | SF9 | "egress" | > +-------------------+----------+ > > > Call the new column "Role" or "Function". It is an indirection to anythin= g the SF vendor wishes to permit. In many cases it would be a configuration= set. > > I think this gives a mechanism for the spiral use cases. > > This new column doesn't have any (direct) impact on what appears on the w= ire, so I can see it might not belong in draft-quinn-sfc-nsh, rather in the= configuration model. > > Speaking of which, I can't find the above SPI/SI/NH table in draft-penno-= sfc-yang. Are these drafts yet to be reconciled? > > > > > > -----Original Message----- > From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > Sent: Thursday, February 26, 2015 3:52 PM > To: Joel M. Halpern; Dave Dolson; Reinaldo Penno (repenno); Ron Parker; m= ohamed.boucadair@orange.com; sfc@ietf.org > Cc: Ben Wright (Ben.Wright@metaswitch.com) > Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals > > > I would agree with that. > > An SF trying to figure out what SFCs it is part of and at what location i= t > is present in each of those SFCs, thus adds severe constraints to how suc= h > an SF can be deployed. An SF limiting itself to service function delivery > alone, aided by the metadata, not only keeps the SF simple, allows for > very flexible deployments as well. > > Surendra. > > On 2/26/15, 9:35 AM, "Joel M. Halpern" wrote: > >> Personally, I would prefer that the firewall use metadata rather than >> path-index. My reasoning is that if functions get added before or after >> the firewall, operations would prefer not to have to change the >> configuration of the firewall SF itself. >> >> Having said that, I don't see any way to stop you from using the path >> index. >> >> Yours, >> Joel >> >> On 2/26/15 12:30 PM, Dave Dolson wrote: >>> For the sake of argument, suppose I have a firewall SF, and I want to >>> use >>> it more than once in a chain. (Maybe I want to book-end the chain with >>> ingress >>> and egress rules.) >>> >>> Do you agree it would be sufficient to use the Path Index to select >>> which of >>> the ingress or egress rule sets should be used? >>> >>> I'm probably missing something; I don't understand how the context >>> headers >>> define functionality. Maybe the device could communicate with itself >>> (e.g., the ingress portion sending a tag to the egress portion) >>> by sending state in the packet. Is that what you are mean by >>> "contextual info" ? >>> >>> >>> >>> -----Original Message----- >>> From: Reinaldo Penno (repenno) [mailto:repenno@cisco.com] >>> Sent: Thursday, February 26, 2015 12:18 PM >>> To: Dave Dolson; Ron Parker; Joel M. Halpern; >>> mohamed.boucadair@orange.com; sfc@ietf.org >>> Cc: Ben Wright (Ben.Wright@metaswitch.com) >>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >>> >>> Agreed on all points. I thought I was missing something so before >>> writing >>> this email I retested our implementation and it worked off the bat. The >>> RSP constructed has the the same (SFF, SF) tuple but different indexes. >>> >>> The same SF is visited multiple times until the path ends. If the SF >>> wants contextual info across visits than context headers are the way to >>> go. >>> >>> >>> On 2/26/15, 8:52 AM, "Dave Dolson" wrote: >>> >>>> Maybe naively, I thought the service functions would be provisioned >>>> with >>>> a table: >>>> >>>> E.g., for element foo: >>>> Path | Path Index | Next Hop | Function >>>> 123 | 4 | SF-bar | first behavior >>>> 123 | 2 | SF-foobar | second behavior >>>> >>>> >>>> The Function is clearly implementation specific. Maybe it points to a >>>> configuration set or a policy set. I think completely out of scope >>>> here. >>>> >>>> I suggest that this is not a problem for the wire protocol, rather for >>>> the configuration model (netconf or whatever). >>>> >>>> It becomes very much vendor-specific if the behaviors are complex >>>> configurations of specialized features. >>>> >>>> If a person were manually configuring chains, I don't think they'd >>>> have a >>>> conceptual problem, because they'd have a diagram they need to >>>> implement: >>>> {SF-foo (first-behavior), SF-bar, SF-foo (second-behavior), SF-foobar} >>>> >>>> If we wanted to standardize it, we could maybe make the Function >>>> simply a >>>> label that means something to the device--an indirection to a >>>> configuration set. >>>> >>>> -Dave >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker >>>> Sent: Thursday, February 26, 2015 11:31 AM >>>> To: Dave Dolson; Joel M. Halpern; mohamed.boucadair@orange.com; >>>> sfc@ietf.org >>>> Cc: Ben Wright (Ben.Wright@metaswitch.com) >>>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >>>> >>>> Hi, Dave. >>>> >>>> I agree that on the wire, this is the way it would work. >>>> >>>> But, when composing the chain, it seems like information would be >>>> lacking >>>> if a chain were expressed simply as {SF-foo, SF-bar, SF-foo, >>>> SF-foobar}. >>>> It is completely implicit that since SF-foo appears twice, it perha= ps >>>> should perform some different duty when index =3D 0 vs when index =3D = 2. >>>> >>>> At first, I thought that an alternative way to handle this would be to >>>> use multiple logical identities for SF-foo. In this case, the chain >>>> above would be expressed as {SF-foo-first-behavior, SF-bar, >>>> SF-foo-second-behavior, SF-foobar}. But, the problem here is >>>> selecting >>>> the RSP, assuming that SF-foo has multiple instances. Nothing in thi= s >>>> second flavor of chain says that the same instance of SF-foo-* must be >>>> selected to satisfy SF-foo-first-behavior and SF-foo-second-behavior >>>> (which may not be required, but should be possible to force as such). >>>> >>>> I guess what I'm saying is that spiraling has a subtlety to it that >>>> isn't >>>> yet adequately addressed and that I don't have a specific proposal to >>>> solve it, either. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dave Dolson >>>> Sent: Thursday, February 26, 2015 11:21 AM >>>> To: Joel M. Halpern; mohamed.boucadair@orange.com; sfc@ietf.org >>>> Cc: Ben Wright (Ben.Wright@metaswitch.com) >>>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >>>> >>>> If I may try to put it simply, I've always thought of it this way: >>>> --> Each node in the chain selects the context for processing and the >>>> next hop on the basis of BOTH path ID and Index, while decrementing th= e >>>> index for the next hop. >>>> >>>> That behavior supports spiraling. >>>> >>>> >>>> >>>> -Dave >>>> >>>> >>>> -----Original Message----- >>>> From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern >>>> Sent: Thursday, February 26, 2015 10:02 AM >>>> To: mohamed.boucadair@orange.com; sfc@ietf.org >>>> Cc: Ben Wright (Ben.Wright@metaswitch.com) >>>> Subject: Re: [sfc] draft-quinn-sfc-nsh: Support of SF Spirals >>>> >>>> There are two different aspects of Spirals. >>>> >>>> One of the two aspects is enabling a packet that repeatedly arrives at >>>> the same SFF to get the correct services provided each time it arrives= , >>>> and to go to the correct next SFF each time it arrives. The Service >>>> Path >>>> Index, used by the SFF to select service functions and next SFF, >>>> provides >>>> that capability. >>>> >>>> The other aspect is how the Service Functions themselves handle >>>> spirals. >>>> To a large degree, that depends upon the individual service functio= n. >>>> I normally assume that it would use packet context (as described in >>>> the >>>> text you quote) to determine what to do. >>>> >>>> Since I would prefer that service functions are independent of the >>>> underlying service function chaining infrastructure, and are not >>>> sensitive to how many functions are before or after them in the chain, >>>> I >>>> would personally prefer that they not use the path index for that. I >>>> would recommend that if the packet does not carry enough context that >>>> the >>>> service function could and should use metadata to carry its needed >>>> state >>>> information. But neither I personally nor the SFC Working Group get t= o >>>> tell folks how to build their service functions. So they may come up >>>> with other methods for addressing their needs. Which is also fine. >>>> >>>> Thus, I would not expect this document to discuss how service function= s >>>> themselves handle revisiting. But metadata clearly allows for a range >>>> of >>>> behaviors that will work. And the path index handles the SFF needs >>>> relative to spirals, which is what we need to handle. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 2/26/15 9:52 AM, mohamed.boucadair@orange.com wrote: >>>>> Re-, >>>>> >>>>> Spiral is not mentioned in the draft, but SF loop is. >>>>> >>>>> I'm asking the question because I don't get from the draft how spiral= s >>>>> could work (that is a SF invoked several time in the context of the >>>>> same >>>>> SFC). >>>>> >>>>> Before proposing text, I would like to understand first how it works. >>>>> If you can provide an example, this will be even great. >>>>> >>>>> Thank you. >>>>> >>>>> Cheers, >>>>> Med >>>>> >>>>>> -----Message d'origine----- >>>>>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com] Envoy=E9 : jeudi 2= 6 >>>>>> f=E9vrier 2015 15:41 =C0 : BOUCADAIR Mohamed IMT/OLN; sfc@ietf.org C= c : >>>>>> Ben Wright (Ben.Wright@metaswitch.com) Objet : Re: [sfc] >>>>>> draft-quinn-sfc-nsh: Support of SF Spirals >>>>>> >>>>>> The SF Spirals requirement is one of the key drivers for the index. >>>>>> The index allows one to tell where one is in the spiral, and also to >>>>>> break a loop if one has a loop instead of a spiral. >>>>>> >>>>>> Is there text that we could add that would help make this clear, >>>>>> since your earlier question about the path index suggests that it is >>>>>> not as clear as it should be? >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 2/26/15 8:42 AM, mohamed.boucadair@orange.com wrote: >>>>>>> Hi Paul, all, >>>>>>> >>>>>>> There were a discussion in the mailing list >>>>>>> (http://www.ietf.org/mail-archive/web/sfc/current/msg01701.html) >>>>>>> that led to defining what is meant by SF Spirals: (below is provide= d >>>>>>> an excerpt from >>>>>>> http://tools.ietf.org/html/draft-boucadair-sfc-requirements-06 wher= e >>>>>>> the conclusions of that discussion were recorded) >>>>>>> >>>>>>> " o Service Function Spiral: denotes a Service Function Chain in >>>>>> which >>>>>>> >>>>>>> data is handled by a Service Function, forwarded onwards, >>>>>>> and >>>>>>> >>>>>>> arrives once again at that Service Function. >>>>>>> >>>>>>> * Note that some Service Functions support built-in >>>>>>> functions to >>>>>>> >>>>>>> accommodate spirals; these service-specific functions >>>>>>> may >>>>>>> >>>>>>> require that the data received in a spiral should diff= er >>>>>>> in a >>>>>>> >>>>>>> way that will result in a different processing decisio= n >>>>>>> than >>>>>>> >>>>>>> the original data. This document does not make such >>>>>>> >>>>>>> assumption. >>>>>>> >>>>>>> * A Service Function Chain may involve one or more Servi= ce >>>>>>> >>>>>>> Function Spirals. >>>>>>> >>>>>>> * Unlike Service Function loop, spirals are not consider= ed >>>>>>> as >>>>>>> >>>>>>> errors." >>>>>>> >>>>>>> And this companion requirement: >>>>>>> >>>>>>> " A. Service Functions MAY be invoked multiple times >>>>>>> in >>>>>>> >>>>>>> the same Service Function Chain (denoted as = SF >>>>>>> >>>>>>> Spiral), but the solution MUST prevent >>>>>>> infinite >>>>>>> >>>>>>> forwarding loops. =BB >>>>>>> >>>>>>> Reading the current draft-quinn-sfc-nsh, I don't see how this is >>>>>>> met. >>>>>>> >>>>>>> Can you please clarify whether this is supported and how? >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Med >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc > From nobody Fri Feb 27 15:35: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 16CAD1A01F2 for ; Fri, 27 Feb 2015 15:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 FVDFlE4efyv1 for ; Fri, 27 Feb 2015 15:35:05 -0800 (PST) Received: from smtp113.iad3a.emailsrvr.com (smtp113.iad3a.emailsrvr.com [173.203.187.113]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58C121A0194 for ; Fri, 27 Feb 2015 15:35:05 -0800 (PST) Received: from smtp31.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp31.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 456C63802B2; Fri, 27 Feb 2015 18:35:04 -0500 (EST) Received: by smtp31.relay.iad3a.emailsrvr.com (Authenticated sender: bgreene-AT-senki.org) with ESMTPSA id 619C63804DE; Fri, 27 Feb 2015 18:35:02 -0500 (EST) X-Sender-Id: bgreene@senki.org Received: from [10.0.1.32] ([UNAVAILABLE]. [139.193.145.135]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.4.2); Fri, 27 Feb 2015 23:35:04 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F198A4CF-FAEA-469C-A167-68C4E772052E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: BARRY GREENE In-Reply-To: <76B41B8FACE1514795D30EC137FF391D7D75B6@LILAS.jungle.qosmos.com> Date: Sat, 28 Feb 2015 06:34:57 +0700 Message-Id: References: <7E05C330D7FD6D4FAD0728C46B89958581B932D4@ORSMSX114.amr.corp.intel.com> <76B41B8FACE1514795D30EC137FF391D7D75B6@LILAS.jungle.qosmos.com> To: Nicolas BOUTHORS X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Jim Guichard , "sfc@ietf.org" Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh 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, 27 Feb 2015 23:35:08 -0000 --Apple-Mail=_F198A4CF-FAEA-469C-A167-68C4E772052E Content-Type: multipart/alternative; boundary="Apple-Mail=_E5C50A5A-223E-4737-AC24-69DA7AF22798" --Apple-Mail=_E5C50A5A-223E-4737-AC24-69DA7AF22798 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 > On Feb 27, 2015, at 3:07 PM, Nicolas BOUTHORS = wrote: >=20 > Support >=20 > Br, >=20 > Nicolas. >=20 > On Feb 26, 2015, at 4:47 AM, Jim Guichard (jguichar) = > wrote: >=20 > Greetings WG: >=20 > The document draft-quinn-sfc-nsh-07 = (https://datatracker.ietf.org/doc/draft-quinn-sfc-nsh = /) has recently = been reissued. The authors of draft-zhang-sfc-sch-03 = (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch = /) have joined the = NSH document so that the WG can focus on a single encapsulation document = going forward. This new version of NSH includes an open items section = based on discussion between co-authors and members of the list. The WG = will work through this list (and any other issues that need to be added) = over the next weeks. We appreciate and recognize the hard work of both = the NSH and SCH authors in pushing the SFC encapsulation work forward. >=20 > With that said, the chairs are calling for WG adoption of = draft-quinn-sfc-nsh-07 as a WG document. The call for adoption will run = for 2 weeks ending 3/12/2015. >=20 > Please note that this is a call for adoption, and not a last call for = content of the document. Adopting a WG document simply means that the WG = will focus its efforts on that particular draft going forward, and use = that document for resolving open issues and documenting the WG=E2=80=99s = decisions. >=20 > Please indicate whether you support adoption for not, and if not why. = Issues you have with the current document itself can also be raised, but = they should be raised in the context of what should be changed in the = document going forward, rather than a pre-condition for adoption. >=20 > Finally, now is also a good time to poll for knowledge of any IPR that = applies to this draft, in line with the IPR disclosure obligations for = WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). = If you are listed as a document author please respond to this email (to = the chairs) whether or not you are aware of any relevant IPR. >=20 > Jim & Thomas > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc = >=20 > This message and any attachments (the "message") are confidential, = intended solely for the addressees. If you are not the intended = recipient, please notify the sender immediately by e-mail and delete = this message from your system. In this case, you are not authorized to = use, copy this message and/or disclose the content to any other person. = E-mails are susceptible to alteration. Neither Qosmos nor any of its = subsidiaries or affiliates shall be liable for the message if altered, = changed or falsified. >=20 > Ce message et toutes ses pi=C3=A8ces jointes (ci-apr=C3=A8s le = "message")sont confidentiels et =C3=A9tablis =C3=A0 l'intention = exclusive de ses destinataires. Si vous avez re=C3=A7u ce message par = erreur, merci d=E2=80=99en informer imm=C3=A9diatement son =C3=A9metteur = par courrier =C3=A9lectronique et d=E2=80=99effacer ce message de votre = syst=C3=A8me. Dans cette hypoth=C3=A8se, vous n=E2=80=99=C3=AAtes pas = autoris=C3=A9 =C3=A0 utiliser, copier ce message et/ou en divulguer le = contenu =C3=A0 un tiers. Tout message =C3=A9lectronique est susceptible = d'alt=C3=A9ration. Qosmos et ses filiales d=C3=A9clinent toute = responsabilit=C3=A9 au titre de ce message s'il a =C3=A9t=C3=A9 = alt=C3=A9r=C3=A9, d=C3=A9form=C3=A9 ou falsifi=C3=A9. >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc = --Apple-Mail=_E5C50A5A-223E-4737-AC24-69DA7AF22798 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

    +1

    On Feb 27, 2015, at 3:07 PM, Nicolas BOUTHORS = <Nicolas.BOUTHORS@qosmos.com> wrote:

    Support

     

    Br,

     

    Nicolas.

     

    On Feb 26, 2015, at 4:47 AM, Jim Guichard = (jguichar) <jguichar@cisco.com>= wrote:
     
    Greetings = WG:

     

    The document = draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/) = has recently been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) = have joined the NSH document so that the WG can focus on a single = encapsulation document going forward. This new version of NSH includes = an open = items section = based on discussion between co-authors and members of the list. The WG = will work through this list (and any other issues that need to be added) = over the next weeks. We appreciate and recognize the hard work of both = the NSH and SCH authors in pushing the SFC encapsulation work = forward.

     

    With that said, the chairs are = calling for WG adoption of draft-quinn-sfc-nsh-07 as a WG document. The = call for adoption will run for 2 weeks ending 3/12/2015.

     

    Please note that this is a call for adoption, and not a last = call for content of the document. Adopting a WG document simply means = that the WG will focus its efforts on that particular draft going = forward, and use that document for resolving open issues and documenting = the WG=E2=80=99s decisions.

     

    Please indicate whether you support adoption for not, and if = not why. Issues you have with the current document itself can also be = raised, but they should be raised in the context of what should be = changed in the document going forward, rather than a pre-condition for = adoption. 

     

    Finally, now is also a good time to poll for knowledge of any = IPR that applies to this draft, in line with the IPR disclosure = obligations for WG participants (see RFCs 3979, 4879, 3669 and 5378 for = more details). If you are listed as a document author please respond to = this email (to the chairs) whether or not you are aware of any relevant = IPR.

     

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

     

    This message and any attachments (the "message") are = confidential, intended solely for the addressees. If you are not the = intended recipient, please notify the sender immediately by e-mail and = delete this message from your system. In this case, you are not = authorized to use, copy this message and/or disclose the content to any = other person. E-mails are susceptible to alteration. Neither Qosmos nor = any of its subsidiaries or affiliates shall be liable for the message if = altered, changed or falsified.

    Ce message et = toutes ses pi=C3=A8ces jointes (ci-apr=C3=A8s le "message")sont = confidentiels et =C3=A9tablis =C3=A0 l'intention exclusive de ses = destinataires. Si vous avez re=C3=A7u ce message par erreur, merci = d=E2=80=99en informer imm=C3=A9diatement son =C3=A9metteur par courrier = =C3=A9lectronique et d=E2=80=99effacer ce message de votre syst=C3=A8me. = Dans cette hypoth=C3=A8se, vous n=E2=80=99=C3=AAtes pas autoris=C3=A9 =C3=A0= utiliser, copier ce message et/ou en divulguer le contenu =C3=A0 un = tiers. Tout message =C3=A9lectronique est susceptible d'alt=C3=A9ration. = Qosmos et ses filiales d=C3=A9clinent toute responsabilit=C3=A9 au titre = de ce message s'il a =C3=A9t=C3=A9 alt=C3=A9r=C3=A9, d=C3=A9form=C3=A9 = ou falsifi=C3=A9.

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

    = --Apple-Mail=_E5C50A5A-223E-4737-AC24-69DA7AF22798-- --Apple-Mail=_F198A4CF-FAEA-469C-A167-68C4E772052E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU8P8iAAoJEFVuk3AWv0Xzgg4IAIXtm8lZPHG/KMCtkVWR2gru DU83FPvWHT1JudiRkl3qgy+fzuHmgMPBO8BSdhu9uUX6n/NyypFVmzEjb9WKEB0m UcJF12ow3tjnYUeZHsSg/ZlHX/e5CPhHQIkY83kzXGRcw/4IeObco3xsdYxwJk9a +Og/ad2T9h7PPvHXcIevIhsz4NeGWvLJFZ7eGcWtOPoQ7ytIFY+AtXwQGVkMRM9s TMakdM0p4a1MGZvr/SAMVnz7tsqCHQW7RvIQQcwvYnMhMqNJ6w7fewCX+yVKzUFk HAmi4lsO0trdtQkoYdnYXGAlGvj5Rb5/48M87d+ew+HOoyG5ZkrbrY76aQb27nI= =l0QB -----END PGP SIGNATURE----- --Apple-Mail=_F198A4CF-FAEA-469C-A167-68C4E772052E-- From nobody Fri Feb 27 16:02: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 3C13B1A1A5B for ; Fri, 27 Feb 2015 16:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 60_FcGLox1jn for ; Fri, 27 Feb 2015 16:02:29 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF201A1A59 for ; Fri, 27 Feb 2015 16:02:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.09,663,1418083200"; d="scan'208";a="151158306" X-IPAS-Result: A2DUBAAnBPFU/+sKqMBbg1RaBLN4jgAdDIVuAoFxAQEBAQEBfIQPAQEBAQMBAQEkRxcEAgEIDgMBAgEBAQEJHgcPGAsUAwYIAgQBEhuIIdZ3AQEBAQEFAQEBAQEBARcEihR+hDsIMgIEhCUFhW6EPokphwCOfIM+giUcgVBvAQEBgUF/AQEB Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 28 Feb 2015 00:02:30 +0000 Received: from SEAEXCHMBX01.olympus.F5Net.com (192.168.15.223) by seaexchmbx01.olympus.F5Net.com (192.168.15.223) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 27 Feb 2015 16:02:28 -0800 Received: from SEAEXCHMBX01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75]) by seaexchmbx01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75%13]) with mapi id 15.00.1044.021; Fri, 27 Feb 2015 16:02:28 -0800 From: Sumandra Majee To: Dave Dolson , "Joel M. Halpern" , "Reinaldo Penno (repenno)" , "sfc@ietf.org" Thread-Topic: [sfc] Support Bidirection/Symmetric flow Thread-Index: AQHQUhVCynhM34uHZEOuTJnMEPtUG50DrfoxgACLmID//4JRAIAAifwAgAEDQYD//+LT/g== Date: Sat, 28 Feb 2015 00:02:28 +0000 Message-ID: <1425081744012.6062@F5.com> References: <1424999534752.97011@F5.com> <54EFC6C5.5030805@joelhalpern.com> <54EFD116.2000707@joelhalpern.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 x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Support Bidirection/Symmetric flow X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 00:02:32 -0000 >>Look also at section 3.2.2.1 in draft-homma-sfc-forwarding-methods-analys= is-01=0A= Thanks for pointing to this draft. Yes, many of these methods are already i= n use when a single vendor distribute/clusterize their own devices. The pr= oblem I am talking about can be approximated via Sub Domain concept (as in = the draft), but that does not automatically means a single processing point= . =0A= =0A= >>So the geographically distributed classifiers instead select a data cente= r,=0A= >>using stateless decision-making, and the required coordination is local, = by re-classifying=0A= >>both directions of traffic using a single instance of classifier.=0A= =0A= This problem does not need to span multiple data center. A cluster of ADC, = classifiers etc. are required to handle current load multiple TB layer 7 pr= ocessing load today in some to South East Asian countries. An ability to do= signalling would clean up the network design. Not all customers are very w= illing or fond of creating tunnels (especially if those need to be setup ma= nually). =0A= ________________________________________=0A= From: Dave Dolson =0A= Sent: Friday, February 27, 2015 9:34 AM=0A= To: Joel M. Halpern; Sumandra Majee; Reinaldo Penno (repenno); sfc@ietf.org= =0A= Subject: RE: [sfc] Support Bidirection/Symmetric flow=0A= =0A= Look also at section 3.2.2.1 in draft-homma-sfc-forwarding-methods-analysis= -01=0A= https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-analysis-01#= section-3.2.2.1=0A= =0A= This shows a network architecture that allows asymmetric traffic arriving= =0A= at a large network to be brought to an "SF Domain Proxy" having=0A= a single classifier responsible for using bidirectional chains properly.=0A= =0A= The problem we faced was how to arrange for geographically distributed clas= sifiers=0A= to be coordinated well enough to select the correct chains.=0A= =0A= So the geographically distributed classifiers instead select a data center,= =0A= using stateless decision-making, and the required coordination is local, by= re-classifying=0A= both directions of traffic using a single instance of classifier.=0A= =0A= Then it becomes reasonable to talk about an SF signaling a single local cla= ssifier=0A= to change the chain for a flow.=0A= =0A= =0A= -----Original Message-----=0A= From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern=0A= Sent: Thursday, February 26, 2015 9:06 PM=0A= To: Sumandra Majee; Reinaldo Penno (repenno); sfc@ietf.org=0A= Subject: Re: [sfc] Support Bidirection/Symmetric flow=0A= =0A= Look at the long-lived flows draft. We talk about exactly that case,=0A= and propose an approach to solving it.=0A= For local optimization, there is also the bypass draft.=0A= =0A= Yours,=0A= Joel=0A= =0A= On 2/26/15 8:52 PM, Sumandra Majee wrote:=0A= >>> I am a little confused by your statement that these are "run time=0A= >>> decisions" with an apparent implication that they are decisions made by= =0A= >>> the forwarding infrastructure. Such an approach is permitted, but not= =0A= >>> req uired, by the architecture and the protocol proposal.=0A= >=0A= > ADC, FW and other types stateful devices has a fair bit of local rules an= d=0A= > states. These equipments and rulesets etc. will be there as NSH is=0A= > introduced in the network. For example the local rule may decide that thi= s=0A= > particular dst ip doesn=B9t need to be TCP spliced. Since it doesn=B9t do= any=0A= > transformation it might want to bypass on the reverse part of flow. When = I=0A= > say local rule, it could be configuration (static) or generated=0A= > dynamically from analytics. Both mechanisms are implemented on platforms= =0A= > that I work on. Since it is flow by flow local decision the most reliable= =0A= > way to alter the forwarding path is in band.=0A= >=0A= >=0A= >=0A= >=0A= > On 2/26/15, 5:22 PM, "Joel M. Halpern" wrote:=0A= >=0A= >> I am a little confused by your statement that these are "run time=0A= >> decisions" with an apparent implication that they are decisions made by= =0A= >> the forwarding infrastructure. Such an approach is permitted, but not= =0A= >> req uired, by the architecture and the protocol proposal.=0A= >>=0A= >> So the question of what mechanisms are needed to enable symmetry when=0A= >> required depends upon both what we need. For example, even the use=0A= >> cases you have suggested are ones where the control mechanisms setting= =0A= >> up the paths will know whether they need to be symmetric. So they can= =0A= >> instantiate suitable state.=0A= >> Now, if an implementation and deployment wants to allow data plane=0A= >> decision, then that implementation needs to come up with a way to meet= =0A= >> the symmetry requirements. It has been suggested by some of those who= =0A= >> wish to deploy that way that the existing protocol hooks are sufficient= =0A= >> for that.=0A= >>=0A= >> Yours,=0A= >> Joel=0A= >>=0A= >> On 2/26/15 8:12 PM, Sumandra Majee wrote:=0A= >>> Reinaldo,=0A= >>>=0A= >>>=0A= >>> The cache example is the easy one. As you noted it could be done by=0A= >>> grouping, a cache must *always* see both side of the traffic.=0A= >>>=0A= >>>=0A= >>> If I replace cache with ADC or other stateful flow aware devices then= =0A= >>> the always part is not true. Flow1 can be deemed as must be=0A= >>> bidirectional and then flow2 can be assymetric, which essentially says= =0A= >>> bypass me.=0A= >>>=0A= >>>=0A= >>> SF1 SF2 ADC=0A= >>> | | |=0A= >>> IN: Classifier <> SFF1 <> SFF2 <> SFF3 < SFF4-RTR<=0A= >>>=0A= >>> Building symmetric and/or hybrid path in dynamic ways is a great tool= =0A= >>> and I am hoping this is one area where NSH can help immensely.=0A= >>>=0A= >>> Because these are run time decision an inband signalling is the reliabl= e=0A= >>> way.=0A= >>>=0A= >>> Regards.=0A= >>>=0A= >>> Sumandra=0A= >>>=0A= >>>=0A= >>>=0A= >>>=0A= >>> -----------------------------------------------------------------------= -=0A= >>> *From:* Reinaldo Penno (repenno) =0A= >>> *Sent:* Thursday, February 26, 2015 2:40 PM=0A= >>> *To:* Sumandra Majee; sfc@ietf.org=0A= >>> *Subject:* Re: [sfc] Support Bidirection/Symmetric flow=0A= >>> It is my impression that if you rewrite the picture like this it might= =0A= >>> help working out the solution=0A= >>>=0A= >>> SF1 SF2 SFF3=0A= >>> | | |=0A= >>> IN: Classifier <> SFF1 <> SFF2 <> Cache(*)/SFF < RTR<=0A= >>>=0A= >>> Since cache is actually directing (steering packets) it becomes a SFF.= =0A= >>> If you adapt the reverse picture Cache/SFF will make sure reverse flows= =0A= >>> to the same SF3.=0A= >>>=0A= >>> This is the whole Service Function Groups concept.=0A= >>>=0A= >>> thanks,=0A= >>>=0A= >>>=0A= >>>=0A= >>> From: Sumandra Majee >=0A= >>> Date: Thursday, February 26, 2015 at 2:10 PM=0A= >>> To: "sfc@ietf.org " >> >=0A= >>> Subject: [sfc] Support Bidirection/Symmetric flow=0A= >>>=0A= >>> Hello,=0A= >>>=0A= >>> The SFC architecture document says (correctly) that ingress path and=0A= >>> egress path of a given flow or work unit could symmetric, asymmetric or= =0A= >>> hybrid. However a front/back (end) classifier is not always the correc= t=0A= >>> place to derive this information. Some cases are simple,=0A= >>>=0A= >>> IN: Classifier <> SF1 <> SF2 <> Cache(*) < >SF3 < RTR<=0A= >>> OUT: Classifier -> SF3 --> Cache <<> RTR=0A= >>>=0A= >>> The actual chains are not laid out like that, but for this discussion= =0A= >>> lets stick with the above figure. In this case a device like cache=0A= >>> detects that both direction of flow must flow thru the cache (cache=0A= >>> miss).=0A= >>>=0A= >>> Now lets replace the cache with a modern ADC device. These devices can= =0A= >>> and will make the decision for each flow. For optimal operation it is= =0A= >>> best to signal the upstream node that flow(X) must come back to this SF= =0A= >>> or should bypass this SF.=0A= >>>=0A= >>> How can we do this signaling? Metadata is an option, but it is a generi= c=0A= >>> use case where the format of this metadata then should be standardized.= =0A= >>> The responsible SF can demand the return PATH to be some 221 that force= s=0A= >>> return traffic thru that SF, well that may not always be the good.=0A= >>>=0A= >>> Some sort of label stack?=0A= >>>=0A= >>> Interested to hear from you..=0A= >>>=0A= >>> Regards.=0A= >>>=0A= >>> Sumandra=0A= >>>=0A= >>>=0A= >>> _______________________________________________=0A= >>> sfc mailing list=0A= >>> sfc@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/sfc=0A= >>>=0A= >=0A= >=0A= =0A= _______________________________________________=0A= sfc mailing list=0A= sfc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sfc=0A= From nobody Fri Feb 27 16:30: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 4937C1A1AA1 for ; Fri, 27 Feb 2015 16:30:57 -0800 (PST) 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 uUE8BPcnGp4o for ; Fri, 27 Feb 2015 16:30:55 -0800 (PST) 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 55A731A1A8F for ; Fri, 27 Feb 2015 16:30:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1077; q=dns/txt; s=iport; t=1425083447; x=1426293047; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=0nhqDQjHDvAISNbumUDUZTXOpuFx5lXMAZUDZ2+nxTw=; b=XL7dJclqfQnlLlZB2pQ0VQUgW0Ot6VVWgUF3Fej6fFSn2+Nt7Y2NVbdl 7BExBUrgLQJ+GPMgOkhiCwFcRLRGzVYBn9/gYBpXBhpIT8jZdfkNt7nTY 9bxhDY1htaqy65ShcI/OFRnn7oMrc+vvYcha+DIbGlI67025+68ZgrROC c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BiBQBgC/FU/4QNJK1bgwJSVQUEwh+FcAKBJE0BAQEBAQF8hBABAQQ6PRICAQg2EDIbAQYDAgQTCYgmCAXWbQEBAQEBAQQBAQEBAQEBG4sShHWEKwWPdoNfhWaBGjmCZo8bI4NubwGBQ38BAQE X-IronPort-AV: E=Sophos;i="5.09,663,1418083200"; d="scan'208";a="399880985" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP; 28 Feb 2015 00:30:46 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t1S0Ukku007809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 28 Feb 2015 00:30:46 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.248]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Fri, 27 Feb 2015 18:30:46 -0600 From: "Reinaldo Penno (repenno)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-penno-sfc-yang-11.txt Thread-Index: AQHQUu2n/C7BQSx4dkuqNnWQvAX+JZ0FFDKA Date: Sat, 28 Feb 2015 00:30:45 +0000 Message-ID: References: <20150228002942.13121.52348.idtracker@ietfa.amsl.com> In-Reply-To: <20150228002942.13121.52348.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.24.71.56] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [sfc] FW: New Version Notification for draft-penno-sfc-yang-11.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: Sat, 28 Feb 2015 00:30:57 -0000 On 2/27/15, 4:29 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-penno-sfc-yang-11.txt >has been successfully submitted by Reinaldo Penno and posted to the >IETF repository. > >Name: draft-penno-sfc-yang >Revision: 11 >Title: Yang Data Model for Service Function Chaining >Document date: 2015-02-27 >Group: Individual Submission >Pages: 56 >URL: =20 >http://www.ietf.org/internet-drafts/draft-penno-sfc-yang-11.txt >Status: https://datatracker.ietf.org/doc/draft-penno-sfc-yang/ >Htmlized: http://tools.ietf.org/html/draft-penno-sfc-yang-11 >Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-penno-sfc-yang-11 > >Abstract: > This document defines a YANG data model that can be used to configure > and manage Service Function Chains. > > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Fri Feb 27 16:37: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 EF75B1A1AB2 for ; Fri, 27 Feb 2015 16:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 fuKiQ7dsh3Pw for ; Fri, 27 Feb 2015 16:37:09 -0800 (PST) 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 A21EC1A1AA1 for ; Fri, 27 Feb 2015 16:37:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 8C74224757E; Fri, 27 Feb 2015 16:37:09 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [50.95.128.180]) (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 CA6E924056D; Fri, 27 Feb 2015 16:37:08 -0800 (PST) Message-ID: <54F10D98.7010008@joelhalpern.com> Date: Fri, 27 Feb 2015 19:36:40 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sumandra Majee , Dave Dolson , "Reinaldo Penno (repenno)" , "sfc@ietf.org" References: <1424999534752.97011@F5.com> <54EFC6C5.5030805@joelhalpern.com> <54EFD116.2000707@joelhalpern.com>, <1425081744012.6062@F5.com> In-Reply-To: <1425081744012.6062@F5.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] Support Bidirection/Symmetric flow X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 00:37:12 -0000 Sumandra, I am not sure what you are asking for at this point. The SFC working group is not standardizing the control channels between policy or control entities and the SF / SFF / classifier components. The cases you seem to be talking about do not seem to need signaling in the data plane across the infrastructure. They can be addressed quite well by various combinations of local communication to the local SFF and control signaling to the entities which set up the rules. And that is why we have pointed at several different drafts. Yours, Joel On 2/27/15 7:02 PM, Sumandra Majee wrote: >>> Look also at section 3.2.2.1 in draft-homma-sfc-forwarding-methods-analysis-01 > Thanks for pointing to this draft. Yes, many of these methods are already in use when a single vendor distribute/clusterize their own devices. The problem I am talking about can be approximated via Sub Domain concept (as in the draft), but that does not automatically means a single processing point. > >>> So the geographically distributed classifiers instead select a data center, >>> using stateless decision-making, and the required coordination is local, by re-classifying >>> both directions of traffic using a single instance of classifier. > > This problem does not need to span multiple data center. A cluster of ADC, classifiers etc. are required to handle current load multiple TB layer 7 processing load today in some to South East Asian countries. An ability to do signalling would clean up the network design. Not all customers are very willing or fond of creating tunnels (especially if those need to be setup manually). > ________________________________________ > From: Dave Dolson > Sent: Friday, February 27, 2015 9:34 AM > To: Joel M. Halpern; Sumandra Majee; Reinaldo Penno (repenno); sfc@ietf.org > Subject: RE: [sfc] Support Bidirection/Symmetric flow > > Look also at section 3.2.2.1 in draft-homma-sfc-forwarding-methods-analysis-01 > https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-analysis-01#section-3.2.2.1 > > This shows a network architecture that allows asymmetric traffic arriving > at a large network to be brought to an "SF Domain Proxy" having > a single classifier responsible for using bidirectional chains properly. > > The problem we faced was how to arrange for geographically distributed classifiers > to be coordinated well enough to select the correct chains. > > So the geographically distributed classifiers instead select a data center, > using stateless decision-making, and the required coordination is local, by re-classifying > both directions of traffic using a single instance of classifier. > > Then it becomes reasonable to talk about an SF signaling a single local classifier > to change the chain for a flow. > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Thursday, February 26, 2015 9:06 PM > To: Sumandra Majee; Reinaldo Penno (repenno); sfc@ietf.org > Subject: Re: [sfc] Support Bidirection/Symmetric flow > > Look at the long-lived flows draft. We talk about exactly that case, > and propose an approach to solving it. > For local optimization, there is also the bypass draft. > > Yours, > Joel > > On 2/26/15 8:52 PM, Sumandra Majee wrote: >>>> I am a little confused by your statement that these are "run time >>>> decisions" with an apparent implication that they are decisions made by >>>> the forwarding infrastructure. Such an approach is permitted, but not >>>> req uired, by the architecture and the protocol proposal. >> >> ADC, FW and other types stateful devices has a fair bit of local rules and >> states. These equipments and rulesets etc. will be there as NSH is >> introduced in the network. For example the local rule may decide that this >> particular dst ip doesnąt need to be TCP spliced. Since it doesnąt do any >> transformation it might want to bypass on the reverse part of flow. When I >> say local rule, it could be configuration (static) or generated >> dynamically from analytics. Both mechanisms are implemented on platforms >> that I work on. Since it is flow by flow local decision the most reliable >> way to alter the forwarding path is in band. >> >> >> >> >> On 2/26/15, 5:22 PM, "Joel M. Halpern" wrote: >> >>> I am a little confused by your statement that these are "run time >>> decisions" with an apparent implication that they are decisions made by >>> the forwarding infrastructure. Such an approach is permitted, but not >>> req uired, by the architecture and the protocol proposal. >>> >>> So the question of what mechanisms are needed to enable symmetry when >>> required depends upon both what we need. For example, even the use >>> cases you have suggested are ones where the control mechanisms setting >>> up the paths will know whether they need to be symmetric. So they can >>> instantiate suitable state. >>> Now, if an implementation and deployment wants to allow data plane >>> decision, then that implementation needs to come up with a way to meet >>> the symmetry requirements. It has been suggested by some of those who >>> wish to deploy that way that the existing protocol hooks are sufficient >>> for that. >>> >>> Yours, >>> Joel >>> >>> On 2/26/15 8:12 PM, Sumandra Majee wrote: >>>> Reinaldo, >>>> >>>> >>>> The cache example is the easy one. As you noted it could be done by >>>> grouping, a cache must *always* see both side of the traffic. >>>> >>>> >>>> If I replace cache with ADC or other stateful flow aware devices then >>>> the always part is not true. Flow1 can be deemed as must be >>>> bidirectional and then flow2 can be assymetric, which essentially says >>>> bypass me. >>>> >>>> >>>> SF1 SF2 ADC >>>> | | | >>>> IN: Classifier <> SFF1 <> SFF2 <> SFF3 < SFF4-RTR< >>>> >>>> Building symmetric and/or hybrid path in dynamic ways is a great tool >>>> and I am hoping this is one area where NSH can help immensely. >>>> >>>> Because these are run time decision an inband signalling is the reliable >>>> way. >>>> >>>> Regards. >>>> >>>> Sumandra >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> *From:* Reinaldo Penno (repenno) >>>> *Sent:* Thursday, February 26, 2015 2:40 PM >>>> *To:* Sumandra Majee; sfc@ietf.org >>>> *Subject:* Re: [sfc] Support Bidirection/Symmetric flow >>>> It is my impression that if you rewrite the picture like this it might >>>> help working out the solution >>>> >>>> SF1 SF2 SFF3 >>>> | | | >>>> IN: Classifier <> SFF1 <> SFF2 <> Cache(*)/SFF < RTR< >>>> >>>> Since cache is actually directing (steering packets) it becomes a SFF. >>>> If you adapt the reverse picture Cache/SFF will make sure reverse flows >>>> to the same SF3. >>>> >>>> This is the whole Service Function Groups concept. >>>> >>>> thanks, >>>> >>>> >>>> >>>> From: Sumandra Majee > >>>> Date: Thursday, February 26, 2015 at 2:10 PM >>>> To: "sfc@ietf.org " >>> > >>>> Subject: [sfc] Support Bidirection/Symmetric flow >>>> >>>> Hello, >>>> >>>> The SFC architecture document says (correctly) that ingress path and >>>> egress path of a given flow or work unit could symmetric, asymmetric or >>>> hybrid. However a front/back (end) classifier is not always the correct >>>> place to derive this information. Some cases are simple, >>>> >>>> IN: Classifier <> SF1 <> SF2 <> Cache(*) < >SF3 < RTR< >>>> OUT: Classifier -> SF3 --> Cache <<> RTR >>>> >>>> The actual chains are not laid out like that, but for this discussion >>>> lets stick with the above figure. In this case a device like cache >>>> detects that both direction of flow must flow thru the cache (cache >>>> miss). >>>> >>>> Now lets replace the cache with a modern ADC device. These devices can >>>> and will make the decision for each flow. For optimal operation it is >>>> best to signal the upstream node that flow(X) must come back to this SF >>>> or should bypass this SF. >>>> >>>> How can we do this signaling? Metadata is an option, but it is a generic >>>> use case where the format of this metadata then should be standardized. >>>> The responsible SF can demand the return PATH to be some 221 that forces >>>> return traffic thru that SF, well that may not always be the good. >>>> >>>> Some sort of label stack? >>>> >>>> Interested to hear from you.. >>>> >>>> Regards. >>>> >>>> Sumandra >>>> >>>> >>>> _______________________________________________ >>>> 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 Sat Feb 28 01:51:49 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 CF1531A03FF for ; Sat, 28 Feb 2015 01:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sQZjZV9jp9r for ; Sat, 28 Feb 2015 01:51:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5374D1A039A for ; Sat, 28 Feb 2015 01:51:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BPS40947; Sat, 28 Feb 2015 09:51:40 +0000 (GMT) Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 28 Feb 2015 09:51:38 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.115]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Sat, 28 Feb 2015 17:51:36 +0800 From: Xuxiaohu To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: WG call for adoption of draft-quinn-sfc-nsh Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50F0Kkg Date: Sat, 28 Feb 2015 09:51:34 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830EBDD@NKGEML512-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.55] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830EBDDNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 09:51:47 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830EBDDNKGEML512MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support. By the way, I hope the NSH could be capable of: 1) containing the service c= hain/path info only; 2) containing the metadata only ;3) containing both se= rvice chain/path info and the metadata. Otherwise, we may need to design a = separate header for containing the metadata in the case where the service c= hain/path info has been embodied by other means than the NSH itself. In thi= s way, it's aligned with the following statement in the SFC architecture dr= aft: "4.3.1. Transport Derived SFF Service function forwarding, as described above, directly depends upon the use of the service path information contained in the SFC encapsulation. However, existing implementations may not be able to act on the SFC encapsulation. These platforms may opt to use existing transport information if it can be arranged to provide explicit service path information. This results in the same architectural behavior and meaning for service function forwarding and service function paths. It is the responsibility of the control components to ensure that the transport path executed in such a case is fully aligned with the path identified by the information in the service chaining encapsulation. " Xiaohu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Thursday, February 26, 2015 8:47 PM To: sfc@ietf.org Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh Greetings WG: The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft= -quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc= -sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined = the NSH document so that the WG can focus on a single encapsulation documen= t going forward. This new version of NSH includes an open items section bas= ed on discussion between co-authors and members of the list. The WG will wo= rk through this list (and any other issues that need to be added) over the = next weeks. We appreciate and recognize the hard work of both the NSH and S= CH authors in pushing the SFC encapsulation work forward. With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n= sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3= /12/2015. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Jim & Thomas --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830EBDDNKGEML512MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Support.

     = ;

    By the way= , I hope the NSH could be capable of: 1) containing the service chain/path = info only; 2) containing the metadata only ;3) containing both service chain/path info and the metadata. Otherwise, we may need to d= esign a separate header for containing the metadata in the case where the s= ervice chain/path info has been embodied by other means than the NSH itself= . In this way, it’s aligned with the following statement in the SFC architecture draft:

     = ;

    “4.3.1.  Transport Derived SFF

     

     

       Service functio= n forwarding, as described above, directly depends

       upon the use of= the service path information contained in the SFC

       encapsulation.&= nbsp; However, existing implementations may not be able to

       act on the SFC = encapsulation.  These platforms may opt to use

       existing transp= ort information if it can be arranged to provide

       explicit servic= e path information.

     

       This results in= the same architectural behavior and meaning for

       service functio= n forwarding and service function paths.  It is the<= /p>

       responsibility = of the control components to ensure that the transport

       path executed i= n such a case is fully aligned with the path

       identified by t= he information in the service chaining encapsulation.

     

    ”

     = ;

    Xiaohu

     = ;

    From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
    Sent: Thursday, February 26, 2015 8:47 PM
    To: sfc@ietf.org
    Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh

     

    Greetings WG:

    &nbs= p;

    The document draft-quinn-sfc-nsh-07 (https://datatracker.= ietf.org/doc/draft-quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc-sch-03 (http://datatracker.iet= f.org/doc/draft-zhang-sfc-sch/) have joined the NSH document so that th= e WG can focus on a single encapsulation document going forward. This new version of NSH includes an open items = section based on discussion between co-authors and members of the list.= The WG will work through this list (and any other issues that need to be a= dded) over the next weeks. We appreciate and recognize the hard work of both the NSH and SCH authors in pushing the= SFC encapsulation work forward.

    &nbs= p;

    With that said, the chairs are calling for WG a= doption of draft-quinn-sfc-nsh-07 as a WG document. The call for adoption w= ill run for 2 weeks ending 3/12/2015.

    &nbs= p;

    Please note that this is a call for adoption, and not a las= t call for content of the document. Adopting a WG document simply means tha= t the WG will focus its efforts on that particular draft going forward, and use that document for resolving open i= ssues and documenting the WG’s decisions.=

     

    Please indicate whether you support adoption for not, and i= f not why. Issues you have with the current document itself can also be rai= sed, but they should be raised in the context of what should be changed in the document going forward, rather th= an a pre-condition for adoption. 

     

    Finally, now is also a good time to poll for knowledge of a= ny IPR that applies to this draft, in line with the IPR disclosure obligati= ons for WG participants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document aut= hor please respond to this email (to the chairs) whether or not you are awa= re of any relevant IPR.

     

    Jim & Thomas

    --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830EBDDNKGEML512MBSchi_-- From nobody Sat Feb 28 06:42: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 1B37E1A1BC9 for ; Sat, 28 Feb 2015 06:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 2GO24xv-RGYr for ; Sat, 28 Feb 2015 06:42:08 -0800 (PST) Received: from mxe02.gs.com (mxe02.gs.com [199.99.47.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3D81A1BCB for ; Sat, 28 Feb 2015 06:42:07 -0800 (PST) Received: from pps.filterd (gsppabdp01sd.idz.gs.com [127.0.0.1]) by gsppabdp01sd.idz.gs.com (8.14.5/8.14.5) with SMTP id t1SEeNHo015266; Sat, 28 Feb 2015 09:41:35 -0500 Received: from gsppacdp03nd.inz.gs.com ([10.205.68.208]) by gsppabdp01sd.idz.gs.com with ESMTP id 1su35v9vr2-1; Sat, 28 Feb 2015 09:41:35 -0500 Received: from pps.filterd (gsppacdp03nd.inz.gs.com [127.0.0.1]) by gsppacdp03nd.inz.gs.com (8.14.5/8.14.5) with SMTP id t1SEbLZo030864; Sat, 28 Feb 2015 09:41:40 -0500 Received: from gshccdp04ex.firmwide.corp.gs.com (gshccdp04ex.firmwide.corp.gs.com [10.135.172.74]) by gsppacdp03nd.inz.gs.com with ESMTP id 1sue7v073h-1; Sat, 28 Feb 2015 09:41:39 -0500 Received: from GSCMAMP19EX.firmwide.corp.gs.com ([139.172.38.36]) by gshccdp04ex.firmwide.corp.gs.com ([10.135.172.74]) with mapi; Sat, 28 Feb 2015 09:41:40 -0500 From: "Zarny, Myo" To: "'Xuxiaohu'" , "'Jim Guichard (jguichar)'" , "'sfc@ietf.org'" Date: Sat, 28 Feb 2015 09:41:38 -0500 Thread-Topic: WG call for adoption of draft-quinn-sfc-nsh Thread-Index: AQHQUcJRZDObBxbiIUWmIP9lX1xWp50F0KkggABL97A= Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830EBDD@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0830EBDD@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-retentionstamp: Firmwide Content-Type: multipart/alternative; boundary="_000_A3233753A4B65F43BCA1B64DA99A9C23071C76FD42GSCMAMP19EXfi_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-02-28_02:2015-02-27,2015-02-28,1970-01-01 signatures=0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-02-28_02:2015-02-27,2015-02-28,1970-01-01 signatures=0 Archived-At: Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Feb 2015 14:42:12 -0000 --_000_A3233753A4B65F43BCA1B64DA99A9C23071C76FD42GSCMAMP19EXfi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Xiaohu, Currently, the draft certainly supports two of your three scenarios: (1) SF= C path only and (3) SFC path info and metadata. As for the scenario of carrying just the metadata, can you clarify your ask= ? I take that you're not mandating that the base header not contain a servi= ce path header; but rather that the NSH be used to carry just the metadata = only, correct? If it's the latter, the NSH does support your scenario. Yes,= the Service Path Header is a required component of the header. But you can= choose an implementation method to ignore the SP header values (SPID and S= PI). (Implementation methods could range from zeroing the fields out to ins= tructing NSH-aware devices to ignore them; etc.) If that meets your expecta= tions, then, the header supports all three scenarios. Now, to be precise and for full disclosure, all three scenarios are support= ed through MD-Type 2, which the draft currently recommends as a "SHOULD" im= plementation [Section 3.2]. Myo From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Xuxiaohu Sent: 28 February 2015 4:52 AM To: Jim Guichard (jguichar); sfc@ietf.org Subject: Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh Support. By the way, I hope the NSH could be capable of: 1) containing the service c= hain/path info only; 2) containing the metadata only ;3) containing both se= rvice chain/path info and the metadata. Otherwise, we may need to design a = separate header for containing the metadata in the case where the service c= hain/path info has been embodied by other means than the NSH itself. In thi= s way, it's aligned with the following statement in the SFC architecture dr= aft: "4.3.1. Transport Derived SFF Service function forwarding, as described above, directly depends upon the use of the service path information contained in the SFC encapsulation. However, existing implementations may not be able to act on the SFC encapsulation. These platforms may opt to use existing transport information if it can be arranged to provide explicit service path information. This results in the same architectural behavior and meaning for service function forwarding and service function paths. It is the responsibility of the control components to ensure that the transport path executed in such a case is fully aligned with the path identified by the information in the service chaining encapsulation. " Xiaohu From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Thursday, February 26, 2015 8:47 PM To: sfc@ietf.org Subject: [sfc] WG call for adoption of draft-quinn-sfc-nsh Greetings WG: The document draft-quinn-sfc-nsh-07 (https://datatracker.ietf.org/doc/draft= -quinn-sfc-nsh/) has recently been reissued. The authors of draft-zhang-sfc= -sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-sch/) have joined = the NSH document so that the WG can focus on a single encapsulation documen= t going forward. This new version of NSH includes an open items section bas= ed on discussion between co-authors and members of the list. The WG will wo= rk through this list (and any other issues that need to be added) over the = next weeks. We appreciate and recognize the hard work of both the NSH and S= CH authors in pushing the SFC encapsulation work forward. With that said, the chairs are calling for WG adoption of draft-quinn-sfc-n= sh-07 as a WG document. The call for adoption will run for 2 weeks ending 3= /12/2015. Please note that this is a call for adoption, and not a last call for conte= nt of the document. Adopting a WG document simply means that the WG will fo= cus its efforts on that particular draft going forward, and use that docume= nt for resolving open issues and documenting the WG's decisions. Please indicate whether you support adoption for not, and if not why. Issue= s you have with the current document itself can also be raised, but they sh= ould be raised in the context of what should be changed in the document goi= ng forward, rather than a pre-condition for adoption. Finally, now is also a good time to poll for knowledge of any IPR that appl= ies to this draft, in line with the IPR disclosure obligations for WG parti= cipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are l= isted as a document author please respond to this email (to the chairs) whe= ther or not you are aware of any relevant IPR. Jim & Thomas --_000_A3233753A4B65F43BCA1B64DA99A9C23071C76FD42GSCMAMP19EXfi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Xiaohu= ,

     =

    Currently, the draft certainly supports two= of your three scenarios: (1) SFC path only and (3) SFC path info and metad= ata.

     

    As for the scenario of carrying just the= metadata, can you clarify your ask? I take that you’re not mandating= that the base header not contain a service path header; but rather that th= e NSH be used to carry just the metadata only, correct? If it’s the l= atter, the NSH does support your scenario. Yes, the Service Path Header is = a required component of the header. But you can choose an implementation me= thod to ignore the SP header values (SPID and SPI). (Implementation methods= could range from zeroing the fields out to instructing NSH-aware devices t= o ignore them; etc.) If that meets your expectations, then, the header supp= orts all three scenarios.

    =  

    Now, to be precise = and for full disclosure, all three scenarios are supported through MD-Type = 2, which the draft currently recommends as a “SHOULD” implement= ation [Section 3.2].

     

    Myo

     

    <= p class=3DMsoNormal style=3D'margin-left:.5in'>From: sfc [mailto:sfc-bounces@= ietf.org] On Behalf Of Xuxiaohu
    Sent: 28 February 2015 4:5= 2 AM
    To: Jim Guichard (jguichar); sfc@ietf.org
    Subject:= Re: [sfc] WG call for adoption of draft-quinn-sfc-nsh

     

    Support.

     

    By the way, I hope the NSH could be capable of: 1) containing t= he service chain/path info only; 2) containing the metadata only ;3) contai= ning both service chain/path info and the metadata. Otherwise, we may need = to design a separate header for containing the metadata in the case where t= he service chain/path info has been embodied by other means than the NSH it= self. In this way, it’s aligned with the following statement in the S= FC architecture draft:

     =

    “4.3.1.  Transport Derived SFF

     

    &n= bsp;

       Service function forwarding, = as described above, directly depends

     = ;  upon the use of the service path information contained in the SFC

       encapsulation.  However, = existing implementations may not be able to

       act on the SFC encapsulation.  These platforms may op= t to use

       existing transport i= nformation if it can be arranged to provide

       explicit service path information.

     

       This results= in the same architectural behavior and meaning for

       service function forwarding and service function pat= hs.  It is the

       responsib= ility of the control components to ensure that the transport

       path executed in such a case is fully align= ed with the path

       identified b= y the information in the service chaining encapsulation.<= /p>

     

    ”=

     

    Xiaohu

    <= p class=3DMsoNormal style=3D'margin-left:.5in'> 

    From: sfc [mailto:sfc-bounces@= ietf.org] On Behalf Of Jim Guichard (jguichar)
    Sent: T= hursday, February 26, 2015 8:47 PM
    To: sfc@ietf.org
    Subject: [sfc] WG call for adoption of dra= ft-quinn-sfc-nsh

    &nbs= p;

    Greetings WG:

     

    The document draft-quinn-sfc-nsh-07 (https://datatr= acker.ietf.org/doc/draft-quinn-sfc-nsh/) has recently been reissued. Th= e authors of draft-zhang-sfc-sch-03 (http://datatracker.ietf.org/doc/draft-zhang-sfc-s= ch/) have joined the NSH document so that the WG can focus on a single = encapsulation document going forward. This new version of NSH includes an <= b>open items section based on discussion between co-authors and members= of the list. The WG will work through this list (and any other issues that= need to be added) over the next weeks. We appreciate and recognize the har= d work of both the NSH and SCH authors in pushing the SFC encapsulation wor= k forward.

     =

    With that said, the chairs are calling for WG adoption of draft= -quinn-sfc-nsh-07 as a WG document. The call for adoption will run for 2 we= eks ending 3/12/2015.

    &= nbsp;

    Please note that this is a call for adoption, and not a last cal= l for content of the document. Adopting a WG document simply means that the= WG will focus its efforts on that particular draft going forward, and use = that document for resolving open issues and documenting the WG’s deci= sions.<= /p>

     

    Please indicate whether yo= u support adoption for not, and if not why. Issues you have with the curren= t document itself can also be raised, but they should be raised in the cont= ext of what should be changed in the document going forward, rather than a = pre-condition for adoption. 

     <= /span>

    F= inally, now is also a good time to poll for knowledge of any IPR that appli= es to this draft, in line with the IPR disclosure obligations for WG partic= ipants (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are li= sted as a document author please respond to this email (to the chairs) whet= her or not you are aware of any relevant IPR.

     

    Ji= m & Thomas

    = = --_000_A3233753A4B65F43BCA1B64DA99A9C23071C76FD42GSCMAMP19EXfi_--